Subtitle Reading Speed Checker

Characters per second is the measure subtitling actually uses, and it is the right one because it accounts for word length in a way a word count cannot. Divide the characters a viewer has to take in by the seconds they have to do it, cue by cue.

It is the reading rate a QC pass measures, and it is the one subtitle quality check that reading the file through will not find — because the cue that fails does not look like the cue that fails.

Markup is stripped before counting. A cue reading <i>Hello</i> puts five characters on screen, not twelve, and the ASS-style {\an8} positioning tags that turn up inside SubRip files put none at all. Counting them inflates the figure on exactly the cues that are already styled, which are usually the ones worth checking.

A line break counts as one space. Two lines of a caption are read as a single sentence — the break is a layout decision, not a pause — so counting the newline as a character would penalise every well-formed two-line cue.

What counts as too fast is a house style, not a law, and it varies by language. Netflix caps most languages at 17 characters per second for adult programming and 13 for children, but their English guide runs looser at 20, and other broadcasters differ again. Arabic and other scripts do not read at the same rate as English at the same character count. That is why the limit here is yours to set rather than baked in.

The tool lists rather than rewrites. Fixing a fast cue means cutting words or giving it more time, and both are the translator’s judgement — a tool that trimmed the text for you would be making an editorial decision and calling it a correction.

Overlapping cues are counted in the status line too. They are a different fault that shows up in the same read, and players resolve them unpredictably.

Press Load a sample and leave the limit at 17. Four cues; one of them is flagged.

Cue 3 is the fault, and reading through the file would not find it. The line is not unusually long and 1.4 seconds is not an unusually short cue. It is the combination — 60 characters in 1.4 seconds, 42.9 per second — and nothing about either number looks wrong on its own. That is what a per-cue count is for.

Cue 2 is the useful contrast. It is nearly the same length — 59 characters, over two lines — and it passes comfortably at 16.9 per second, because it has 3.5 seconds rather than 1.4. One character shorter than the cue that fails, and two and a half times easier to read. Long is not the problem. Fast is.

Drop the limit to 12 — a children’s programming figure — and cue 2 appears in the list as well. Nothing about the file changed; the audience did.

If cues are also mistimed against the picture, retime the track first. Reading speed measured against the wrong timings measures nothing.