Timecode sync

[Sound Chaser]

On a location shoot I usually like to hardwire from camera to recorder, "record run." As a post guy this is really the only config I want to see.

For this shoot the D.O.P. did not know what record run was and insisted on time of day. No problem I said, I can work with that. He then proceeded to tell me that I was not allowed to run a line into his camera (Red) which is known to have drift problems. He would only allow occasional sync checks when he felt like it. At the start of day two there was a 4 second drift from the previous day and he would not allow a sync!

My question: Do you prefer a hard wired connection. If not what kind of wireless transmitter would you use for this purpose. Will a lav work? If you are not running 'rec/run' would you simply jam every now and then and live with minor timecode drift? Rec/run not withstanding, is there any difference which unit sends and which unit chases....I figure it shouldn't matter.

 

[Steve House]

Pretty typical is sound chases video when you're using timecode. But much more important for eliminating drift is to slave the audio sample rate clock to the video clock and that's not really a factor of timecode at all - timecode simply establishes a single lineup point. Remember that digital audio recorders only set a timecode timestamp on the first sample and the code for the balance of the take is derived from the starting timestamp and the sample rate during playback. Code only serves to maintain sync through the shot when you're shooting film and resolving audio through telecine. To operate untethered and still have a common timebase, one uses something like a set of tuned Lockit boxes, one outputing genlock for the camera and the other providing Wordclock for the audio recorder. Setup properly such an arrangement will hold +/- 1 frame sync over 24 hours.

 

[wabbit]

If your recorder supports TC in and genlock then connect the two with recorder as slave. Using rec run, everytime the TC starts advancing the recorder starts. Like anything else avoid w/l whenever you can.

Cheers

 

[Sound Chaser]

To operate untethered and still have a common timebase, one uses something like a set of tuned Lockit boxes, one outputing genlock for the camera and the other providing Wordclock for the audio recorder. Setup properly such an arrangement will hold +/- 1 frame sync over 24 hours.

Can you refer me to such a setup. I'll just research it and educate myself from there.
THX

 

[Steve House]

Can you refer me to such a setup. I'll just research it and educate myself from there.
THX

Ambient Lockit's would be the timebase source for code and sync. Video could be any broadcast grade camera accepting external code and genlock. Audio could be a Sound Devices 7xxT, Zaxcom Deva, Cantar, Fostex or other recorders that accept external code and wordclock sync. Pop in at Trew Audio down on Villiers Street and pick up a copy of Wolf Seeberg's book on sync sound for a good overview of how it comes together. (Not the clearest writing but worth the trouble to wade through it.)

 

[wabbit]

You would want lockits if you are multicaming but if it is a single camera and recorder then a simple camera master/recorder slave is all you need.

Cheers

 

[Steve House]

You would want lockits if you are multicaming but if it is a single camera and recorder then a simple camera master/recorder slave is all you need.

Cheers

However I think he wants to work untethered. Timecode has a slow enough data rate to be sent wirelessly but wordclock/video sync doesn't. Sending TC from the camera to the recorder is a convenient way to establish a line-up point similar to a slate clap but it only sets a single point, marking the first sample of the audio file with a timestamp determined by the camera timecode being sent at that instant. But that single timestamp is the only time information that is actually recorded in the file. The running LTC seen on playback is not a record of the code that was being sent to the recorder when the file was made, instead it is new code derived during playback from the starting timestamp plus the sample count. If the recorder sample clock doesn't share a common timebase with the camera clock, the code generated on playback at a point X samples into the clip (or associated with that sample in the timeline after importing into an NLE) will not be the same code that the camera was sending to the recorder during the moment that sample was being recorded. Unfortunately, while TC capable recorders can slave their internal timecode counters to external code, they don't also slave their sample clocks to it. Thus without a common timebase for camera sync and audio sample clock such as provided by the Lockits, the audio can still drift with respect to picture as the shot progresses, even when the recorder is continuously fed incoming camera timecode.