23.976 vs 25 fps: why your sync drifts — frame rate mismatches explained

The symptom: perfect at the head, wrong at the tail

The classic report from the edit suite goes like this: the sync point lines up exactly. Lips match for the first minute or two. By minute five the audio is visibly early or late, and by the end of a 20-minute interview it is off by more than a second. Re-syncing at the tail breaks the head. Nothing was bumped, nothing dropped out — the offset just grows, smoothly and linearly.

Linear growth is the fingerprint that matters. Random dropouts jump; a bad sync point is a constant offset; oscillator drift wanders slightly with temperature. An error that accumulates at a perfectly steady rate means two clocks are running at different speeds — and when the rate difference works out to one of two magic numbers, 0.1% or 4.1%, the cause is a frame rate mismatch, not hardware.

Where 23.976 comes from — and why it refuses to die

Film runs at 24 fps. European television runs at 25 fps, locked to 50 Hz mains history. American colour television runs at 29.97 fps because in 1953 the NTSC colour subcarrier had to avoid interference with the audio carrier, and the fix was to slow the 30 fps monochrome rate by the ratio 1000/1001. Every “fractional” rate you meet is that same ratio applied somewhere else: 30 → 29.97, 60 → 59.94, and 24 → 23.976 (precisely 24,000/1001 = 23.976023… fps), invented so film-originated material could sit cleanly in the 29.97 broadcast chain via 2:3 pulldown.

The broadcast reason is gone; the rate is not. Camera menus call it “24p” when the sensor is actually running 23.976, streaming platforms accept it, and an enormous amount of mirrorless and cinema camera footage is shot at it by default. Meanwhile 25 fps remains the standard across Europe for broadcast and most corporate work. Any production that mixes American-market defaults with European-market defaults — or true 24 with “24p” — has planted a sync problem that will only show up in post.

The three mismatches and their real drift numbers

1. 23.976 vs true 24: the 0.1% pulldown

The ratio 1001/1000 means one device counts 0.1% slower than the other. In concrete terms:

• 1 ms of drift per second of running time.
• One full frame (at 24 fps, 41.7 ms) every ~42 seconds.
• 60 ms per minute — visibly out of lip-sync (the broadcast tolerance is roughly 40 ms) within the first minute and a half.
• 3.6 seconds per hour — the same figure known from drop-frame timecode, because it is the same ratio.

This is the trap hiding inside the word “24”. A camera shooting “24p” (actually 23.976) with an audio recorder generating true 24-frame timecode — or a sound recorder set to “24” while the camera menu says “23.98” — produces exactly this drift. Both devices are healthy. Both clocks are accurate. They are counting different seconds.

2. 25 vs 23.976 (or 24): a 4.1–4.2% speed gulf

Between 25 and 23.976 the difference is not subtle: 25/23.976 ≈ 1.0427. Nothing accidentally “drifts” by 4%; instead this mismatch breaks things categorically. Timecode-based sync fails immediately, because the two devices do not even agree what a frame number means — frame 12 of a second exists on both, but lands at different points in real time, and the counts diverge mid-second. A 25 fps B-camera or drone dropped into a 23.976 timeline either gets retimed by the NLE (with a 4.2% slow-down and a semitone-ish pitch shift if its audio comes along) or plays at the wrong speed with duplicated or skipped frames. The good news: because the error is huge, it is caught early. The bad news: the common “fix” — letting the NLE conform speed silently — quietly destroys any timecode relationship the clip had.

3. 48 kHz vs 48.048: audio pulldown

The 1000/1001 ratio also exists on the audio side. Some field recorders and DSLR-era workflows record at 48.048 kHz (48 kHz × 1001/1000) so that when the file is later played at 48 kHz it slows by exactly 0.1% and matches pulled-down picture. If a 48.048 file is imported as if it were 48 kHz — or vice versa — you get the same 1 ms/s drift as case 1, from the audio side. Check the actual sample rate in the file header, not the label on the recorder; and note that some recorders write 48.048 samples but stamp the header 48000 deliberately, which is invisible until you measure duration against timecode.

Diagnosis: mismatch or clock drift?

