Subtitle Frame Rate Converter

Cinema shoots 24 frames a second. PAL television shows 25. The cheapest way to put one on the other — and the way it was done for fifty years — is simply to run the film one frame per second faster and leave every frame exactly where it is. No frames are added, none are dropped, and the transfer is frame for frame.

What changes is time. The picture plays 4.17% faster, which makes the running time 4% shorter. Those are not two different facts and they are not the same number: 25 ÷ 24 is 1.041667 and 24 ÷ 25 is 0.960000, the same conversion read from the two ends of a division. Almost every article on the subject prints one of them as both. An hour of film comes back 2 min 24 s short, and the audio rides up with it — 71 cents, about 0.71 of a semitone, which is why voices in old PAL transfers sound faintly wrong to anyone who knows the film.

A subtitle file made for one version is therefore wrong against the other from the first line onward, and increasingly wrong as it plays — 2 min 24 s by the end of an hour. It starts as a few frames — unnoticeable — and finishes with a caption for the line after the one being spoken. That is the conversion this page exists for, and it is the first option in the tool.

When NTSC added colour in 1953 it had to stay watchable on the black-and-white sets already in living rooms, so the colour information was squeezed into the signal alongside the existing picture and sound carriers. At the original 30 frames a second the new subcarrier beat audibly against the audio carrier. The fix was to slow the whole system by exactly one part in a thousand and one — 30 became 30000 ÷ 1001, and when film rates followed the same television plumbing, 24 became 24000 ÷ 1001.

So the ratio is exactly 1000 ÷ 1001 — as a decimal it is 0.999000999… and it never resolves, which is the whole reason the fraction is what gets carried around. Every NTSC rate on this page is its integer partner multiplied by it. It is not 23.98, and it is not "about 24". The labels are labels: this tool stores 24000 ÷ 1001 and 30000 ÷ 1001 and does the arithmetic on those, which is why the factor for 23.976 → 24 comes back as the rational 1000 ÷ 1001 rather than a fifteen-digit decimal.

The same fraction is what makes drop-frame timecode necessary, for the same reason and with different consequences — the timecode converter handles that side of it, and the frame calculator turns any of these rates into frame counts and back.

One part in a thousand sounds like nothing, and for the first minute it is nothing. The problem is that it accumulates. Below is a file timed for 24 fps played against 23.976 — the smallest mismatch in the whole table, and the one people dismiss as rounding.

A cue meant to land on a cut is judged in frames, not seconds. One frame late is invisible. Fourteen frames — a little over half a second — is a caption that appears while the previous shot is still on screen. 86 frames is a caption for a line that has already been said, and that is where an unconverted file ends up after an hour.

That 3.6 seconds is the same figure an hour of non-drop timecode gains against the wall clock at an NTSC rate, which is not a coincidence — it is the same 1000 ÷ 1001 seen from two directions. It is worth knowing that the two are not interchangeable in the other direction: going from 23.976 up to 24 the hour delta is 3.6 s, three milliseconds short of 3.6, because the factor is 1000 ÷ 1001 rather than its reciprocal. The tool computes each direction rather than assuming they mirror.

Every figure here is produced by the same function the tool above calls, so the published table cannot drift from the calculator. Column headings sort.

"Same frame grid" is whether the two rates count the same number of frames per second of timecode — 24 for both 23.976 and 24, 30 for both 29.97 and 30. Only those pairs can be re-read against a different grid without touching the picture, which is what the second option in the tool means and why it is refused everywhere else.

Telecine pairs such as 23.976 → 29.97 are deliberately not in this table. They belong to the third case below, where the running time does not change at all, and printing a speed-change factor beside them would publish exactly the wrong answer.

The rates alone do not determine the answer. Two files can go from 23.976 to 29.97 and need opposite treatment, because what matters is what was done to the picture — and that is the question almost no other converter asks.

The refusal

"The timings were counted at a wrong rate" is only defined between rates that share a timecode base. Between 24 and 25 there is no such thing as re-reading the same frame numbers against a different grid, so the tool disables that option and says why instead of handing back the speed-change number under a different label. Any converter can multiply two numbers; telling you that the operation you picked does not apply to the rates you picked is the part worth having.

The one that changes nothing

2:3 telecine and plain frame duplication add or drop frames while the clock keeps running at the same speed. An hour is still an hour, so the cue times are already right and the correct output is the file you put in, with a factor of exactly 1. The tool says so and still offers the download, because a renumbered, correctly-encoded, frame-snapped copy is worth having. Handled as a speed change instead, 23.976 → 29.97 multiplies by 4 ÷ 5 and drags the last cue of an hour 11 min 60 s early.

When none of them fit

If the file is out by the same amount from the first line to the last, it is not a frame-rate problem at all — it is an offset, usually a different release with an extra logo or a trimmed recap on the front. Convert nothing and shift the whole file instead. And if it starts in sync and drifts but you do not know either rate, the same tool will fit it between two cues whose correct times you can read off the picture.