Farss, your profile did not show an email address. Please email "apitt34356" at "gmail" dot com. thank you in advance.

For those who cannot find it:
farss [AT] optusnet [DOT] com [DOT] au
Bob.

Two tries and both of you seem to use gmail accouts which are bouncing the email because of the attachment being illegal.
Only other way would be for me to put it up on a temp ftp server. My ISP may object, I'll try in a few hours.
Bob.

Bob try this:
You Send it and when you have it there just ost th elink here. FIles stay for 7 days and they are gone but that would give one week for people to get it who want it.

http://s5.yousendit.com/d.aspx?id=3MHHX7S2AD6510FMV7INNFWEXY

Thanks to Filmy for putting me onto this site.

Bob.

Definatly a step in the right Direction.. So Many Talented People around here !

Just downloaded it. Sounds interesting. Thanks farss and filmy!

Ok,

So here is some info - done some more testing and refining. This may help you in the PPro to Vegas and vice versa "project".

In doing a test - and some of this info is redundant if you have read past posts and thread where I talk about the issue - I have gotten an EDL to work in both Vegas *and* Premiere.

First - test project cuts only. Very, very basic and simple at this point. Here is the exact CMX output from PPro.

TITLE: Sequence 01

FCM: DROP FRAME



001  001      B     C        00:00:26:04 00:01:11:09 00:00:00:00 00:00:45:03

* FROM CLIP NAME:  shot1.avi

002  001      B     C        00:05:08:18 00:05:43:00 00:00:45:03 00:01:19:17

* FROM CLIP NAME:  shot2.avi

003  001      B     C        00:15:39:21 00:15:55:04 00:01:19:17 00:01:35:00

* FROM CLIP NAME:  shot3.avi

004  001      B     C        00:19:09:16 00:19:22:13 00:01:35:00 00:01:47:27

* FROM CLIP NAME:  shot4.avi

Now, as is, this CMX EDL will not import into Vegas without issues. My first thought was that Vegas did not understand the "B" element because in my tests it imported the media to the media pool, but not the timeline. But I was wrong avbout that as you will see in a second.

First issue, and the main one, is that Vegas ignores source TC info - which is really bad IMO. I did not really know this until a few weeks ago when it came up in another thread, had I known this I might have figured this issue out a long time ago. In short, Vegas goes off of first frame of each clip on the timeline and sets first frame TC at 00:00:00:00. So if you import the above EDL directly you get Vegas just assuming that, based on zero first frame TC, the first shot starts 26 seconds and 4 frames in. Thing is you get nothing on the video track and audio, in this case, is "empty' because the Vegas assumed TC info is wrong - pulling audio from a place where there is none. However all media will be added to the media pool.

So to start to fix the problems you can add the direct path to the file - so "* FROM CLIP NAME: shot1.avi" would become, for example, : "* FROM CLIP NAME: D:\scene1\shot1.avi". Now - hey - video on the timeline! However Vegas, still mis-reading the Source TC info, does a freeze frame when the shot runs out. And when there is no footage it just puts a freeze frame on the last frame in the media for the length of the shot. So it is not really working yet.

Now the next really big issue - getting the actual timeline to work/look/load correct - well, what I found is that if you redo the Source TC info and zero it out - it works! But there is a mixed issue - Say you take the EDL as is, but only change the Source TC and nothing else. You now will have correct audio but still no video...even after you have located the matierial. So you have to do 2 things for Vegas to "fully" read a CMX EDL -
1> Add the full path to the source material.
2> Recalculate the Sources TC in and and out.

Here is the same CMX EDL, "fixed" for Vegas -

TITLE:   Sequence 01

FCM: DROP FRAME



001  001 B      C     00:00:00:00 00:00:45:02 00:00:00:00 00:00:45:03

* FROM CLIP NAME:  D:\scene1\shot1.avi

002  001 B      C     00:00:00:00 00:00:34:09 00:00:45:03 00:01:19:17

* FROM CLIP NAME:  D:\scene1\shot2.avi

003  001 B      C     00:00:00:00 00:00:15:10 00:01:19:17 00:01:35:00

* FROM CLIP NAME:  D:\scene1\shot3.avi

004  001 B      C     00:00:00:00 00:00:12:21 00:01:35:00 00:01:47:27

