Why subtitle offset is not subtitle drift

Two failures that look alike for thirty seconds

“The subtitles are late” describes a symptom, not its geometry. At the opening of a film, a track that is uniformly two seconds late looks much like a track whose clock is running a fraction too slowly. Both show text after the matching speech. The distinction appears only after time passes.

A constant offset moves the whole subtitle timeline without changing its scale. Every cue is two seconds late, or every cue is 750 milliseconds early, from the first line to the credits.

A drift changes the error over time. A cue may be correct at minute one, one second late at minute twenty, and three seconds late near the end. Moving the complete file by one number can align any one of those points and cannot align all of them.

That is why the first useful action is not trying offsets until one feels close. It is measuring two points.

The two-point test

Choose an event that is easy to identify in both tracks — a door slam, a title appearing, or the first syllable of an isolated line. Record:

error = matching media time − subtitle cue start time

A positive error means the cue starts before the matching media event and must move later. A negative error means it starts after the event and must move earlier. The sign convention matters less than writing it once and using it consistently.

Repeat the measurement near the end. Suppose the first spoken word is at 00:01:03.250 while its cue starts at 00:01:01.250:

early error = 63.250 − 61.250 = +2.000 seconds

At 52 minutes, another word occurs at 00:52:10.800 and its cue begins at 00:52:08.800:

late error = 3,130.800 − 3,128.800 = +2.000 seconds

The two errors agree. Move every cue later by two seconds.

Now keep the early measurement but suppose the late cue begins at 00:52:05.800:

late error = 3,130.800 − 3,125.800 = +5.000 seconds

The error has grown by three seconds. A two-second shift aligns the beginning and leaves the end three seconds late; a five-second shift aligns the end and makes the beginning three seconds late. The timeline needs scaling or a mapping across an edit, not translation alone.

Before you read on

A subtitle is 1.5 seconds early near the beginning and 1.5 seconds early near the end. What correction fits both observations?

• AMove every cue 1.5 seconds later.

  Yes. Equal signed errors at separated points support one constant offset.

• BStretch the subtitle timeline.

  Stretching changes the distance between cues and would create a new error where none was measured.

• CChange the video frame rate.

  The two measurements do not show a changing clock; altering media speed would disturb the media itself.

Move every cue 1.5 seconds later. The early and late measurements have the same sign and magnitude, so the subtitle clock has the right scale and the wrong origin. Adding 1,500 milliseconds to every cue start and end translates the complete timeline while preserving every cue duration and every gap. A scale correction is justified only when the error differs between separated points.

Why a shift preserves the track

SRT and WebVTT both store absolute start and end timestamps for each cue. Their punctuation differs — SRT commonly writes 00:00:03,500, while WebVTT writes 00:03.500 or 00:00:03.500 — but the operation is the same after each time is expressed in milliseconds:

new_start = old_start + offset
new_end   = old_end   + offset

new_duration = new_end − new_start
             = old_end − old_start

The duration cancels the offset. Gaps and overlaps between cues cancel it too. This is why a subtitle time shifter can make a strong promise: for cues that remain above zero, only their place on the media timeline changes.

The beginning is the one physical boundary. A cue from 0.500 to 2.000 seconds shifted one second earlier would begin at −0.500. Neither SRT nor WebVTT has negative media time. Keeping the visible remainder means clamping its start to zero and shortening that cue; removing it means discarding the whole block. Everything ending at or before zero has no visible remainder and must go.

Drift is a scale problem

For smooth drift, the simplest model maps two subtitle times to two media times:

scale = (media₂ − media₁) ÷ (subtitle₂ − subtitle₁)
mapped_time = media₁ + (subtitle_time − subtitle₁) × scale

When scale is 1, the expression reduces to a constant offset. When it is not 1, every distance on the subtitle timeline changes. That may be the right repair when the source and target are the same edit at different durations. It is not automatically right whenever two measurements differ.

A film with an inserted logo, a removed recap or a different studio ident has a piecewise error: cues are aligned before the edit, jump by a fixed amount at the cut, then remain aligned at the new offset. Scaling the entire track would smear that one edit across every cue. Measure a third point around any suspected cut; a sudden jump calls for shifting a range or using an editor with edit markers.

The useful classification is therefore:

Measurements	Model worth trying
Same error at separated points	Constant offset
Error grows smoothly	Scale or speed mismatch
Error jumps after one scene	Different edit; shift a range
Error changes irregularly	Cue-level editing or a damaged track

Where frame rate enters — and where it does not

Subtitle sidecars store time, not a promise about how the media arrived at that time. A frame-rate workflow can still create drift by changing playback duration. If one master is played faster than another, its one-hour point occurs at a different wall-clock time even though both files have perfectly valid timestamps.

But “frame-rate problem” should be a conclusion supported by duration or workflow evidence, not a synonym for any subtitle mismatch. Two equal offset measurements do not show a rate error. A growing difference does not identify which production step caused it; it only proves that one translation cannot be the complete repair.

The W3C WebVTT specification requires cues to be ordered by start time and each end to be later than its start. The Library of Congress describes the same start-arrow-end structure for SRT while noting that SRT is not formally standardised. Neither format can tell you whether its timeline belongs to the particular media file beside it. That relationship has to be checked against the content.

A practical repair sequence

1. Keep an untouched copy of the subtitle file.
2. Identify one unambiguous sync event near the start and calculate its signed error.
3. Identify another near the end and calculate the same way.
4. If the errors agree, shift subtitle timing by that constant amount and test a cue in the middle.
5. If they differ smoothly, use a tool that maps two sync points and scales the timeline; verify at least one third point.
6. If they jump, locate the edit boundary and repair ranges separately.

When the media itself was shortened at the beginning, the diagnosis is often known already. If you trim a WAV file by removing exactly 12.500 seconds before the first retained sample, an unchanged sidecar is now 12.500 seconds late relative to that audio and every cue needs the same earlier shift. The cut is a translation because no time inside the retained section was stretched.

The reliable rule

Do not choose a repair from one cue. One point can tell you the offset that aligns that point and nothing about the clock between it and the end.

Two separated, matching errors justify a constant shift. Two different errors prove that a constant shift is incomplete. A third point distinguishes smooth drift from a cut or an irregular track. That small measurement habit prevents the most frustrating failure in subtitle repair: making the opening perfect and discovering an hour later that the ending is now worse.