Automatic transcription has become good enough that people trust it too early. The transcript looks clean, the sentences are grammatical, and then a number or a name turns out to be wrong in a way that changes the meaning. Spotting those failures is a skill worth building, and it is easier when you know where the model is likely to slip.
Where it slips
Numbers and units. "Fifteen" and "fifty", "two point five" and "two to five". Any figure that matters should be checked by ear against the audio.
Proper nouns. Names, product names and place names get normalised to something more common. A person called Kasia becomes "cashier" surprisingly often.
Speaker changes. Diarisation is the weakest part of most pipelines. In a two-person interview the transcript will frequently attribute a whole paragraph to the wrong speaker, and it is rarely obviously wrong from the text alone.
Domain vocabulary. A medical or legal call is full of words the model has seen rarely in that combination. The output stays fluent, which is exactly the problem.
A checking pass that takes ten minutes
- Read the transcript once without the audio. Mark anything that feels oddly specific or oddly generic.
- Play the audio at the marked points and fix them.
- Check every number, every name, and every negation. A dropped "not" is the most expensive error in the whole file.
- Check who is speaking at each section boundary, not every line.
That is enough for meeting notes and interviews. For anything published, a full read against the audio is the only honest option.
Doing it without a workflow
For a single file, the fastest path is a browser tool rather than a local pipeline. FreeScribe accepts common formats such as MP3, WAV, M4A and MP4, produces an editable transcript, and adds subtitles and a summary. No account is needed, which is convenient for one-off files.
What it does not do is remove the checking step. Transcription gets you to a draft in minutes; the ten-minute pass is what makes the draft usable.
Top comments (0)