* FROM CLIP NAME:  D:\scene1\shot4.avi

And this will also re-import into PPro just fine. ..unlike Vegas, PPro seems to able to deal with TC info or without TC info on the source side.

Well - so far so good huh? Being able to come with up some sort of translation script that will input a CMX EDL's 'SrcIn' and 'SrcOut' and recalculate based on zero, and add the full path to the files would do the trick it seems. Keeping in mind I have not tested anything like fade in/out, basic dissolves or split audio tracks yet.

Now going from Vegas to a CMX EDL is a bit tricker. Same basic rules apply hower the export CMX script is limited and has glitches. Here is the exact same project via the CMX export script.

TITLE:   undefined

FCM: NON-DROP FRAME

001  UNKNOWN V      C     00:00:00:00 00:00:45:03 00:00:00:00 00:00:45:03

* FROM CLIP NAME: SHOT1

002  UNKNOWN V      C     00:00:00:00 00:00:34:14 00:00:45:03 00:01:19:17

* FROM CLIP NAME: SHOT2

003  UNKNOWN V      C     00:00:00:00 00:00:15:13 00:01:19:17 00:01:35:00

* FROM CLIP NAME: SHOT3

004  UNKNOWN V      C     00:00:00:00 00:00:12:27 00:01:35:00 00:01:47:27

* FROM CLIP NAME: SHOT4

005  UNKNOWN AA     C     00:00:00:00 00:00:45:03 00:00:00:00 00:00:45:03

* FROM CLIP NAME: SHOT1

006  UNKNOWN AA     C     00:00:00:00 00:00:34:14 00:00:45:03 00:01:19:17

* FROM CLIP NAME: SHOT2

007  UNKNOWN AA     C     00:00:00:00 00:00:15:13 00:01:19:17 00:01:35:00

* FROM CLIP NAME: SHOT3

008  UNKNOWN AA     C     00:00:00:00 00:00:12:27 00:01:35:00 00:01:47:27

* FROM CLIP NAME: SHOT4

This really does nothing in the world of EDL...matter of fact this will not even re-import into Vegas correctly. First thing is that the script only exports in non-drop frame mode even if the project is somehting else. Second the script strips out any reel info so all sources read "UNKOWN". Next the script breaks down each event - video and audio, which is fine but is just adding extra info is some cases. And the two really important things that happen are that it strips off the file extension and removes a space in the "FROM CLIP NAME:" section. I said this before but you can't fault Vegas for an external script, but some of this script is based on limits of Vegas so part of it is a 2 way street. Either way it would take, seemingly, more work to get the export working than the import.

A few other things with all of this - the EDL import does *not* change project settings. Thusly if you import a 24fps EDL into a 30fps or 29.970fps project it does not change the project settings for you. Importing a PAL project into an NTSC project will not change the settings either. On top of that the ruler does not change either. All these things need to be set manually in Vegas, based on the original project being exported. The reverse of this is that when you import an EDL into PPro it will ask you the time base of the EDL - NTSC, PAL or 24 and adjust the project accordingly.

Hope this info is of help. :)

*EDIT* - just was re-reading this and wanted to add a few things to be clear. In this example I used full captures because I just wanted to test. Normally you don't have this - you actually 'edit' something. So the Vegas method of going off the first frame of the captured media makes sense, however not everyone really captures everything is full - say from TC 00:00:00:00 to 00:59:59:29 if you know what I mean. So this adds in another factor - Vegas won't know where the file has been edited and neither will the translation. So say the first cut was edited so it became:

001  001      B     C        00:00:46:04 00:01:11:09 00:00:00:00 00:00:25:03

Remember the "full" shot would be this:

001  001      B     C        00:00:26:04 00:01:11:09 00:00:00:00 00:00:45:03

So I have cut out the first 20 seconds. But how would Vegas know this? If you time shift based on Zero for Vegas first frame it would become simply:

001  001      B     C        00:00:00:00 00:00:25:03 00:00:00:00 00:00:25:03

