Timecode Calculator: Drop Frame vs Non Drop 29.97

Q: Does drop frame actually delete frames?

No, and the name is why this question keeps being asked. Not a single picture is discarded. Drop frame skips numbers in the counter, the way a hotel skips the thirteenth floor. Every frame you shot is still in the file, in order, and can still be played, cut and exported. What changes is only what the counter calls them.

Q: Why does timecode usually start at 01:00:00:00?

Two practical reasons. Everything before the programme, bars and tone, a slate, a countdown, black, needs somewhere to sit, and if the programme starts at zero all of that lands on negative timecode, which most systems handle badly or refuse outright. Starting at one hour leaves a full hour of room. The second reason is the midnight rollover: timecode counts to 23:59:59 and wraps to zero, and arithmetic that crosses that join produces nonsense.

Convert timecode to frames and frames to timecode at any rate, and see exactly what drop frame is doing to your clock at 29.97 and 59.94. The difference is 3.6 seconds an hour, and it is the reason your programme came out short.

What this calculator is for

Timecode is an address system for frames. This page converts between the address and the frame number in both directions, at every common rate, and it is strict about drop frame in a way most converters are not.

Editors checking a duration. You need to know whether a timeline that reads 00:28:30:00 will actually run 28 minutes 30 seconds when somebody puts a stopwatch on it. At 29.97 non drop, it will not.
Anybody reading an EDL, a report or a spreadsheet. Frame numbers are what arithmetic works on. Timecode is what humans read. This converts between them without you counting on your fingers.
Anybody handed a delivery specification. Broadcasters specify a rate and a drop frame setting, and getting either wrong costs a redelivery.
Anybody who has just discovered that two cameras disagree. The section on mixing the two below is the one you want.

How the conversion actually works

Non drop is the easy half. The frame number is simply how many frames have gone by.

Non drop: frames = (hours x 3600 + minutes x 60 + seconds) x rate + frame count. At 29.97 non drop the rate used for counting labels is 30, not 29.97, which is exactly where the trouble starts.

Work one. 00:10:00:00 at 29.97 non drop is 600 seconds times 30, which is 18,000 frames. Now ask how long 18,000 real frames take at 29.97002997 frames per second, and the answer is 600.6 seconds. The label said ten minutes. The world took ten minutes and 0.6 seconds.

Drop frame fixes that by removing labels from the counting.

Drop frame at 29.97: count the labels as if the rate were 30, then subtract 2 for every minute that has passed, except every tenth minute. At 59.94 the same idea removes 4 labels per minute instead of 2.

Work one. 00:10:00;00 at 29.97 drop frame. Ten minutes of labels at 30 a second is 18,000. Nine of those ten minutes drop two labels each, and the tenth does not, so 18 labels come out. 18,000 minus 18 is 17,982 frames, and 17,982 frames at 29.97002997 fps is 599.9994 seconds. The label now agrees with the clock to within a thousandth of a second.

Scale it to an hour and the same arithmetic gives 108,000 labels minus 108 dropped, which is 107,892 frames, or 3,599.9964 seconds. That is the number this whole convention exists to produce.

Drop frame does not drop frames

Start here, because the name has confused people for sixty years. Drop frame timecode never discards a single picture. Every frame you shot is still there. What gets dropped is a label, a number in the counter, and nothing else.

Here is why it exists. NTSC video does not run at 30 frames per second. It runs at 30000/1001, which is 29.97002997 and a bit. If you count timecode labels at a flat thirty a second, your counter runs slightly faster than the wall clock. After an hour of real time the counter reads 01:00:03:18, which is 3.6 seconds ahead. Over a broadcast day that is 86 seconds, and in an industry that sells thirty second slots, 86 seconds is a disaster.

The fix was to skip labels. Drop frame timecode does not use the first two frame numbers of every minute, except every tenth minute. So the label after 00:00:59;29 is 00:01:00;02, and 00:01:00;00 and 00:01:00;01 simply do not exist. Nine minutes out of ten lose two labels each, which is eighteen labels per ten minutes, and that is almost exactly the error. The clock and the wall now agree to within a fraction of a frame per hour.

This calculator refuses to accept a timecode that drop frame never writes. Type 00:01:00;00 as drop frame and it tells you the label does not exist rather than quietly sliding you to a neighbouring frame. That behaviour is the whole reason this page exists.

The drift, shown

The same number of real frames, labelled both ways, with the error in the last column. This is what you are choosing between.

