The 4-Hour Interview That Drifted 8 Frames
A two-person documentary crew records a 4-hour interview with a Sony FX3 at 23.976fps and a Sound Devices MixPre-6 II recording dual-system audio. They jam sync at the start. The camera menu says "24p." The audio recorder is set to 48kHz with internal timecode at 24.000fps.
In the edit, the first 20 minutes sync perfectly. By the 2-hour mark, the audio is 4 frames ahead of picture. By the end of the 4-hour interview, the audio is 8 frames out of sync. The editor can align the head or the tail, but not both. Every cut after the first hour needs a manual slip correction.
The problem is not equipment failure. The camera is recording at 23.976fps, not 24.000fps. The audio recorder is running at true 24.000fps. That 0.1% difference, defined in the SMPTE ST 12-1 standard, accumulates into 3.6 seconds of drift per hour of real time. Over 4 hours, the gap is 14.4 seconds, or approximately 345 frames at 23.976fps.
This post explains why timecode drift happens, which frame rates cause it, and how to lock your devices so they stay in sync for the full recording duration. The frame rate and timecode standards referenced here are defined in SMPTE ST 12-1, the governing standard for linear timecode in film and broadcast production. Additional practical guidance draws from Alister Chapman's timecode sync notes and the SMPTE timecode explained reference at vitelnk.com.
Why 23.976 Is Not 24: The Frame Rate Drift Problem
The most common cause of timecode drift on modern productions is frame rate mismatch. The camera records at 23.976fps. The audio recorder runs at 24.000fps. These numbers look identical in a menu, but they are not the same frame rate.
23.976fps = 24.000 / 1.001. This fractional frame rate exists because of NTSC television standards, which required color broadcast signals to run at a frequency compatible with the existing black-and-white transmission infrastructure. The 1001/1000 timing offset was the engineering solution, and it has plagued post-production sync ever since.
The drift math: at 23.976fps with non-drop-frame (NDF) timecode, the timecode counter runs at 24fps but the actual frame rate is 24/1.001. This means the timecode drifts from real time by 3.6 seconds per hour. After 1 hour of real recording, the timecode reads 01:00:00:00 but the actual elapsed time is 01:00:03:14 (3.6 seconds, or 86 frames at 23.976fps).
Worked example: A 1-hour interview at 23.976fps NDF. The camera timecode reads 01:00:00:00 at the end. The real elapsed time is 3,603.6 seconds. An audio recorder running at true 24.000fps with NDF timecode would read 01:00:03:14 at the same moment. The 3.6-second gap is the drift.
The same problem exists at 29.97fps NDF: 29.97 = 30 / 1.001. The drift is the same 3.6 seconds per hour. Drop-frame (DF) timecode solves this by skipping frame numbers periodically to keep the timecode aligned with real time. At 29.97fps DF, drift is under 0.1 seconds per hour. But 23.976fps has no drop-frame standard, so the drift at 23.976 NDF is unavoidable.
A secondary drift source is crystal oscillator tolerance. Every timecode generator uses a quartz crystal with a rated tolerance in parts per million (ppm). A ±2 ppm tolerance produces 0.0072 seconds of drift per hour, or 0.17 frames at 24fps. This is small compared to frame rate mismatch drift but becomes measurable on 8+ hour continuous recordings. Professional timecode boxes like the Tentacle Sync E (±0.2 ppm) and Ambient Lockit (±0.2 ppm) minimize this to negligible levels.
Three Real-World Drift Scenarios
Example 1: Documentary Interview, No External Timecode, 4-Hour Duration
A documentary crew uses a Sony FX3 at 23.976fps and a Sound Devices MixPre-6 II at 24.000fps. No external timecode generator. Both devices are jammed at the start via their internal clocks. The camera menu says "24p" but the actual frame rate is 23.976fps. The audio recorder runs at true 24.000fps.
Drift calculation: The frame rate mismatch produces 3.6 seconds per hour of drift. Over 4 hours: 14.4 seconds, or approximately 345 frames at 23.976fps. The audio is 14.4 seconds ahead of picture by the end of the interview. Even if the oscillator tolerance is perfect (±0.2 ppm), the frame rate mismatch dominates. The fix: set both devices to the exact same frame rate before recording.
Example 2: Multi-Cam Event, 29.97 NDF, 8-Hour Day
Two Sony FX6 cameras and one Sound Devices 788T recorder all use free-run timecode at 29.97fps NDF. No drop-frame. By the end of the 8-hour event day, the timecode has drifted 28.8 seconds from real time (3.6 seconds per hour x 8 hours). If any device was set to 29.97fps DF instead of NDF, that device's timecode stays aligned with real time while the others drift, creating a 28.8-second offset between DF and NDF devices.
The fix: confirm all devices use the same timecode mode (NDF or DF) before the shoot. For broadcast delivery at 29.97fps, use DF on all devices. For non-broadcast work, use NDF on all devices and account for the drift in post.
Example 3: Theatrical Film, 24.000fps, Single Master Clock
A narrative feature shoots on ARRI ALEXA 35 at true 24.000fps with a Tentacle Sync E (±0.2 ppm) as the master timecode generator. All cameras and the audio recorder jam to the same generator at the start of each roll. Because 24.000fps is an integer frame rate, there is no NTSC 1001/1000 offset and no frame rate drift. The only drift source is oscillator tolerance: at ±0.2 ppm over an 8-hour day, drift is 0.0058 seconds, or 0.14 frames. This is operationally irrelevant.
The lesson: 24.000fps with a dedicated timecode generator eliminates both sources of drift. The problem only exists when fractional frame rates (23.976, 29.97) are involved, or when devices run at different frame rates.
Timecode Drift by Frame Rate and Recording Duration
The table below shows how much timecode drifts from real time at each common frame rate. Integer frame rates (24, 25, 30, 60) produce zero drift. Fractional NTSC frame rates (23.976, 29.97) produce 3.6 seconds per hour of drift with non-drop-frame timecode. Drop-frame timecode at 29.97fps reduces drift to under 0.1 seconds per hour.
| Frame Rate | Drop Frame? | Drift Per Hour | Drift Per 8-Hour Day | Use Case |
|---|---|---|---|---|
| 23.976fps | N/A (no DF standard) | 3.6 seconds | 28.8 seconds | NTSC theatrical, US broadcast |
| 24.000fps | No | 0 | 0 | True 24fps theatrical, festival delivery |
| 25fps | No | 0 | 0 | PAL regions, European broadcast |
| 29.97fps NDF | No | 3.6 seconds | 28.8 seconds | US broadcast (legacy) |
| 29.97fps DF | Yes | <0.1 seconds | <1 second | US broadcast (modern) |
| 60fps | No | 0 | 0 | High frame rate, gaming, sports |
The 23.976fps row is the most common source of drift on indie productions. The camera menu says "24p" but the actual frame rate is 23.976. The audio recorder is set to 24.000. The 3.6 seconds per hour accumulates silently until the editor discovers it on the first long take.
How to Prevent Timecode Drift on Set: Step by Step
Step 1: Decide the frame rate before day one. Match all devices exactly. If the camera shoots 23.976fps, set the audio recorder to 23.976fps. If the camera shoots 24.000fps, set the recorder to 24.000fps. Do not assume "24p" in the camera menu means 24.000fps. On most Sony, Canon, and Panasonic cameras, "24p" is 23.976fps. Check the actual frame rate in the camera's technical menu or recording metadata.
Step 2: Use a single master timecode generator. A Tentacle Sync E, Ambient Lockit, or Sound Devices timecode output serves as the master clock. All cameras and recorders jam to this one reference. This eliminates oscillator drift between devices because all devices share the same crystal after jam.
Step 3: Jam sync every camera and recorder at the start of the day. Confirm the jam took by checking the timecode display on each device. If any device shows a different timecode value after jam, re-jam it.
Step 4: Re-jam after battery swaps, lunch breaks, or location moves. Power cycling a device can reset its internal timecode reference. A 30-second re-jam after every power cycle eliminates this source of drift.
Step 5: Record timecode on an audio track (LTC) if the camera has no dedicated timecode input. The audio recorder outputs LTC to a track on the camera. In post, the editor reads the LTC from the audio track to align clips. This is the standard workflow for cameras without TC inputs, including the Sony FX3, Canon R5, and Panasonic GH6.
Step 6: In post, set the timeline to the exact frame rate of the source footage. A 23.976fps timeline with 24.000fps source footage will drift. A 24.000fps timeline with 23.976fps source footage will drift. Match the timeline frame rate to the recording frame rate, not the delivery frame rate. Use the Timecode Calculator to verify frame rate conversions.
Pro Tips and Common Mistakes
Pro Tip: Always record a slate clap even with timecode. The clap gives a visual sync point if timecode fails entirely. If the timecode generator dies mid-take, the editor can still sync manually using the clap. This is a 5-second insurance policy that saves hours of post work.
Pro Tip: Re-jam devices at least every 4 hours, even if the manufacturer claims longer stability. Crystal oscillator performance varies with temperature. A camera sitting in direct sun runs hotter than spec, and its oscillator drifts more than the published tolerance. A 30-second re-jam at lunch costs nothing and eliminates the variable.
Pro Tip: When a sync issue is discovered in post, check whether the drift is constant or accelerating. Constant drift (same offset from head to tail) means a jam was applied at the wrong frame rate. Accelerating drift (offset grows over time) means a frame rate mismatch between devices. These two problems have different fixes: constant drift needs a one-time slip, accelerating drift needs a speed correction.
Common Mistake: Mixing 23.976fps and 24.000fps on the same timeline. The drift is invisible for clips under 5 minutes but compounds over long takes. A 1-hour interview at 23.976fps placed on a 24.000fps timeline drifts 3.6 seconds by the end. The fix: confirm the exact frame rate of every source clip in the NLE project settings before editing begins.
Common Mistake: Assuming "24p" in the camera menu means 24.000fps. On most cameras, "24p" is 23.976fps. True 24.000fps is usually labeled "24.000" or requires a specific menu setting. Check the recording metadata after the first take to confirm the actual frame rate. The Timecode Calculator can verify the frame rate from the clip metadata.
Frequently Asked Questions
Does timecode drift affect short clips?
For clips under a few minutes, the drift is usually under 1 frame and not noticeable. At 23.976fps NDF, a 5-minute clip drifts 0.3 seconds, or approximately 7 frames. A 2-minute clip drifts 0.12 seconds, or approximately 3 frames. The problem appears on long takes, interviews, and live events where recording duration exceeds 30 minutes.
What is the difference between 23.976 and 24fps?
23.976 is 24 divided by 1.001, an NTSC-era timing offset. It looks identical to 24fps in playback but causes 3.6 seconds of timecode drift per hour relative to real time. True 24.000fps has no drift. The two frame rates are not interchangeable on the same timeline without speed correction.
Should I use drop-frame timecode for film?
No. 23.976fps has no drop-frame standard. Drop-frame timecode exists only for 29.97fps and 59.94fps broadcast workflows. For 23.976fps productions, use NDF timecode and account for the 3.6 seconds per hour drift in post. For 29.97fps broadcast delivery, use DF timecode on all devices.
Can I fix drift in post?
You can slip the audio by a fixed frame amount if the drift is constant. If the drift is accelerating (growing over time), the fix is a speed correction: stretch or compress the audio by the calculated percentage. Most professional NLEs (Premiere Pro, DaVinci Resolve, Avid Media Composer) can apply this non-destructively. The correction factor is: (actual clip length) / (intended clip length). For a 1-hour clip at 23.976fps that should be 24.000fps, the correction is 3600 / 3603.6 = 0.999, or a 0.1% speed reduction.
What is the cheapest way to lock timecode on a small shoot?
A Tentacle Sync E or Deity TC-1 timecode generator costs under $300 and can feed multiple cameras and a recorder. One unit on the audio recorder outputs LTC to the camera via a 3.5mm cable. For cameras without TC inputs, record the LTC on an audio track and use it for sync in post. This is the minimum viable timecode setup for any production with dual-system audio.
Related Tools and Resources
The Timecode Calculator converts between frames, seconds, and timecode values for any frame rate, and can calculate the expected drift for a given recording duration. The Frame Rate Converter helps you plan frame rate conversions and understand the drift implications. For understanding the full timecode workflow, Timecode in Film Production: The Complete Guide covers jam sync, LTC, drop-frame, and non-drop-frame with production examples. For audio delivery standards once sync is resolved, Audio Delivery Standards for Film and Television covers the submission requirements for broadcast and streaming.
External resources: The SMPTE ST 12-1 standard defines the linear timecode format. Alister Chapman's timecode sync notes provide practical guidance for cinematographers. The SMPTE timecode explained reference at vitelnk.com covers drop-frame and non-drop-frame in detail.
Lock Everything to One Reference
Timecode drift is not a mystery. It is a frame rate mismatch. 23.976 is not 24. 29.97 NDF is not real time. The fix is simple: match all devices to the same frame rate, jam to a single master clock, and re-jam after every power cycle. The math is defined in SMPTE ST 12-1 and has been understood for decades. The productions that experience drift are the ones that skipped the 30-second jam sync procedure or assumed "24p" meant 24.000fps.
This post covers drift from frame rate differences and oscillator tolerance. Other sync issues, including sample rate mismatch and clock jitter, require separate diagnosis. For productions shooting at true 24.000fps with a dedicated timecode generator, drift is a solved problem before the camera rolls.
What is the longest take you have had to sync manually, and how many frames did it drift by the end?