And that would be wrong. So the question now would be how to tell whatever translation program/script what the first frame of the media "really' is. If Vegas kept TC info this would be no problem, but it doesn't so it is. And a CMX EDL does not tell what first frame of media is - what it was meant for was doing an online from the source (tape) material. Pop in tape/reel 001 in this case and capture 00:00:46:04 to 00:01:11:09 and all will be well. But pop in a file that a program just takes as 0:00:00:00 to 00:00:45:02 and all bets are off. FWIW Premiere will read the EDL and also the media files TC info and rebuild the project fine. So I am not so sure this could be done external to the programs - it would have to be done somehow inside the programs because it would need to be able to read TC from the file and make translations based on that. (or maybe from the batch capture files if they exist)

Why doesn't Vegas keep the actual media TC and use it?
Simple, they broke the original paradigm. I can drop just about anything onto the Vegas TL but unless it was captured from tape or has embedded source TC then there'll be no TC anyways. Hence Vegas can only work with source file TC and not tape TC. As you rightly pointed out only batch capture knows where that came from. Probably that data is stored internally within the Vegas project and is sent out as part of the XML export. I haven't looked at that as XML is still an alien language to me.
However one could ignore that issue to some extent, so long as you get the project and the source files all on a disk you don't really need the tape TC as you don't need to recapture. Well that's unless the PP EDL defines itself that way then we're kind of dead in the water I think.
Bob.

>>>I can drop just about anything onto the Vegas TL but unless it was captured from tape or has embedded source TC then there'll be no TC anyways.<<<

Not really - Vegas won't read TC info in files even if it is embedded because Vegas looks in a different place for embedded TC info. This means it only reads TC from Mini-DV captured files captured in VidCap. One exception I have found is that if you capture with SCLive, Vegas will read the TC info, as will Premiere. SCLive is one of the few (only?) programs that actually embeds TC info that is cross NLE compatable. Vegas has another issue as well with all of this - it only seems to read TC info from DV files - as in Mini-DV files. I tried some off line, low rez, AVI files that had TC in them and Premiere reads it fine, Avid reads it fine, SCLive reads it fine - Vegas comes up with nothing. Nor was there any option to "recapture" that media which leads me to think the option is only available with mini-dv captured files as far as Vegas goes, plus it is clear that Vegas does not do "offline/online". (Perhaps this issue is 'resolved' with the next version of Vegas with HDV/HD editing and a need to "offline" edit?)

On the XML side - as a test I tried to convert an EDL to XML format and bring it into Vegas. Vegas would not read it, said it was an unknown file format. I admit I am not up with the XML concept other than Vegas claims to support it.

>>>so long as you get the project and the source files all on a disk you don't really need the tape TC as you don't need to recapture. Well that's unless the PP EDL defines itself that way then we're kind of dead in the water I think.<<<

It isn't so much the source/tape TC that is the issue - it is the way Vegas *ignores* the info and makes its own rules that is the issue. Even if all the media is on the disk and you never are going back to the source tapes there needs to be some way of knowing what the cut is based on and Premiere outputs a real CMX EDL. SrcIn and SrcOut are normally defined by the source materials in and out points, based on TC and on tape numbers. That just is and doesn't have to do with Premiere. That part is a "standard". But I guess to get around this you can do this:

In Premiere
1. Save your project with a new name, such as "Zero TC [PROJECT NAME]"
2. Highlight one clip at a time in the bin.
3. From the "file" drop down menu pick "Timecode" and re-set the real TC with "00:00:00:00". Click ok. Do the next file.
4. Export the EDL.

Problem is you have to manually do this for every piece of media, there is not "reset all TC to zero" option. But it works with a bit less effort on the filp side - by doing it this way you only have to manually edit the EDL with the direct path to the media.

And for those who really wonder why there might be a need to do this - several reasons. For me it would to use Vegas as a finishing tool, working with original footage rather than having to do a render first. (or frame serve, which I have done) I love the audio tools in Vegas so I would much rather do the final audio in Vegas. I shouldn't need more than 4 audio tracks to start off with anyway - these would be production tracks anyway. On the video side if I needed to build anything complex I would use After Effects and do a render prior to going to Vegas. (Although saying all of this perhaps the whole HDV thing will render all of the null and void - I have no clue how HDV footage with the cineform in between would work between Premiere and Vegas. The media part seems to work fine, it is the EDL/project/TC part I am not sure about)