29.97 fps, the same footage counted both ways
Real elapsed time	Drop frame reads	Non drop reads	Non drop error
1 minute	00:00:59;28	00:00:59:28	0.07 s
10 minutes	00:10:00;00	00:09:59:12	0.6 s
30 minutes	00:30:00;00	00:29:58:06	1.8 s
1 hour	01:00:00;00	00:59:56:12	3.6 s
2 hours	02:00:00;00	01:59:52:24	7.2 s
8 hours	08:00:00;01	07:59:31:07	28.77 s
12 hours	12:00:00;01	11:59:16:25	43.17 s

The error is a flat 0.1 percent, so it grows with the length of the piece and with nothing else. At one minute it is 0.06 seconds and invisible. At ten minutes it is 0.6 seconds. At half an hour, 1.8. At an hour, 3.6 seconds. On a two hour feature, 7.2 seconds. Across a full broadcast day, 86 seconds.

Here is the case that catches people. Cut a programme to exactly 00:28:30:00 of non drop timecode and you have 51,300 frames, which at 29.97 fps is 1,711.71 seconds of real time, or 28 minutes 31.7 seconds. The timeline says 28:30. The stopwatch says 28:31.7. If a broadcaster has ever told you a programme runs long while your timeline swore it did not, this is the whole explanation.

When to use which

Use drop frame when the timecode has to match real elapsed time. Broadcast delivery with a hard duration, anything live, anything where the clock is a contract.

Use non drop when you want simple, continuous, arithmetic friendly numbers and the duration is not being policed to the second. A lot of post production runs on non drop for exactly that reason: every minute has 1800 frames, no exceptions, and mental arithmetic stops being a minefield.

The only real sin is mixing them inside one job. Two cameras, one set to drop frame and one to non drop, will look synchronised for the first minute and then slide apart in a way that is genuinely painful to untangle in the edit.

Writing it down

The convention is a semicolon or a full stop before the frames for drop frame, and a colon for non drop. So 01:00:00;00 is drop frame and 01:00:00:00 is not. Software mostly respects this. People mostly do not, which is why the frame rate selector on this page is explicit rather than guessed from the punctuation.

What 23.976 does about all this

Nothing, and that surprises people. 23.976 is also a 1000/1001 rate and it drifts against the wall clock in exactly the same way. There is no standard drop frame scheme for it, because the arithmetic does not land as neatly as it does at 29.97. So 23.976 timecode is always non drop and always slightly slower than real time, and everybody has agreed to live with it. If you need real elapsed time on a 23.976 job, read the running time, not the timecode.

The rates that never need any of this

Drop frame is a fix for one specific problem, and most frame rates do not have that problem.

24, 25, 30, 50 and 60 are exact. A second contains a whole number of frames, so the labels and the clock agree by construction. There is no drift and therefore nothing to correct. If a piece of software offers you drop frame at 25 fps, it is offering you something that does not exist.

29.97 and 59.94 are the only two that drift and have a fix. Both are 1000/1001 rates and both have a standard drop frame scheme, removing 2 labels a minute at 29.97 and 4 at 59.94. One hour of non drop at 59.94 is 216,000 labels against 215,784 in drop frame, and again the difference is 3.6 seconds of real time.

23.976 drifts and has no fix. It is also a 1000/1001 rate and it runs slow against the wall clock in exactly the same way, but there is no standard drop frame scheme for it, because the arithmetic does not land neatly. So 23.976 timecode is always non drop and always slightly slow, and the whole industry has agreed to live with it. One hour of 23.976 timecode is 86,400 frames, which is 3,603.6 seconds. If a 23.976 job needs true elapsed time, read the running time and not the timecode.

Mixing the two is the only real mistake

Choosing drop frame is defensible. Choosing non drop is defensible. Having both on one job is not, and it fails in a particular way that is worth recognising.

Two cameras, one set to drop frame and one to non drop, agree perfectly for the first minute. Then the drop frame camera skips two labels and the non drop one does not, and from there they slide apart by two frames per minute, except every tenth minute. Half an hour into a multicamera shoot they are 54 labels apart, which is 1.8 seconds, and it is not a constant offset you can nudge back into place because it grows in steps.

The fix is a decision, not a technique. Pick one before the first camera rolls, write it on the call sheet next to the frame rate, and check the menu on every body. It takes a minute at the start of the day and it is the reason someone does not spend an evening realigning a sequence by hand.

Why timecode usually starts at 01:00:00:00

Look at almost any professional master and the programme begins at exactly one hour rather than at zero. That is a convention with two practical reasons behind it, and once you know them you will never set a timeline to zero again.

The first is that everything before the programme needs somewhere to live. Bars and tone, a slate, a countdown, black. All of that sits before the first frame of picture, and if the programme starts at zero then all of it has to sit at negative timecode, which most systems either refuse or handle badly. Start at one hour and there is a full hour of room in front of you.

