Looking for confirmation or correction of the following:

Time code: To use TC, your camcorder and sound recorder must accept an external
TC signal from a common source.

Sync: In order to stay in sync with each other, the units must be driven by a common clock or genlocking source. The units must have physical TC in and Genlock connectors on them.

Conclusion: TC is good for lining up video with audio but only if it's laid down in sync and forced to stay in sync.

Pretty much excludes most pro-sumer camcorders like my XH-A1 (not the G1) and most Sony camcorders.

The same would be true if trying to lock two cameras.

any comments?
thx

Ok, your camera and recorder dont necessarily need TC to sync up. Its sweet if you have TC IN/OUT on the camera and/or recorder, and you can send TC out from the camera into the recorder or the other way around.

I have a TC capable recorder but the camera doesnt have TC IN/OUT. I can set the recorder to 23.976 frame rate so it matches with the camera frame rate.

The best way is to use the good old clapperboard and to record that sound onto your recorder and to film it on your camera. then you have to manually line up the sound of the clack along with the clapperboard closing. this technique has been used since the inception of double system and it works. Yes, you have to line up every take and thats why its good to assign scene/take numbers to everything you shoot. it makes it easier in editing and syncing.
It works nicely for me.

You are correct for the most part. There are two elements to fully syncing audio and video, a positional reference and a speed reference. Timecode only provides the position reference, really it's just a fancy slate. To prevent drift, you must also have a speed reference, that is, the camera and the audio recorder must share a common timebase. There are several ways that can be accomplished. If one has a camera that accepts genlock, one way is to use a master clock to simultaneously send genlock to the camera and wordclock to the audio recorder. Sound Devices 7xxT recorders offer a variation of that where their internal clock is a module made by Ambient that is similar to a Lockit box built right in to the recorder, and another Lockit can be tuned to it to provide genlock to a camera that accepts it. Another is to use an audio recorder such as the Tascam HD-P2 or Sound Devices 788T that accepts video coming from the camera and slaves its sample clock to the embedded blackburst (SD) or Tri-level (HD) sync signal. Sure wish someone made a battery-powered and affordable converter box that would accept a composite video signal from a camera and generate wordclock from it but AFAIK none are on the market at the moment.

Some time ago I got a mail from Sound Devices confirming the following, which I really didn't know:

"The 702T, 744T, and 788T all handle time code in the same manner. When
recording with time code the recorders internal timecode generator is always
running and is available as an analog signal via the 5 pin LEMO connection.
When the file is written, the starting time code value is stamped into the
header information of the file. When the file is brought into a program that
can read the time code stamp, it usually can insert it at the appropriate
point on the time line. When the file is played back on the recorder the
recorders internal timecode generator is again triggered and SMPTE time code
is again present at the LEMO out. If one needed time code striped to an
audio track for say, transcription purposes, you could run a LEMO 5 to XLR
cable back around to an available input and route it to a track on the
recorder while recording audio on the others."

Apparently all TC recorders work in the same way, though not all allow going in with a video signal, as Steve points out, to lock to and really be in sync.

Elaborating further about this same question, if the TC just sets a positional reference and it's stamped once at the beginning of the take, there was something Ambient did offer some time ago.

I think it was called TC burst, and it allowed you to use crystal-sync controlled non-TC machines, like Nagras, DAT and MD recorders. During transfer to a computer or perforated tape you would feed that TC burst into a TC generator that would re-construct the complete TC signal and stripe the audio file with it.

Taking that to present times, a similar routine could be implemented on non-TC CF recorders, even if the speed reference set by the genlocking video would not be accomplished. Then only shots up to perhaps 30 minutes should be in sync. On thing I don't like about the genlocking system is that you would need a cable to link camera and audio recorder. I'm not sure you should genlock through a wireless link.

Elaborating further about this same question, if the TC just sets a positional reference and it's stamped once at the beginning of the take, there was something Ambient did offer some time ago.

I think it was called TC burst, and it allowed you to use crystal-sync controlled non-TC machines, like Nagras, DAT and MD recorders. During transfer to a computer or perforated tape you would feed that TC burst into a TC generator that would re-construct the complete TC signal and stripe the audio file with it.

