Drop-frame timecode, explained properly

Drop-frame timecode drops frame numbers, not frames. No picture is ever discarded — the counting scheme just skips two frame labels each minute (except every tenth minute) so that timecode at 29.97 fps stays in step with the clock on the wall. You can spot it instantly by the semicolon: 01:00:00;02 is drop-frame, 01:00:00:02 is non-drop. This guide explains why the scheme exists, exactly how the skipping works, when you must (and must not) use it — and where to check the math on a real timecode.

Why 29.97 exists at all

Blame color television. Black-and-white NTSC ran a clean 30 frames per second; when color arrived in 1953, engineers had to squeeze a color subcarrier into the existing broadcast channel without breaking millions of black-and-white sets. The fix was to slow the frame rate by exactly 0.1% — to 30000/1001 ≈ 29.97 fps. Analog broadcasting is history; the 0.1% lives on in every NTSC-region camera, timeline, and deliverable spec (and its doubled sibling, 59.94).

The 3.6-second problem

Timecode counts whole frames and assumes 30 of them per second. At 29.97 fps, reality falls behind the label:

• One hour of clock time at 30 fps = 108,000 frames.
• One hour at 29.97 fps = 107,892 frames — 108 fewer.
• So after one real hour, non-drop timecode reads only 00:59:56;12 — it's drifted 3.6 seconds behind the clock (Frame.io's timecode guide walks the same math).

For editing, that drift is harmless — every frame still has a unique, ordered label. For broadcast, where a 58:30 program had better end at 58:30 on the master clock, it isn't.

How drop-frame fixes it

The scheme: skip frame numbers 00 and 01 in the first second of every minute — except minutes 00, 10, 20, 30, 40, and 50.

So the counter runs …00:00:59;29 → 00:01:00;02 (numbers ;00 and ;01 never appear that minute), but at the ten-minute marks it counts straight through. That skips 2 × 54 = 108 frame numbers per hour — exactly the discrepancy — so drop-frame timecode crosses 01:00:00;00 at one real hour, on the nose.

Again, nothing is dropped from the video. Every frame exists; some labels don't. That's the whole trick.

When to use which

• Drop-frame (semicolons): 29.97 and 59.94 material headed for broadcast or any deliverable where program duration is measured in clock time. US broadcast specs generally require it.
• Non-drop (colons): everything that isn't 29.97/59.94 — 23.976, 24, 25 (PAL never had this problem), 30, 50, 60 — plus 29.97 workflows where frame count matters more than wall-clock, like some VFX and archival contexts.
• Never mix them silently. A 29.97 DF sequence receiving NDF timecode (or vice versa) puts every event up to 3.6 s/hour out of position — the classic "why is my conform drifting" bug, and the first thing to check when an EDL lands offset in a timeline.

Note the trap in the names: "30 fps" on a spec sheet usually means 29.97, and true 30.00 is rare. When a tool asks, answer with the exact rate — it changes the math.

Doing the math without hurting yourself

Drop-frame arithmetic is genuinely annoying by hand — adding durations across skipped numbers, converting frames to real seconds at 30000/1001. The free timecode calculator does it correctly for 29.97 DF and 59.94 DF (frame counts, real elapsed time, and rate conversions in both keep-the-moment and keep-the-count modes), and the frame rate converter handles re-expressing a timecode at a different rate. The same drop-frame-aware math runs inside the SRT to Avid TXT and EDL to CSV converters, which is why their output lines up when the source is NTSC.

FAQ

What is drop-frame timecode? A timecode counting scheme for 29.97/59.94 fps material that skips two frame numbers each minute (except every tenth minute) so timecode matches real clock time. It drops labels, never actual frames of video.

How do I tell drop-frame from non-drop timecode? The last separator: a semicolon (01:00:00;02) means drop-frame; a colon throughout means non-drop. Most NLEs follow this convention in timelines and burn-ins.

Does drop-frame timecode delete frames from my video? No — this is the most common misconception. Every frame is preserved; only certain frame numbers are skipped in the count, the way some buildings skip a 13th floor without removing a storey.

Why does non-drop timecode drift 3.6 seconds per hour? An hour of real time at 29.97 fps produces 107,892 frames, but 30 fps-style counting expects 108,000. The 108-frame gap equals 3.6 seconds per hour — exactly what the 108 skipped numbers per hour compensate for.

Should I use drop-frame for YouTube or web video? Duration accuracy barely matters on the web, so either works — but stay consistent with your footage: if the camera shot 29.97 DF, keep the sequence DF and you'll never fight an offset.

Does PAL (25 fps) have drop-frame? No. 25 fps divides evenly into real time, so PAL timecode never drifts and has no drop-frame variant. Drop-frame exists only because of NTSC's 0.1% slowdown at 29.97/59.94.