You the timecode properties in the Project Property. Drop Frame timecode is designated by Semi-Colons, whereas Non-Drop is just colons.

Without the Option to Insert Edit onto a tape deck and a more sophisticated machine control, I don't think you can be assured that timecode will start at a specific time.

Dave T2

Unfortunately you are probably not set up duplicate (or regen in sync) time code in the method that they would need for laying back audio. When dubbing beta tapes, you can transfer the timecode from one tape to another. Loading it into Vegas you can not to the best of my knowledge maintain the original tape's timecode. I hate to say it, but I would say that the audio house has a big problem ahead.

K

I went into Project Properties and I could not find a colon or semi colon. All I see is "NTSC DV 29.97 fps" Where can I find it?

If the duplication house can insert edit onto a beta tape deck, can I just insert my avi file at the 2 pop of the original Beta tape?

Can a different timecode be printed to MiniDV tape?

Al

Is the time information from the "Time Ruler" printed into the avi file as timecode?

From the Vegas help index:
A time ruler offset allows you to change the ruler to start at a specific time. Typically, this feature is used in conjunction with SMPTE and MIDI projects when their timelines are the main reference. An offset allows you to set the Vegas ruler based on another project’s timeline for reference purposes.

If I set this to match the Timecode on the beta, would it carry over to the MiniDV tape and then to the beta?

Al

NTSC 29.97 IS drop frame mode. It's still actuatly 30fps, but drops frames at certain intervals to make up for a time lag (i forget why and when it drops, but that answers your drop frame question).

Somewhere in the setup (maybe it is on the timeline setup) it allows you to set Non Drop and Drop. But I think, at least on my digital camera, when you output to tape, the camera decides on the drop code and starts at 00:00;00 everytime. It also defaults to Drop Frame. If you can sync to the 2 beep, then the audio house can resync it. They just might scream and yell because that is what audio people do. :)

Dave T2

OK, lets clear this up a bit...


Any post-house with a beta editing deck can restripe the beta tapes with the correct starting TC. If there is no drift in the editing/transfers, the layback will be fine.

For the record: NTSC color video runs at 29.97... drop-frame TC permits the counting of frames such that the TC matches "real-time"... actual counts of the frames at 30fps will indicate lower #s since video runs slightly slower. (slower counting = less indicated elapsed)

(If the post-house needs a tip, they can set the TC to re-stripe at the two-pop starting at 59:58:00.)




HTH, MPH

Tips:
http://www.martyhedler.com/homepage/Vegas_Tutorials.html


P.S.

Vegas does not output TC.

DV is drop-frame.

The above two points are irrelevant as far as the transfers to/from - in the above case.

Thanks Marty,

I had a feeling you would be showing up. So, If this audio guy did the original audio on the original beta, which is non drop. and I dub to DV. When I go back to Beta, if the duplication house sets the beta deck to non drop, will it all time out perfectly. The audio I layed down matched the dv footage perfectly. The duplication house made the beta dub a drop (I am guessing because the dv tape I gave him was drop.) Then the original audio guys timecodes on his audio were all for non drop. Will making a non drop beta dub of my dv tape fix this?

Thanks,
Al

Your miniDV output is NTSC DV, which by definition runs at 29.97fps. Timecode is just an accounting nicety, and if NTSC ran at 30fps, then the frame labelled 46:22:00 would be occuring exactly 46 minutes, 22 seconds after the start. But NTSC is 29.97, so the that 46:22:00 frame would actually occur at 46 minutes and about 25 seconds after the start as measured by the clock on the wall. SMPTE drop code brings the timecode back in approximate alignment with the real time by dropping an occasional frame number (it never drops the actual frame, just the number). It seems to me that as long as the final output is striped the same as the other portions, all will be well. I hope I haven't confused the issue even more.