Taking that to present times, a similar routine could be implemented on non-TC CF recorders, even if the speed reference set by the genlocking video would not be accomplished. Then only shots up to perhaps 30 minutes should be in sync. On thing I don't like about the genlocking system is that you would need a cable to link camera and audio recorder. I'm not sure you should genlock through a wireless link.

The genlock signal is at a much higher frequency than an audio signal or a SMPTE timecode burst and regular wireless transmitters and receivers would be not be appropriate for it. Eliminating the cable is where Lockits come into play. The Lockits have highly stable oscillators that can be precisely tuned to each other. One is connected to the camera's genlock in and provides the video reference clock. Another is connected to the audio recorder's wordclock in and provides the audio reference clock. (And they also provide TOD timecode to both camera and recorder.) As I mentioned before, the Sound Devices 7xxT series of recorders have the equivalent of a Lockit already built-in so if you're using one of them you don't need the external box for the audio recorder - all you need is a Lockit for each camera.

I think one of the reasons this whole timecode sync thing is confusing to a lot of people is back when TC was first introduced, the post workflow involved transferring the sound from analog tape or DAT to magnetic perf or, after Avid replaced the Movieolas and Steenbecks, essentially capturing it in real time from the DAT tape into the file format the audio workstation needed, much like the process today of capturing a DV tape from your camera's playback into your computer for editing. The analog and DAT tapes had LTC recorded alongside the audio when the original recording was made. That TC signal playing back off of the tape was continuously compared to a standard reference clock during the dubbing or transfer process and controlled the playback speed, speeding it up or slowing it down so it matched the reference. But modern file-based workflows where the production audio is recorded directly into a wav, bwf, or mp3 file on a hard drive or CF card don't work like that.

thx to all for the replys. I guess I have to keep syncing the hard way as it seems u have to pony up a boatload of money to do multi-camera and double sound. Most, if not all, of these prosumer cameras aren't built for it.

thx to all for the replys. I guess I have to keep syncing the hard way as it seems u have to pony up a boatload of money to do multi-camera and double sound. Most, if not all, of these prosumer cameras aren't built for it.

Well, I wouldn't say so. The problem with most prosumer cameras is that their internal mic preamps suck, and even more most of the mics they come with.

If to that you add that using an on-camera position for the mic is most of the times far from good and you need a boom man and/or lapel mics, wireless or hardwired, then doing double system sound may be the way to go.

This may not work for long takes, longer than 30 minutes or so, but it does work superb in all other situations.

You may sync using a clapper, a bloop light or simply sync the audio wave-forms in the editing program. But after that everything goes fine.

In any case, if you are doing multiple camera situations you should feed the same sound to all cameras, so you would still have to sync things.

So question is, would it work to take the video out of my Canon XH-A1 and connect it to the video clock input on the Tascam P2 recorder? I realize that this is not TC but would it lock the speed of the tascam to the Canon to prevent drift?
thx

So question is, would it work to take the video out of my Canon XH-A1 and connect it to the video clock input on the Tascam P2 recorder? I realize that this is not TC but would it lock the speed of the tascam to the Canon to prevent drift?
thx


You need a genlock signal, which I don't know if the Canon provides.

You can also feed an external TC signal into the Tascam P2 with a Denecke generator, like the SB-3.

So question is, would it work to take the video out of my Canon XH-A1 and connect it to the video clock input on the Tascam P2 recorder? I realize that this is not TC but would it lock the speed of the tascam to the Canon to prevent drift?
thx

Yes, the Tascam is expressly built to sync its internal sample clock to the blackburst imbedded in the video signal if you give it one. Ot if you want fancier, the new Sound Devices 788T also accepts video and will sync to it. Alas the older 702T and 744T do not.

um... I thought gen lock was the vertical sync pulse. I've heard u can simply use a black generator or the P2 would sync to the vertical sync pulse of the cameras video out.

