Why subtitles drift out of sync, and how to fix it

A constant offset is the easiest case and the most common. The subtitle file was made against a version of the video that had a title card, a countdown, or a different opening, and the version being played does not. Every line is wrong by the same number of seconds, which is why it is also easy to recognise.

The fix is a single shift applied to every cue, in either direction. The judgement call is how much: measure the gap on three lines at different points in the file, and if the number is the same, apply it. If the three measurements disagree, it is not a constant offset and shifting will make the file worse.

This is also the case where a player-side offset setting is the wrong tool. A player offset hides the problem for one viewer and leaves the file wrong for everyone else. Fix the file, then use player offsets only for genuinely personal preferences like audio latency on a specific device.

Drift is the case that convinces people subtitles are cursed. The first line is fine, the middle is slightly late, and the last line is seconds off. The gap is proportional to elapsed time, which is the signature of two timelines that run at different rates.

The classic cause is the 23.976 versus 24 distinction. Film is shot at 24 frames per second, but the video standard derived from it runs at 24/1.001, about 23.976, so that audio can be carried at a convenient rate. If a subtitle file is timed against one and played against the other, it drifts by roughly 3.6 seconds per hour. That number is worth memorising, because it is a fingerprint.

The 25 versus 23.976 case is more dramatic: a film transferred to PAL runs about 4 percent fast, so a subtitle file made for the film version drifts by over two minutes across a feature. Recognising the ratio — 25 divided by 23.976 — is what tells you to re-time rather than nudge.

Variable frame rate is the modern version of the same problem. Phone recordings and screen captures often declare an average frame rate while the actual frame times vary, so a timing derived from the average is correct at the start and wrong wherever the frame rate changed. The only reliable fix is to time against the delivered file.

When the timing is right on average but the text appears one frame late, a cut makes it visible. The line seems to arrive after the shot has already changed, and at a fast edit the result is a flicker: text appears, disappears, appears again within a fraction of a second.

The cause is a mismatch between the grid the subtitle file uses and the grid the video uses. A file timed in whole seconds cannot land on frame boundaries at all. Even a file timed in milliseconds will land between frames, because a frame at 23.976 lasts about 41.7 milliseconds and very few millisecond values are multiples of that.

Frame-accurate timing means converting each cue boundary to the nearest frame time for that specific frame rate, so that the subtitle switches on the same frame the picture does. It is a small difference numerically and a large difference perceptually, because the viewer’s eye is synchronised to exactly those transitions.

Sync is about the relationship between text and time. Alignment is about the relationship between text and audio within a cue. A file can be perfectly in sync — every line arrives when it should — and still be badly aligned, with the highlight landing a word behind the voice.

The two are fixed in order. Sync first, because a global shift or a re-time invalidates any per-word alignment built on the wrong times. Alignment second, once the cue boundaries are final, because alignment assumes the boundaries are correct.

This is also why alignment does not rescue a drifting file. If the timeline is wrong, the aligned highlight will be precisely wrong, and the precision makes the error more obvious rather than less.

Before touching the file, measure. Pick a line with an unmistakable audio landmark — a gunshot, a door slam, a name spoken clearly — and write down the stated cue time and the observed time. Do this at the start, middle and end.

Three numbers tell you almost everything. If they are equal and non-zero, shift. If they grow linearly, re-time for the correct frame rate. If they are inconsistent, the source is suspect: maybe a variable frame rate file, maybe two different cuts concatenated, maybe a player that is applying its own offset.

That last case is worth ruling out early, because editing a file that is already correct in a broken player produces a file that is wrong everywhere else. Play the file in a second player before concluding the subtitles are broken.

Our timing is derived from the audio of the file you upload, so the first version is in sync with that file by construction. If you then deliver from a different cut or a different frame rate, the file will drift — which is why the delivered file, not the original, is the reference for any re-time.

The Studio renderer snaps cue boundaries to the frame grid of the target frame rate before drawing, so a rendered MP4 does not inherit the rounding error of a file timed in whole milliseconds. The SRT and ASS exports keep the timing as derived, because the destination player will do its own rounding and a pre-rounded file would be rounded twice.

If a file arrives out of sync and you cannot tell why, send the measurement, not the diagnosis. Three numbers — cue time and observed time at start, middle and end — identify the cause faster than any description of what it looks like.

Play the first thirty seconds with the file as delivered and note whether the text arrives early or late. Skip to the last thirty seconds and note the same thing. That is two minutes of work, and it separates a shift from a re-time before you have touched a single timestamp.

If both ends are off by the same amount, shift. If the end is off by more than the start, do not shift; measure the ratio. Divide the observed gap by the elapsed time and compare it to 1.001 (the 23.976 case) or 1.0427 (the film-to-PAL case). A match is a diagnosis, not a coincidence.

If neither pattern holds, stop editing and check the source. Two cuts joined together, a variable frame rate phone recording, or a player applying its own offset will each produce a pattern that no amount of shifting fixes, and each is cheap to rule out once you are looking for it.

Keep the measurement for the next time. A file that drifted once will drift again for the same reason, and the second diagnosis should take seconds rather than another afternoon.