A cue that lands on the first cut and arrives late on the last one is drifting, and the cause is almost always the frame rate the picture was exported at. One divisor does nearly all of the damage. Dividing 24 by 1.001 gives 23.976, dividing 30 by 1.001 gives 29.97, and the resulting error is 0.0999 percent, which works out to 59.94 ms per minute of programme and 3.596 seconds per hour. Inside the first bar it hides. Across a ten-minute reel it becomes a missed cut. What follows is where that number comes from and which direction to apply it in.
How fast does the drift actually accumulate?
At one part in 1001 the arithmetic stays linear and easy to keep in your head. A minute of programme accumulates 59.94 ms of error, three minutes accumulate 179.8 ms, ten minutes accumulate 599.4 ms, and an hour accumulates 3.596 seconds. ITU-R BT.1359-1, the recommendation broadcasters use for the relative timing of sound and vision, puts the detectability threshold at +45 ms where sound is advanced on vision and -125 ms where it lags. Run the two figures together and the answer is uncomfortable: a 0.1 percent error crosses the 45 ms line about 45 seconds into the reel. Music gets judged harder than dialogue here, because a hit point is measured against a visible cut instead of a moving mouth. One frame at 24 fps is 41.67 ms, so a hit landing two frames late at 83 ms reads as sloppy to everyone in the room, including the people who cannot say why.
Where does the 1001 come from?
From the arrival of colour television in the United States. To fit a colour subcarrier into a signal that black and white receivers still had to decode, engineers moved the field rate off 30 by a factor of 1.001, which produced 29.97. Film at 24 followed the same divisor down to 23.976 so that a transfer needed one correction instead of two. Frame.io's account of timecode and frame rates traces that decision and its consequences. The result is countable. An hour at a nominal 30 fps should contain 108,000 frames. At 29.97 it contains 107,892. The gap is 108 frames, or 3.6 seconds, and every problem in this article is a different face of the same 108.
How many samples sit inside one frame at 48 kHz?
This is the cheapest sanity check available. At 48 kHz, 24 fps gives exactly 2000 samples per frame, 25 fps gives 1920, and 30 fps gives 1600. At 23.976 fps the figure is still a whole number, 2002, because 48,000 x 1001 / 24,000 divides cleanly. At 29.97 fps it is 1601.6, and that fraction is why 29.97 sessions cause more grief than 23.976 sessions carrying the same 0.1 percent offset. It is also the reason 48 kHz became the delivery rate for picture work. Netflix's technical specification for image and sound processing asks for 48 kHz 24-bit polyphonic BWAV sound rolls and lists 23.976, 24, 25 and 30 as the frame rates supported for its Atmos deliverable. Which files a placement needs beyond that, I covered in an earlier note on sync delivery.
Which direction do you pull, and by how much?
Two directions, one number. Moving from film speed to video speed the audio slows by 0.1 percent, which is a pull down, and 48,000 Hz becomes 47,952.048 Hz. Moving the other way the audio speeds up by the same amount, a pull up, and 48,000 becomes 48,048. The three-two pull down process that put 24 fps film onto 29.97 video is where the convention was set.
There are two ways to apply the correction and they behave differently. Changing the clock plays the same samples at a new rate, so nothing is resampled and the pitch moves by 1200 x log2(1.001), which is 1.73 cents. Resampling holds the rate and converts the sample count, so the pitch stays put and the quality of the conversion starts to matter. On its own 1.73 cents is inaudible. It stops being inaudible when a pulled cue has to sit against a source cue that nobody pulled, because then two copies of the same reference pitch are 1.73 cents apart and a sustained note beats slowly against itself. PAL work sits in a different bracket. Going from 25 to 24 is 4.167 percent, or 70.7 cents, which is most of a semitone, and it has to be resampled.
Why does drop frame timecode not fix any of this?
Because it renumbers frames and leaves the pictures alone. Drop frame skips two timecode values at the start of every minute except every tenth minute, which is 2 x 54 = 108 skipped numbers per hour, cancelling the 3.6-second labelling error exactly. No picture is removed and no audio is touched. The clock on the wall now agrees with the timecode display, and the sample rate relationship underneath is unchanged. A session set to 29.97 drop frame whose audio was recorded at true 30 fps speed still drifts by 3.596 seconds per hour. Drop frame answers the question of what to call a frame. It says nothing about how many samples pass while that frame is on screen.
What do you check before the first cue?
Three answers from the picture editor, in this order. The project frame rate. Whether the QuickTime was exported at that rate or conformed to it from something else, since a 23.976 file exported out of a 24 fps timeline is the exact case that produces silent drift. And the timecode of the first frame, because 01:00:00:00 and 00:59:58:00 both turn up in the wild, and the second usually means a two-pop is sitting two seconds ahead of picture start.
Then run the tail test. Import the picture with a burned-in timecode window, park on the last frame of the reel, and compare the burn-in against the session timecode. Agreement at the head proves nothing, because a drifting session agrees at the head by definition. Agreement at the tail to within 1 frame means there is no rate error left to chase. The test takes about 20 seconds on a 10-minute reel, and it stands between fixing a rate error before the first cue and re-conforming a session that was already finished.
Frequently asked
Why does my music start in sync and end late? The picture and the audio are running at rates that differ by 0.1 percent, which accumulates 59.94 ms per minute and 3.596 seconds per hour. Set the session to the picture's real frame rate, or apply a pull up or pull down in the correct direction.
Is 23.976 the same as 24 fps? No. 23.976 is 24 divided by 1.001. A file exported at one rate and played at the other drifts by 0.0999 percent, which is roughly one frame every 42 seconds at 24 fps.
Does drop frame timecode cause audio drift? No. Drop frame skips 108 timecode numbers per hour so that the timecode display agrees with the clock. It removes no frames and changes no sample rate, so any drift present came from somewhere else.
If a cue is going to picture this week
Get the frame rate in writing, set the session to it before recording anything, and run the tail test on the burn-in as well as the head. If the number that comes back is 23.976 or 29.97, work at that rate from the start, because pulling a finished cue afterwards adds a conversion the schedule rarely has room for. Full credit list with sources at /credits, background and contact at /about.