Timecode Question (RE. Drift)

[Jamie Tongue]

I have a hypothetical/theoretical question about timecode. I am not asking for any practical reason, and I have no timecode enabled equipment to test this on myself.

I'm pretty sure I understand the differences between timecode and genlock/sync, namely, that timecode alone does not force synchronised recording speeds between devices, it only stamps synchronised time numbers over the top of the recordings.

EG, I am aware that if one jam-syncs the timecode of multiple devices at the start of shooting, then disconnects the timecode cables, after a while, the timecodes (and thus, the recordings themselves) can/will drift out of sync.

But what happens when the timecode is constantly being fed, not a single jam-sync? Say, for example, you have a single audio recorder and a single camera. The audio recorder is sending timecode to the camera constantly via cable. What happens when the camera 'tries' to drift out of sync? The timecodes cannot drift out of sync (as they would if only jam-synced at the start of shooting), as that is the whole point of having constantly connected timecode cables, right?

I have been reading up online about this, and different websites seem to imply two different possibilities:

A) the recording of the slave device (the single camera, in my above scenario) will simply drift out of sync from the master (the single audio recorder, in my above scenario), even though the timecodes remain the same throughout the recordings.

Or B) as the slave recording 'tries' to go out of sync by a full frame, it 'tries' to take the timecode with it, but it cannot, so it 'jump' corrects itself. EG, as the camera 'tries' to run 1 frame slower than the timecode it is being fed, it forcibly corrects itself by adding a frame (and/or the opposite, of course). I have come across references to 'green flashes' in footage as a result of a slave camera 'trying' to drift from its incoming timecode. I guess these green flashes are the result of the camera 'adding' a frame (of green?) to force correct itself to match the incoming timecode?

Or something else entirely?

[Guy Caplin]

Well Jamie an interesting point of discussion and one that used to give us nightmares in the analogue world. Fortunately in the digital world the problem seems to have gone away.

In practice, in your example, you would feed time-code from the camcorder to the audio recorder, not the other way round. As the sound recorder is essentially free running you will not get any time-code conflicts.

The camera time-code is derived from the camera frame synch and runs with great accuracy. Once the camera is recording, to the best of my knowledge, the time-code cannot be changed other than being ‘jam-synched’ initially to get two of or more cameras to run with the same time-codes. To keep them totally in step keep the lead in. Usually once they are running the master time-code the synch lead is removed and the cameras will run in step for quite some time.

You worry that a device would gradually drift out of synch, in theory this is true, but in the digital world it hardly matters.

I have covered conferences on three camcorders in one-hour sections. The cameras shoot freely with no connection between them. One camera has a feed from the conference sound mixing desk and the other two cameras pick up sound from their integral mics. During editing, when we place the sound and video tracks on the editing timeline, the sound tracks are used to pull all tracks into synch at the beginning of the each section. At the end of each section I find that each camera is in synch within one or two frames. Although the cameras run time of day time-code to get rough synch and to clearly identify when a piece of material was shot, we no longer bother to jam synch the time-codes. It just isn’t necessary in this case. If we were recording lots of short scenes that would be a different matter.