Skip to content

Build1 publisher3 min readPublished

Stretching cues into speech pauses fixed 27 of 47 too-fast Whisper subtitles

Extending Whisper subtitle cues into the next pause cut the count over 17 characters per second from 47 to 20 in a dev.to test on one 168-second clip. The result argues for fixing timestamps before trimming words, wherever the speaker leaves silence to borrow.

The Engineer · Build desk

Illustration accompanying Stretching cues into speech pauses fixed 27 of 47 too-fast Whisper subtitles

What happened

  • A dev.to post ran Whisper's base model on its authors' product voiceover and split the transcript with ScribeToAny's rules of at most 84 characters and 7 seconds per cue.
  • With every cue starting on its first word and ending on its last, two thirds of the cues were flagged as too fast to read.
  • Extending each cue's end into the silence before the next line, with an 80 ms gap and a 7-second cap, cut cues over 17 CPS from 47 to 20 without changing a word.
  • The post says merging cues that were still too fast with their short neighbours fixed most of the remaining failures.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • decision A subtitle pipeline can run the timestamp-only pass first, with no editor and no model call, and send only what it leaves over to text condensing.
  • constraint Timing fixes can only spend silence the speaker left, so a target near the bottom of the BBC's 14-16 CPS band would push this clip back to cutting words.
  • exposure A QA gate built on a tool that skips spaces or punctuation will report lower CPS for the same cue, and can pass subtitles a full-count checker would flag.

Reading speed is characters divided by time on screen. Time on screen is the cue's end minus its start, not the time the speaker took to say the words [1]. In this test every cue started on its first word and ended on its last [5]. Screen time therefore equalled speaking time. Whisper's timings were accurate, in the narrow sense that the words were in fact spoken inside them. A cue built that way runs at the speaker's pace for that phrase, and this voice averaged 17.0 CPS while talking [3]. That matches Netflix's stricter English limit, the one it uses for children's programmes [6], so any phrase delivered a little faster than average fails it.

Short cues fail worst. "Need more?" was on screen for 0.36 seconds, or 27.8 CPS, and "Fix it right there." for 0.6 seconds, or 31.7 CPS [8]. Both are shorter than Netflix's minimum duration of 5/6 of a second [14]. Holding "Need more?" to that minimum alone drops its 10 characters to 12 CPS [3]. "Fix it right there." has 19 characters. At the minimum it still runs at 22.8 CPS, and it needs about 1.12 seconds to get under 17 [4].

The extension step works on this clip because the speaker left room. The clip runs 168 seconds and the words fill 142 of them, so about 26 seconds, or 15% of the runtime, is silence available to borrow [2]. Moving end times into it cleared 57% of the over-limit cues [1]. The pass edits end timestamps and nothing else. I'd run it first in any subtitle pipeline, before a person or a model condenses a line. The post says merging short neighbours then "fixed most of the rest" [10]; the count after that step was not available.

The author wrote of too-fast AI subtitles: "They're timed too tightly, and you can fix most of them without deleting a single word." [15] The evidence is one clip, one synthetic voice with natural pauses between sentences, and Whisper's base model [3][4]. For the result to transfer, the audio needs similar silence. The post itself notes that a word-for-word subtitle of a fast talker can break 17 CPS on text alone [12].

Timing also has a floor. If every second of this clip were screen time, its 2,413 characters over 168 seconds would average about 14.4 CPS [5]. On average that clears Netflix's 17 and 20 with room. The BBC's 160-180 words per minute works out to about 14-16 CPS in the post's counting [11]. A target at the low end of that band would leave this clip almost no slack, and cutting words would come back.

The method is careful. The post defines its character count, spaces and punctuation included and only the line break excluded, before quoting any figure [2]. It also says a Latin-script limit would never flag Chinese or Japanese text, which needs its own threshold [13].

What to watch

  • A rerun on unscripted, multi-speaker audio with overlapping speech, where the silence the extension step borrows is scarcer.
  • The post's count after the merge step, which would show how many cues still need their text condensed.
  • Whether subtitle QA tools publish whether they count spaces and punctuation, since that changes every CPS figure they report.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories