Frame rate converter and fps calculator for timecode

Re-express a SMPTE timecode at a different frame rate, as the same moment in real time (the conform case) or the same frame count (the reinterpret case), across 23.976 to 60 fps, with correct drop-frame handling.

Timecode

From rate

To rate

Conversion mode

Same moment in time (retime — conform/sync)Same frame count (reinterpret — speed change)

Result at 29.97 fps drop-frame

01:00:00;00

Frames: 107,892Real time: 00:59:59.996

Same time vs. same frames, the distinction that prevents drift

Almost every frame-rate mistake in post comes from conflating two different questions. If a sound mixer needs to know where your 25 fps reference mark lands in their 29.97 session, you are asking about the same moment. Hold real time constant and let the frame count change. If you reinterpret footage so the same frames play at a new rate, you are asking about the same count. Hold frames constant and let every duration change (24 to 25 fps is the classic 4.17% PAL speed-up).

The converter does both, shows the resulting frame count and real elapsed time either way, and formats drop-frame output legally; skipped frame numbers are never emitted.

Worked examples

Every value below was produced by this tool. The starting timecode is 01:00:00:00 in each case.

25 fps to 29.97 drop-frame, same moment: 01:00:00;00, 107,892 frames, 0:59:59.996 of real time. Drop-frame tracks the clock, so an hour stays an hour. The same moment in 29.97 non-drop reads 00:59:56:12, because non-drop labels 108,000 frames as an hour.
24 fps to 25 fps, same frame count (PAL speed-up): 00:57:36:00. All 86,400 frames are kept and play 4.17% faster, so the runtime shrinks from 60:00 to 57:36. In same-moment mode the answer is 01:00:00:00 at 90,000 frames instead.
23.976 to 24 fps, same frame count: 01:00:00:00, 86,400 frames. The label does not change, but the real duration does: 1:00:03.600 at 23.976 becomes exactly 1:00:00.000 at 24.
23.976 to 24 fps, same moment: 01:00:03:14, 86,486 frames. The real hour-and-3.6-seconds moment needs 86 extra frames at the faster rate. Going the other way, 24 fps 01:00:00:00 is 00:59:56:10 at 23.976.
29.97 non-drop to 29.97 drop-frame, same moment: 00:10:00:00 becomes 00:10:00;18. Same 18,000 frames, same 10:00.600 of real time, but the drop-frame counter has already skipped 18 numbers by then.
59.94 drop-frame to 29.97 drop-frame, same moment: 01:00:00;00, 215,784 frames become 107,892. Both counters track the clock, so the labels agree.

How it is calculated

Every timecode is first turned into an absolute frame count at its own rate. In same-moment mode that count is converted to real seconds and back: seconds = frames / exactFps, then newFrames = round(seconds x newExactFps). In same-frame-count mode the count is kept and only re-labelled at the new rate.

The exact rates are the fractions, not the rounded names: 23.976 is 24000/1001, 29.97 is 30000/1001, and 59.94 is 60000/1001. That 1.001 factor is why an hour of 29.97 non-drop timecode lasts 1:00:03.600 of real time, and why a drop-frame hour is 107,892 frames rather than 108,000. Drop-frame skips frame numbers 00 and 01 at every minute change except minutes ending in zero (108 numbers an hour), and 59.94 skips 00 through 03. The drop-frame timecode guide walks through that arithmetic. The PAL speed-up is simply 25/24, a 4.1667% change in speed and pitch.

Where this shows up in real work

Conform notes moving between an offline cut and a finishing timeline at different rates; caption files timed at the wrong rate (if subtitles drift progressively later, the rate, not the start point, is wrong, and the SRT shifter explains how to tell the two apart); comparing durations across NTSC and PAL masters; and translating frame counts from render logs, QC reports, or EDL events into timecode at the rate a spec sheet demands. For adding and subtracting timecodes at one rate, use the timecode calculator. For caption conversion specifically, the SRT to Avid TXT converter applies this same math to every cue in the file.

FAQ

Is there a frames per second calculator for timecode?

Yes, this is one. Enter a timecode at its source fps, pick the target fps, and the calculator returns the timecode, the frame count, and the real elapsed time at the new rate. It covers 23.976, 24, 25, 29.97 and 59.94 drop-frame and non-drop, 30, 50, and 60 fps.

What does converting a timecode between frame rates actually mean?

It depends which of two things you hold constant. "Same moment in time" answers: the event at 01:00:00:00 in my 25 fps timeline, what timecode is that same real moment at 29.97? "Same frame count" answers: frame 90,000, what does that count read as at the new rate? The first is the conform and sync case; the second is the reinterpret and speed-change case.

Which mode do I want for a conform?

Same moment in time. When media is retimed or notes travel between a 25 fps offline and a 23.976 finish, the thing that must line up is the real-world moment, not the counter value.

Which mode matches "interpret footage" in an NLE?

Same frame count. Reinterpreting 24 fps footage as 25 keeps every frame but plays them at a new rate, the classic 4.17% PAL speed-up. The frame count is unchanged while every duration shortens: an hour of 24 fps becomes 00:57:36:00 at 25.

What is 30000/1001?

The exact NTSC frame rate that everyone calls 29.97. It is 30 divided by 1.001, which is 29.970029... frames per second. The same 1.001 factor turns 24 into 23.976 (24000/1001) and 60 into 59.94 (60000/1001). Frame counts at these rates are computed as round(seconds x 30000/1001), never with the rounded 29.97.

Why does 25 fps 01:00:00:00 become 01:00:00;00 at 29.97 drop-frame in time mode?

Because drop-frame timecode is designed to track the wall clock. One real hour is one hour of drop-frame timecode, 107,892 frames. The same moment in 29.97 non-drop reads 00:59:56:12, because non-drop counts 108,000 frames per labelled hour and runs 3.6 seconds behind the clock.

How do I convert 23.976 to 24 fps?

If you are reinterpreting the footage, keep the frame count: 01:00:00:00 stays 01:00:00:00, but it now plays in exactly one hour instead of 1:00:03.600. If you need the same real moment, the timecode moves: 01:00:00:00 at 23.976 is 01:00:03:14 at 24 fps, 86 frames later.

What is the PAL speed-up?

Playing 24 fps film at 25 fps. Every frame is kept, so the frame count is identical, but the runtime shrinks by 24/25: a 100 minute film runs 96 minutes and the pitch rises 4.17% unless corrected. In this tool that is "same frame count" from 24 to 25.

Why do my subtitles drift later over time?

Progressive drift means the subtitles were timed at a different frame rate than the video. Subtitles made for 25 fps played against 23.976 material run 4.27% slow: 25.6 seconds late after ten minutes and 2 minutes 34 seconds late after an hour. A fixed shift cannot fix that; the timing has to be scaled by the rate ratio.

Is any video converted or re-rendered here?

No. This is timecode math only. Converting actual footage between frame rates is a render operation in your NLE; this tool tells you where a moment or a count lands at the new rate.