Tag Archives: sync

Notes on Timecode and Timecode Sync for cinematographers, part 2.

In the first part of this 2 part article we saw how at some frame rates timecode will drift relative to a real time clock (Click Here for part 1). As well as drifting relative to real time due to the way timecode can only count the actual whole frames recorded,  the internal clocks that govern the timecode generators in many devices may drift slightly over time.

For single camera operation this drift is rarely significant but as soon as you start using multiple cameras or recording sound separately to the camera, even very small differences of just a frame or two between each device can cause problems. A one frame error is enough to cause a visible lip sync error, by two frames the sync error is pretty obvious to most people.

So, very often we need to synchronise the timecode across multiple devices so that the audio timecode matches the camera timecode or multiple cameras all have the same timecode so that it’s easy to re-align everything in post production. Most professional video cameras will have a timecode in or timecode out connector and the simplest way to sync two cameras is to feed the timecode from one cameras timecode out to the other cameras timecode in. For this to work both cameras must be set to “Free Run” timecode.


This is the part that often gets overlooked. If you read the first part you should understand that when a video camera is recording the timecode is generated by counting the number of frames recorded. As a result the precise frame rate of the camera will determine how many frames are recorded in any given time period and as a result the timecode for that clip. When you press the record button to start a recording the cameras timecode will match any external timecode fed to the camera. But from that point forward until the end of the recording the timecode just counts the frames recorded and will ignore any external timecode.

So the only way to ensure 100% accurate timecode sync between multiple cameras or between a camera and some other external timecode source is by providing not only a common timecode source but also a sync source that is locked to the timecode. By feeding the camera sync that is locked to the timecode into the cameras genlock input the cameras frame rate will be locked to the master frame rate so you will not get any timecode drift.

It’s amazing how many people overlook the fact that a cameras timecode generator counts frames while recording, so if the cameras frame rate is a tiny bit off, even with an external timecode source it will drift. It’s only by synchronising the camera through sync and genlock that you can be sure to eliminate any timecode drift.


If you are recording sound remotely from the camera you need to keep the camera and audio recorders timecode in sync. The timecode in a camera is dependant on the actual frames recorded while the timecode on an audio recorder is often nothing more than a data or audio track that records the timecode signal. It is rarely locked to the recorders sampling or recording rate. Because of this the correct way to link the timecode in this scenario is from the camera to the recorder.

If you do it the other way around (which for some reason appears to be the most common way) you cannot be sure that you won’t get timecode drift unless the audio recorder is also sending sync to the cameras genlock input. Normally a small amount of drift will go un-noticed on shorter shots. The cameras timecode will re-sync with the external timecode when you stop recording, so the beginning of each shot will have the correct timecode. As a result you will normally get away with feeding timecode only from an audio recorder.  But on longer takes, say shooting a music event it can become a significant issue as the camera and recorder drift apart over longer takes.


As you should have learnt from part one, 23.98fps timecode can be particularly difficult to deal with as the timecode in a camera shooting at 23.98fps will always drift by 3.6 seconds an hour relative to real time. So be very, very careful if shooting 23.98fps but using an audio recorder that uses a real time clock. There is no way to satisfactorily sync a real time clock with a camera shooting 23.98fps. Over the course of a 1 minute clip you will see the timecode drift by over 1 frame. If you wish to do sync sound at 23.98fps you need to ensure your audio recorder supports either 23.98fps timecode or at a push Non Drop Frame 29.97fps timecode. You can only sync 23.98fps tmecode with 23.98fps timecode, but a free running, Non Drop Frame 29.97fps recorder should stay closer in sync than a real time clock.

If your audio recorder only has a real time clock I strongly suggest shooting at 24fps rather than 23.98fps where you can. 24fps is a whole number so 24fps timecode does not drift by 3.6 seconds per hour compared to real time. So any sync issues should be much reduced at 24fps compared to 23.98fps. If shooting 29.97fps (often mistakenly referred to as 30fps/60i) then you should use Drop Frame Timecode when working with recorders with a real time clock.


