WER scores a wrong name, a wrong number and a missing "not" the same as a dropped "the". Judge a transcription system by which errors it catches and whether you can see its fixes, not by its headline number.
Word error rate is the standard yardstick for speech recognition. Take a reference transcript a person has checked, line the machine's output up against it word by word, and count three kinds of mistake: substitutions (a wrong word), insertions (a word never said) and deletions (a word missing). Add them up and divide by the number of words in the reference.
WER = (substitutions + insertions + deletions) / words in the reference
The lining-up is not done by eye. The two transcripts are aligned by minimum edit distance (the Levenshtein distance, applied to words rather than letters): of all the ways to pair the output with the reference, the scorer picks the one with the fewest edits and counts those. Because insertions count and the denominator is the length of the reference, WER can exceed 100 percent: a model that fills a quiet minute with text scores worse than one that writes nothing.
Suppose the reference is "we will meet Dr Okafor at nine on Thursday", nine words, and the machine writes "we will meet the doctor at nine on Tuesday". That is three substitutions (Dr, Okafor, Thursday) over nine words: a WER of 33 percent. Two-thirds of the words are right, and you are still at the wrong meeting on the wrong day. If only "Thursday" were wrong, the score would be 11 percent. A version with every word right but an added "um" nobody said also scores 11 percent, because an insertion counts the same as a substitution.
Before the count, both texts are usually normalised, and the choices made there move the score as much as the model does. Is "Dr" the same word as "Doctor"? Is "nine" the same as "9"? Do casing and punctuation count? Strict scoring would mark "Dr" against "Doctor" as a substitution. Most published scores lowercase everything, strip punctuation and write every number one way, as words or as digits, before comparing. A vendor's figure therefore quietly depends on a normaliser you cannot see. Languages written without spaces between words, such as Chinese, Japanese and Thai, have no clean word boundary to count, so they are scored by character error rate (CER) instead: the same formula, applied to characters.
Two things follow. First, a WER of 5 percent is one word in twenty, which comes to several hundred words in a one-hour talk. For scale, human transcribers are often quoted at roughly 4 to 5 percent on conversational speech, and a much-cited 2017 result on the Switchboard telephone corpus put a machine at about 5.1 percent, though both figures depend on the audio and the scoring rules. Second, the number depends entirely on the test audio: clean read speech gives one figure, and a noisy panel with accents and crosstalk gives a very different one. A headline WER describes the vendor's test set as much as it describes the vendor's system.
That is the count. What it leaves out is the cost of each error to the person reading.
WER treats every word as equal. Readers do not:
Each of these is one or two errors in the WER column. In the reader's column they range from nothing to a different meeting on a different day. So the question is not only "what is the error rate" but "what kinds of errors, and what catches them".
Several layers catch what recognition gets wrong, and every change is recorded so it can be inspected and reversed. On a live transcription this happens while the text is still arriving: each line shows first as a draft that may still change and then becomes final (Live translation latency, explained covers why).
Some mistakes fit the sound but not the sentence: "their" where the sentence needs "there". These can be caught from context, and a correction reaches readers as a visible update (transcript.amended in the API), not a silent rewrite. Context is good at words the sentence can predict. It is helpless with the ones it cannot.
Names and technical terms are the errors context cannot fix, because a name often appears only once, with nothing around it to predict it from. A reference script solves this: give the system the speech, the slides or a list of names and terms before you start, and its words take priority over what the engine misheard. During the recording the script follows the transcript like a teleprompter, so the host can see how far the engine has got. A script covers the words you can predict; noisy audio and accents produce the ones you can't.
AI-assisted auto-fix is on by default. It corrects likely mishearings as lines arrive, which earns its keep on noisy audio and heavy accents. Every fix is marked, and the marking is the point: a corrected word is flagged as corrected, in the Dashboard and in the API's transcript, so anyone can tell a recognised word from a repaired one. If auto-fix is switched off mid-recording, no new fixes are made from the next line on; fixes already made stay, and each can still be reverted. A model, however good, still only knows what was said; it does not know what was meant.
Some errors only a person in the room can see. Manual corrections let the host rewrite any word or line while the transcription is still live, and every listener on the broadcast sees the change. The system points the host at the likely candidates: words the engine was unsure of can be coloured and underlined, and the host can step through the uncertain segments one at a time rather than reread the whole transcript. Through the API, GET /v1/recordings/{id}/corrections lists a recording's corrections and POST /v1/corrections/{id}/revert undoes one; see the API reference. Even a person in the room, though, cannot correct a line nobody could hear.
The last layer accepts that some audio is not recoverable. When a line scores below the transcription's confidence threshold (confidence.hideBelow, 0.60 by default), listeners see "Audio unclear" in its place instead of a guess, and the line is never read aloud. Readers lose a line; they do not gain a fabricated one.
The same questions that shaped these layers work on any vendor's accuracy claim, including ours.
A short checklist for reading any accuracy claim:
VocalStack does not publish an internal WER figure, for the first reason above: it would describe our test set, not your audio. We measure accuracy continuously. Where we compare other systems, we use published independent benchmarks and vendor-published figures, never private tests. The rest is for your own audio to decide.
