Drop-frame vs non-drop timecode, explained
Drop-frame timecode confuses people because its name is a lie: nothing is dropped from your footage. It is one of the most common sources of "the timecode doesn't match" errors in post, and it comes down to a fraction. Here is what is really going on, and how to do the maths without getting burned.
Why 29.97 exists at all
When colour was added to NTSC television, the frame rate was nudged from a clean 30 fps down to 29.97 fps (and 60 to 59.94) for technical compatibility. Timecode, though, still counts 30 frames per second. That tiny gap adds up: run non-drop timecode at 29.97 fps for an hour and the counter reads about 3.6 seconds ahead of a real clock. For broadcast, where a "one-hour" programme must actually be one hour, that drift is unacceptable.
What "drop-frame" actually does
Drop-frame fixes the drift by skipping frame numbers - not frames. Specifically, it drops the first 2 frame numbers (00 and 01) at the start of every minute, except every tenth minute. Over 10 minutes that is 18 skipped labels, which almost exactly cancels the 29.97 error. At 59.94 fps the same rule drops 4 numbers per minute. No picture is ever removed - the count just jumps from, say, 00:00:59;29 to 00:01:00;02.
The tell is the separator. Non-drop writes a colon before the frames: 01:00:00:00. Drop-frame writes a semicolon (or a period): 01:00:00;00. If you see that semicolon, you are in drop-frame - and your maths must account for it.
Non-drop is still fine - just not clock-accurate
Non-drop timecode at 29.97 is perfectly valid and widely used, especially where an exact real-time match doesn't matter. It counts every frame sequentially with no skips, which makes frame arithmetic simpler. The trade-off is only that its "one hour" is a few seconds long. Integer rates - 24, 25, 30, 60 - never need drop-frame because there is no fractional drift to correct.
Where the maths goes wrong
The classic mistake is adding two drop-frame timecodes as if they were non-drop, or converting a frame count to timecode without applying the drop rule. Because 18 labels vanish every 10 minutes, a naive addition can be off by many frames over a long timeline - enough to push a delivery out of spec. The safe method is to convert each timecode to an absolute frame count, do the arithmetic in frames, then convert back using the correct drop-frame rule.
Do it correctly in your browser
Editorial Toolkit's timecode calculator uses the canonical drop-frame algorithm, so you don't have to. It:
- Converts frames ↔ timecode at 23.976, 24, 25, 29.97 DF, 30, 59.94 DF and 60.
- Auto-detects drop-frame from a semicolon in the input, and lets you force it on with a checkbox.
- Adds and subtracts timecodes in the frame domain, then formats the result correctly for the chosen rate.
Pick the frame rate, type a timecode or frame count, and read the answer - all locally, nothing uploaded.
Carrying it through a conversion
Drop-frame status also travels with your cut. When you convert an EDL to OTIO or FCPXML, make sure the frame rate you set matches the source sequence, so that a 29.97 drop-frame EDL is not silently read as 30 fps non-drop. Getting the rate right at import is the single biggest thing that keeps record timecodes lined up downstream.
Tracking a show, not just a timecode
If frame-accurate timecode is feeding a larger delivery - conforming shots, checking handles and ranges, comparing turnovers - Cutlist Tracker builds on the same formats and frame-rate handling to run a full conform check and per-department delivery matrix across your cut. Editorial Toolkit gets the numbers right; Cutlist Tracker keeps the whole show on the rails.