*EDIT - some spelling and some clarifications.

So the CMX EDL is obviously based on the old linear editing paradigm, makes sense. I can possibly see why Vegas didn't continue that, how would it cope with media that doesn't have TC such as VHS, WMV etc.
But to the issue at hand. Let's see if I get this right. On a CMX EDL that PP is going to create assuming a tape that starts with TC of 1:00:00:00 and I have a clip that starts 30 seconds in and ends at 60 seconds Vegas is going to read those numbers as 1:00:30:00 as the in point and unless the file is that long fail or even if it is get it horribly wrong because it's using the time into the file NOT the TC it reads from the file, right.

If that's right there MIGHT be a way around this. So long as you know the original tapes start TC you could easily subtract that value during conversion. Of course that'll fail if the captured file isn't a full clone of the tape.
So what we might need to be able to do is read the real source TC from the file(s) to get the offsets. That'll probably work except I don't have a clue how to read TC from an AVI file and secondly the conversion utility would need access to the files.
The reason I'm probably having no problems with what I'm doing is they're only stills so there's no source TC to deal with, the PP EDLs list the ins and outs as all zeroes.
Bob.

Lets see if I can answer your questions -

1> Vegas seems to "ignore" TC info in the long run, even if it is from footage captured with VidCap. In a way this makes sense because in Vegas "all footage is the same" and I mean in that no matter what the source is, once it is on the timeline Vegas sees every clips first frame as a time code of 00:00:00:00. So VHS, Mini-DV, HD, QT, WMV, Divx and whatever else you toss on the timeline all has the "same" TC so to speak. One place I see TC info being used timeline wise is in the "recapture" option and it only works with minidv material that was captured with VidCap.

2> If the EDL incoming shows a SrcIn of 01:00:30:00 you are correct that Vegas will take that to mean the first frame comes one hour and 30 seconds into that piece of media because Vegas is just assuming the TC on that media's first frame is 00:00:00:00.

3> If you capture in VidCap, or SCLive, and edit in Vegas you will have TC info on the CMX EDL export from Vegas, and you will have tape/reel numbers as well. However I already mentioned that the CMX export script for Vegas is not really that great - all that I said before still holds true. But the idea is more to get a PPro project to open in Vegas, although being able to extract something usable from Vegas that you could use in PPro would be nice. (you know maybe that Vegas > AE plug-in would work in PPro...hmmmm)

4> Yes if someone has captured the entire tape, a tape from any source, you could manually set the TC to be 00:00:00:00 and all would be well so to speak. But again, most people who would use an EDL would log tapes and do selects. They need the logs and the EDLs for various reasons - and they need to call back the original source. So, as I mentioned, an
"easy" way would be to save a copy of the PPro project and zero out every piece of media's TC and than export. For a long project, or even a short one with many cuts (music video), this would be a bit of a nightmare.

5> You can read TC info from files in PPro. So you would have acces to the file info from within Premiere. Another way is to drop the files into SCLive. You can set it up to read TC in and out. You can even export a CMX EDL - but it wouldn't work too well for import.

TITLE: Sclive-Project

FCM: DROP FRAME

001  @IMPORT   AA/V  C         00:00:26:04  00:01:11:07  01:00:00:00  01:00:45:02

002  @IMPORT   AA/V  C         00:05:08:18  00:05:42:29  01:00:45:02  01:01:19:16

003  @IMPORT   AA/V  C         00:15:39:21  00:15:55:03  01:01:32:13  01:01:47:26

004  @IMPORT   AA/V  C         00:19:09:16  00:19:22:12  01:01:19:16  01:01:32:13

But it at least shows orginal TC in and out. But there is a much nicer way to get info out - and maybe this would be helpful somehow. You can set up SCLive to show certian information and you can export it as a TXT file with that information. So you can end up with something like this:

timecode-in	timecode-out		name	              duration

0;00;26;04	0;01;11;07	D:\scene1\shot1.avi	0;00;45;03		

0;05;08;18      0;05;42;29	D:\scene1\shot2.avi	0;00;34;12		

0;15;39;21	0;15;55;03	D:\scene1\shot3.avi	0;00;15;13		

0;19;09;16	0;19;22;12	D:\scene1\shot4.avi	0;00;12;27	