Riredale is correct. All NTSC color video is 29.97 and the choice of drop or non-drop is independent of that. Non-drop is easier to count because no frame numbers are dropped. Drop frame coincides with real-time by dropping certain frame numbers to keep the count accurately adjusted for the difference between running at 29.97 and counting at 30 frames per second.
Back to the original questions. You set drop or non-drop in Vegas in "File, Properties, Ruler". You can also set it in "Options, Ruler Format".
Where you set these on the decks depends on the models involved. Some mini-dv decks can be set to drop or non-drop and started at whatever timecode number you select.
Maintaining matching timecode is totally dependent on what video decks you use and how they are hooked up and operated. You must have a mini-dv deck capable of accepting incoming timecode in order to dub from a betacam tape and maintain matching code. This is rather rare and expensive, (much more rare than a mini-dv deck that can be simply preset). You also have to set the deck correctly and to be really accurate, you should have all decks and Vegas running under sync from the same video sync generator during all these operations.
In order to get the matching code back out to tape from Vegas, you must run Vegas under control of the timecode output from the deck into a SMPTE to midi converter that's controlling Vegas. You also must have either a deck that can do audio insert editing or two decks (one to play and one to record). As was stated earlier, Vegas doesnt actually output timecode, it just runs in sync with external timecode. The timecode comes from the video deck, the audio comes out of Vegas with the appropriate timing. The audio is either re-inserted to the deck that's playing back the timecode, OR the audio, video and timecode is sent to a second video deck.
If this was a long project, even matching up the "2-pop" may show drift at the end of the tape regardless of restriping the code, since all these processes were running under independent video clocks. If it's a short project, then matching up the 2-pops in both your audio, and the music track, as well as establishing the right offset in the NLE at the music house (to compensate for the difference in timecode between the original betacam and the copies you had made) should make things work out. But i'm sure the audio people doing the final mix will complain because of the extra work.
Unfortunately, any time you're going back and forth between betacam and mini-dv you will have difficulty maintaining matching code because most mini-dv decks are incapable of matching the code. Somebody's going to have to do extra work somewhere to match things up again. It would have been easier for the music people to send you the music and let you do the final mix, THEN make the final betacam copies from your mini-dv's. That would make the original betacam timecode irrelevent and they probably didnt want to do it that way.

Hi all,

This is an interesting question, the one about drift, that is...

The digital tape formats may actually hold sync better than older analog VTRs, because the analog units would servo the capstan to correct for time-base errors and control-track pulses... digital VTRs are essentially just TBCs being fed data from tape-storage... the tape transport has little to do with the clocking of the signal.

All decks *could* lock to a generator; but when dubbing, the recorder is locking to the input source anyway.




HTH, MPH

Tips:
http://www.martyhedler.com/homepage/Vegas_Tutorials.html

That's partly correct, digital decks do run much closer to each other than analog decks, but they still wont hold perfect sync over a long time span. The key is whether he had Vegas and the mini-dv deck running under direct matching video sync during input and output. From what he said, I dont think that was the case. Even though the difference might be very small, it only takes 2 frames after 45-50 minutes to wreck lip-sync.
In addition, since the beginning deck was analog (he didnt say "digi-beta"), and there have been 3 probably un-controlled steps before going back out to analog for the final time, it would be very lucky if there's no drift over the long haul.
It all depends on how long the project is.

Yeah, might be tough, but bear in mind that capture DV to Vegas is a digital dump, not a real capture per se... same with printing to tape.


As for the dub from beta to DV the beta is clocking-out time-base corrected video and the DV is locked to IT, with no servoing needed for writing to tape the digital data... on the other end, the beta deck is locked to a stable time-base output of the DV, so all may be well...

...even MD seems to sync pretty well even in long takes.



mph

This is awesome info guys, thanks.

Just to clear up. The orginal BetaSP (not Digi-Beta) was sent to a dup house. They dubbed to MiniDV. That should time out perfectly, correct? Then I captured into vegas through vegas's capture using my camera. That should be an exact digital copy, correct? I did my thing in vegas, rendered a new avi file, printed back to tape from vegas to the camera (firewire), that should be an exact copy, correct? Then I sent it back to the duplication house to get dubbed to beta.

