It has to go by the timecode because I very rarely recapture tapes from the exact same point and usually they match up. Vegas does keep the timecode information, it's listed in the Edit Details window. If you load a veg project that has offline media, the timecode information is still kept in the veg file.

I just tried something different, I tried recapturing the footage by setting the ins and outs myself in the advanced capture tab (The same in and out points as the original capture). I captured the whole clip but it only reaches 99 percent complete in the capture progress window. The same thing happens when I recapture my offline media directly from the veg file...my clips never get 100 percent captured...it stops at 99 percent. It doesn't capture from the point that is specified...it was supposed to start at 00:19:43:01 but instead it started at 00:19:44:27...This is crazy.

Vegas doesn't even care what the clip's timecode is. Vegas references the physical start of the clip. Since you captured 47 seconds before the original clip start you now see this 47 seconds on the timeline. The same thing would happen in reverse if you captured starting after the original timecode in that everything would be shifted back to the left.

Is this really so??? Holy meowmix Batman!! If this is for really true no wonder they have never offered full on EDL support - they couldn't/can't. So you mean that if someone wanted to recreate a timeline but did not have the vidcap file - opting to capture the entire tape - the timeline could never be rebuilt? Ok, logic says it makes sense - but all files have timecode, the timeline can output a window burn with the "original" TC - so logic also says that this info *is* retained. What limited EDL support there is will show timecode, just no tape numbers.

Just walk with me here -

1> Replace footage would just replace the footage. Timecode info be damned.
Correct?
2> Recapture offline footage should re-capture, and place on the timeline, frame matching footage. Based off of the orginal source time code.
Correct?

3> Importing an CMX EDL, I know this is very limited with Vegas, provided footage is in the same folder - that Vegas should rebuild the timeline based on orginal TC of the files. If the file has a different name you get a pop up asking for the file. So logic says to me that even if the file has a different name Vegas will read the files timecode. overly simple example - if I have a file called file "2.avi" and it has timecode from 5 - 40 and the EDL shows "2.avi" "in 6" "OUT 35" and when someone rebuilds they have a file called "tape1.avi" and it contains the entire tape when it asks for "2.avi" I select the replacement file of "tape1.avi". Vegas should be reading the time code in that file and only placing what is between 6 and 35 on the timeline.

Based on what you say - not correct?

See my problem with this is that it makes sense, for example, when bringing in files captured outside of Vegas. The timecode info is placed somewhere other than where Vegas reads it. In *this* case the files would be read based off of length. All files would indicate a start time of 0, even if that is not true and In these cases you can't rebuild/recapture from the timeline, or import a longer file - even if it contains all of the original material - without being off. This also follows your comment of "Vegas references the physical start of the clip".

But if this is also true with footage that *does* have Vegas readable timecode - this would be, IMO, a majorly poor design. And going back to logic - it would seemingly render the whole "recapture offline footage" option useless. However many people are able to re-capture footage with no issues from Vegas - this is based off of timecode.

I understand that you may want Vegas to behave differently than it does in this or some other regard, but if you recapture offilne (or all) DV media, without intervening or changing anything during the recapture process, and, assuming that you captured with our own capture app in the first place, and, you don't drop frames during recapture, everything should line up, you should have a perfect mirror of the original project.

Yes, I can state this. Have done it with recapturing the offline media and it worked fine.

Marco

>>>assuming that you captured with our own capture app in the first place, and, you don't drop frames during recapture, everything should line up, you should have a perfect mirror of the original project.<<<

This is what I thought - but does this mean what Kelly said is not correct?

Vegas doesn't place clips on the timeline based on their timecode. Vegas doesn't even care what the clip's timecode is.

In other words - going back to the original question, if you capture footage - in Vidcap - and you drop that footage into a project, the timecode info is ignored? Or if you re-import footage by any method than it will *only* line up if the first frame is exaclty the same? In other words Vegas ignores all timecode info? (ie - ScLive captures 'readable by Vegas' timecode. So if you capture all footage in ScLive, edit with Vegas - will Vegas rebuild a project? if so than it would be because of the timecode info correct?)

Note - this is for my clarification right now, but it would help the original question as well.

Is it possible that you've changed the project's ruler format from, say, drop to non drop?

Vegas Vidcap always forces footage to be drop frame, even if the camera was set to non drop. It's a major confidence shaker when I have to tell people this-obviously they set the camera to non-drop 'cause they wanted non-drop.

It sure sounds to me like Vegas is just counting out the frames from the start of the file. Another confidence shaker if true. What happens if you recapture with an extra bit of head and tail?

Rob Mack

What Kelly said is correct. Vegas doesn't strip the original timecode, it just ignores it, because when you render a new timecode is created. But Vegas DOES keep track of the timecode from the original media, for purposes of recapture and keyframing. This is why you can always reload a veg and recapture exact timecode locations. I've had to do this several times due to dumb management. I use my cake analogy....Vegas doesn't care if there are 2 cups of flour and 1 cup of chocolate chips, or 3 tablespoons of sugar, because when it's all rendered, it's a cake. Except that Vegas does REMEMBER how many cups and tablespoons of each ingredient are used, and it does that based on original timecode.
Now, if you're recapturing and you put in the wrong tape, Vegas will only locate the T/C on that particular tape, it doesn't care what tape is used. I kinda suspect that there is something more at play with jimingo's project than just recapturing media captured with Vegas originally.

