The most dangerous transcription errors read perfectly

A Norwegian interview, clean audio. The interviewee is saying they did not cheat on their partner. One engine's transcript has them saying they chose to cheat.

The sentence is grammatical. No typos. It doesn't even jar in context. A reader has no reason to stop.

A flipped negation is the worst error an interview transcript can have

When a word is misspelled, readers usually notice. When the meaning is reversed, they don't.

The Norwegian case wasn't a one-off. We later ran five more Norwegian clips through Gemini and Qwen. Both produced the same kind of error on clear passages.

It happens in English too. "You're still not a cop" became "still a cop" in both of Qwen's speech models. The "not" was simply gone.

We tried instructing the model directly: keep every negation exactly as spoken, mark anything you can't hear, don't fill anything in. It made no difference. The "not" still disappeared.

A majority vote won't save you

The obvious fix is to run several engines and go with the majority.

In five languages (Russian, Korean, Ukrainian, Norwegian and Spanish) we found places where several engines made the identical mistake and the correct version was in the minority. In four of them, the mistake was a negation or a reversed meaning. In the Norwegian case, five engines flipped it and only one got it right. Put it to a vote and the wrong answer wins.

The reason is that one unclear stretch of audio can lead several engines to "hear" the same wrong thing. Their errors aren't independent.

So our rule is: wherever negation or reversed meaning is involved, agreement between engines counts for nothing. We need hard evidence, such as the logic of the surrounding sentences or the speaker restating the point a moment later. Without it, the spot is flagged for a person to listen to. We don't make that call for the reader.

Fluent mistakes are harder to catch than obvious ones

Flipped negations are one kind. There's a subtler one.

We built a test recording: Spanish conversation with one line of Chinese spliced into the middle, "你是谁?" ("Who are you?"). One engine didn't transcribe the Chinese. It translated it, writing "¿Quién eres?". The whole transcript contained no Chinese at all and read perfectly. If you don't speak Chinese and didn't listen to the audio, you'd never know another language had been spoken there.

What these errors share is that the transcript looks completely fine. You can't find them by reading. Someone has to tell you which second to go and listen to.

A transcription tool should tell you where it's unsure

So do the transcription tools people actually use tell you "I'm not sure about this bit"? In September 2026 we went through 15 common ones: help centres, product documentation, API docs and changelogs.

Three show it in the editor:

• Sonix has a heatmap you can switch on, shading each word by how confident the engine is. Lighter means less confident. Sonix itself notes that a light word is "not necessarily an error".
• Rev has an editor toggle that highlights words its engine flagged as possibly wrong in grey.
• Happy Scribe shows low-confidence words in red. Our source is a help article from 2023; we haven't confirmed the current interface.

Only in the API or exports: Amberscript can include a per-word confidence score in its export files; for highlighting in the editor we only found third-party claims. For TurboScribe, only third-party articles say it highlights low-confidence words in yellow, and we couldn't load its own site to check.

We found no such feature in 10: Transkriptor, Otter.ai, Fireflies.ai, Notta, Noota, Trint, Descript, Riverside, Dovetail and transcribe.com.

Not finding it isn't the same as it not existing. Some API documentation sits behind a login or loads with scripts, and we couldn't read all of it. If you use one of these and it does have the feature, tell us and we'll correct this.

An engine grading itself is not the same as engines disagreeing

The three tools that have this feature all flag the same thing: one engine's score of its own confidence.

That's genuinely useful, with one blind spot. If an engine mishears something confidently, its own score won't raise an alarm.

Our approach is to have several engines transcribe the same audio and flag the places where they don't agree, along with names, companies and technical terms, which are where mistakes cluster. Each flag carries a timestamp, and one click plays that second. Only when every flag has been dealt with does the product say the transcript is ready to export.

That still won't catch everything. When several engines all get the same spot wrong in exactly the same way, they "agree", and nothing gets flagged. That's why we check negation and reversed meaning even when every engine says the same thing.

What we can promise is that you don't have to replay the whole recording. Only the places worth doubting.