Fix Overlapping Subtitles

Three faults, one pass, and one rule that governs all of them: only the ends move. A start is anchored to the moment the line is spoken. Move it and the subtitle stops matching the picture — which is the fault this page exists to fix, so a tool that introduces it while tidying has made things worse. An end is padding: it is how long the line stays up after the speech, and it is the only part there is room to negotiate with.

Overlapping subtitles. A cue that is still on screen when the next one starts. Players resolve a cue collision differently and none of them resolves it well: some stack the two, some drop the earlier one, and some alternate between them fast enough to flicker. The earlier cue’s end is pulled back until the gap you asked for exists.

Cues too brief to register. Under about a second, a line does not read as words — it reads as a flash. This is what a machine-generated track produces when it times a cue to the exact length of the phrase, and it is why a minimum duration is part of every broadcast specification. Short cues are held on screen longer, up to the point where doing so would crowd the next one.

Cues that hang about. A line still on screen twenty seconds after it was said, usually because a cue’s end was set to the next cue’s start across a long silence. Seven seconds is the usual ceiling, and past it a viewer has read the line three times and started wondering whether the file is broken.

The gap, and why zero is not the default

Two cues that touch exactly — one ending at 04.000 and the next starting at 04.000 — do not overlap, and still flicker. Frames are discrete: at 25 frames per second there is no moment between them, so the player has to decide which cue owns that frame, and different players decide differently on different frames. Two frames of clear air, which is 80 milliseconds at 25fps, is what most house styles ask for.

What it refuses to do

When the gap cannot be made without leaving the earlier cue too short to read, the timing is left exactly as the author wrote it and the clash is reported as left alone. Two cues genuinely occupying the same moment are either a mistake nobody can fix automatically or two people talking at once, and only the person who made the file knows which.

Press Load a sample, and leave the defaults: an 80 millisecond gap, a one-second minimum duration, a seven-second maximum. The status line reads overlapping 1 and changed 3.

Cue 1 ran to 00:00:04,400 and cue 2 starts at 00:00:04,000. In the output, cue 1 ends at 00:00:03,920 — four hundred milliseconds of overlap removed, plus the eighty of gap. Cue 2 still starts at 00:00:04,000, exactly where it did, because its start is where somebody speaks.

Cue 3 was on screen for a tenth of a second and now runs to 00:00:09,000 — a full second, which is the minimum you set. Cue 4 ran for twenty seconds and now ends at 00:00:16,000, seven seconds after it started. Cue 5 is untouched: it was always fine, and a tidy pass that rewrites correct cues is a tidy pass you cannot check.

Set the gap to 0 and cue 1 ends at 00:00:04,000 instead — touching cue 2 exactly. That is legal, it is not an overlap, and on a 25fps encode it is still where a player flickers.

Reading speed and duration pull against each other: holding a short cue longer makes it easier to read, and cutting a long one shorter makes it harder. Run the reading-speed check after this, not before, because these changes move the numbers it reports.