Whole-frame SMPTE math at every delivery rate - drop-frame included - plus the two numbers your NLE keeps to itself: the real elapsed time, and whether you meant the difference or the inclusive duration.
Premiere, Avid and Resolve all count the Out frame, so their Duration column is one frame longer than Out − In. An EDL record-out is not: it is exclusive.
Same frames, 0.1% apart: the running time moves by 00:00:01.425. This is pull-down.
Scripted and streaming delivery. Drifts 3.6s per hour and cannot be corrected.
Whole-frame math. Drop-frame, pull-down and the inclusive-duration question, answered together.
Frame rate for bare timecodes
A timecode is a frame count wearing a clock face, and the two stop agreeing the moment the rate is fractional. One hour of 23.976 timecode is 86,400 frame numbers, and those frames take 3,603.6 seconds to play. That 3.6 seconds is not a rendering fault, a setting, or a drifting crystal - it is the 1000/1001 factor that colour television left behind in 1953, and it is still in every streaming deliverable shipped today.
Everything here is computed in whole frames and only converted to seconds at the end, which is the only way drop-frame comes out right. Pick a rate, type a timecode the way you would type it into Premiere - colons, semicolons or just the digits - and read back the frame count, the real running time, and both readings of the duration.
Reference
| Rate | Frames per second | Frames in 01:00:00:00 | Real length of that hour | Used for |
|---|---|---|---|---|
| 23.976 | 24000/1001 | 86,400 | 01:00:03.600 | Scripted and streaming masters. No drop-frame exists. |
| 24 | exact | 86,400 | 01:00:00.000 | Theatrical, DCP. Timecode is real time. |
| 25 | exact | 90,000 | 01:00:00.000 | PAL broadcast - UK, EU, Australia. |
| 29.97 NDF | 30000/1001 | 108,000 | 01:00:03.600 | US broadcast when the number must identify a frame. |
| 29.97 DF | 30000/1001 | 107,892 | 00:59:59.996 | US broadcast when the number must match a clock. |
| 30 | exact | 108,000 | 01:00:00.000 | Web and screen capture. Not a broadcast rate. |
| 50 | exact | 180,000 | 01:00:00.000 | PAL-region HD and UHD sport. |
| 59.94 NDF | 60000/1001 | 216,000 | 01:00:03.600 | US live and sport, continuous count. |
| 59.94 DF | 60000/1001 | 215,784 | 00:59:59.996 | US live and sport, clock-matched. Skips 4 numbers a minute. |
| 60 | exact | 216,000 | 01:00:00.000 | Web, gaming, 60Hz-region UHD. |
The fourth column is the one that causes arguments. At the three NTSC rates a timecode hour takes 3,603.6 real seconds, because the label counts whole frame numbers while the frames themselves arrive 0.1% slower. Drop-frame closes that gap to 3.6 milliseconds by skipping numbers - read drop frame vs non-drop frame for how the skipping works and when to pick which.
The complaint that never stops
Sequence at 23.976 reads
00:40:00:00
MediaInfo reports
00:40:02.400
Both numbers are right. Forty minutes of 23.976 timecode is 57,600 frame numbers, and 57,600 frames at 24000/1001 take 2,402.4 seconds to play. The 2.4 seconds are arithmetic, not a render fault, and no setting removes them.
It scales linearly: 1.8 seconds every half hour, 3.6 every hour. If a broadcaster asks for a 44-minute programme measured in real time, the 23.976 timecode duration you cut to is 00:43:57:09, not 00:44:00:00. The same maths explains every "my export is three seconds long" thread on the Adobe and Blackmagic forums.
Duration vs difference
In Premiere, Avid and Resolve the In and the Out are both part of the clip, so the Duration column reads Out − In + 1 frame. Mark In and Out on the same frame and the duration is one frame, not zero. Subtract the two timecodes by hand and you are a frame short of what the NLE will tell you.
EDLs go the other way: an EDL record-out is exclusive, one frame past the last frame you can see. That single convention mismatch is behind most "my conform is one frame off" threads, and it is why the calculator above prints both numbers side by side instead of picking one and hoping.
Difference (Out − In)
00:23:45:12
What subtraction gives you. What an EDL means. What a gap between two marks measures.
Duration (inclusive)
00:23:45:13
What the NLE's Duration column says, and what a runtime on a delivery spec means.
Pull-down
| Conversion | Factor | What it does to you |
|---|---|---|
| 24 → 23.976 | 1000/1001 (0.1% slow) | 86,400 frames take 3,603.6s instead of 3,600 - 3.6 seconds longer, every hour, forever. |
| 23.976 → 24 | 1001/1000 (0.1% fast) | The same 86,400 frames take 3,600s instead of 3,603.6. Pull-up is the exact mirror. |
| Audio pull-down | 48000 → 47952 Hz | Sound that should have been pulled and was not drifts 3.6s an hour: in sync at the slate, a second out by the end of a 30-minute reel. |
| Audio pull-up | 48000 → 48048 Hz | What a recordist sets to pre-compensate, so the 48kHz file lands in sync at 23.976. |
| 2:3 pulldown | 23.976 → 29.97 | Four progressive frames become five interlaced ones (ten fields, 2-3-2-3). The 0.1% slow-down happens first; the cadence is the second step. |
| 24 → 25 (PAL) | 25/24 (4.167% fast) | Not a 0.1% problem at all. A 100-minute film runs 96 minutes, and the audio needs 50kHz or a pitch shift. |
Set the calculator to 23.976, put your duration in, then pick 24 in the "same frames at" row. The gap it prints is the pull-down, in the units your delivery spec is written in.
Every timecode question reduces to one conversion, done twice. A timecode label is turned into a whole number of frames, the arithmetic happens on that number, and the number is turned back into a label. Doing it any other way - adding the fields column by column, or going via seconds - is where the off-by-one-frame errors come from, because the frame field rolls at the frame rate while the fields above it roll at 60, and at the NTSC rates the seconds field is not a second.
The one subtlety worth internalising: the frame field counts at the nominal rate, not the true one. A 23.976 timecode counts 00 to 23 exactly as 24 does, and a 29.97 timecode counts 00 to 29 exactly as 30 does. The fractional part never appears in the label. It only appears when you ask how long the frames take to play, which is a different question and the one your delivery spec is usually asking.
A timecode hour at 24: 3,600 seconds of 24 frame numbers each.
The same hour of drop-frame, 108 numbers lighter - and 3.6 milliseconds off a real hour rather than 3.6 seconds.
Two seconds of VFX handles at 23.976 is 48 frames, and 48 frames take 2.002 seconds. The two-second handle is not two seconds.
All three show you a timecode and a duration. None of them shows you the real elapsed time of a selection, which is the number a broadcaster's slot, a YouTube upload limit and a client's "keep it under two minutes" are all measured in. At 25 fps that omission costs nothing. At 23.976 it costs 3.6 seconds an hour, and it is invisible until the deliverable comes back rejected.
The second omission is the frame at the end. Mark In and Out on the same frame in Premiere and the Duration column reads one frame, not zero, because both marks are part of the selection. Subtract the two timecodes by hand and you get zero. Neither is wrong, but only one of them is what you meant, and an EDL exported from the same sequence uses the other convention again - its record-out is exclusive. The recurring "my conform is one frame off" thread is almost always this, not a media problem.
Third, the two spellings. Avid labels 29.97 drop-frame as 30DF and writes a semicolon before the frames; After Effects greys the drop-frame option out entirely unless the composition is 29.97. If your notes came from one app and your timeline is in another, the safest test is to scrub to the first frame after a minute boundary. Drop-frame reads 02, non-drop reads 00.
The sequence and the file disagree by two seconds, and both are telling the truth.
Difference or inclusive duration. The calculator above prints both rather than choosing for you.
Drop-frame never issues :00 or :01 at a minute that is not a multiple of ten. Typing one is an error, and the calculator says so.
The keypad reads a bare timecode at whichever rate you selected above it, so the same expression follows your project instead of a hard-coded 24.
Pull-down in one line. An hour of 23.976 is 3.6 seconds longer than an hour of true 24, and the suffix is what makes the engine treat 23.976 as 24000/1001 rather than the decimal.
Out minus In at PAL 25. The NLE Duration column will read one frame more than this - 00:23:45:13 - because it counts the Out frame.
Carry across seconds, minutes and the hour boundary at 30 fps, with the frame field rolling at 30 rather than 60.
Raw frame counts mix with everything else. A bare f uses the selected rate; f24 pins that term to 24 whatever the project is.
Convert both to frame counts, add, convert back. Frames carry at the frame rate and seconds and minutes at 60, so at 24 fps 00:59:30:00 + 00:01:15:12 = 01:00:45:12. The calculator above does the conversion for you at any rate, including drop-frame, where the frame numbers are not a straight count.
23.976, 24, 25, 29.97 in both drop-frame and non-drop, 30, 47.952, 48, 50, 59.94 in both drop-frame and non-drop, and 60. The NTSC rates are treated as the exact rationals 24000/1001, 30000/1001, 48000/1001 and 60000/1001, not as their decimal spellings - the difference is 3.6 milliseconds per timecode hour, which is small but real.
No. It skips frame numbers 00 and 01 at the start of every minute except every tenth, which is 18 numbers every ten minutes and 108 an hour. No picture is discarded and the file length is identical either way. At 59.94 it skips four numbers a minute, 216 an hour.
Because at 23.976 and 29.97 non-drop the timecode counts whole frame numbers while the frames themselves arrive 0.1% slower. Forty minutes of 23.976 timecode is 57,600 frames, and 57,600 divided by 24000/1001 is 2,402.4 seconds - 40 minutes and 2.4 seconds. Both numbers are correct and no setting removes the gap.
One frame more, in every NLE. Premiere, Avid and Resolve treat both the In and the Out as part of the clip, so mark In and Out on the same frame and the duration is one frame, not zero. EDLs are the exception: an EDL record-out is exclusive, one frame past the last frame you see. The calculator prints both numbers so you never have to remember which convention you are in.
86,400 at 23.976 and 24, 90,000 at 25, 108,000 at 29.97 non-drop and 30, 180,000 at 50, 216,000 at 59.94 non-drop and 60. Drop-frame counts fewer numbers for the same hour: 107,892 at 29.97 and 215,784 at 59.94.
Pull-down is playing 24 fps material at 23.976, exactly 1000/1001 of the speed. It makes an hour of source run 3.6 seconds longer, and it is why 48kHz audio has to be pulled to 47,952 Hz to stay in sync - or recorded at 48,048 Hz to pre-compensate. Sound that should have been pulled and was not is in sync at the slate and a second out by the end of a 30-minute reel.
Yes. The keypad treats a timecode as a value like any other, so 01:00:00:00 + 30s + 12f is a legal expression, and the result can be read back as timecode, as a frame count in real seconds, or as plain hours and minutes.
Free to embed
Post house, film school, rental desk, a wiki page your team keeps reopening - paste the snippet and the calculator runs on your page. No tracking, no account, nothing to keep updated. All we ask is the credit line the snippet already includes.
<iframe id="tcalc-timecode" src="https://tcalc.it/widgets/timecode"
title="Timecode calculator" width="100%" height="920" loading="lazy"
style="border:0;max-width:520px"></iframe>
<p><a href="https://tcalc.it/timecode-calculator">Timecode calculator</a> by TCalc.it</p>
<script>addEventListener('message',function(e){var h=e.data&&e.data.tcalcTimecodeHeight;if(h)document.getElementById('tcalc-timecode').style.height=h+'px'})</script>The last line is optional: it lets the iframe shrink to fit once it has loaded, so a narrow column does not clip the calculator and a wide one does not leave a gap. Drop it and the fixed height still works everywhere.
The embed lives at /widgets/timecode and sits alongside the other TCalc widgets.