thx Steve. The tascam is now tempting. I've used it a couple of times. However, I don't like the business with the limiter switches. It's some murky setup where ur using the mic inputs (XLR) and the limit switches are supposed to work with them. The manual is pretty useless. However, I'm sending line level from a mixer into the them. Already a shakey deal. I swear I can hear the clipping even though the "limiters" are activated.
Next thing is, I sure wish there was a 4 channel version.

:-)

thx Steve. The tascam is now tempting. I've used it a couple of times. However, I don't like the business with the limiter switches. It's some murky setup where ur using the mic inputs (XLR) and the limit switches are supposed to work with them. The manual is pretty useless. However, I'm sending line level from a mixer into the them. Already a shakey deal. I swear I can hear the clipping even though the "limiters" are activated.
Next thing is, I sure wish there was a 4 channel version.

:-)
There's always the Sound Devices 788T 8-channel model, a mere 6 grand <g>. I thought Horita made a battery powered synchronizer that accepted video and sent wordclock but I was checking for it last night and have'nt been able to locate it.

Today I was discussing this drift question with a friend of mine that works with video, and he tells me that when shooting with several cameras they go to "free run" and then jam sync them all to the same clock. They then go their separate ways and shoot without any links.

So he asked me why there should be any drift in these audio machines, which are basically digital based and shouldn't "slip-away" as DAT or MD discs might do.

Isn't any clock reference recorded along with the audio and why isn't it as accurate as that on the video cameras?

Today I was discussing this drift question with a friend of mine that works with video, and he tells me that when shooting with several cameras they go to "free run" and then jam sync them all to the same clock. They then go their separate ways and shoot without any links.

So he asked me why there should be any drift in these audio machines, which are basically digital based and shouldn't "slip-away" as DAT or MD discs might do.

Isn't any clock reference recorded along with the audio and why isn't it as accurate as that on the video cameras?

Because any clock is subject to manufacturing tolerances, different temperatures, etc. A nominal 48khz clock may in fact be a few hz off in one direction or the other. Even if a clock reference is embedded into the recorded audio, if it's not exactly the same, to the single digit parts per million level of accuracy, as the camera's clock, sync will eventually drift.

Your friend is making the classic error of confusing SAMPLE clock with TIMECODE clock - they are two entirely separate things. One "tick" of the timecode clock is 1/30 or 1/60 of a second. One "tick" of the sample clock is 1/48000 second. Even tuned Lockits, as well designed and tight-toleranced though they are, will eventually drift away from each other. If I recall the numbers correctly, Ambient says they can be tuned using Ambient's Clockit master clock to within 0.2 parts per million error between them, leading to a drift of about 1 frame per day. But we're talking about a single clock module that at about a kilobuck in price is more expensive than most complete consumer level camcorders.

Because any clock is subject to manufacturing tolerances, different temperatures, etc. A nominal 48khz clock may in fact be a few hz off in one direction or the other. Even if a clock reference is embedded into the recorded audio, if it's not exactly the same, to the single digit parts per million level of accuracy, as the camera's clock, sync will eventually drift.

So the question is reduced to how accurate the clock is in parts per million, which is how it should be. But how is that units like TC DAT machines had a logical mechanical drift, worst clock references, just TC and did their job? Things now are not mechanical but drift more?!?!

Your friend is making the classic error of confusing SAMPLE clock with TIMECODE clock - they are two entirely separate things. One "tick" of the timecode clock is 1/30 or 1/60 of a second. One "tick" of the sample clock is 1/48000 second. Even tuned Lockits, as well designed and tight-toleranced though they are, will eventually drift away from each other. If I recall the numbers correctly, Ambient says they can be tuned using Ambient's Clockit master clock to within 0.2 parts per million error between them, leading to a drift of about 1 frame per day. But we're talking about a single clock module that at about a kilobuck in price is more expensive than most complete consumer level camcorders.

I bet my friend is not confusing them, as he IS an electronics engineer and I am not. What he also told me is that they just sync the camera's TCs and shoot as long as they want. Maybe because the camera lockits are very accurate?

They mix down to a Tascam DA-88 for more than a hour long programs with no drift, and there's only TC controlling it all. No wordclock reference.

So the question is reduced to how accurate the clock is in parts per million, which is how it should be. But how is that units like TC DAT machines had a logical mechanical drift, worst clock references, just TC and did their job? Things now are not mechanical but drift more?!?!

