TCalc.it Blog · 9 min readDrop Frame vs Non-Drop Frame Timecode
Drop frame skips frame numbers, never frames. Why 29.97 exists, the exact 3.6 seconds per hour of drift, which rate uses which, and how to tell them apart.
The short answer
Drop-frame timecode skips the frame numbers 00 and 01 at the start of every minute except every tenth minute. That is 18 skipped numbers every 10 minutes, or 108 per hour, which is what it takes to keep a 29.97 fps timecode clock in step with a wall clock. No picture is discarded. Nothing is deleted. Only the counting changes.
Non-drop frame at 29.97 counts every number in order, so it falls behind real time by 3.6 seconds every hour. Neither is wrong. They answer different questions: drop-frame answers "how long has this been playing?", non-drop answers "which frame is this?"
Colour television is why 29.97 exists
Black-and-white NTSC ran at exactly 30 frames per second. When colour was added, the colour subcarrier interfered with the audio carrier, and the fix was to slow the frame rate by a factor of 1000/1001. Thirty became 29.97, and every colour NTSC broadcast since has run 0.1% slow so that 1950s television sets could keep receiving it.
SMPTE timecode, standardised later, counts in whole frames: 00 through 29, then the second increments. It has no way to express 29.97 of anything. So the timecode clock ticks off 30 frames while only 29.97 elapse, and it runs fast. The 1000/1001 factor is the single number underneath all of this, and it turns up again in 23.976, in 47.952 kHz audio, and in the 48.048 kHz sample rate that sound recordists use to pre-compensate for it.
The drift is 3.6 seconds per hour
Timecode hours × 1.001 = real hours. One hour of non-drop timecode at 29.97 takes 3,603.6 real seconds to play. Over a broadcast day that is nearly a minute and a half.
| Elapsed timecode | Behind wall clock by | In frames |
|---|---|---|
| 1 minute | 0.06 s | ~2 frames |
| 10 minutes | 0.6 s | 18 frames |
| 1 hour | 3.6 s | 108 frames |
| 1 hour (23.976) | 3.6 s | 86 frames |
| 24 hours | 86.4 s | 2,592 frames |
Read the table the other way and it explains a question that comes up constantly in delivery: one real hour of programme ends at timecode 00:59:56:12, not 01:00:00:00. If a broadcaster asks for a 44-minute programme measured in real time, the timecode duration you cut to is 43:57.4, not 44:00.
How the skipping actually works
At the start of every minute, frame numbers 00 and 01 are skipped. So the count runs 59:29 then 01:00:02, never 01:00:00. The exception is every tenth minute, where nothing is skipped.
00:09:59:29 → 00:10:00:00 (tenth minute, nothing skipped)
Nine skips of two numbers per ten minutes is 18 numbers, or 108 per hour. The exact correction needed is 107.892 numbers per hour, so drop-frame overcorrects by 0.108 frames every hour. It is accurate to about 8.6 milliseconds per hour, or roughly two frames a day. Precise, not exact.
Reading it: semicolon means drop-frame
The separator before the frame count tells you which you are looking at. A colon is non-drop, a semicolon is drop-frame.
01:00:00;00 = drop frame
Some software writes the semicolon before every field, some only before the frames, and some substitutes a full stop. If the separator is ambiguous, the reliable test is to scrub to the first frame after a minute boundary. If it reads 02 rather than 00, it is drop-frame.
Which rates can even have drop-frame
| Frame rate | Drop-frame? | Separator | Notes |
|---|---|---|---|
| 23.976 | no | : | The dominant delivery rate. Drift is unfixable by numbering. |
| 24 | no | : | True 24. Timecode and wall clock agree exactly. |
| 25 | no | : | PAL. Exact, no drift. |
| 29.97 | yes | ; (DF) or : (NDF) | The only rate where the choice exists. |
| 30 | no | : | Exact. Rare outside of some archival work. |
Drop-frame only exists at 29.97 and its multiples. It was designed around the relationship between 30 and 29.97, and the arithmetic does not transfer.
What everyone gets wrong
"Drop-frame drops frames"
It drops numbers. Your picture is untouched, your audio is untouched, the file is the same length either way. The name is a fifty-year-old piece of bad branding that has confused every generation of editors since. If drop-frame actually discarded frames, cutting a sequence to drop-frame would shorten it, and it does not.
"Use drop-frame and the drift goes away"
Only at 29.97. At 23.976, which is now the dominant rate for scripted delivery and most streaming, there is no drop-frame standard at all. The timecode counts 24 numbers per second while 23.976 frames elapse, so it drifts by the same 3.6 seconds per hour, and there is no numbering trick available to fix it.
This is the source of the most-reported timecode complaint in editing forums: a sequence reads 00:39:59:19 and the exported file reports 40 minutes 2 seconds. Both numbers are correct. 40 minutes of timecode is 57,600 frames, and 57,600 ÷ (24000/1001) = 2,402.4 seconds. The 2.4 seconds are arithmetic, not a bug.
"A mismatch means someone's clock drifted"
Usually not, and the slope tells you which it is. A drop-frame versus non-drop mismatch between two devices grows at 108 frames per hour of elapsed time-of-day. Genuine crystal drift between two decent recorders grows at roughly 1 to 2 frames per hour. Measure the offset at two known points, divide by the time between them, and the answer is unambiguous.
elapsed 02:00:00:00 → 100 frames drifted over 2 hours ≈ 50 f/hr → not crystal drift
When to use which
Use drop-frame when the number has to match a clock: broadcast delivery, commercial spots sold by duration, anything with a slot time, live programming, and any deliverable whose spec names a running time. Use non-drop when the number has to identify a frame: VFX pulls, conform, dailies, and archive, where a continuous unbroken count is worth more than clock accuracy.
The rule that prevents most problems is duller than either: whatever the delivery spec says, set it on the camera, in the recorder, and in the sequence before the first day of shooting. Changing it in post is a conform problem, not a settings change.
Doing the arithmetic
Timecode does not add or subtract like a decimal number. Frames carry at the frame rate, seconds and minutes at 60, hours at 24, and drop-frame skips numbers in the middle of all that. The manual method is to convert to a total frame count, do the sum, and convert back.
TCalc treats timecode as a first-class value, so the conversion step disappears and you can mix timecode, plain durations and raw frame counts in one expression:
01:12:04:09 - 01:12:00:21 + 48f (a cut plus VFX handles)
22:10 to 06:30 (a night shoot, across midnight)
The timecode calculator has the frame rates preset, and the editor layout puts frame arithmetic and a configurable default fps on the keypad.
Frequently asked questions
- Does drop-frame timecode delete frames from my footage?
- No. It skips frame numbers in the count. The picture, the audio and the file duration are identical either way.
- How do I tell drop-frame from non-drop at a glance?
- The separator before the frames: 01:00:00;00 is drop-frame, 01:00:00:00 is non-drop. If your software is inconsistent about separators, scrub to the frame after a minute boundary: drop-frame reads 02, non-drop reads 00.
- Is there drop-frame at 23.976?
- No, and there never has been. Drop-frame was designed around the 30 to 29.97 relationship. At 23.976 the timecode drifts by the same 3.6 seconds per hour and nothing in the numbering can correct it.
- Why is my export longer than my sequence?
- At 23.976 or 29.97 non-drop, a sequence duration read in timecode is not a real-time duration. Multiply by 1.001 to convert: 40:00 of timecode plays for 40 minutes 2.4 seconds.
- How many frames does drop-frame skip in an hour?
- 108. Two at the start of each minute, except the tenth, twentieth, thirtieth, fortieth, fiftieth and sixtieth minutes, which are skipped from the skipping.
- Can I change from non-drop to drop-frame after the edit is locked?
- You can change how a sequence displays timecode, but any notes, EDLs, cut lists or VFX pulls made against the old numbering will no longer line up. Treat it as a conform, not a preference.
The part that is still unsettled
Drop-frame exists because a 1953 compromise about colour subcarriers is still baked into a delivery chain that has otherwise moved on entirely. Streaming has no broadcast slot to fill, and 23.976 already abandoned the attempt to make the numbers match the clock. Whether it makes sense to keep dragging 1000/1001 through file-based workflows that never touch an NTSC transmitter is a fair question, and one the standards bodies have not answered. Until they do, the drift is 3.6 seconds an hour and it is yours to track.