How to fix out-of-sync subtitles

First work out whether it is a constant offset or a drift — the fixes are different.

There are two completely different problems hiding behind "the subtitles are out of sync", and applying the wrong fix makes things worse. Spend thirty seconds diagnosing before you touch anything: check the offset near the start of the file, then check it again near the end. If it is the same, you have an offset. If it has grown, you have a drift.

Open the subtitle editor → Opens the editor. Import your SRT, add the video, and use the waveform to check the offset at both ends.

Case one: a constant offset

This is the common one, and it comes from an edit. Someone trimmed an intro, added a sponsor bumper, or exported a version with a different amount of black at the head. Every line is late or early by the same number of seconds from the first line to the last.

The fix is a single shift. Import the subtitle file, load the video, find a line where you can clearly hear the first word, and measure how far off it is — the waveform makes this exact, because you can see the speech start and the subtitle block on the same axis. Then open Timing, type the difference (positive moves everything later), and apply it to the whole track. Check the last line before you export: if it now matches too, you are done.

Case two: a drift

If the offset is a quarter of a second at the start and four seconds at the end, no single shift will fix it — you have a frame-rate mismatch. This happens with subtitles made for a 25 fps broadcast version played against a 23.976 fps file, and with old telecine conversions. The whole track is running at a slightly wrong speed.

The classic fix is to multiply every timestamp by a ratio, and that is genuinely the right answer when the ratio is one of the standard ones. This editor does not have a stretch function yet, which is an honest gap: if the drift is small, re-generating the subtitles from the video takes a few minutes and produces a track that matches by construction. If the drift is small but the text is human-written and valuable, the practical workaround is to split the track into sections and shift each one — tedious, but it works and it does not need a formula.

Case three: some lines are fine and others are not

This is usually not a timing problem at all. It happens when the subtitle file was made for a different cut — a director's cut, a version with scenes reordered, or a regional release with a segment removed. No global operation will fix it, because the two things genuinely do not correspond any more.

Here re-generating is almost always faster than repairing. Drop the actual video in, let recognition build a track that matches this cut, and use the old file as a reference for spellings if it was well made.

Working with the waveform

The reason timing work is slow in most tools is that you are listening for something instead of looking at it. With the audio drawn under the timeline, the start of a sentence is a visible edge — silence is flat, speech is a block. Zoom in with ⌘ or Ctrl and scroll until one second fills the screen, and dragging a subtitle block's left edge onto the start of the speech becomes a single precise motion rather than a scrub-and-guess loop.

One convention worth knowing: subtitles are usually set to appear a fraction before the speech rather than exactly on it, because the eye needs a moment to move to the text. A tenth of a second early reads as natural; exactly on the word reads as late.

Frequently asked questions

How do I know if it is an offset or a drift?

Check the error near the start and near the end. Same error at both ends is an offset — one shift fixes it. Growing error is a drift caused by a frame-rate mismatch.

What number do I type for the shift?

The amount the subtitles are late, as a positive number, or the amount they are early, as a negative one. Positive moves everything later.

Can it stretch timings for a frame-rate mismatch?

Not yet. For now, re-generating from the video is usually the quickest reliable fix, or shift section by section if the existing text is worth keeping.

Does shifting break the file?

No. The shift moves every start and end by the same amount and refuses to push anything below zero, so the file stays valid.