What is drop-frame timecode?

Q: Exactly which frame numbers are skipped?

At 29.97 fps drop-frame, ;00 and ;01 are skipped at the start of every minute except minutes divisible by ten. At 59.94 fps drop-frame, ;00 through ;03 are skipped under the same rule — twice as many, because the rate is twice as high, so the same real-time correction needs twice as many frame numbers removed per minute.

Q: How many frames are in 10 minutes of 29.97 drop-frame timecode?

17,982 — not the 18,000 you would get by multiplying 30 fps by 600 seconds. The 18 fewer frames are exactly the 18 frame numbers dropped across the nine non-exempt minutes in that span (2 per minute × 9 minutes).

Q: How can I tell if a timecode I'm looking at is drop-frame?

By convention, a semicolon before the frames field — 01:00:00;00 — marks drop-frame, and a colon — 01:00:00:00 — marks non-drop-frame. Some software is inconsistent about the separator, so if you have access to the sequence or project settings, the frame-rate field there is the more reliable source.

Drop-frame timecode skips certain frame numbers, never actual frames, so that the displayed clock keeps tracking real elapsed time at 29.97 and 59.94 fps instead of slowly falling behind it. Here is the exact rule, why the correction is shaped the way it is, and a converter to try it on your own numbers.

Frame rate

Timecode

Frame number

Timecode A

Operation

Frame count

The rule, stated precisely

At 29.97 fps drop-frame, the frame numbers ;00 and ;01 are skipped at the start of every minute, except minutes whose number is divisible by ten (:00, :10, :20, :30, :40, :50). At 59.94 fps drop-frame, four frame numbers — ;00 through ;03 — are skipped under the identical rule. That is the entire specification. Everything else — every formula, every worked example on this page — is a consequence of that one sentence.

The most important word in it is numbers. Nothing about a video frame is deleted, blended, or repeated. If you have 30 frames of picture captured in one real second, you still have 30 frames of picture in that second whether you are looking at drop-frame or non-drop-frame timecode. The only thing the rule changes is which text label — HH:MM:SS;FF — is printed under a given frame.

Why the correction exists at all

29.97 fps is not 30 fps. It is exactly 30000/1001 frames per second, which works out to roughly 29.97002997… — about one tenth of one percent slower than a clean 30. That tiny difference exists for a historical engineering reason: see 29.97 vs 30 for the full derivation.

If you simply counted every second as 30 frames — non-drop-frame timecode — the displayed clock would very slowly fall behind real elapsed time, because real time keeps passing at the true, very slightly slower rate while the label increments as if it were exactly 30. Over one real hour the gap is 3.6 seconds. That is not large in absolute terms, but it compounds: over a full day of continuous recording it is more than a minute and a half, enough to make a timecode-driven schedule, a caption sync, or a broadcast automation trigger measurably wrong.

Drop-frame timecode was devised to prevent that drift from accumulating, by periodically skipping frame numbers so the label stays close to real time indefinitely, without changing the actual video signal at all.

Deriving the exemption

Here is the arithmetic that explains why minutes divisible by ten are left alone, rather than dropping frame numbers in every minute uniformly.

In one real minute, 29.97 fps produces 29.97 × 60 = 1798.2 frames. A non-drop-frame clock counting at a nominal 30 fps would expect 30 × 60 = 1800 frames in that same minute — 1.8 more than actually occurred. Over ten minutes, that gap is 10 × 1.8 = 18 frames.

If two frame numbers were dropped every single minute, ten minutes would remove 10 × 2 = 20 frame numbers — two more than the actual 18-frame gap, overcorrecting. Exempting one minute in ten removes frame numbers in only nine of the ten minutes: 9 × 2 = 18, matching the real drift exactly. That is the entire reason for the minute-ten exemption: it is not an arbitrary carve-out, it is the number that makes the correction land on the true rate instead of overshooting it.

The same arithmetic scales to 59.94: in one minute, the true rate produces 59.94 × 60 = 3596.4 frames against a nominal 60 × 60 = 3600 — a gap of 3.6 frames per minute, 36 over ten minutes. Dropping four frame numbers in nine of ten minutes removes 9 × 4 = 36, again matching exactly.