This is where it got hairy. The orginal beta was non drop. They guy who was doing the audio was the person that originally put the audio on the orginal "non drop" beta. He was expecting to get betas from me that were non drop and had a starting timecode of 1hour. The dup house took my miniDV and dubbed it to beta but made a "drop" copy, why, I don't know. They are redubbing them right now. I am guessing there is a switch or something on the front of the beta deck that can make it drop or non drop. The audio guy gave me a call and said that nothing lined up, and that the timecodes did not match. He said the time code wasn't a big deal, he just needed to punch in zeros instead of 1 hour. but the drift was bad. I have done 20 other projects and not had a problem with drift. Could the descrepancy between drop and non drop be screwing this up? I have to give some kind of explanation of the problem to everyone involved. Just trying to identify the problem.

BTW, the video is 10 minutes long.

Yep,,,, I think your new dub should work fine,,,,,
By the way in defense of the dub house ,unless specified drop would be the norm---least in my opinion

Hopefully yes, this will make the layback close enough over 10 minutes that no one will notice.
What MartyH was saying earlier is correct except for one thing. That it's wrong. :-)
Ok, it's only wrong in circumstances that most people never run into, namely laying back to the original tape. It's perfectly correct for creating a finished product through a number of steps that never have to directly match up with the original tape.
However, if you do have to match up with the original tape, then the problem can occur because each device uses its own clock when passing the information to the next step in the chain. It doesnt matter that each recorder is syncing to the input of the device before it when each recording is made. What matters is that each device when playing back to the next device is now using its own internal clock.
No matter how close they are, they cant be perfectly matched unless all the devices are running under the control of a single sync generator.
So for 99.9% of work, then MartyH is correct, the differences are so small that it will not be a problem. If you're laying back long-form audio to an original tape, this microscopic difference can kill ya.

I will add the way we do it for large films with multiple audio pros working at a time. We take the original referrence tape, beta, hd whatever. We dub to a VHS with the TC on an audio track. Everyone then creates their stuff using the audio track as the referrence. This includes the composer, the sound designers, the dialog cutters etc. The dialog and the score etc are then editted in Protools or other application that syncs to timecode. I bet we could do this with the midi time code in Vegas. Then we play back the finished work to the original tape and lay it back.

The key here is that everyone works off of a tape with the audio time code on it. We route that audio timecode to the decks etc instead of the tape timecode. That allows us to maintain sync. Everything chases this audio. One trick is that we almost always use a time code reshaper in the routing to keep the timecode signal sharp.

K

>>>>"No matter how close they are, they cant be perfectly matched unless all the devices are running under the control of a single sync generator."<<<

Gee, that must be why so many network news edit-bays can edit machine-to-machine without blackburst to either machine... and field edit systems, and corporate edit systems and educational edit systems... without TBCs no less.

If there is drift, it could be just as likely that the beta recorder was inappropriately set to external sync during record, instead of servo-locking to the input signal.


DF or NDF TC is probably not at the root of this problem if punching-in an offset or restriping isn't resolving the issue.


BUT, something is amiss...

in the meantime, can the audio post accept a .wav or CD audio? Takes VTRs out of the equation, anyhow...


MPH

OK flash,

Rereading the thread, I see that it's the audio post that cannot resolve the issue using an offset...

They are likely chasing the TC out of the port... the DF/NDF issue could be the hangup... punching in an offset won't work. I would suggest re-striping the tape with NDF and check the results.

MPH

>>>"Gee, that must be why so many network news edit-bays can edit machine-to-machine without blackburst to either machine... and field edit systems, and corporate edit systems and educational edit systems... without TBCs no less."<<<

That has absolutely nothing whatsoever to do with the situation we're talking about. The first step, recording machine to machine isnt the problem. As I said earlier, the problem isnt in going from machine A to machine B. The problem occurs when machine B plays back with internal sync to machine C. Then machine C plays back with internal sync to machine D. The original poster described a situation where there were 6 steps of this before trying to match back to the original tape. This just isnt going to match perfectly except by shear luck if all playback steps arent controlled by the same sync generator. At least the project is only 10 minutes long. Even at that short length, drift may be a problem.

As a coworker of mine once said,

It might work, but there is no reason that it should!

Dave T2

Thanks guys,

All of this info helped.

The dub house made new dubs as non drop and that fixed the problem. The audio guy got the betas and they matched up perfectly.

Any help on my "apostophe" thread would be greatly appreciated.

Thanks,
Al