I think this is the way most or even any dv NLE works. The read the first frames timecode and from here on what they do is simply counting the frames.
But it works fine if you do a Batch Capturing of offline media or from a former batch-capture list.

Marco

>>>I think this is the way most or even any dv NLE works. The read the first frames timecode and from here on what they do is simply counting the frames.<<<

Yes - no - maybe. For example capture in Premiere. The file has timecode and Premiere (as well as other NLE's) reads that timecode. Premiere can output an EDL with tape numbers and timecode. Import that same file into Vegas - it won't read timecode. Vegas VidCap captured files store TC info in another place - However ScLive will capture timecode that is readable in Premiere as well as Vegas. In some thread it was posted that the developer of ScLive asked SoFo where Vegas took TC info from in a file - thus support for Vegas was added. My point here is that TC info is stored somewhere *in* the file, and that you do not need VidCap captured files for TC info to be read. Time code - this is how EDL's are created - this, along with edge numbers, is also how film matchbacks can be done. It is not as simple as "counting frames". On film - sure - look at each frame. With Video it was always frame/field and Drop frame or non-drop...sevaral variables came into play. Now add progressive and other factors...and sort of going back to counting frames. Most every NLE has a set up for DF or Non-DF...now most also have 24p support and options for film. Every NLE does not work the same in this reguard. Clearly it is one reason why Vegas does not do Online or film Matchback. (By the way - not knocking it, just saying)

Yes it stands to reason that counting begins from "first frame" - it has to work that way with everything. However the nuking/ignoring the orginal time code is what I am taking issue with. Yes, as Spot said, "Vegas doesn't strip the original timecode, it just ignores it, because when you render a new timecode is created" and this logic (not Spots logic) is something of a pain at times...but in the long run makes sense for DIY. But this also can go to the fact that if you create effects and play with the shot you can't really recapture *that* shot. But now say you want to go back, or someone wants to go back, and re-do that shot. Unless that file has TC info that somehow calls back the "original" file you are SOL. Such is the DIY system and person...it wouldn't matter. But once you send it out to others it does become an issue.

This info would tie into being able to use Vegas for things such as film matchback using Slingshot Pro or audio post tools such as Virtual Katy. Vegas has the potential to be so much more than it is - but than again, it is sort of like trying to get your kid to be something they don't want to be. It just sort of unerved me to hear that Vegas gladly tosses out TC info...even though really it isn't...again, take ScLive captured files as an example. Also take the ability to manually enter in new timecode info, just remember that Vegas does not retain that new timecode when you render. (After Effects comes to mind with the option to render using the new timecode). And one need not forget you can do SMPTE > MIDI triggering.

I am so confused now. I had hopes that someone would come up with a Vegas interface for all the TC info - but maybe there just is not any way to make that happen. Only basing this on what has been said here.

*Edit* - just wanted to also say that I do get that the TC is not removed in anyway and I do get the cake analogy but this even sets my slant off more. Why ignore the info? I can use an analogy as well - I can buy parts to repair a car. The car may not care where the parts came from,what brand, or even if they are new parts, but the car will run better if they are the correct parts and are put in correctly. Yes, a car can function without a horn, without lights, without a radio and so on. It can even function without things like water, transmission fluid and oil - but not for long. After all - most people have access to all these things - so why discard them?

And some know how I used D/Vision in the past. I have said this before but there was "Cineworks" - sort of like Vegas in that it captured TC and it allowed for recapture but you really had no access to the TC info. Thing was that Cineworks *was* D/Vision - if you had a dongle you had access to EDLs and so forth. Follow me?

I'm not really sure about it but I think Premiere does not read the real timecode but also only reads the first frame timecode of a captured stream and then begins counting the frames internally. You can test and proof this if you have a dv tape with a timecode-jump (not a break with a piece of blankness where no timecode is at all) which does not break the capturing. Take a scene with a timecode jump and capture it using Premiere. Now try to trace the timecode of that captured clip in Premiere and I think you'll see there is no timecode jump no more because Premiere only did take the first frames timecode and rest are internally counted frames.

EDLs of Premiere (asumed what I said is true what I'm not really sure about) are also based on having only first frame timecode of each clip stored and rest calculated by counting the frames.

Marco

In addition - just thinking loud: Maybe in general DV is not stored with each single frame's timecode information. TC either on a separate track info, if on tape. Or stored as a base information in the AVI or Quicktime-Header, if stored as a file. Each single AVI file then gets only one TC information - rest is calculated anew within a NLE.

Made me curious how it really is. Maybe taking ScenalyzerLive to capture a clip with an tc jump would be a proper way to proof.

Marco