Frames to Timecode Calculator (SMPTE, Drop Frame and Non-Drop)

Background.

A frame count is not a time. Turning one into the other looks like simple division until you meet 29.97 frames per second, at which point the obvious arithmetic quietly produces the wrong answer and keeps producing it for as long as the timeline runs. This calculator converts a frame count into a SMPTE-style time address and back again at ten frame rates, and it counts drop-frame correctly, which is the entire reason the page exists.

Start with where 29.97 comes from. It is not a rate anyone chose for its own sake; it is 30000/1001, a rate adopted when colour information was fitted into an existing monochrome broadcast signal, and ITU-R BT.2020 still lists the family that way today — 24/1.001, 30/1.001, 60/1.001 alongside their whole-number siblings. The consequence is that a counter ticking at a nominal 30 frames per second while the pictures actually arrive at 30000/1001 gradually falls behind real time. SMPTE quantifies it exactly: counting non-drop at a rate that is a multiple of 30/1.001 "will yield a deviation of approximately +3.6 seconds in one hour of elapsed time". After a day that is about a minute and a half.

Drop-frame counting is the fix, and it is misnamed in a way that misleads almost everybody who meets it. Nothing is dropped from the picture. What is omitted is a pair of *labels*. The SMPTE rule, quoted from the standard: the first two frame numbers, 00 and 01, are omitted from the count at the start of each minute except minutes 00, 10, 20, 30, 40 and 50. So 00:00:59;29 is followed directly by 00:01:00;02 — the frames 00:01:00;00 and 00:01:00;01 never existed as addresses, though the pictures that would have carried them are all still there. Skipping 2 numbers in 54 of every 60 minutes removes 108 labels an hour, which is almost exactly the accumulated error, and reduces the residual drift from 3.6 seconds to about 3.6 milliseconds. Over 24 hours the leftover error is roughly 86 milliseconds, or 2.6 frames.

That is why this page treats the counting mode as a first-class choice rather than a checkbox. Feed the same 107,892 frames to the two 29.97 modes and you get 01:00:00;00 in drop-frame and 00:59:56:12 in non-drop — a difference of nearly four seconds on the same physical hour of footage. Neither is wrong; they are different labelling schemes over identical pictures, which is precisely why an edit list cut against one and conformed against the other lands in the wrong place.

Drop-frame only exists at rates that are multiples of 30, and only at the fractional ones. There is no 24 fps or 25 fps drop-frame — 25 fps is an exact integer rate with nothing to compensate for, and SMPTE states directly that drop frame is not applicable to multiples of 24-frame counting. That is why the frame-rate menu here pairs a drop and a non-drop option for 29.97 and 59.94, and offers a single option for everything else.

The calculator also refuses two things that most converters silently allow. It rejects a frame count of a full day or more, because a SMPTE address runs 00:00:00:00 to 23:59:59 and then starts over, so 24:00:00:00 is not an address. And it rejects a drop-frame timecode that names a number the rule omitted: type 00:01:00;00 and you will be told why it does not exist rather than handed a plausible frame number for a frame that was never labelled. Alongside the conversion you get the true elapsed time computed from the exact fractional rate, and the drift between that and what the address reads — the number that makes the whole drop-frame business make sense in one line.

What is frames to timecode calculator?

SMPTE timecode is a label attached to every frame of a video or audio recording, written as hours:minutes:seconds:frames and progressing like a 24-hour clock from 00:00:00:00 to 23:59:59 and the last frame of that second. It is defined in SMPTE ST 12-1 and extended for high frame rates in ST 12-3. Because it labels frames rather than measuring time directly, its relationship to the clock depends on the frame rate and on the counting mode. At exact integer rates such as 24, 25, 30, 50 and 60 the label and the clock agree perfectly. At the fractional NTSC-derived rates — 23.976, 29.97 and 59.94, which are really 24000/1001, 30000/1001 and 60000/1001 — they do not, and two counting modes exist. Non-drop frame numbers every frame consecutively and accepts that the address falls behind real time. Drop frame omits selected frame numbers on a fixed schedule so the address stays within milliseconds of the clock. This calculator converts between an elapsed frame count and a time address in either direction, applies the correct counting rule for the rate you pick, and reports both the true elapsed time and the residual drift.

How to use this calculator.

