Frame-accurate subtitles at any frame rate

Subtitle files store time in milliseconds. Editing timelines think in frames. Converting between the two badly is why captions that looked fine at the start of a video are visibly wrong by the end. This is what actually has to happen, and what to set.

A millisecond cannot name a frame

At 23.976 fps a frame lasts 1001/24000 of a second (41.708333… ms). No frame boundary after the first lands on a whole millisecond, so an SRT timecode is always slightly off the frame it means. That error alone is harmless. What is not harmless is what a tool does with it.

Round each time independently and errors scatter. Convert at the wrong rate and the error is proportional to elapsed time, which is the drift people actually notice: fine in the first minute, a second out by minute ten.

The rates, and why the odd ones exist

• 23.976, 29.97 and 59.94 are the NTSC rates. They are exactly 24000/1001, 30000/1001 and 60000/1001, not 24, 30 and 60 with a rounding error. The /1001 comes from a 1953 decision about colour subcarrier spacing and has outlived every reason for it.
• 24, 25, 30, 50 and 60 are exact. 25 and 50 are the PAL rates; 24 is film.
• The pairs that catch people are 23.976 against 24, and 29.97 against 30. They differ by 0.1%, which is one frame every 33 seconds: imperceptible at the start, a second of error every 17 minutes.

What frame-accurate export requires

Every time has to be an integer frame index, and the arithmetic has to stay in integers. Here each caption's start is floored to a frame and its end is ceiled, so a caption is on screen for every frame in which its words are audible, with a minimum of one frame and no overlap between neighbours.

FCPXML writes each time as an exact rational (1001/24000 s), so it is a frame multiple by construction rather than by rounding. Premiere marker XML writes integer frame counts, which is already what the frame model produces. SRT, WebVTT and SubViewer are converted from those same frames, so all five formats land on identical frames rather than each rounding separately.

Which rate to pick

The frame rate of the sequence you are importing into, which is not necessarily the source video's. A 29.97 clip dropped on a 23.976 timeline is conformed by the editor; your captions are not, unless you tell them.

Detecting the rate automatically

For MP4 and MOV files the rate is read straight out of the container's metadata, which gives the exact rational rather than a decimal that could be 23.976 or 24. Nothing is decoded, so it works for ProRes, a codec browsers cannot play and exactly what a Final Cut user exports. For WebM or a damaged file it falls back to timing decoded frames. Either way it only preselects the picker, and you should confirm it against your sequence.

Frequently asked questions