...

They mix down to a Tascam DA-88 for more than a hour long programs with no drift, and there's only TC controlling it all. No wordclock reference.

First of all remember that a DAT records a linear data track that is captured into the editing system for post while a hard-drive / CF card recorder records a random-access data file that is copied to the computer for post. The DAT record/capture process is a linear affair very similar to shooting and capturing a DV video tape. The file-based audio recording/edit process is a copy process very similar to shooting a digital still photo and copying it from your camera to your computer. The difference between the two is crucial for understanding what's going on.

The Tascam DA-88 is a DAT recording/playback system. If linear timecode is recorded in parallel to the audio, it can be compared to a stable external clock during playback for capture and the playback speed adjusted based on the comparison. When a DAT is ingested into the editing system it is a file capture process rather than a file copy operation - essentially it is being played and re-recorded and so the timecode accompanying it can sync to the video by comparing the recorded code to the the video timebase. The process is very similar to the old days of analog tape being resolved to magnetic perf where the recorded crystal sync tone was compared to the line frequency and controlled the speed of the tape playback motor.

With a file based audio recording system such as the current generation of hard-drive or CF card recorders timecode does not control the speed of playback because the code is not recorded continuously in the file itself. In fact there is no clock actually recorded in the file at all - the only timing information is a record of the nominal clock frequency in the file header. All the timecode does is provide a timestamp of the first sample in the file in the file header and that is it. If you playback the file after recording it, the timecode you see rolling by in the window on the recorder is not coming from the audio file itself - it is a calculated value based on adding the sample count to the starting timestamp. When you drop the file into the editing system (if it recognizes the bwf file timestamp - not all do) it lines up the timestamp with the matching point on the editing timeline but that is it - there is no mechanism to adjust the file length to match the video length if there was any discrepancy at all in the clock rates of the video camera and the sample clock of the audio recorder. In fact this property is exploited in one of the techniques used to apply the .1% slowdown going from film to NTSC video - the file is recorded at a real sample rate of 48.048 kHz but is stamped in the header as having been recorded at 48.000kHz. When it is dropped into the editing workstation, it is automatically slowed down (ie, lengthened) by the .1% required to match the pulldown introduced into 24 FPS film to convert to 29.97 FPS NTSC video.

An excellent explanation, Steve. Particularly because most people do not know how things were in the analog days. That at least I am familiar with, as I come from Nagra days.

So how, doing the leap to present digital days, is sync maintained in HD and CF devices? Just by working on the sample rate? How does video/genlock/wordclock get to control things and avoid drift?

Take the Tascam HD-P2, for example. Apparently it uses its internal RTA clock for the TC, so its accuracy is limited, except if linked to a camera, by cable or wireless. You can use an external TC generator, like Denecke or Horita, which you can jam to a film or video camera, avoiding a long cable or wireless link and getting more precision.

But as you say only a TC time stamp will be used at the beginning of each take, not a continuous signal, and the rest is just computed numbers started from it. A better TC source will only preserve sync on the jammed generator, but if the shot is long there will be drift due to the sampling clock. So you would need a video signal or genlock to avoid drift.

An excellent explanation, Steve. Particularly because most people do not know how things were in the analog days. That at least I am familiar with, as I come from Nagra days.

So how, doing the leap to present digital days, is sync maintained in HD and CF devices? Just by working on the sample rate? How does video/genlock/wordclock get to control things and avoid drift?

Take the Tascam HD-P2, for example. Apparently it uses its internal RTA clock for the TC, so its accuracy is limited, except if linked to a camera, by cable or wireless. You can use an external TC generator, like Denecke or Horita, which you can jam to a film or video camera, avoiding a long cable or wireless link and getting more precision.

But as you say only a TC time stamp will be used at the beginning of each take, not a continuous signal, and the rest is just computed numbers started from it. A better TC source will only preserve sync on the jammed generator, but if the shot is long there will be drift due to the sampling clock. So you would need a video signal or genlock to avoid drift.

