Subtitle two-point resync

Two kinds of wrong, and only one of them is a shift

Subtitles go out of sync in two ways, and almost every tool only fixes the easy one.

The whole file is out by a fixed amount. Every line is three seconds late, from the first to the last. A shift fixes it, and that is what most subtitle tools offer.

The file drifts. The first line is half a second out, the last is forty seconds out, and everything in between is somewhere on the way. Here a shift is useless: correct the beginning and the end gets worse by the same amount you just moved it.

Drift almost always means frame rate. A film mastered at 23.976 frames a second and broadcast in Europe at 25 runs about 4% faster and finishes several minutes earlier. Subtitles made from one played against the other separate steadily, which is why the mismatch feels fine for the first ten minutes and unwatchable by the end.

Two points define the correction

Both problems are the same straight line with different numbers in it:

new time = scale × old time + shift

A pure shift is the case where the scale is 1. Drift is the case where it is not. Given where one early line should really be and where one late line should really be, there is exactly one line through both points, and that is the correction.

So there is no separate shift mode here and no need for one. Tell it two lines are each three seconds late and it produces a shift; tell it the first is one second late and the last is forty, and it produces the stretch that fixes the drift.

Pick your two points far apart

This is the one thing worth getting right, and it is easy to get wrong.

The scale comes from dividing the difference between your two corrections by the gap between them. Divide by a small gap and any error in your readings is magnified across the rest of the file.

Two points a minute apart turn a half-second misreading into an 0.8% error, which is about thirty seconds adrift by the end of a film. The same misreading over ninety minutes is 0.01%, which is under a second. So take the second reading from the last few minutes, not from the next scene. The tool says so when your two points are close.

The other half of that: you do not need to be precise. Pausing at roughly the right moment is fine, as long as the two points are far apart.

The frame rates are not the numbers on the label

If you know the two frame rates involved, that mode does the arithmetic exactly and you do not need to read anything off a player at all.

It uses 24000/1001 and 30000/1001 rather than 23.976 and 29.97, and that is not pedantry. Those rounded decimals are a legacy of fitting NTSC colour into an existing black-and-white signal, and using them instead of the fractions introduces a drift of about 1.8 seconds over two hours. That is enough to notice, and it is exactly the sort of error somebody arrives here to fix.

Only the times change

The text, the line breaks, and everything WebVTT carries alongside a cue (positioning, alignment, notes, styling blocks) are written back exactly as they arrived. A resync that quietly dropped the positioning on the one cue that needed it would be a worse outcome than the timing being out in the first place.

The two formats are the same idea written slightly differently: SRT puts a comma before the milliseconds and numbers its cues, WebVTT uses a full stop and adds a header. You can convert between them when you save. Getting that separator wrong is worth knowing about, because a player given a comma in a VTT file usually loads every cue at zero rather than refusing the file, which looks like a broken download rather than a broken timestamp.

Everything happens in this tab. There is no request in this page that could send your file anywhere, nothing is stored, and it works with the network off.