Jump to content

Recommended Posts

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. Just a curiosity.

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 (NO genlock) 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? But at the same time, timecode alone will not force the recordings to sync? So...?

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?

Link to comment
Share on other sites

When recording to files, time code is "stamped" (information in the file's header) at the beginning of each file and, on playback, is computed by whatever is reading that file.  Therefore, sending continuous time code to a device is actually only relevant at the point when the recording device begins capturing.

 

Sync, (tri-level sync, in the case of hi-def) on the other hand, is a signal that can lock devices (that are equipped to do so) to the start of each frame.

Link to comment
Share on other sites

Hi, and welcome...

" I'm pretty sure I understand the differences between timecode and genlock/sync, "

I'm not so sure...

" namely, that timecode alone does not force synchronised recording speeds between devices, "

er....

" the timecodes (and thus, the recordings themselves) can/will drift out of sync. "

well, when the jam synced equipments are all operating within specs, the SMPTE/EBU TC drift is pretty minimal, and according to your earlier statement, that alone does not force  them out of synchronization... the

" What happens when the camera 'tries' to drift out of sync? "

if it is using an external TC reference, it will be locked to that reference, 

you still do not understand this stuff...

 

" Or something else entirely? "

yes

 

what JB says applies, but devices that comply with SMPTE/EBU TC are supposed to comply with the accuracy spec's, as they run...

in the real world, this may not always be the case...

Edited by studiomprd
Link to comment
Share on other sites

When recording to files, time code is "stamped" (information in the file's header) at the beginning of each file and, on playback, is computed by whatever is reading that file.  Therefore, sending continuous time code to a device is actually only relevant at the point when the recording device begins capturing.

Right, OK. So, even with a continuous timecode feed, if the take is left rolling long enough, the recordings and timecode will/can eventually run out of sync with each other? So, the purpose of a constant timecode feed is purely to ensure that the start point of every individual take is synced and throughout the day? While, during each take, any incoming timecode is essentially ignored and by the slave device and it keeps time to its own clock (until recording is stop and started again), even with a constant external timecode source?

 

Which, if you wanted, could also be achieved by re-jamming manually before the start of every take? I realise that re-jamming before every take would be rather inconvenient compared to just leaving in a constant cable, I am just asking hypothetically.

Edited by Tailschao
Link to comment
Share on other sites

" will/can eventually run out of sync with each other? "

will/can eventually run out of sync with each other? maybe...

" during each take, any incoming timecode is essentially ignored and by the slave device and it keeps time to its own clock (until recording is stop and started again), even with a constant external timecode source? "

nope, not if the device is set to (use) external TC..

 

what you are hypothesizing seems to be a device that has an internal clock that is out of SMPTE/EBU specifications.

keep studying...

Link to comment
Share on other sites

Without a shared clock digital recording devices that do not have very accurate clocks of their own (TXCO, closely tuned) will drift out of sync with each other.  As you have said, the TC is merely a label attached to the beginning of the file, it is not a running sync reference on most cameras and sound recorders currently in use (there are exceptions to this, but not many).  How fast the devices get out of sync with each other w/o genlock depends on the accuracy of the clocks of the devices, how close they ended up being to each other in the speed of their counting, which can be affected by ambient temperature, among other factors.  Whether this difference in the speed and thus the absolute length of each recording and thus exactly what moment of the recorded program a specific TC frame number refers to on recordings made by the different devices matters is down to how the post workflow goes.  Often these days it is not an issue, but it's best to make sure before the shoot.

 

philp

Link to comment
Share on other sites

What you are asking TC to do is essentially what Genlock is for. Also, I 'd like to point out that while the TC clocks of both devices may drift over a period of time that does not neccesarily (sorry, I never know how to spell that word) mean that the two recordings are actually going out of sync.

Your suggestion to jam TC on all devices before each take is very good. It's been done for years and it works well. Just call it a slate

Link to comment
Share on other sites

Some of the confusion between Timecode and Clocking (Genlock for cameras, word Clock for Audio) you may find in online sources may refer to Audio Interfaces.  Some Audio devices, such as MOTU audio interfaces one might use with computer based recording software such as Boom Recorder, Reaper or ProTools, can synchronise their internally generated Word Clock to what some manual-writers incorrectly call the 'embedded' sync reference in a timecode stream. This is simply the fact that if the timecode is coming from a camera, presumably the same crystal oscillator in the camera is clocking both the picture and timecode generating circuitry. The MOTU interface just looks at the exact time interval of the incoming LTC timecode and 'tunes' it's internal word clock to match. Most purpose-buit Audio Recorders do not offer this facility, and there are other reasons why Audio chasing and syncing to Camera Timecode is not a popular workflow, though.

 

The Senator's oft-repeated assertion is that if you use professional devices, with in-spec internal clocking, drift will not be an issue. That is correct for the normal length takes found in dramatic film production, commercials etc. For those of us who do Concert / Live Event recording (and possibly for the Documentary shooters fond of long interviews), the reality is that even with the best of gear one should expect enough drift to need some sort of intervention in post with takes longer than maybe 10 minutes. Often the fix is as simple as cutting and nudging the audio between each song in a concert, using the applause to cover the join. That's easier to do if you recorded a guide audio track on the Camera that gets carried into the editing system. Using Genlock on the cameras and Word Clock on the Audio Recorder, all being fed from a common source (or a set of tightly-tuned lockits) can be a great help in these longer-form shoots - but more and more I find clients are used to the snip-and-slip method and they choose to only worry about Genlock on projects involving complex multiple takes and extensive editing where timecode based conforming or assembly is anticipated.

 

The Green Flash thing - I've never come across it, but often get threatened with it by Camera Technicians from the rental houses when they find out I AM intending to genlock their cameras (REDs, particularly). My understanding is that it is something to do with external genlock vs internal circuitry in the camera, and not involving timecode, but I'd be happy for a better explanation here.

 

There is a problem with some computer based recorders (DAWs) such as ProTools and Reaper being capable of actually chasing timecode rather than just stamping the start and then free-running. That is desirable for playback, of course, but in recording, if you do not have the time reference (clock, genlock) synced as well, if the incoming timecode gets too far out with the DAW's timeline, you can indeed get a jump in the recorded audio as the DAW tries to catch up. The amount of drift the DAW allows is usually set in a menu somewhere, and in the case of ProTools, you can tell it to use timestamp and freewheel mode instead.

Link to comment
Share on other sites

Thanks for the responses, I get most of it. But can someone confirm my understanding in the 4th post in this thread?

 

Post #5 seems to contradict itself, and also seems to contradict post #2, so I am leaning towards being happy that my understanding in post #4 is correct, unless someone else can tell me where I am wrong?

Link to comment
Share on other sites

Yes - your summary in post 4 is correct. The writer of post 5 is simply pointing out (in his unique way) that with good quality equipment, and for the relatively short takes common in 'normal' shot-by-shot motion picture production, that is likely all you need to maintain acceptable sync. Just like an old-skool Nagra and Film Camera being synced each shot with a slate clap then running on their own motors (or a Zoom and a GoPro...). Timecode can be thought of as simply a way of speeding up the process of re-associating the vision files with the audio files in post.

 

In my work, I ONLY do live event capture (or projects done in that style), and therefore do experience the sync drift your post suggests, but we are talking continuous takes of over an hour here. The basic answer to your initial question was given in post 2. any gear you are likely to come across nowadays is file based and works that way.

Link to comment
Share on other sites

Many good answers here. The trick is that the relationship between the first line of video and the timecode can get off by just a few milliseconds, and this is enough to create a timecode phase problem. When the timecode decoder tries to display the embedded timecode in the clip, it may come in a little early or late in relation to the incoming frame of video, and so that number gets interpreted as one frame early or one frame late, or dead-on. This can be frustrating in post. The problem with an external timecode feed is that it's not precisely lined up with the camera's own internal sync, which is why the camera needs an external reference.

 

I don't personally think it's that big a deal for a single-camera shoot -- I just say to the post guys, check it and fix it if it's wrong -- but it is a problem with multicamera shoots. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...