The second is the midnight rollover. Timecode counts to 23:59:59 and then wraps to zero. A programme that begins near the end of that range crosses the wrap partway through, and any arithmetic that runs across the join produces nonsense. Starting at one hour keeps a normal programme comfortably clear of both ends.

Timecode is not a timestamp

They look alike and they answer different questions, which is a good source of confusion in any workflow that touches both.

A timestamp records when something happened in the world. Two files with the same timestamp were created at the same moment. Timecode records where a frame sits in a sequence. Two files with the same timecode occupy the same position on a timeline, and that is exactly what you want when you are synchronising cameras and sound, because you are asking which frames belong together rather than what time it was.

The practical difference shows up in the edit. Sorting rushes by timestamp gives you the order in which the files were written, which is often not the order in which anything was shot, because cards get offloaded out of sequence. Sorting by timecode gives you the order the day actually happened, provided the cameras were jammed to the same source. That is the whole argument for jamming timecode in the first place.

Common questions

What is the difference between drop frame and non drop frame?

Drop frame skips two frame labels at the start of every minute except every tenth minute, so the counter keeps pace with real time at 29.97 fps. Non drop counts every label, which makes the clock run 3.6 seconds fast every hour. Neither one discards a picture.

Why does 00:01:00;00 not exist in drop frame?

Because those are two of the labels drop frame skips. At 29.97 the label after 00:00:59;29 is 00:01:00;02. A calculator that accepts 00:01:00;00 as drop frame is quietly giving you a different frame than the one you asked for.

How many frames are in one hour at 29.97 fps?

One hour of drop frame timecode is 107,892 frames, which is one hour of real time. One hour of non drop labels is 108,000 frames, which is 3,603.6 seconds of real time.

Does drop frame actually delete frames?

No, and the name is the reason this question keeps being asked. Not a single picture is discarded. Drop frame skips numbers in the counter, the way a hotel skips the thirteenth floor. Every frame you shot is still in the file, in order, and can still be played, cut and exported. What changes is only what the counter calls them.

Is 29.97 always drop frame?

No. 29.97 is a frame rate. Drop frame is a labelling scheme you can apply to it or not, and both are legitimate. Broadcast delivery normally requires drop frame because the duration is contractual. A lot of post production runs 29.97 non drop because the arithmetic is simpler and nobody is policing the running time to the second. What matters is that everyone on the job made the same choice.

Should I use drop frame or non drop frame?

Use drop frame when the clock is a contract: broadcast delivery with a hard duration, anything live, anything where somebody will time the programme. Use non drop when you want clean arithmetic and the exact duration is not being enforced, because every minute then holds exactly 1,800 frames with no exceptions. If a delivery specification names one, that decision has already been made for you.

What does drop frame do at 59.94?

The same thing at twice the scale. It skips four labels at the start of every minute except every tenth minute, instead of two. One hour of 59.94 non drop is 216,000 labels and one hour of drop frame is 215,784, and the difference is the same 3.6 seconds of real time as at 29.97, because both rates drift by the same 0.1 percent.

How do I convert timecode to seconds?

Convert to frames first, then divide by the true frame rate rather than the nominal one. That second step is where most people go wrong. At 29.97 the true rate is 30000/1001, not 30. So 00:10:00:00 non drop is 18,000 frames, and 18,000 divided by 30000/1001 is 600.6 seconds. Dividing by 30 instead gives 600, which is the answer that looks right and is not.

How do I count the frames in a clip?

Subtract the start timecode from the end timecode in frames, using the frames mode above for both, then add one if you want the count to include the last frame. That last part causes more disagreements than the arithmetic does. A clip running from frame 100 to frame 199 contains 100 frames, not 99, and different applications make different assumptions about whether the out point is included.

Why does timecode usually start at 01:00:00:00?

Two practical reasons. Everything that comes before the programme, bars and tone, a slate, a countdown, black, needs somewhere to sit, and if the programme starts at zero then all of that lands on negative timecode, which most systems handle badly or refuse outright. Starting at one hour leaves a full hour of room. The second reason is the midnight rollover: timecode counts to 23:59:59 and wraps to zero, and any arithmetic that crosses that join produces nonsense, so a normal programme is kept clear of both ends.

Is timecode the same as a timestamp?

No. A timestamp records when a file was made. Timecode records where a frame sits in a sequence. Two clips with the same timecode belong at the same point on a timeline, which is exactly what you want when synchronising cameras and sound. Two files with the same timestamp were merely written at the same moment, which is often just the order somebody offloaded the cards in.

Timecode Calculator: Drop Frame Against Non Drop