There are a few pro cameras that don’t have a dedicated timecode in or timecode out port. The very popular Sony PXW-FS7 does not have timecode in and can’t be genlocked unless you add the optional extension unit to the camera. For cameras such as these, if you need to record sync sound on a separate recorder one option is to record the timecode output from the audio recorder as an audio signal on one of the cameras audio tracks. Timecode recorded on an audio track like this will rarely line up perfectly with the cameras own internal timecode so it should never be used as the main timecode for the recorded video. But there are plenty of software tools that will allow you to read this timecode in post production so that you can use it to line up your audio recordings with the video recording. This isn’t an ideal solution, but it’s better than relying on two different clocks, one in the camera, one in the recorder possibly running at quite different rates.


If you have multiple cameras or audio recorders it may be possible to loop the time code (and hopefully sync too) from camera to camera, so that every device is connected. Another option is to use a single master timecode and sync source and hard wire every camera to that. The problem with either of these is that if the venue is large you need a lot of cable. Sometimes it simply isn’t possible to use cables to connect everything together so instead of cables we connect the cameras wirelessly.


Wireless timecode connections normally work OK. If you momentarily loose the wireless timecode link the cameras timecode clock will just keep counting the frames recorded without issue. But as we have already seen, for true drift free timecode lock we also need to synchronise the camera via genlock. Sending genlock wirelessly is not normally a good idea. Any interruption of the sync signal will cause the cameras frame rate to jitter and that’s really bad. In practice it is quite common to link the timecode of several devices wirelessly without sync. Again for shot takes this is often perfectly OK. The lack of sync however can be an issue on longer takes. A good example of this would be a music concert where it really is vital that all the cameras and recorders run in sync.

Companies such as Ambient have wireless timecode and sync devices where each of the sync boxes (lockit box) has it’s own very high precision, temperature compensated sync clock.  All the boxes then sync to one master device, should the wireless signal drop out the internal sync clocks will continue to provide both a genlock sync pulse and timecode that is so precise that you should not see any timecode or sync drift over several days.

If you missed part 1 you can find it by clicking here.

Notes on Timecode and Timecode Sync for cinematographers.

This is part 1 of two articles. In this article I will look at what timecode is and some common causes of timecode drift problems. In part 2 I will look at the correct way to synchronise timecode across multiple devices.

This is a subject that keeps cropping up from time to time. A lot of us camera operators don’t always understand the intricacies of timecode. If you live in a PAL/50Hz area and shoot at 25fps all the time you will have few problems. But start shooting at 24fps, 23.98 fps or start trying to sync different cameras or audio recorders and it can all get very complicated and very confusing very quickly.

So I’ve written these notes to try to help you out.


The timecode we normally encounter in the film and video world is simply a way to give every frame that we record a unique ID number based on the total number of frames recorded or the time of day.  It is a counter that counts whole frames. It can only count whole frames, it cannot count fractions of frames, as a result the highest accuracy is 1 frame. The timecode is normally displayed as Hour:Minute:Second:Frame in the following format



The two most common types of timecode used are “Record Run” and “Free Run”. Record run, as the name suggests only runs or counts up when the camera is recording. It is a cumulative frame count, which counts the total number of frames recorded. So if the first clip you record starts with the time code clock at 00:00:00:00 and runs for 10 seconds and 5 frames then the TC at the end of the clip will be 00:00:10:05. The first frame of the next clip you record will continue the count so will be 00:00:10:06 and so on. When you are not recording the timecode stops counting and does not increase.

With “Free Run” the timecode clock in the camera is always counting according to the frame rate the camera is set to. It is common to set the free run clock so that it matches the time of the day. Once you set the time in the timecode clock and enable “Free Run” the clock will start counting up whether you are recording or not.


In “Free Run” once you have set the timecode clock it will always count the number of frames recorded and in some cases this will actually cause the clock to drift away from the actual time of day.


