Timecode Drift Calculator

Why NDF drifts and DF doesn't

The cause fits in one sentence: 29.97 fps is exactly 30 x 1000/1001, so a timecode counter that labels 30 frames every second is counting 0.1% slower than the video actually plays. Run the exact fraction through: 30 divided by (30000/1001) = 1001/1000 = 1.001 -- not a rounded approximation, an exact ratio, because 29.97 fps is defined as 30000/1001, not a decimal. That means one second of non-drop (NDF) timecode label corresponds to 1.001 real seconds, and the gap between the two -- 1.001 minus 1 = 0.001 -- is exactly 0.1%. So for any program timed to L labeled seconds, the real running time is L times 1.001, and the drift is:

drift (seconds) = L x 0.001

That is the whole derivation. No rounding, no fudge factor -- it falls straight out of the 1001-based definition of the NTSC-derived rate family.

The pinned markers, worked

Take the 22-minute row in full, since it is the one worth checking by hand: 22 minutes = 1,320 seconds. Drift = 1,320 x 0.001 = 1.32 seconds. Converted to frames at 29.97 fps: 1.32 x 29.97 is about 39.56, which rounds to about 40 frames. Run the same arithmetic across the standard program lengths broadcast QC actually times against:

22 and 44 minutes are not arbitrary -- they are the standard US half-hour and hour-long broadcast content lengths once commercial time is stripped out, which is exactly the running time a delivery QC pass times a program against. A 44-minute program that was cut and timed entirely on NDF timecode is roughly 2.64 seconds -- about 79 frames, well over two seconds -- ahead of where its own on-screen counter says it should be relative to the wall clock. On air, against a hard out-cue or a network junction point, that is not a rounding error; it is a missed break.

Drop-frame: the fix, and its own (much smaller) residual

Drop-frame timecode (DF) corrects this by skipping frame labels 00 and 01 at the start of every minute except each tenth minute -- 108 skipped labels per hour -- which realigns the counter to the wall clock without touching a single frame of picture. DF is not perfect either: because the correction happens in whole-frame jumps rather than continuously, it leaves a residual of approximately 3.6 milliseconds per hour -- roughly a thousand times tighter than NDF, and small enough that it only accumulates to a full frame after about 9.3 hours of continuous roll. For any program at normal broadcast lengths, that residual is functionally zero.

When NDF is still the right call

Drop-frame is not free -- the discontinuous numbering complicates edit math and confuses anyone reading timecode off a monitor. So NDF stays the right default for short-form work (anything under about ten minutes keeps drift under a second), for film-adjacent post at 23.976 fps (which has no drop-frame equivalent at all -- 23.976 is a slowed-down true-24 rate, not a broadcast-native NTSC rate, so there is no SMPTE drop-frame spec for it and the 0.1% drift is simply lived with or corrected downstream), and for any workflow that never has to line up against a hard broadcast automation out-cue.

Drift in seconds is rate-family-invariant -- 23.976 and 59.94 drift the identical seconds as 29.97, because the 0.1% comes from the shared 1000/1001 ratio; only the frame count differs, since 59.94 counts twice as many labels per second as 29.97.

Once a program is confirmed to be timed on the wrong scheme, this chart tells you how much it is off by -- to actually relabel a set of timecodes from NDF to DF (or back), use the DF/NDF Subtitle Timecode Converter.

1. Pick a frame rate family - the 29.97 or 59.94 NTSC-derived rates where drop-frame applies.

2. Read the drift at the five pinned markers: 30 seconds, 22 minutes, 44 minutes, 90 minutes and 2 hours, each in seconds and frames.

3. Type your own program length for an exact figure, or convert a time-of-day timecode with the Timecode and Wall-Clock Calculator.