The closed-form formula

Rather than looping frame by frame, the conversion used throughout this site is a single expression:

frameNumber = nominal×3600×h + nominal×60×m + nominal×s + f
              − dropFrames × (totalMinutes − floor(totalMinutes / 10))

where totalMinutes = 60h + m, nominal is 30 or 60, and dropFrames is 2 or 4. The subtracted term counts exactly how many frame numbers have been dropped by the time you reach a given h:m:s:f: the total number of minutes elapsed, minus the number of those minutes that were multiples of ten (which contributed nothing to the count).

The inverse — going from a frame number back to h:m:s:f — adds that dropped count back in, worked out from how many complete ten-minute blocks the frame number has passed and how far into the current block it sits.

Quick reference

Quantity	29.97 fps DF	29.97 fps NDF	59.94 fps DF
Frame numbers dropped per non-exempt minute	2	0	4
Frames in 10 minutes	17,982	18,000	35,964
Frames in 1 hour	107,892	108,000	215,784
Real time for 1 “hour” of nominal timecode	3,599.9964 s	3,603.6 s	3,599.9964 s
Drift from real time per hour	≈3.6 ms	≈3.6 s	≈3.6 ms

Every value above is reproduced exactly by the converter on this page — type 00:10:00;00 or 01:00:00;00 into the Timecode ↔ Frame tab under any of these rates and read off the frame count yourself.

Common misconceptions

“Drop-frame is less accurate than non-drop-frame”

The opposite is true. Drop-frame timecode is more accurate as a real-time clock — that is its entire purpose. Non-drop-frame is arithmetically simpler (a plain integer frame rate, no exemptions to remember), which is a real advantage for editorial math done by hand, but it is the one that drifts against a wall clock, not drop-frame.

“Drop-frame skips a frame every second”

No — it skips two frame numbers (or four, at 59.94) at the start of most minutes, not every second, and it skips numbers rather than frames regardless. A timecode display that appeared to jump every second would indicate a fault, not correct drop-frame behaviour.

“You can hear or see the difference in playback”

You cannot. Drop-frame versus non-drop-frame is purely a labelling convention layered on top of identical picture and sound. Play the same piece of footage back with each labelling scheme selected and every frame appears at the same instant, in the same order, at the same rate — the numbers printed under the picture are the only thing that changes.

“29.97 drop-frame and 30 fps NDF are the same thing, just labelled differently”

Not quite — this is close but conflates two separate facts. 29.97 fps DF and 29.97 fps NDF are the same underlying frame rate with two labelling conventions, and converting between them changes only the text. A plain 30 fps rate, however, is a genuinely different, exact frame rate with no fractional drift at all — it happens to share the same nominal frame-counting arithmetic as 29.97 NDF, which is why the two are easy to conflate, but a file shot at true 30 fps and one shot at 29.97 and labelled non-drop-frame are not interchangeable; only one of them actually runs at 30.000 frames per second.

Where drop-frame actually matters day to day

For projects that stay entirely inside an editing timeline and are delivered as a file for streaming, drop-frame is close to invisible — most editing software handles the labelling automatically and the exported file carries no burned-in dependency on it. It becomes concretely important in a handful of specific situations:

Broadcast delivery specifications. Many broadcast masters intended for NTSC-legacy markets are still required to carry drop-frame timecode matching the true frame rate, because downstream broadcast automation, closed-captioning insertion, and as-run logging systems key their scheduling off the timecode track directly.
Multi-camera and long-form live-to-tape production. When several cameras or an entire live broadcast need to stay synchronised to a real-world clock for hours at a time, non-drop-frame's 3.6-second-per-hour drift becomes a real scheduling problem; drop-frame timecode is what keeps a timecode-driven cue sheet aligned with the actual wall clock.
Legacy tape-based workflows and EDLs. Edit decision lists exported from or imported into older systems frequently assume drop-frame at 29.97, and getting the labelling wrong produces an EDL that conforms one or two frames off at every reel boundary.
ADR and dubbing sessions timed against a broadcast clock. Voice recording sessions scheduled against real elapsed time for a long-form project benefit from drop-frame's closer real-time tracking over the length of a session.