An old problem is that in the USA and other NTSC areas the frame rate is a really odd frame rate, it’s 29.97fps (this came about to prevent problems with the color signal when color TV was introduced). Timecode can only count actual whole frames, so there is no way to account for the missing 0.03 frames in every second. As a result timecode running at 29.97fps runs slightly slower than a real time clock.

If the frame rate was actually 30fps in 1 hour there would be 108,000 frames. But at 29.97fps after one real time hour you will have only recorded  107,892 frames, the frame counter TC, won’t reach one hour for another 3.6 seconds.


To eliminate this 3.6 seconds per hour (relative to real time) timecode discrepancy in footage filmed at 29.97fps a special type of time code was developed called “Drop Frame Timecode“. Drop Frame Timecode (DF) works by: every minute, except each tenth minute, two timecode numbers are dropped from the timecode count. So there are some missing numbers in the timecode count but after exactly 1 real time hour the time code value will increment by 1 hour. No frames themselves are dropped, only numbers in the frame count.


Drop Frame Timecode is only ever used for material shot at  29.97fps, which includes 59.94i. (We will often incorrectly refer to this as 60i or 30fps – virtually all 30fps video these days is actually 29.97fps). If you are using “Rec Run” timecode you will almost never need to use Drop Frame as generally you will not by syncing with anything else.

If you are using 29.97fps  “Free Run” you should use Drop Frame (DF) when you want your timecode to stay in sync with a real time clock. An example would be shooting a long event or over several days where you want the timecode clock to match the time on your watch or the watch of an assistant that might be logging what you are shooting.

If you use 29.97fps Non Drop Frame  (NDF) your cameras timecode will drift relative to the actual time of day by a minute and a half each day. If you are timecode syncing multiple cameras or devices it is vital that they are all using the same type of timecode, mixing DF and NDF will cause all kinds of problems.

It’s worth noting that many lower cost portable audio recorders that record a “timecode” don’t actually record true timecode. Instead they record a timestamp based on a real time clock. So if you record on the portable recorder for lets say 2 hours and then try to sync the 1 hour point (01:00:00:00 Clock Time) with a camera recording 29.97fps NDF timecode using the 1 hour timecode number (01:00:00:00 NDF Timecode) they will be out of sync by 3.6 seconds. So this would be a situation where it would be preferable to use DF timecode in the camera as the cameras timecode will match the real time clock of the external recorder.

WHAT ABOUT 23.98fps?

Now you are entering a whole world of timecode pain!!

23.98fps is a bit of a oddball standard that came about from fitting 24fps films into the NTSC 29.97fps frame rate. It doesn’t have anything to do with pull up, it’s just that as NTSC TV runs at 29.97fps rather than true 30fps movies are sped up by 0.1% to fit in 29.97fps.

Now 23.98fps exists as a standalone format. In theory there is still a requirement for Drop Frame timecode as you can’t have 0.02 frames in a timecode frame count, each frame must have a whole number. Then after a given number of frames you go to the next second in the count. With 23.98fps we count 24 whole frames and the increment the timecode count by one second, so once again there is a discrepancy between real time and the timecode count of 3.6 seconds per hour. The time on a camera running at 23.98fps will run fast compared to a real time clock.  Unlike 29.97fps there is no Drop Frame (DF) standard for 23.98, it’s always treated as a 24fps count (TC counts 24 frames, then adds 1 to the second count), this is because there  is no nice way to adjust the count and make it fit real time as there is with 29.97fps. No matter how you do the math or how many frames you drop there would always be a fraction of a frame left over.

So 23.98fps does not have a DF mode. This means that after 1 hour of real time the timecode count on a camera shooting at 23.98 fps will be 00:01:03:14. If you set the camera to “Free Run” the timecode will inevitably drift relative to real time, again over the course of a day the camera will be fast by almost one and a half minutes compared to a real time clock or any other device using either drop frame timecode, 24fps or 25fps.

So, as I said earlier 23.98fps timecode can be painful to deal with.