1. 01Choose the direction. "Frames to timecode" turns a frame count from a codec report, an FFmpeg readout or a render queue into an address. "Timecode to frames" does the reverse, which is what you want when you need an absolute frame number for a script or an EDL.
2. 02Pick the frame rate — and if it is 29.97 or 59.94, pick the counting mode deliberately. Broadcast deliverables are usually drop-frame; film-originated and online material is often non-drop. If you do not know, look at the separator your editing software prints before the frames field: a semicolon almost always means drop-frame.
3. 03For frames-to-timecode, enter the frame count. Count the first frame as frame 0, the way the standard does, so a clip of N frames runs from frame 0 to frame N minus 1.
4. 04For timecode-to-frames, type the address. Colons, semicolons, periods and commas all work as separators and leading zeros are optional, so 1:0:0:0 is accepted for 01:00:00:00.
5. 05Read the drift line to see how far the address has strayed from the clock. In non-drop 29.97 it grows steadily to about 3.6 seconds an hour; in drop-frame it stays within a few milliseconds.
6. 06Check the skipped-frame-numbers figure if you are reconciling two counts that disagree. The gap between a drop-frame and a non-drop address over the same footage is exactly that number of frames.

The formula.

Non-drop counting needs no explanation beyond division. The frame count is split by the nominal rate into seconds, the seconds into minutes, the minutes into hours, and whatever is left over is the frames field. At 30 nominal, frame 107,892 is 3,596 whole seconds and 12 frames, which is 00:59:56:12.

Drop-frame counting works by putting the omitted numbers back before doing that division. The rule omits d numbers at the start of every minute except every tenth, so a ten-minute block contains 600n − 9d frames rather than 600n: at 30 nominal with d = 2 that is 18,000 − 18 = 17,982 frames per ten minutes, and each dropped minute holds 60n − d = 1,798 frames. Given a frame count f, count how many complete ten-minute blocks have passed, add back 9d numbers for each of them, then add back d more for each complete dropped minute inside the partial block. The result is the count that the ordinary division above expects, and splitting it gives the address.

The inverse runs the same idea backwards. Convert the address to a naive frame count as if nothing had ever been dropped, then subtract d for every minute that was subject to the rule — that is the total number of minutes minus the tenth minutes, or (60·hours + minutes) − ⌊(60·hours + minutes)/10⌋. At 01:00:00;00 that is 60 − 6 = 54 dropped minutes, 108 omitted numbers, and 108,000 − 108 = 107,892 frames.

Real elapsed time never uses the nominal rate. It is the frame count divided by the exact rate — 30000/1001, not 29.97 — because the rounded decimal is off by about one part in ten million, which is enough to move the answer by several frames across a feature-length timeline. The drift figure is that true elapsed time minus what the address reads, and it is the cleanest way to see what the two counting modes are actually doing: at the end of a nominal hour it is about +3.6 seconds in non-drop and about −3.6 milliseconds in drop-frame.

One consequence worth internalising: the two modes label the same pictures, so an hour of footage is 107,892 frames in both. It is the address that differs, not the material.

A worked example.

Frequently asked questions.

References& sources.

1. [1]SMPTE ST 12-3:2016, "Time Code for High Frame Rate Signals and Formatting in the Ancillary Data Space". Section 6.4.3 gives the drop-frame rule verbatim: "the first two super-frame numbers (00 and 01) shall be omitted from the count at the start of each minute except minutes 00, 10, 20, 30, 40, and 50", with the note that the residual deviation is "approximately 3.6 ms" after one hour and "approximately 2.6 super-frames (86 ms)" over 24 hours. Section 6.4.2 gives the non-drop deviation of "approximately +3.6 seconds in one hour" at rates that are a multiple of 30/1.001; section 6.4.1 fixes the 24-hour clock range; section 7.3 defines the drop-frame flag at bit 10; section 6.6 notes drop frame is applicable only to multiples of 30-frame counting.
2. [2]SMPTE EG 40:2016, "Conversion of Time Values between SMPTE ST 12-1 Time Code, MPEG-2 Systems Layer Program Clock Reference Time Base and Local Wall Clock Time". Sections 6.1 and 6.5 enumerate conversion formulas between ST 12-1 time-address values and local wall clock time for exactly the rate set offered here — 23.98 non-drop, 24, 25, 29.97 drop frame, 29.97 non-drop and 30 — and note that the hours value is constrained to be less than 24.
3. [3]Recommendation ITU-R BT.2020-2, Table 2, Picture temporal characteristics: "Frame frequency (Hz) 120, 120/1.001, 100, 60, 60/1.001, 50, 30, 30/1.001, 25, 24, 24/1.001". Source for treating 23.976, 29.97 and 59.94 as the exact fractions 24000/1001, 30000/1001 and 60000/1001 rather than as rounded decimals.
4. [4]Apple, Final Cut Pro Help, "Navigate using timecode". Confirms the hours:minutes:seconds:frames form and that a comma, colon or semicolon are all accepted as separators when typing a timecode — the basis for this calculator accepting any of them on input.