Recorders like the HD-P2 or the Sound Devices 7xxT series have two separate clocks, a high accuracy, high frequency sample clock and a lower accuracy timecode counter. When everything is working on internal the sample clock rules and its output is divided down to the slower rate of the TC counter. If you jam external code, it sets the TC counter equal to the code input to it and the internal clock keeps it ticking over from that point on BUT it is the internal sample clock, not the external code, that provides the timebase. If you instead of jamming (set and disconnect) you slave the TC counter to continuous external code, the same situation applies except that the counter is being continually updated from the external code. However the TC counter updating does NOT exert any influence on the sample rate clock - it still keeps ticking away on its own completely independent of the information coming in with the timecode signal. Timecode signals are just too slow to provide a clock for the sample rate. It's only when you give it video blackburst (Tascam or SD 788T) or wordclock (Tascam, SD) does the external device exert any influence on the rate of the sample clock, causing it to slave to the clock embedded in the external sync signal. One of the reasons the SD recorders are more expensive than the Tascam and the SD 702T model is so much more expensive than the SD702 model is their timecode and sample clocks are very accurate modules made by Ambient, the Lockit box folks, and are stable enough to hold sync after the slate for a reasonable length of time. But even SD says that one should be very careful of drift with shots over about 15 minutes long without taking further precautions.

Steve, this is probably a crazy question, so please feel free to simply laugh at it.

Is it possible to add a TC burst on a non-TC digital recorder, like say the Edirol R-44 and convert that BWF file so that the file WILL have a TC embedded on it? Say like it was recorded on an SD 744T?

Ambient did devise a way to do that in the mid-nineties, so that you could use non-TC Nagras and DATs. You recorded a TC burst in the audio track at start and then fed that burst into a TC generator that would then reconstruct and strip that audio in post-production. But the system was very expensive, so I researched into doing that with low-budget equipment, particularly MD portables. Denecke also did have a generator that could be fired from that burst and strip the audio. The system was much more affordable than Ambient's.

The question is that I don't know if there are any programs that may handle BWF files and do this I am proposing now. It should be cool if it was possible.

Steve, this is probably a crazy question, so please feel free to simply laugh at it.

Is it possible to add a TC burst on a non-TC digital recorder, like say the Edirol R-44 and convert that BWF file so that the file WILL have a TC embedded on it? Say like it was recorded on an SD 744T?

Ambient did devise a way to do that in the mid-nineties, so that you could use non-TC Nagras and DATs. You recorded a TC burst in the audio track at start and then fed that burst into a TC generator that would then reconstruct and strip that audio in post-production. But the system was very expensive, so I researched into doing that with low-budget equipment, particularly MD portables. Denecke also did have a generator that could be fired from that burst and strip the audio. The system was much more affordable than Ambient's.

The question is that I don't know if there are any programs that may handle BWF files and do this I am proposing now. It should be cool if it was possible.

BWF files aren't that exotic and most NLE and DAW handle them just fine. They're just normal wav files, even the extension is wav, with some metadata in the file header.

The SD744T does not record TC alongside the audio nor does it lock its sample clock to incoming TC. It does the timestamp in the header thing, getting the timestamp from its timecode counter which, in turn, gets its value and is updated either by the internal TC clock or the incoming external code. The ONLY timecode information that is recorded in the audio file itself is the timestamp of the first audio sample.

BWF files aren't that exotic and most NLE and DAW handle them just fine. They're just normal wav files, even the extension is wav, with some metadata in the file header.

So is there a way to work on that metadata?

The SD744T does not record TC alongside the audio nor does it lock its sample clock to incoming TC. It does the timestamp in the header thing, getting the timestamp from its timecode counter which, in turn, gets its value and is updated either by the internal TC clock or the incoming external code. The ONLY timecode information that is recorded in the audio file itself is the timestamp of the first audio sample.

That seems to be clear by now. There's no continuous TC and the sampling clock is independent from the TC generator. The timestamp rules.

So is there a way to work on that metadata?

Yes, there are a number of programs on the market that let you view and/or edit it. One that is very popular is Courtney Goodin's shareware "BWF Widget." Sound Devices has their Wave Agent available for download.