24fps timecode does not have this problem as there are exactly 24 frames in every second, so a video camera shooting at 24fps should not see any significant timecode drift or loss of timecode sync compared to a real time clock.

It’s worth considering here the problem of shooting sync sound (where sound is recorded externally on a remote sound recorder). If your sound recorder does not have 23.98fps timecode the timecode  will drift relative to a camera shooting at 23.98fps. If your sound recorder only has a real time timecode clock you might need to consider shooting at 24fps instead of 23.98fps to help keep the audio and picture time codes in sync. Many older audio recorders designed for use alongside film cameras can only do 24fps timecode.

In part 2 I will look at the correct way to synchronise timecode across multiple devices.



Notes on Timecode sync with two cameras.

When you want two cameras to have matching timecode you need to synchronise not just the time code but also the frame rates of both cameras. Remember timecode is a counter that counts the frames the camera is recording. If one camera is recording more frames than the other, then even with a timecode cable between both cameras the timecode will drift during long takes. So for perfect timecode sync you must also ensure the frame rates of both cameras is also identical by using Genlock to synchronise the frame rates.

Genlock is only going to make a difference if it is always kept connected. As soon as you disconnect the Genlock the cameras will start to drift. If using genlock first connect the Ref output to the Genlock in. Then while this is still connected connect the TC out to TC in. Both cameras should be set to Free-run timecode with the TC on the master camera set to the time of day or whatever time you wish both cameras to have. If you are not going to keep the genlock cable connected for the duration of the shoot, then don’t bother with it at all, as it will make no difference just connecting it for a few minutes while you sync the TC.

In the case of a Sony camera when the TC out is connected to the TC in of the slave camera, the slave camera will normally display EXT-LK when the timecode signals are locked.

Genlock: Synchronises the precise timing of the frame rates of the cameras. So taking a reference out from one camera and feeding it to the Genlock input of another will cause both cameras to run precisely in sync while the two cameras are still connected together. While connected by genlock the frame counts of both camera (and the timecode counts) will remain in sync. As soon as you remove the genlock sync cable the cameras will start to drift apart. The amount of sync (and timecode) drift will depend on many factors, but with a Sony camera will most likely be in the order of a at least a few seconds a day, sometimes as much as a few minutes.

Timecode: Connecting the TC out of one camera to the TC in of another will cause the time code in the receiving camera to sync to the nearest possible frame number of the sending camera when the receiving camera is set to free run while the camera is in standby.  When the TC is disconnected both cameras timecode will continue to count according to the frame rate that the camera is running at. If the cameras are genlocked, then as the frame sync and frame count is the same then so too will be the timecode counts. If the cameras are not genlocked then the timecode counts will drift by the same amount as the sync drift.

Timecode sync only and long takes can be problematic. If the timecodes of two cameras are jam sync’d but there is no genlock then on long takes timecode drift may be apparent. When you press the record button the timecodes of both cameras will normally be in sync, forced into sync by the timecode signal. But when the cameras are rolling the timecode will count the actual frames recorded and ignor the timecode input. So if the cameras are not synchronised via genlock then they may not be in true sync so one camera may be running fractionally faster than the other and as a result in long clips there may be timecode differences as one camera records more frames than the other in the same time period.

The RIGHT way to get good timecode sync with multiple cameras.

So, you have a multi camera shoot and you want to have the timecode in perfect sync between all of the cameras. For a start lets assume we are talking about pro cameras that actually have timecode in and out, because without a way to connect an external timecode source, getting truly accurate TC sync is all but impossible. The other thing you need if you want REAL timecode sync is genlock (or an Arri Alexa with an Ambient Lockit box).

The most common way used to get timecode sync across multiple cameras is to simply connect a timecode source to the timecode in of the cameras. This can be done with cables or wirelessly. This is a method I’ve used many times and it works….. kind of. Actually this is NOT the best way to get good timecode sync, but it’s probably the most commonly used method. It is especially problematic when you have very long takes, say shooting a rock concert without stopping between songs.

Here’s the problem.

