Subtitle timing is off: why it drifts and how to fix it
Subtitle timing off usually means one of three things: a constant offset, drift that grows through the file, or a few cues out on their own. How to fix each.
Three different faults get described as subtitle timing off, and each needs a different fix. Either every cue is wrong by the same amount from beginning to end, or the error is tiny at the start and huge at the end, or most of the file is fine and a handful of cues sit a second out. Checking three places in the file tells you which one you are looking at, and that takes about a minute.
Subtitle timing off means one of three different problems
They behave differently over the length of the file, which is what makes them easy to tell apart.
| What you see | Likely cause | Fix |
|---|---|---|
| Every cue late or early by the same amount, start to finish | Timed against a different cut of the video | Shift every time by one number |
| Right at the start, a little late in the middle, badly late at the end | Made for a version that runs at a different speed | Stretch the file between two anchor points |
| Most cues land, a few are a second or so out | Estimated timings from a speech model | Nudge those cues by hand |
| Correct up to one point, then permanently out by one cue | A broken block in the file itself | Repair the file, then check again |
The last row is a file format fault rather than a timing one: a missing blank line makes the player read the next counter as dialogue, and everything after it slides by one subtitle. How to make an SRT file covers that. The other three are below.
A constant offset comes from a different cut of the video
This is the common case. The first cue is two seconds late, the last is two seconds late, and so is everything in between. The words are right; the clock is wrong by a fixed amount.
The usual explanation is that the file was timed against a different version of the same content: a copy with a longer logo at the front, a re-upload with the cold open trimmed, a talk where the first twenty seconds of room noise were cut before publishing. Something changed at the front, nothing after it was touched, so every cue inherits the same error.
The fix is a shift. Any subtitle editor can apply one number to every cue and save the result. Most video players can nudge subtitles with a keyboard shortcut while the video plays, which is a fast way to find the number, but the player is usually only remembering it for this session rather than writing it into the file.
Drift that grows through the file is a speed mismatch
Here the start looks perfect, the middle is a second or two late, and by the end the subtitles are half a minute behind the speech. Shifting only moves the problem: pull the end back into place and the start goes early.
The classic cause is a frame rate mismatch. The subtitles were timed against a copy that runs at a slightly different rate to yours, so the two reach the same word at different clock times. Because a frame is a fixed slice of time, the gap between them grows in proportion to how far into the file you are.
You do not need to know either frame rate to correct it. The fix is a stretch, which editors label as synchronising by two points, or adjusting by two anchors. You give it two pairs: a word near the very start with the real time you hear it, and a word near the very end with the real time you hear it. Everything in between is rescaled in proportion.
Check the middle afterwards. If both ends line up and the middle is still out, a chunk was probably cut from one version, and the only honest repair is to split the file into sections and shift each separately.
Cues that wobble on their own are estimated timings
The third case has no pattern to it. Ninety cues are right and four are a second early. This is what automatic timings look like. A speech model does not measure when a word was spoken; it estimates where each piece started and ended, and those estimates get shakier around pauses, music, overlapping voices and long silences.
In our transcriber that kind of error cannot pile up over a long recording, and the reason is worth knowing.
A long file is transcribed in windows of about a minute. Audio is decoded a piece at a time and collected until there is a window’s worth, then the tool picks where to cut: it scans three seconds either side of the one minute mark, measures the loudness of each twenty five millisecond frame, and cuts through the middle of the quietest one, so the join lands in a pause rather than through a word. That window goes to the model on its own, comes back as text with times measured from the start of the window, and the tool adds the window’s start time to each of them before the text reaches the transcript.
The bookkeeping is the part that matters. The offset added to a window is the amount of audio already consumed, counted in samples, not the end time of the last text that came back. So if the estimate inside window seven is half a second out, window eight still begins in exactly the right place. Errors stay inside the window that made them. A near-silent window is skipped without going to the model at all, and even then the clock advances by its full length, so nothing after it moves.
None of that makes the estimates themselves sharper. Individual cues can still be early or late, and a hand nudge in an editor is the fix for those.
Three spots tell you which problem you have
Open the video in a player, load the subtitle file next to it, and check three moments: the first line of speech, something near the middle, and something in the last minute. For each, note the time you actually hear the words and subtract the cue’s start time. That gives you three numbers.
- All three roughly equal, and none of them zero: constant offset. Shift by that number.
- Near zero at the start and growing steadily: speed mismatch. Stretch between two anchors.
- All three near zero, but individual cues elsewhere feel wrong: estimated timings. Nudge those cues.
- Near zero, then every cue from a certain point on out by exactly one subtitle: a broken block. Fix the file.
Do the stretch before the shift if you need both. Rescaling changes every number in the file, including any offset you just applied.
What our exporter controls, and what it does not
Our exporter turns the model’s segments into cues under fixed rules: forty two characters per line, two lines at most, one to six seconds on screen, and at least eighty milliseconds between cues. A segment too long for that gets split, at sentence endings first, then commas and clause breaks, then word boundaries.
Two things there are worth being straight about. When a segment is split, its duration is shared between the pieces in proportion to how many characters each has, which quietly assumes an even speaking pace, so a piece that follows a pause inside the segment can appear slightly early. And the eighty millisecond gap is always made by pulling the earlier cue’s end backwards, never by pushing the next cue’s start forwards. A cue is never delayed by the one in front of it, so a single long cue cannot shove the rest of the file late.
The tool runs on desktop Chrome or Edge with working WebGPU, in English, using OpenAI’s open-source Whisper model in its base size, and takes roughly the length of the recording on a thin laptop. Timings good enough to publish usually still want a pass in a subtitle editor, the same as the words do. If you want a file to start from, transcribe your recording and export the subtitles without uploading anything.
Frequently asked questions
Why are my subtitles exactly two seconds late the whole way through? Almost always a different cut of the video. Something at the front changed after the timing was done, so every cue carries the same error and one shift clears it.
Do the timings change when I convert SRT to VTT? No. The numbers are identical, the punctuation around them differs, and there is a header at the top. Which export do you need covers the differences.
What if the timing is fine but the words are wrong? That is a separate job, and reading the whole transcript against the audio is the slow way to do it. Seven mistakes to fix before you publish lists the ones worth hunting for.
Will transcribing the file again fix bad timing? Only if the transcription was the problem. If the subtitles were made for another version of the video, a fresh transcript of yours fixes it completely, because the times then come from the audio you actually have.
Sources, checked 15 September 2026
- Our own transcription worker (
site/src/tool/worker.ts): minute-long windows, cut at the quietest frame within three seconds of the target, each window offset by the audio consumed so far. - Our own cue builder (
site/src/tool/export.ts): forty two characters per line, two lines, one to six seconds, eighty millisecond gap, made by shortening the earlier cue. - No third-party sources were needed here. Every number above describes our own tool.