EDIT - some formating and spelling

Filmy,
I'm thinking you and me aren't quite on the same wavelength here. I'm not using the Export EDL script!
I'm doing a File>Save As EDL.
This gives you way more data than the script does, it does include the full path to the file which includes the tape name if you captured and didn't rename the file.
I'm still not certain about the source TC issue as the only tape I have captured on the system has source TC of 0:00:00:00. The EDL I'm seeing also includes fade in and out time etc.
Bob.

>>>I'm thinking you and me aren't quite on the same wavelength here. I'm not using the Export EDL script!<<<

I know that. I am talking about in premiere pro you only have one option - a CMX EDL. In Vegas you have either an internal TXT.EDL or the CMX script. For going *from* Vegas *to* another NLE that TXT.EDL is useless. The CMX script is supposed to output a "standard" CMX EDL that can read in other programs, but it doesn't do a very good job.

The whole topic has come up before about being able to get a project done in another NLE into Vegas, or getting a Vegas project out to another NLE. So what I am mostly talking about here is getting a PPro project into Vegas and the "easiest" way to do this is to export a CMX EDL and import that into Vegas. The other way would be to either come up with a plug-in for premiere that exported to the internal Vegas TXT.EDL or come up with an external program that either converted a CMX EDL to the Vegas EDL *or* a PPro project file to a Vegas project file or Vegas TXT.EDL.

OK,
now at least we're on the same wavelength. Why is the TXT EDL useless?
I realise that probably nothing apart from Vegas can read it but the crucial question is does it contain all the data needed to build something that can be read elsewhere? Or do the limitations regarding source TC apply to it as well?
There does seem to be a fair amount of stuff in the TXT .EDL file. If everything that's needed is in there then reformating it should be fairly easy.

Same goes the other way around or do we hit the same problem again of the source tape TC?
Bob.

The Vegas TXT EDL isnt usless to Vegas, it is just not a standard EDL in the sense that you can't really use it in other apllications. When we were doing mass mailing for upcoming releases I had to import a txt db into a format - I think we moved everything over to Filemaker. But I know one could "map" entrys. I am wondering if we could get something like this -

Vegas EDL format contains - and this will be jumbled a bit -

"ID";"Track";"StartTime";"Length";"PlayRate";"Locked";"Normalized";"StretchMethod";"Looped";"OnRuler";"MediaType";"FileName"
;"Stream";"StreamStart";"StreamLength";"FadeTimeIn";"FadeTimeOut";"SustainGain";"CurveIn";"GainIn";"CurveOut";"GainOut";"Layer";"Color";
"CurveInR";"CurveOutR":"PlayPitch";"LockPitch"

The things we would need to "map" would be from any CMX EDL - Premiere output or not.
So lets do a quickie - first part of any EDL

TITLE: Sequence 01

FCM: DROP FRAME



001  001      AA/V     C        00:00:26:04 00:01:11:09 00:00:00:00 00:00:45:03

* FROM CLIP NAME:  shot1.avi

In a Vegas TXT EDL we need to "first" worry about "translating" or mapping:
"ID";"Track";"StartTime";"Length"

Than , I think, nothing is a direct translation until:
"MediaType";"FileName";"Stream";"StreamStart";"StreamLength"

But keep in mind this is only based on simple cuts only - a good place to start at least. Get to things like fades and such later (?).

Near as I can figure out
"ID" = Event number or "001" "002" "003" and so on on the CMX EDL.

"Track" = Video and audio. As near as I can figure "1" would be a Video track 1 and "0" is track 1 on the audio side. I am not sure because there doesn't seem to be a Video track "0" *or* an audio track "0" as you look at the gui. Looking at a Vegas timeline everything is just numbered from the top down starting with "1". Other NLE's take a visual cue from tape with buttons and labels such as V1, V2 and A1, A2. My thought is that when used in connection with "MediaType" it is much the same thing - "VIDEO" "1", "AUDIO" "0"

"StartTime" = RecIn on the CMX EDL. (Vegas noramlly is "0.0000" and CMX EDL is normally "00:00:00:00")

