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.

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?!?!

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.

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.

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.

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.

So is there a way to work on that metadata?

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.

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.