Outside those contexts — a short-form web video, most narrative features finishing at 23.976 or 24, anything delivered purely as a streamed file — the choice barely matters in practice, which is part of why the rule feels obscure to anyone who has not personally hit one of the situations above.

Worked examples

1. Crossing into a non-exempt minute

Select 29.97 fps DF above, type 00:00:59;29, note the frame number, then add 1 frame on the Arithmetic tab.

00:00:59;29  +1 frame  →  00:01:00;02

Minute 1 is not a multiple of ten, so the moment it begins, frame numbers ;00 and ;01 are skipped — the next frame after ;29 is labelled ;02, not ;00.

2. Crossing into an exempt minute

00:09:59;29  +1 frame  →  00:10:00;00

This time the label lands cleanly on ;00, because minute 10 is a multiple of ten and the drop rule specifically excludes it. Nothing is skipped here at all.

3. Ten minutes, in frames

Enter 00:10:00;00 on the Timecode ↔ Frame tab and read the frame number: 17,982, not the 18,000 a naive 30 × 600 would suggest. The 18-frame difference is exactly the 18 frame numbers skipped across minutes 1 through 9 (2 each), with minute 10 contributing none.

4. One full hour

01:00:00;00 at 29.97 DF is frame 107,892. Switch to the Timecode ↔ Real Time tab with the same value: the exact real elapsed time is 3,599.9964 seconds — 3.6 milliseconds short of a clean hour. Compare that to reading the same 108,000-frame count (a plain 30 fps NDF “hour”) at the true 29.97 rate: 3,603.6 real seconds, a full 3.6 seconds off. Drop-frame is roughly a thousand times closer to real time over the same span.

5. Confirming there is no drop-frame at 25 fps

Switch the rate selector to 25 fps (PAL): there is no drop-frame option to choose, because 25 is an exact integer rate with no fractional drift to correct. The same is true for 24 fps. Only 29.97 and 59.94 carry a drop-frame variant in this tool, matching the SMPTE ST 12-1 standard itself.

Frequently asked questions

Does drop-frame timecode delete any video?

No. It skips frame numbers, never frames of picture or sound. Every captured frame plays, in order, at the same rate, in both drop-frame and non-drop-frame labelling. Only the HH:MM:SS:FF text attached to a given frame differs between the two.

Exactly which frame numbers are skipped?

At 29.97 fps drop-frame, ;00 and ;01 are skipped at the start of every minute except minutes divisible by ten. At 59.94 fps drop-frame, ;00 through ;03 are skipped under the same rule — twice as many, because the rate is twice as high, so the same real-time correction needs twice as many frame numbers removed per minute.

Why are minutes divisible by ten exempt?

Because dropping frame numbers every single minute overcorrects the drift. The true rate is 30000/1001, about 0.1% slower than 30 — over ten minutes at 30 fps nominal that is a drift of 18 frames (10 × 1.8), not 20 (10 minutes × 2 dropped). Exempting one minute in ten removes exactly 18 frame numbers over that span (9 minutes × 2), matching the drift precisely instead of over-correcting it.

How many frames are in 10 minutes of 29.97 drop-frame timecode?

17,982 — not the 18,000 you would get by multiplying 30 fps by 600 seconds. The 18 fewer frames are exactly the 18 frame numbers dropped across the nine non-exempt minutes in that span (2 per minute × 9 minutes).

Is there a drop-frame version of 24 fps or 25 fps?

No. Drop-frame exists specifically to correct the drift caused by a true rate of exactly N × 1000/1001 against a nominal integer N. 24 fps and 25 fps are exact integers with no such drift, so there is nothing for a drop-frame rule to correct.

How can I tell if a timecode I'm looking at is drop-frame?

By convention, a semicolon before the frames field — 01:00:00;00 — marks drop-frame, and a colon — 01:00:00:00 — marks non-drop-frame. Some software is inconsistent about the separator, so if you have access to the sequence or project settings, the frame-rate field there is the more reliable source.

More on timecode

See all the tools on this site →