"Length" = RecOut on the CMX EDL. One thing I notice is that in the Vegas TXT EDL audio and video events are always a bit off because Vegas treats them as individual events. I do not know how much this matters in the grand scheme of things. Example is a "captured at the same time" "locked" picture with audio. in the Vegas TXT EDL Video ends at "45145.0097" and the sync audio ends at "45145.1250". On the CMX EDL this time is "00:00:45:03" for both.

"MediaType" = "V" , "A", "AA", "B" on a CMX EDL. But going back to what I said above for the Vegas TXT EDL "track" Vegas uses two entrys where a CMX EDL uses only one. V = Video, A = Audio, AA = Stereo Audio, B = both Audio and Video. These are tape based concepts - putting "AA" into Vegas would duplicate the audio on Audio track 0 and Audio track 1. Vegas takes in either mono or stereo audio onto one track, so does Premiere. Going to an online with the CMX EDL would put "A" onto the left channel and "AA" would be recording to both Left and Right channel. To define it a bit more you can also have A1, A2, A3, A4 in a CMX EDL. Keeping in mind a literal tape translation is being done and the CMX EDL just figures these are all mono events. For our use however they are either stereo or mono events placed on one audio track. Thusly I think:
Audio/Video = "MediaType";"Track"
V = VIDEO 1
A = AUDIO 0
A1 = AUDIO 0
A2 = AUDIO 1
A3 = AUDIO 2
A4 = AUDIO 3
AA = AUDIO 0 / AUDIO 1 (Duplicated audio)

"FileName" = something added as a note for NLE's but this would be the "* FROM CLIP NAME: shot1.avi" note. One would need to "locate" the full path to the media and add it to the translation because it is not output to a CMX EDL exported in Premiere. All I know is that if you import a CMX EDL into Vegas and it does not have the full path of the media no video imports. I do not know if the same result happens if you leave off the full path in a Vegas TXT EDL.

"Stream" = Not sure if there is any direct relation. I know the same media I used in my testing all has "0" as the stream. Could mean "avi" as all audio in my test came from the AVI file, could mean it is a DV based project and the media is all DV based, could be the "master stream" of the media. I dunno - but should be clarified by someone in the know.

"StreamStart" = SrcIn

"StreamLength" = SrcOut

The above two I think are maybe the most important things in this entire equation. The problem has already been explained above so I won't waste space saying it all again. Either Vegas has to start reading TC info from other files, We need to re-set all media TC to "00:00:00:00" in Premiere before we export, or the translation from premiere to vegas has to co-exist with some sort of script that will somehow do this, more or less in this order:
1> Read the CMX EDL.
2> Import media to the Vegas media bins
3> Change the "default" 00:00:00:00 TC that Vegas is reading to whatever value the CMX EDL has in the SrcIn and SrcOut. In other words - one can manually do this by right clicking on a piece of media in the media pool > select "properties" > timecode > use custom timecode. So if a script can be made that will read a CMX EDL's SrcIn value and put that value in the "use custom timecode" space we are partly on our way.
3> *NOW* after doing the TC change to all media, build the timeline.

It has to be done in this order because it becomes pointless if you import media, build a timeline that is wrong and than go in and change media TC. Doing that and you may as well just start from scratch.

Now the other entries in the Vegas TXT EDL I don't think would come from Premiere - for sure not from any CMX EDL. Ok - some would, fade in, fade out, basic dissolve. but for the test the only other ones that might have to be set at a default would be:
"PlayRate" = 1.000000 for a 1:1 transfer - no slo mo, no fast motion. This based on project settings - which I don't really see reflected in the Vegas TXT EDL anyway.

"Looped" = TRUE would just tell the video and audio to play normal and "loop" past the last frame. If this is set at FALSE you end up with a freeze frame at the end of the media. For the most part this may not matter anyway as long as all the cuts are translated fine.

Filmy,
thanks for all this info, don't quite have the time to fully digest it at the moment but I sure get the gist of the problem! I'm going to probably come back to this post NAB, I'm trying to shut down on work just to give myself time to plan out the NAB thing and follow on hols.

One thing you'd mentioned and struck me as well, Vegas has no media type "B" which explains a lot of my grief with Vegas, it's got no way of knowing there's anything special about the audio track coming off a tape but Premiere sure does, just try unlocking A'V sync in P and you'll see you've got to jump through a few hoops and no matter where that audio track ends up on the T/L you can lock it back to it's vision and it stays locked.

