A timecode calculator converts between the two ways a moving image can be located in time: a plain count of frames from the start, and the hours-minutes-seconds-frames label that editors, broadcasters and playout systems actually use. The conversion is trivial arithmetic at 24 or 25 frames per second. At 29.97 and 59.94 it is not, and the reason it is not has been causing errors in broadcast schedules since 1953.
Arb Digital publishes this in its free tools library beside the time lapse calculator, which plans a capture rather than labelling one, and the video file size calculator, which sizes a rendered clip. This page does frame and timecode arithmetic on values you type. It does not read a file's embedded timecode track and it does not process footage.
What This Timecode Calculator Does
It does three things at once. It converts a frame count into SMPTE timecode at your chosen rate. It converts two timecodes into frame counts, adds or subtracts them, and converts the result back. And it reports the real elapsed wall-clock time that the result represents, which at 29.97 and 59.94 is not the same as the timecode reads.
Drop-frame is a selectable mode rather than an assumption, because at 29.97 both counting schemes are legal and in active use. Broadcast delivery is almost always drop-frame. Post-production, archives and a great deal of online video are non-drop. Both display as 29.97 in the file's metadata, and choosing the wrong one silently shifts every calculation.
The frame count outputs are given prominence deliberately. A frame count is unambiguous: it is an integer number of pictures since the start of the sequence and it means the same thing in every system. A timecode string is a label, and its meaning depends on a counting convention that the string itself only hints at through a semicolon that many systems do not display.
How to Use It
- Choose the exact rate and counting mode first. At 29.97, drop-frame and non-drop are different calculations, and selecting the wrong one produces answers that look plausible and are wrong by seconds over an hour.
- Enter timecode A as the position or duration you already know. Any of the four fields may be entered with or without leading zeros, and either a colon or a semicolon works as the last separator.
- Enter timecode B as a duration. Adding a ten minute duration to a one hour start point is the classic use, and the arithmetic happens in frames rather than in the displayed digits.
- Read the frame counts as well as the result. They are what you will need if the value has to move between two systems that disagree about the counting convention.
- Use the frame count field for the reverse conversion. Editors, encoders and animation tools report positions in frames far more often than they report timecode.
The Formula / How It's Calculated
For any non-drop rate, the conversion is straightforward division against the nominal integer rate — 24, 25, 30, 50 or 60. frames = hours × rate × 3600 + minutes × rate × 60 + seconds × rate + frame number, and the reverse is the corresponding sequence of divisions and remainders.
Drop-frame at 29.97 works on a nominal rate of 30 but skips certain frame labels. Under SMPTE ST 12-1, Time and Control Code, frame numbers 00 and 01 are omitted at the start of every minute except minutes divisible by ten. That is 18 labels skipped in every ten minute block: nine minutes drop two each, and the tenth minute drops none.
Converting a timecode to a frame count therefore subtracts the labels never used: frames = 30 × 3600 × h + 30 × 60 × m + 30 × s + f − 2 × (totalMinutes − floor(totalMinutes ÷ 10)), where totalMinutes is 60h + m. At 59.94 the nominal rate is 60 and four labels are dropped per affected minute rather than two.
Worked example, matching the values the page loads with. At 29.97 drop-frame, timecode 01:00:00;00 converts to 30 × 3600 = 108,000 minus 2 × (60 − 6) = 108 skipped labels, giving 107,892 frames. Timecode 00:10:00;00 converts to 18,000 minus 2 × (10 − 1) = 18 skipped labels, giving 17,982 frames. Adding them gives 125,874 frames, which converts back to 01:10:00;00. Reading the frame count field, 17,982 frames is exactly 00:10:00;00. Crucially, 107,892 frames at the true rate of 30,000 ÷ 1,001 is 107,892 ÷ 29.97003 = 3,599.9964 seconds — within four milliseconds of one wall-clock hour, against the 3,603.6 seconds a non-drop hour would take. That near-cancellation is the entire point of drop-frame.
Why Drop-Frame Exists, and What It Does Not Do
The single most persistent misunderstanding about drop-frame is that it discards pictures. It does not. Not one frame of video is removed, skipped, dropped or lost. What is dropped is a set of numbers in the counting sequence — the labels 00 and 01 at the top of most minutes. Every frame that was shot is still there and still plays.
The problem it solves is a colour television compromise from 1953. When colour was added to the existing black and white NTSC system, the field rate had to shift very slightly to keep the colour subcarrier from interfering with the sound carrier, and 30 frames per second became 30 ÷ 1.001, or 29.97002997. Timecode, however, counted in whole frames at 30 per second. So a timecode reading one hour represented 108,000 frames, which at the real rate takes 108,000 ÷ 29.97003 = 3,603.6 seconds. Timecode ran slow against the clock by 3.6 seconds every hour, or 86.4 seconds a day.
For a broadcaster selling advertising by the second, an eighty-six second daily error is intolerable. Drop-frame fixes it by skipping labels at a rate that exactly compensates: 18 labels per 10 minutes, 108 per hour, 2,592 per day. An hour of drop-frame timecode is 107,892 frames, which at 29.97002997 fps takes 3,599.9964 seconds. The compensation is not perfectly exact — dropping 108 labels an hour slightly overshoots the 107.892 that would cancel the error completely — so drop-frame timecode runs about 3.6 milliseconds fast per hour, or 86 milliseconds a day. Against 86.4 seconds of uncorrected drift, that is close enough that no broadcaster has ever cared.
What drop-frame does not do is make 29.97 into 30. The material still runs at 29.97 frames per second. Drop-frame only makes the labels track wall-clock time. Non-drop timecode at 29.97 is equally valid and is often preferable in post, where an editor cares about counting frames consistently and does not care what the clock says. It simply must not be mixed with drop-frame in the same calculation.
The Errors This Prevents
Timecode mistakes are expensive precisely because they are quiet. Nothing crashes and nothing looks obviously wrong; a programme is simply the wrong length, or an audio track drifts out of sync several minutes into a piece.
The most common error is treating drop-frame and non-drop as interchangeable at 29.97. A one hour programme delivered as non-drop when the schedule expects drop-frame runs 3.6 seconds long against the clock. Over a broadcast day that compounds into more than a minute of accumulated slip, which in a live schedule means something gets cut off.
The second is arithmetic done on the digits rather than on the frames. Subtracting 00:59:59;29 from 01:00:00;02 by treating the fields as ordinary numbers suggests a difference of three frames. Converted properly, both are consecutive frames and the difference is one, because the labels ;00 and ;01 do not exist at that minute boundary. Any calculation that does not convert to frames first will get this wrong.
The third is the 23.976 trap. Film transferred for NTSC delivery frequently runs at 24 ÷ 1.001 = 23.976 fps, but drop-frame is not defined at that rate — there is no standard skipping scheme for it. Timecode at 23.976 is always non-drop, and it therefore always drifts against the clock by the same 0.1 per cent. Anyone expecting a 23.976 timeline to match wall-clock time is expecting something the format cannot provide.
The fourth is audio. Audio sample rates are exact — 48,000 samples per second, with no 1.001 factor — so a video frame at 29.97 does not contain a whole number of audio samples. Over a long programme this is why sync drifts if the two are conformed independently rather than locked to a common reference. The rate structure all of this inherits was fixed by the studio encoding parameters in ITU-R Recommendation BT.601, which standardised the digital representation of both 525-line and 625-line television.
Reading Timecode in the Wild
Conventionally, a semicolon before the frames field marks drop-frame — 01:00:00;00 — while a colon throughout marks non-drop. It is a useful convention and it is not universal. Plenty of software displays colons regardless, some uses a full stop, and file metadata often records only the rate and a separate boolean flag that no user interface exposes. Treat the separator as a hint rather than as authority, and confirm the mode from the project settings.
Timecode also wraps at 24 hours. Values roll over from 23:59:59;29 to 00:00:00;00, which is why productions often start programme material at 01:00:00;00 or 10:00:00;00 rather than at zero — it leaves room for bars, tone and slate ahead of the first frame without going negative. That convention is worth adopting even for online delivery, because it makes the first frame of content unmistakable.
Finally, timecode is a label and not a duration until you fix a start point. The difference between two timecodes is a duration; a single timecode on its own is a position. This page treats field B as a duration when adding or subtracting, which is the common editorial case, and reports every value in frames alongside so the interpretation is never in doubt. For plain clock arithmetic with no frames involved, the time duration calculator and the add and subtract time calculator are the simpler tools.
Arb Digital builds fast sites where video-led pages start playing quickly, adapt to the connection and hold their layout while they load.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Mixing drop-frame and non-drop in one calculation — both display as 29.97, and the mismatch costs 3.6 seconds per hour without any visible warning.
- Doing arithmetic on the digits instead of the frames — the skipped labels at minute boundaries make field-by-field subtraction wrong by exactly the number of labels crossed.
- Believing drop-frame discards video — it skips numbers in the counting sequence, never pictures, and every frame shot is still present and still plays.
- Expecting drop-frame at 23.976 — no drop scheme is defined at that rate, so 23.976 timecode is always non-drop and always drifts against the clock.
- Trusting the separator to identify the mode — a semicolon conventionally means drop-frame, but many applications display colons regardless, so confirm the mode in the project settings.
Related Free Tools From Arb Digital
Plan an interval sequence with the time lapse calculator, size the render with the video file size calculator, and check delivery with the streaming bitrate calculator. Work out how long an altered playback rate runs with the playback speed calculator, do plain clock arithmetic with the time duration calculator and the add and subtract time calculator, and convert units with the time converter. Everything else is in the free online tools hub.
Frequently Asked Questions
No. It skips numbers in the counting sequence, specifically the labels 00 and 01 at the start of every minute except minutes divisible by ten. Every frame that was recorded is still present and still plays. Only the labels are omitted, so that the count keeps pace with the clock.
When colour was added to the black and white NTSC system in 1953, the frame rate was shifted by a factor of 1.001 so the colour subcarrier would not interfere with the sound carrier. Thirty frames per second became 30 divided by 1.001, or 29.97002997, and timecode counting in whole frames has had to compensate ever since.
By 3.6 seconds every hour, or 86.4 seconds over a full day. A non-drop hour is 108,000 frames, which at the true rate of 29.97002997 takes 3,603.6 seconds. A drop-frame hour is 107,892 frames, which takes 3,599.9964 seconds, leaving a residual error of under four milliseconds.
That depends on delivery, not preference. Broadcast delivery is almost always drop-frame because schedules are sold against the clock. Post-production, archives and much online video use non-drop because consistent frame counting matters more than clock agreement. Follow the delivery specification you were given.
No. Those rates are exact integers, so timecode counting at them already matches the clock and there is nothing to compensate for. Drop-frame is defined only at 29.97 and 59.94, the rates that carry the 1.001 factor.
It carries the same 1.001 factor but has no defined drop scheme, so timecode at 23.976 is always non-drop and always runs slow against the clock by 0.1 per cent. Expecting a 23.976 timeline to agree with wall-clock time is expecting something the format does not offer.
108 at 29.97 — two per minute for fifty-four of the sixty minutes, since the six minutes divisible by ten drop none. At 59.94 the figure is 216, because four labels are dropped per affected minute rather than two.
No. It performs arithmetic on values you type, so it works for planning, conforming and checking a delivery specification. Extracting an embedded timecode track from a file is a job for editing or media inspection software.
