Key Takeaways
Check a line near the start and a line near the end. If both are off by roughly the same amount, that’s a constant offset, and shifting the whole file by that amount fixes it. If the start is close to correct but the end is badly wrong, that’s drift, usually caused by a frame rate mismatch, and it needs the timings scaled rather than shifted. Shifting a drifting file only moves the point where the error happens to be zero — it doesn’t fix anything.
Subtitles going out of sync feels like one problem, but it’s almost always one of two unrelated faults. One is a simple, fixed delay: every line is late by the same couple of seconds, from the first word to the last. The other is a creeping mismatch: the opening lines look fine, and by the closing scene the subtitles are a sentence or two behind the dialogue.
The fix for one does nothing for the other, and if you apply it anyway, you can end up with a file that’s wrong in a new and more confusing way. The good part is that telling them apart takes about thirty seconds, and once you know which one you’ve got, the fix itself is quick.
Tell the difference in thirty seconds
Play a line of dialogue near the start of the video and note how far off the subtitle is — half a second late, three seconds early, whatever it is. Then skip to somewhere near the end and check a line there too. That’s the whole test.
If the gap at the start and the gap at the end are roughly the same size and in the same direction, you’re dealing with a constant offset. The whole file needs to move by that one amount, and it’ll be correct everywhere.
If the gap at the start is small or nonexistent, but the gap at the end is noticeably bigger, that’s drift. The error is growing as the video plays, which tells you it isn’t a delay at all — it’s a difference in speed between how the subtitle file was timed and how the video actually plays.
Fixing a constant offset
A constant offset is the easier of the two, and also the more common one — someone started the video a couple of seconds before or after the subtitle track, or the file was exported with a small built-in delay. Because every timestamp in the file is off by the same fixed amount, the fix is arithmetic: add that amount to every cue if the subtitles are early, or subtract it if they’re late.
Subtitle files store timing per line, as a start and end time for each cue. A shift doesn’t touch the text of any line — it only moves the numbers attached to it, so the wording, the speaker breaks, everything else stays exactly as it was. A time shift tool does exactly this: you give it the amount and direction, and it applies that same adjustment to every cue in the file in one pass, rather than you nudging each line by hand.
Watch the start of the file after a backward shift
If you’re shifting the whole file backward by a large amount — pulling every cue earlier — check what happens to the very first cue. If it started close to zero, shifting it back can push its start time below zero, which is not a valid timestamp. Players don’t agree on what to do with a negative start time: some clip it to zero, some skip the line, some refuse to load the file at all. After a big backward shift, open the file and look at cue one before you trust the rest of it. A subtitle validator will flag a negative timestamp for you rather than you scrolling through the raw file looking for it.
Why subtitles drift instead of just being late
Drift feels stranger than an offset because it seems to get worse for no reason, but the usual cause is mundane: the subtitle file was timed against a copy of the video running at a different frame rate than the copy you’re actually watching. Frame rate is how many frames the video shows per second, and if the subtitle timings assume one rate while the video plays at another, the two drift apart a little more with every second that passes. Near the start, the drift is tiny and easy to miss. By the end of a two-hour film, it can be several seconds.
The classic mismatch is a film mastered at 24 frames per second paired with a broadcast version running at 25. Neither number is wrong on its own — they’re just two different masters of the same content, and a subtitle file built for one runs slightly ahead or behind on the other, compounding as the video plays.
Fixing drift with a frame rate conversion
Because drift is a rate mismatch and not a fixed delay, shifting the file doesn’t fix it — shifting only moves the whole file earlier or later by a fixed amount, and drift isn’t fixed, it’s proportional to how far into the video you are. Shift a drifting file and you might get the start and the end to look right at the same time by luck, but the middle will still be off, because you’ve moved the error, not corrected it.
What drift actually needs is for every timestamp to be scaled — stretched or compressed by a ratio — rather than moved by a flat amount. Some subtitle tools expose this directly as a frame rate conversion: you tell it what rate the file was timed for and what rate the video actually runs at, and it recalculates every cue’s timing against that ratio rather than adding or subtracting a fixed number. If your subtitle tool only offers a plain shift, look for a frame rate or speed conversion option instead — that’s the one built for this specific fault, not the one built for a fixed delay.
When it’s not offset or drift at all
Sometimes only part of the file is wrong — the first twenty minutes match perfectly, then a stretch in the middle is off, then it lines up again later, or vice versa. That pattern isn’t an offset and it isn’t drift either, because both of those affect the whole file in a predictable, steadily-growing way. A subtitle file that’s fine in places and wrong in others usually means it was built for a different cut of the video: a version with an extra scene, or one with adverts removed, or a director’s cut that runs a few minutes longer somewhere in the middle.
No shift and no frame rate conversion fixes that, because the underlying content the subtitles are timed against isn’t the same content you’re watching. There’s no arithmetic that turns a subtitle file for one cut into a correct file for another — the extra or missing footage has to be accounted for at the point where it actually occurs, which usually means finding a subtitle file made for the specific cut you have, or re-timing that one section by hand.
If what you actually have is the raw audio or video and no subtitle file that matches it at all, going back to source and generating fresh timings is sometimes simpler than trying to patch an old file into shape. A subtitle converter handles format differences once you have a working file, but it won’t create timings that don’t exist yet — for that you need something that transcribes the audio itself, which is what a transcription app like SozAI does, turning the actual audio or video you have into text with its own timing, rather than trying to stretch someone else’s file to fit.
What to expect when you’re not sure which fault you have
Not every mismatch is a clean offset or a clean drift. Some files have a small offset and a small amount of drift stacked together — timed against the wrong frame rate and started a second late on top of it. In that case, checking start and end alone can be misleading, because the two errors partly cancel out or partly add up depending on direction. If the numbers at the start and end don’t tell a clean story, check a third point in the middle of the video as well; a genuine offset stays flat across all three checks, and genuine drift grows steadily across all three, so a third data point usually settles which one you’re looking at.
It’s also worth knowing that subtitle format itself has no bearing on any of this. Whether the file is one format or another changes how the timings and text are written down, covered in more detail in the comparison of subtitle formats, but it doesn’t change whether the fault is an offset, drift, or a mismatched cut. Fix the sync first, in whatever format the file is already in, and only convert the format afterward if you actually need to.
Finally, don’t expect a shift or a frame rate conversion to be reversible by eye once you’ve applied several of them in a row without checking. Each adjustment is simple on its own, but stacking a shift on top of a frame rate conversion on top of another shift, guessing at each step, tends to produce a file that’s wrong in a way that no longer matches either fault cleanly. Check after each change, not after several.
