Two-Point Sync Tool

The Two-Point Sync Tool fixes subtitles that drift progressively out of step with the picture. Paste the file into the SRT Content box, name two anchor cues in First reference line # and Last reference line #, and type when those lines should really appear into First correct timecode and Last correct timecode. The output is a full SRT rescaled to fit between the two anchors.

Drift is not the same as lag. A file that is two seconds late throughout is cured by a flat offset. But subtitles authored against a 25 fps master and played at 23.976, or taken from a version with different breaks, go wrong by a growing amount: fine at the top of the reel, badly out by the end. Archive material, festival screeners, PAL-to-NTSC conversions and fan-sourced caption files all show this, and no single shift can fix it because each end needs a different correction.

The maths is a linear transform. The tool reads the current start times of your two reference cues as c1 and c2 and, with your targets t1 and t2, computes a scale of (t2 - t1) divided by (c2 - c1) and an offset of t1 minus c1 times that scale. Every start and end is then scaled, offset and rounded to the nearest millisecond. A pure delay gives a scale of 1; a frame-rate mismatch gives something near 1.001. Timecodes use HH:MM:SS,mmm, at least two cues are required, and the tool stops if both anchors share the same source time.

Everything is computed in the browser with no upload, and the resynced file downloads as .srt.

• True linear rescale: Rather than adding a constant, the tool stretches or compresses the entire timeline between your anchors, which is the only correction that fixes an error that grows across the file.
• Anchors chosen by cue number: First reference line # and Last reference line # take the subtitle index as shown in your editor, so you can pick any two lines whose real timing you can verify against the video.
• Exact target timecodes: First correct timecode and Last correct timecode accept full HH:MM:SS,mmm values, letting you correct to the millisecond rather than eyeballing a slider.
• Handles frame-rate conversions: Because the scale factor is derived from your own measurements, 25 to 23.976 and similar pulldown mismatches are corrected without you needing to know the ratio.
• Starts and ends both transformed: Each cue's in and out point is rescaled together, so durations stretch proportionally and no cue is left with a mismatched out point.
• Millisecond rounding: Results are rounded to whole milliseconds so the output is always a legal SRT rather than carrying fractional values.
• Clear guard rails: The tool tells you when the file has fewer than two cues, when a reference number or timecode is missing, and when both anchors share the same source time and no unique scale exists.
• Confirmation in the output: The result opens by naming the two line numbers it synced with, so you have a record of which anchors produced the file.

1. Paste the drifting subtitles into the SRT Content box, or press Load sample to practise on a short file first.
2. Play the video and find an early line of dialogue you can time precisely, noting its subtitle number and the true moment it is spoken, then do the same for a line as close to the end of the programme as possible.
3. Enter the early cue's index in First reference line # and its true time in First correct timecode using the HH:MM:SS,mmm pattern, for example 00:00:12,400.
4. Enter the late cue's index in Last reference line # and its true time in Last correct timecode, keeping the two anchors as far apart as you can since a wide span makes the scale far more accurate.
5. Press Run; the output confirms which lines were used and then lists the complete rescaled SRT.
6. Check the file at three points, near the start, in the middle and at the very end, because a correct scale shows its value in the middle of the reel.
7. Copy the result or download it as a .srt file, and if a small residual error remains, run the tool again on the new file with fresh anchors to refine it.

Example 1 - a 25 fps file played at 23.976. Line 1 is correct at the top but by line 400 the captions are more than a minute early. Anchoring both ends rescales the whole timeline.

Inputs:
First reference line #: 1      First correct timecode: 00:00:10,000
Last reference line #: 400     Last correct timecode: 01:29:57,600

Cue 200 before: 00:44:20,000
Cue 200 after:  00:46:11,050

Example 2 - a constant delay. Setting both targets two seconds later than the current times yields a scale of 1 and a flat two second push, so the same tool handles simple offsets.

Cue 1 before: 00:00:01,000 --> 00:00:04,000
Cue 1 after:  00:00:03,000 --> 00:00:06,000

The first case is the one no offset tool can solve: early cues barely move while later cues shift by minutes, which is exactly what progressive drift requires.

• Rescues files a simple shift cannot fix: Progressive drift is the most frustrating sync fault there is, and two anchors solve it in one pass instead of an evening of nudging cues.
• Recovers subtitles for a different master: A caption set authored for another frame rate or another cut becomes usable rather than being discarded and retimed from scratch.
• Accuracy you can verify: Because you supply real observed timecodes, the correction is grounded in the actual video rather than in a guess about ratios.
• Consistent across the whole programme: The end of the reel lands as accurately as the beginning, which is what viewers and QC reviewers notice.
• Hours of retiming avoided: Manually dragging hundreds of cues to chase a growing error is slow and introduces new mistakes; a single linear transform is repeatable.
• Screeners stay private: All computation runs locally in the browser, so pre-release material is never uploaded.