When you hit record on the camera the timecode MUST increment by 1 frame every time you record a new frame, regardless of what the timecode on the TC in is doing. Every frame MUST have a unique TC number. So, if the cameras sync clock is running a tiny bit faster or slower than the TC clock of the external source, the cameras TC will slowly drift out of sync with the external TC until you stop recording at which time the cameras TC will re-sync with the external TC. On long takes this may result in a loss of sync between the external TC and the TC generated by the camera. Often this isn’t more than a few frames, but on a music shoot or where you have sync sound, being a few frames out can be a real pain.

Timecode will not synchronise a camera, it will not pull the cameras frame rate into sync with the external TC clock. Unless it is an Arri Alexa and you are using an Ambient Lockit box as Ambient can pull the Alexa’s clock into sync via a special “Tune” pin. The only thing that will alter the cameras actual frame or sync rate is genlock. So if you want the cameras to truly stay in sync you must genlock them to a common sync source.

Now I know that very often this is not possible, especially with remote or mobile cameras. That’s why companies such as Ambient include a sync output that you can connect to the cameras genlock in on their wireless TC boxes, so you can genlock the camera to bring it in to true sync with the external clock as well as feeding it sync TC.

If your working with a single camera and a sound recordist, rather than having the soundie feed TC to the camera, the more accurate way is to use the camera as the TC source and send the TC to the sound recorder. The sound recorder doesn’t have a frame rate as such so the TC does not need to be in sync with the sound recorder in the same way as it should be in sync with the cameras actual frame rate. A sound recorder can have time periods shorter or longer than a frame, a video camera cannot. By sending the TC from the camera to the sound recorder you will eliminate sync drift between the TC and the actual video frame count during longer takes.

I know this is not how it’s done in practice. In most cases TC is sent to the camera and in most cases genlock isn’t used. Probably because this is the easiest way to do things. Most of the time, if the takes are shorter than 10 minutes or so, you won’t see any issues. But if you really want accurate TC over long takes you need to do it properly and either genlock the cameras or use the camera as the TC source on a single camera shoot.


Shooting 3D with 2 Cameras and Synchronisation (Camera Rigs)

It is important to understand that no matter how much you slip and slide the clips from you cameras in the edit suite timeline to bring them into sync, if the images captured by the two cameras sensors are not in sync, you may have some big problems. Even if you press the record buttons on the cameras at exactly the same moment, they may not be running in sync. In the edit suite you can only adjust the sync by whole frames while the cameras may be running half a frame out and this can be impossible to correct in post production.
Remember that from the moment you turn a camera on it is capturing frames. When you press the record button the recording doesn’t start instantly, but at the start of the next full frame, so the synchronisation of the camera is dependant on when the camera was turned on and how long it takes to start working, not when you press the record button….. Unless you have Genlock, which overrides the cameras own internal clock and matches it to an external reference signal, forcing the camera to run in sync with the sync source which can be the second camera or a sync generator.
It is possible to shoot 3D with non-sync cameras, but any motion in the scene, or camera movement such as a pan may lead to strange stereoscopic effects including distortion of the 3D space, un wanted depth changes and moving objects appearing to float in front or behind where they should really be.
This doesn’t mean that you can’t use a non sync camera, just that it is less than ideal and it’s use will limit the kinds of shots you are able to do.
If you don’t have genlock a further option is to use a pair of Canon or Sony camcorders with LANC control. It is possible to get special LANC controllers such as LANC Shepherd or the controllers I have listed below:
These work with most camcorders that have a LANC port or AV/R port and provide good sync for periods of up to around 15 minutes at a time. To reset the sync the cameras must be powered off and back on. They work by synchronising the start up of both cameras and then measuring the sync error. The sync won’t be perfect, but it will be good enough for most 3D applications. However as there will always be slight variations in the master oscillators in the cameras, over time the sync will start to drift apart. The controller will tell you how far apart the sync is and when it becomes excessive you will need to re start the cameras to bring them back into sync, typically you get between 10 minutes and 20 minutes of useful synchronisation.