I measured why AI subtitles "read too fast". It was the timing, not the words

Strong measurement, and the timing-before-words ordering is right. One thing worth surfacing in the QC output: the ratio of the file's spoken CPS to the target reading limit. 447 words in 2:48 is about 160 WPM, which is fast for narration — the same cue-splitting rules over a 135 WPM read would push far fewer cues over 17 CPS, and a reader can't tell from "68% over limit" whether they're looking at a timing problem or a fast speaker. Printing measured speech CPS next to the limit also predicts how much headroom the timing fixes have: when speech CPS sits at or near the limit, extending cues into pauses and merging short neighbours can absorb most of the overflow, which is exactly what your 68% to 24% shows. When speech CPS is well above the limit, no timing fix gets there and the character cut is unavoidable — so the ratio tells you which branch you're in before you start editing.

Same finding here. Most "too fast" complaints disappear once you time cues by reading speed instead of by when the words are spoken. The rules that have worked for us: cap at ~17 characters per second (15 for kids/learners), minimum ~1s on screen, max ~6-7s, max 2 lines of ~42 chars, and a small 2-frame gap between cues so the eye registers the change. Then let a cue hang a bit past the end of the speech when the next line allows it, and snap cue in/out points to shot changes when they're within ~10 frames, because a subtitle straddling a cut feels rushed even when the CPS is fine. Break lines on phrase boundaries, not mid-phrase. Word-level timestamps from the ASR are great for the start time, but the end time should come from the reading-speed math.

The measurement is the insight here. Most people debugging subtitle speed would look at the word count per cue, which points at the text. Measuring CPS against the actual speech rate isolates the variable — the text is fine, the container is wrong.

The minimum-duration fix is elegant because it does not touch the content at all, just the window around it. We run into a similar pattern with page-load timing in our site audit tool — a page that loads in 400ms can still fail a performance check because the measurement window captures the wrong phase of the load. The metric and the thing it measures are both correct, but the alignment between them is off.

Four comments suggests this is under-read for how specific the finding is.

Nice measurement. One addition worth reporting: the per-cue 90th percentile CPS alongside the % over limit. A file can pass on the % and still have a few 30+ CPS cues that feel broken. Also worth noting the sample: 447 words at 2:48 is ~160 WPM, and speech rate is the biggest confound here. Rerunning this on a 130 WPM and a 190 WPM file would tell you whether that 68% baseline is stable or rate-dependent.

Fair challenge. I’d frame it as a measured finding from one test case, not yet a broad user-validated productivity claim. I don’t have data showing a specific reduction in editing time yet.

What I can say is that timing changes alone took this file from 68% to 24% of cues above 17 CPS, with no words removed. That suggests timing-first can avoid unnecessary rewriting; the next step is testing whether that translates into fewer edits and faster completion across real user projects.

Have real users shown that fixing cue timing first reduces their editing effort, or is the timing-first workflow still mainly a finding from your own test case?