Interesting aside, one client told me last week their client had stuffed up a big edit in FCP and they had to make it right in PP, client really wanted them to load the FCP EDL into PP which they could have done but the editor just rebuilt the project in PP, much quicker and less error prone, client was blown away by how much easier PP was to use than FCP.
Bob.

hey guys,

i'm a disgruntled pprov1.5 user poking around looking for alternatives.
found your thread because i've heard vegas is not so good with edl's
and poor edl capability is one of my gripes with ppro. just wanted to
warn you about a couple of things.

ppro has some serious issues with edl's and timecode in general.
one thing to be aware of is that ppro bases its edl's on the project
settings, not the embedded timecode in a file. if you have a df clip
in an ndf timeline, the edl you output will show the clip as being ndf.
this has played havoc with some of my work. there are other things
but it would be more efficient for you to do a search of the adobe site's
ppro forum for 'edl' and 'timecode.' just don't be surprised if you get
this all working finally and on closer inspection find that the clips
are on the timeline, are the right length, but are out of sync. this could
be due to errors in ppro's handling of timecode. that would mean you
need to code a workaround and then remove the workaround if they
ever fix ppro. lot of extra work for you.

i think it's great that you're doing what you're doing. just wanted to
warn of some possible pitfalls. also wondering a little how come you
guys have to do this and why the developers aren't doing it. on the
other hand, if you can get this kind of thing really working, it'd
convince me to switch to vegas. as a linux user i really like seeing
the community involvement here. and i love the scripting thing.

just downloaded the demo for vegas and will try it out in the next
couple of weeks.

BabaG

Gee I feel glad I mostly work with PAL.

that helps. there are huge issues with 24p as well; in both the actual handling
of the pulldown, and the handling of timecode with it.

Never tried to work with 24p but I know lots here do and I've never heard anyone complain about how Vegas handles it.
Unless of course you mean for film matchback and that's another whole world of pain from what I hear in anything other than Avids dedicated system.
I think the underlying problem there is that most NLEs these days are time not frame based.

The Drop frame / Non Drop frame issue has been around for ions - it is not an NLE issue. What you say is true - but this is not always the fault of Premiere. An editor is supposed to match the project to the source - so if you bring in DF to a NDF project whose fault is that? Likewise in *any* program you can tell it to set project seetings and have the EDL as DF or NDF - it does not mean your source tapes are either. Before I ever went to NLE I had issues with having a film lab do a transfer of one reel in DF when everything else was NDF. The lab had to redo the telecine on tnat one reel. In the case of PPro and the DF/NDF EDL - read on and I think you will see the issue that is causing this.

The 24p issue is more of a film issue - EDL's have been around before the 24p cameras have been. Match back software has been based on "standard" things - and it is a combination of things...including film edge numbers that are also logged in there own form of EDL. The 2 things are combined and spit out for a negative cut. Obviously, again, if this calculation is all based on, say, Drop Frame, and you have put Non Drop into the project something is going to be off. If you do a search you can find articles about how to use Premiere for film matchback. iIt would also *always* be best to talk to your negative cutter to see what they need and have them give you hard copy of the specs. Make sure the lab gets a copy as well because that is the start of it all.

Now we look at one other issue - that is more of a question. If you are never going back to the source tapes - and it is not a "shot on film/needs to be neg cut" project, is this really an issue? Most NLE's now will gladly mix and match formats and footage. You can take interlaced footage and convert it to progressive. You can take footage shot on video and put it on the timeline with telecine material. You can mix 24p footage and 30p footage and flash and PAL and NTSC - and it all comes out "nice" in a final render. So again why fault any NLE if TC is off somehow compared to source materials TC?

I say go back to the editor. (And before that go to the DP and the lab) It is an editors job to also make sure they know what they have and to set up the project accordingly. If the DP, in the case of video, has shot every thing the exact same in reguards to TC and frame rates that all the editor needs to do is make sure the project matches the footage. In the case of the lab - same thing. Trust me I have done ths - when I was cutting with D/Vision I made sure that the lab got specs for what they had to do. This included the postion of the windows burn, the type of TC, any user bits, where to start the TC and what hour (reel number) to use. Also how to make the dub from 3/4 to VHS - TC on the right channel, between - 6 and - 10 db and so on. The project was set up the same.

Now in reguard to PPro - I admit that Premiere 6.5 (and before) had more robust TC options but since that time and Premiere Pro 1.5 a lot has changed - not just with Premiere but with the industry. When PPro came out it did not include TC support. Enough people complained so it was put back in for version 1.5 - and it was called a "new" feature to boot. (yes, many laughed at that marketing) CMX 3600 is sort of the "standard" EDL anymore...and since tape based finishing is slowly vanishing you can have a product like Vegas come in and sort of throw "old school" things out the window. But the fact is that EDL's are still based around tape and the limitations that the media and hardware had/has. To visually tell if something was drop frame of non drop one needed to only look at the last numbers - ":" meant it was Non Drop and ";" meant it was Drop. But this seems to not be used much anymore in the world of NLE - and perhaps this is what BabaG means - the PPro CMX output just flags all the TC with ":" in the EDL - Drop or Non-Drop the EDL still shows ":" And Vegas CMX export script seems to just keeps everything at ":" as well, even if the Vegas TC filter will show you different...and that is part of my point here as well. Yes I can have a drop frame project in PPro and yes, the project will output a CMX EDL that says "FCM: DROP FRAME" yet the actual TC info in the EDL if set for Non Drop via the ":" (00:00:14:03 should be 00:00:14;03 if it is Drop) So who knows? Either way it would import into a 24p project the same way as a 30p or 29.97 project...and that goes back to my first point. Keep in mind that as far as same rate footage goes TC does not change what is there - it only changes things like EDL's and "run times" and the like. To be clear frame 148,011.000 is still the same frame no matter what the TC might say. My point is that if the material comes in and the project settings are the same as the source material the issues should me minimal.

(For the heck of it - Frame "148,011.000" is 01:22:18;18 at 29.97 Drop frame and 01:22:13:20 at 29.97 Non-Drop. For PAL it is 01:22:18:15 and for 23.976 it is 01:22:13:16. Now if TC was recorded at those rates than that should be what the TC of the project is at...and should also be what the project you import to is set at as well. The EDL is really nothing more than a reflection of what the media is - and what the project is set at. To do a test import a window burned tape and comapare TC settings.)

Rememember in the past it was these little things that allowed a machine to read the EDL and tell what was going on. Now NLE's don't seem to much care about what the EDL says. As I mentioned already Vegas will not change any project settings based on the EDL settings. Premiere will ask you if it is NTSC, PAL or 24p but it isn't going to know things like aspect ratio or if the footage is progressive or interlaced or even the speed of the footage...that is all ifno contained *in* the file...or so rumor has it. Depends on which program you 'ask'. LOL! And here is the issue as I see it - again, EDL's had certian givens - NTSC and PAL. The only real variables were the time code being drop frame or non drop frame. Now we have so many options - and CMX EDL's do not reflect those.

Vegas exported CMX EDL's will not open in EDL Mirror. Again, I think this is more of the script than internal Vegas. But PPro CMX EDL's open fine. More than that it does not change to match what the "FCM" says. But if it has ";" it will reflect that. So, in a way, if you plan on going back to do an online session than these are real issues. They need to be addressed to be sure - but at the root we are talking about getting a PPro project out and into Vegas for more work, or "finishing" and as long as the tape settings match the project settings and the Vegas project settings match all should be fine.

Just a program to look at - I hadn't known this was ported over to Windows now - is PreReader™ . This is sort of the things that I think should be created to get either a PPro project over to Vegas or a CMX EDL over to Vegas. (or vice versa - get that Vegas TXT.EDL into another NLE) And they have other fun things now too - Edlmax24 helps to fix these problems with 24p. And they have EdlMax24 PRO which adds OMF support. Either way - these are the type of tools I would like to see out there for Vegas/Premiere. it is funny because there is a little blurb in there that fits this whole topic here - just replace "Avid" with "Vegas".
Only EDLMAX can generate EDLs for error-free import to Avid sequence, Quantel EditBox/Henry, and Screensound. By specially tailoring the list, EDLMAX can assure loading to these advanced devices. If you need this, you need it bad.

EDIT - formating, Spelling