Genuine oscillator drift — two crystals free-running after a jam-sync — is typically a few parts per million: tenths of a frame per hour (the timecode drift guide covers that failure mode in depth). A pulldown mismatch is 1,000 ppm, two orders of magnitude larger. Separating them takes two measurements and one division:

1. Measure the offset at the head. Sync on a clap, a slate, or a waveform transient near the start. Note the residual offset (ideally zero).
2. Measure the offset at the tail. Find a transient near the end of the same take — a door, a plosive — and measure how far audio leads or lags picture there.
3. Divide drift by duration. Offset grew by 600 ms over 10 minutes? 600 ms / 600 s = 0.1% — pulldown mismatch, case closed. Offset grew by 15 ms over 10 minutes? That is 25 ppm — a free-running clock, fixed by re-jamming on set, not by conforming.

Two corroborating checks: a rate mismatch produces the same ratio on every clip pair from the same two devices, all day — oscillator drift varies with temperature and resets at power cycles. And the file metadata usually confesses: compare the video stream’s exact frame rate (23.976 vs 24.000 vs 25.000) and the audio file’s true sample rate against what the production thought it was shooting. On timecode-carrying material, a 23.976 file whose timecode counts 24 frames per labelled second is expected — that is how 23.976 timecode works — but its “seconds” are 0.1% long in real time, which is exactly the discrepancy you measured.

The fixes, from set to timeline

On set (free): pick one frame rate family and make every device sign up to it. 25 fps productions: cameras at 25, recorder timecode at 25, no “24p” B-roll from someone’s personal camera. 23.976 productions: make sure devices offering both “24” and “23.98” all say the same thing — those are different rates, 0.1% apart, and mixing them is this article’s case 1. Audio at plain 48 kHz unless the workflow explicitly calls for 48.048.

In the NLE (after the fact): the repair is a 0.1% retime of one side, applied before sync, not a hand-slip at the tail:

• Premiere Pro: right-click the clip → Modify → Interpret Footage. For picture at the wrong rate, assume the correct frame rate; for drifting audio, a 100.1% (or 99.9%) constant speed adjustment on the audio clip — or resample the WAV externally — brings it onto the picture’s clock. Interpret Footage is non-destructive and survives relinking.
• DaVinci Resolve: clip attributes → Video → frame rate for picture; for audio, retime controls or a conformed copy. If you group angles, fix rates before building the multicam — Resolve’s sync map assumes a common clock, as covered in the multicam sync guide.
• Audio-side conform: sample-rate convert the recording by 1000/1001 (48,000 → 47,952 playback or the reverse) in any decent audio tool. Do it once, at full quality, and keep the original.

What not to do: stretch audio by ear until the tail looks right (the ratio will be almost-but-not-quite 0.1%, and every other clip needs its own guess), or cut the take into chunks and re-sync each one (the classic sign a mismatch was never diagnosed — and a conform pass later will scatter those hand-fixes).

Fail modes that keep this problem alive

• “24” that means 23.976. Camera menus, NLE labels and rental-house paperwork round it away. Treat any “24” or “23.98” you did not verify as unknown until the file says otherwise.
• Mixed-market kits. A European 25 fps shoot with an American-default action camera or drone at 29.97/23.976 in the bag. Every such file needs conforming or retiming — budget for it or ban it.
• Timecode that “matches” but does not. Two devices can display the same numbers at the clap and still count at different rates; matching start stamps only guarantees sync at one instant. This is why timecode-first workflows still verify against the waveform.
• Silent NLE conforms. Dropping a mismatched clip into a timeline often “works” because the NLE retimes it without asking — until audio from that clip is exported, or the project moves to another system that interprets the rate differently.
• The 48.048 header lie. Audio pulldown workflows that write incorrect sample-rate headers on purpose. If a file’s duration × sample rate does not match its sample count, believe the samples.

Where Launchr Post fits

Launchr Post reads the actual rates out of every file it ingests — the video stream’s exact frame rate, the audio’s true sample rate, and the timecode’s counting rate — rather than trusting labels. When it syncs a shoot day, it matches by timecode first and refines against the waveform, so a clip pair that lines up at the head and walks off at a steady 0.1% stands out immediately in the sync report, named as a rate mismatch rather than left for the editor to discover at minute five. Everything runs locally on your Mac, and the report states per clip which clock was trusted.