I compressed a recording 22 times to see how much accuracy it costs
By Andrey ChmerevI build Kekoso, and the transcription below was done with it, so treat the app as the instrument rather than the subject. The reference text is synthetic speech, which is cleaner than a real recording — the absolute error rates are therefore optimistic, and the comparison between variants is what the measurement is for. Run on 5 September 2026.

Everyone recording something to transcribe later asks the same question: how much does audio quality matter for transcription accuracy? The advice is usually “as good as possible,” which is not an answer.
So I measured it. One recording, several levels of destruction, the same transcription model on all of them.
The method
The reference is a 130-word passage — meeting minutes with names, numbers and technical words in them — synthesised to speech so the correct transcript is known exactly rather than typed out by hand. That removes the usual weak point of these comparisons, where someone transcribes the reference themselves and their own mistakes end up in the baseline.
That original was then encoded several ways, and each version transcribed with the same local model. Word error rate is edit distance against the reference — the full method, with the traps — after normalising numbers and punctuation so that 47 and “forty seven” count as a match — the same metric the published model benchmarks use, computed the same way.
So this is a measurement of audio quality for transcription in the narrow sense: same words, same voice, same model, only the encoding changes.
One honest caveat up front: synthesised speech is cleaner than a real recording. No room, no microphone, no accent, no overlapping talkers. The absolute numbers below are therefore optimistic. What the measurement is for is the comparison between variants, and that holds because every variant came from the same source audio.
The numbers
| Variant | File size | Errors in 130 words | Word error rate |
|---|---|---|---|
| WAV, 22,050 Hz (reference) | 2,128 KB | 3 | 2.3% |
| WAV, 8,000 Hz | 772 KB | 4 | 3.1% |
| Opus, 16 kbps | 100 KB | 5 | 3.8% |
| MP3, 16 kbps | 97 KB | 7 | 5.4% |
The bottom row is the headline. Twenty-two times smaller, three percentage points worse. And 16 kbps MP3 is not a normal setting — it is well below what anyone would pick for music, chosen here to find the breaking point.
Every version was completely readable. Not once was the meaning in doubt.
Telephone quality costs almost nothing
Dropping from 22 kHz to 8 kHz — the sample rate of a landline — cost one extra error in 130 words.
That is the whole story of sample rate for transcription, and it is not surprising once you look at where speech lives: the energy that carries intelligibility sits below 4 kHz, and by the Nyquist limit an 8 kHz sample rate captures exactly that. Everything above it is what makes a voice sound present and natural, and almost none of it is what makes words distinguishable.
This is also why speech models are trained at 16 kHz rather than 44.1 — Whisper’s own repository expects that rate. Feeding them a higher one does not help; it gets resampled on the way in.
The result that changed my mind
At the same 16 kbps, Opus scored better than MP3: 3.8% against 5.4%. On the table, Opus wins.
Then I read the actual transcripts.
MP3’s mistakes were currently becoming currency, and the rollout becoming a roll-out. Annoying, obvious, harmless.
Opus turned “Sarah raised a concern” into “Third, raised a concern”. It deleted a person’s name from a set of meeting minutes and replaced it with a word that fits the surrounding grammar perfectly. Nothing about the sentence looks wrong. If those were real minutes, the attribution of a concern to a named person would have quietly vanished.
Two mistakes, two error rates, and the one with the better score is the one I would rather not have. Word error rate counts words, not what the words were carrying.
Some errors are not about audio at all
The uncompressed reference still scored 2.3%. The model wrote covers for “covered” and, more interestingly, rollbook for “rollback” — a technical term it evidently does not know.
No amount of bitrate fixes that. rollback came out wrong at every quality level, identically, from the pristine WAV to the 97 KB MP3. It is a vocabulary problem, and the fix is a vocabulary: a list of your own terms applied after recognition, which is why most local apps have one and why it matters more than your recording settings do.
What to do with this
Stop optimising the recording and start optimising the words. If your transcripts come back with the wrong product names, the fix is a custom vocabulary, not a better microphone.
Compress audio transcription workflows without guilt. Bitrate for speech recognition matters far less than the vocabulary does: a one-hour meeting at 16 kbps is about 7 MB. You can keep years of recordings on a laptop without noticing, so the reason to delete them is policy, not disk.
Don’t chase sample rates. 16 kHz is the target the models were trained on. Recording at 48 kHz costs four times the disk to be resampled down anyway.
Do care which codec, if names matter. This is the one place where the choice is not free, and it is the opposite of what the error rate suggests.
And check the recording itself, not its settings. Nothing in this table simulates the actual killers: two people talking at once, a room with hard walls, a microphone across the table. Those cost far more than any codec, and this experiment deliberately did not test them — which is the honest limit of what it proves.
The whole run took a few minutes with a transcription app and ffmpeg — the same commands used for pulling audio out of a video produce every variant in the table. The method is in the FAQ above if you want to repeat it on your own voice, which will give you numbers that are worse than mine and truer for you.
Questions people ask
Does audio quality affect transcription accuracy?
Less than people assume. In my measurement, compressing a 2.1 MB recording down to 97 KB — a factor of 22 — moved the word error rate from 2.3% to 5.4%. That is three percentage points for twenty-two times less data. Every version remained completely readable and the meaning was never in doubt.
What sample rate do I need for speech recognition?
16 kHz is what the models are trained on, and 8 kHz costs surprisingly little. Downsampling my reference from 22,050 Hz to 8,000 Hz — telephone quality — moved the error rate from 2.3% to 3.1%, one extra mistake in 130 words. Speech energy lives below 4 kHz, and 8 kHz sampling covers that by the Nyquist limit.
Should I record in WAV or is MP3 fine for transcription?
MP3 is fine, and the file is an order of magnitude smaller. Even 16 kbps MP3 — well below what anyone would choose for music — produced a transcript with seven word errors in 130 words, all of them minor. If you are recording specifically to transcribe, storage is not the constraint you thought it was.
Which codec is best for recordings you plan to transcribe?
The comparison surprised me. At the same 16 kbps, Opus scored better on paper than MP3 — 3.8% against 5.4% — but its errors were worse: it turned the name Sarah into the word Third. MP3's mistakes were function words. A lower error rate is not automatically a better transcript.
Why is my transcript wrong even from a clean recording?
Some errors have nothing to do with audio quality. My uncompressed reference still scored 2.3%: the model wrote covers for covered and rollbook for rollback. Names, technical terms and unusual words are where recognition fails regardless of bitrate, and a custom vocabulary fixes those where more data does not.
How was this measured?
A 130-word text was synthesised to speech so the reference transcript is known exactly, then encoded into several variants and transcribed with the same local model. Word error rate was computed by edit distance after normalising numbers and punctuation. Synthetic speech is cleaner than real recordings, so absolute figures are optimistic — the comparison between variants is the point.