# How to transcribe a long recording accurately

What accuracy percentages actually measure, where the errors really land, and the three-pass check that finds them without re-listening.

## In short

Transcription accuracy figures are measured on clean single-speaker audio and do not predict how a tool performs on your recording. Errors cluster in proper nouns, numbers, short replies and overlapping speech rather than spreading evenly. Improve the recording before the model: separate tracks per speaker, a close microphone, and a vocabulary list of names. Then check the transcript by searching for those names and numbers rather than by reading it through.

## What does "99% accurate" actually mean?

Accuracy claims are almost always measured on clean, read, single-speaker audio,
which is the easiest material that exists. Whisper large-v3 scores around 2.7%
word error rate on LibriSpeech test-clean. That is audiobook recordings: one
speaker, close microphone, no interruptions, no crosstalk.

On real meetings, podcasts and phone calls the same model lands nearer 8 to 12%.

![Word error rate for the same model across different audio conditions](https://peachimp.com/blog/transcribe-a-long-recording/02-wer.png)

| Condition | Word error rate |
|---|---|
| LibriSpeech test-clean, read audiobook speech | 2.7% |
| Real meetings and calls | 8 to 12% |
| Spontaneous conversation | around 31% |
| Low-resource languages | 25% and higher |

Word error rate counts the proportion of words inserted, deleted or substituted
against a reference transcript. A 2.7% figure and a 31% figure can describe the
same model on the same afternoon. The only thing that changed is what it was
asked to listen to.

The practical consequence is that vendor accuracy numbers cannot rank tools for
your use. What separates them is behaviour on the specific things your audio
contains, and none of that appears in the headline figure.

## Is human transcription the gold standard?

Human transcription is the reference these models are scored against, and the
reference turns out to be less stable than it sounds. Careful human
transcription of one corpus has been measured at 4.1 to 4.5% error. Quick
transcription of the same material came in at 9.6%. Same people, same audio,
different amount of care.

It gets less comfortable than that. When four human transcribers produced
versions of one recording, the error rates between the humans ranged from 10% to
20%. On the CallHome corpus, the accepted human reference differs by a factor of
1.66 between two competent teams working from identical tape.

> A claim of "human parity" is a claim about one transcription protocol, not
> about human beings. Two labs measuring the same thing got answers that
> differed by more than the gap they were trying to measure.

For a long recording the useful conclusion is blunt. A perfect transcript does
not exist to be bought at any price. The realistic goal is a transcript whose
errors sit in places you can find, which is a completely different target and a
much cheaper one.

## Where do the errors actually land?

Errors cluster, and they cluster in the places that matter most for searching
and quoting later:

- **Proper nouns.** A model resolves ordinary English from context and has no
  context for your colleague's surname, so it substitutes the nearest common
  word and does it confidently.
- **Numbers.** Dates, quantities and figures, which are high-value and hard to
  spot as wrong.
- **Short replies.** Single-word utterances have the highest error rate of any
  length, thought to follow from these models being trained on thirty-second
  chunks.
- **Overlapping speech.** Two people at once is the condition every benchmark
  avoids and every real meeting contains.
- **Domain jargon.** Terms a general model has no reason to have seen.

The short-reply problem deserves more attention than it gets. In a meeting
recording the single words are `yes`, `no` and `agreed`, and those are the words
decisions hang on. A transcript that is 94% accurate overall can still be wrong
about who agreed to what.

Overlap is the other reliable failure, and it is architectural rather than
incidental. Whisper does not perform speaker diarization at all. Working out who
spoke when is a separate model layered on top, usually pyannote.

![The pyannote speaker diarization project, the standard open model for working out who spoke when](https://peachimp.com/blog/transcribe-a-long-recording/03-pyannote.png)

Diarization has its own error rate, reported around 11 to 19% on standard
benchmarks and worse on audio with heavy overlap or more than four speakers.
Those errors compound with transcription errors rather than replacing them.

## How do you set up a long recording to transcribe well?

Fix the audio before you touch the model, because no model recovers information
the recording never captured.

A separate track per speaker eliminates the overlap problem entirely, and it is
the single highest-value change available. Most conferencing tools will export
per-participant audio if you ask before the call rather than after. Ten seconds
of setup removes the failure mode that costs the most to repair.

Failing that, get the microphone close. Reverberation costs Whisper large-v3
about 2.3 points of word error rate, and costs Whisper tiny over 15 points, so
room acoustics punish small models hardest. A lapel or headset microphone at
conversational distance beats any amount of post-processing.

![OpenAI's file transcription documentation, showing the 25 MB upload limit and the supported input formats](https://peachimp.com/blog/transcribe-a-long-recording/01-whisper.png)

Watch the file size limit before starting a long job. OpenAI's file transcription
endpoint accepts uploads up to 25 MB, which an hour of good quality audio
exceeds comfortably. A long recording therefore has to be compressed or split,
and chunking on silence rather than on a fixed clock keeps words from being cut
in half at the boundary.

Compression is usually the better answer for speech. Dropping to a 64 kbps mono
MP3 costs almost nothing in recognition accuracy, because speech recognition
models are not listening to the frequencies that bitrate discards.

## Should you give the model a vocabulary list?

Give it one whenever you know the names in advance, which for a meeting or an
interview is nearly always. Most transcription APIs accept a prompt or a phrase
list, and supplying the proper nouns is the cheapest accuracy improvement
available. It costs one line of input and it targets exactly the errors that
model scale does not fix.

What belongs on the list:

- People's names, including the ones spelled unusually
- Company and product names
- Acronyms your field uses
- Technical terms a general model would not have seen
- Place names local to the conversation

What does not belong: ordinary vocabulary. A list padded with common words
dilutes the signal and makes the useful entries less influential.

Where a tool offers no vocabulary feature, fall back to find and replace over
the finished transcript. Less reliable, because a substituted name is not always
substituted the same way twice, but it takes minutes and it fixes the errors a
reader notices first.

## How do you check a transcript you cannot re-listen to entirely?

Check the places errors cluster instead of reading the whole thing. Nobody
re-listens to a two-hour recording, and reading the transcript straight through
does not work either, because a confidently wrong word reads as perfectly good
prose.

Three passes, in increasing cost:

1. **Search for every name on your vocabulary list.** A name that never appears
   was substituted by something else. This takes about a minute and finds the
   errors most visible to anybody you send the transcript to.
2. **Search for the numbers.** Dates, figures, quantities, times. Digits are
   high-value and frequently wrong, and they are quick to scan.
3. **Spot-listen where confidence is low or speakers overlap.** If the tool
   reports per-segment confidence, sort by it. If it does not, look for very
   short turns in the diarized output, which is where overlap usually is.

| Pass | Time on a 2-hour recording | What it catches |
|---|---|---|
| Name search | 1 to 2 minutes | Substituted proper nouns |
| Number search | 3 to 5 minutes | Wrong dates and figures |
| Confidence spot-listen | 15 to 30 minutes | Overlap and crosstalk errors |

The first two cost almost nothing and catch the errors that embarrass you. The
third is the one to skip when the transcript is for your own reference and to
run when somebody else will quote from it.

The principle underneath all three is that you check with a different instrument
from the one that produced the artifact. Re-reading a transcript uses the same
faculty that produced the error in the first place. Searching for a name you
already know is genuinely independent, which is the same reason a
[subtitle file gets watched muted](https://peachimp.com/blog/add-subtitles-to-a-video), and the
reason every pipeline in our [worked examples](https://peachimp.com/docs/examples) ends with a
measurement rather than a delivery.

## Which tool should you use for a long recording?

Pick on three things: whether it does diarization, whether it accepts a
vocabulary list, and what happens to files over an hour. Raw accuracy is the
axis everybody compares on and the one that separates these least.

| What to check | Why it decides the job |
|---|---|
| Speaker labels | Meetings are unusable without them |
| Vocabulary or prompt support | The cheapest accuracy gain available |
| File size and length limits | Decides whether you have to chunk |
| Per-segment confidence | Tells you where to spot-listen |
| Export with timestamps | Needed to jump back to the audio |
| Where the audio is stored | Matters for anything confidential |

The last row is the one that gets skipped and then causes a problem. A recording
of an internal meeting is company data, and uploading it to a consumer service
with unclear retention is a decision somebody should make deliberately rather
than by default. Running a model locally is genuinely practical here, because
speech recognition is one of the few tasks where an open model on a laptop is
close to the hosted state of the art.

For a one-off recording, use whatever the platform already gives you and spend
the saved effort on the checks. For anything recurring, the cost of setting up a
vocabulary list and a per-speaker export pays back within about three
recordings, because both changes attack the errors that take longest to find.

## When is it worth paying a human?

Pay a human when the transcript is evidence, when the audio is bad and cannot be
re-recorded, or when the material is legally or medically consequential.

Evidence is the clearest case. A transcript quoted in a document somebody else
relies on needs to be right in the places that matter, and the cost of a human
pass is small against the cost of being wrong in public. Professional
transcription typically runs somewhere between $1 and $3 per audio minute
depending on turnaround and accent difficulty.

Bad audio is the second case, and the economics are counterintuitive. Machine
transcription of a difficult recording produces a transcript that takes longer to
correct than it would have taken to type, because you have to listen to
everything anyway to know which parts are wrong. Past roughly 20% word error
rate the machine draft stops being a head start.

Everything else is a good fit for a machine draft plus the three checks above.
That covers the overwhelming majority of meetings, interviews and podcasts, and
it costs a few cents rather than a few hundred pounds.

## Steps

1. **Record a separate track per speaker if you can** — Separate tracks remove the overlapping-speech problem entirely. Ask before the call, because most conferencing tools will export per-participant audio.
2. **Get the microphone close** — Reverberation costs the largest models about two points of word error rate and the smallest over fifteen. Room acoustics punish cheap models hardest.
3. **Write a vocabulary list before transcribing** — Names, companies, products, acronyms. One line of input, and it targets exactly the errors that model scale does not fix.
4. **Split long audio on silence, not on a clock** — The OpenAI file endpoint accepts up to 25 MB, which an hour of good audio exceeds. Chunk at pauses so no word is cut in half at a boundary.
5. **Check by searching, not by reading** — Search for every name on your list, then for every number. A confidently wrong word reads as correct prose, so reading through will not find it.

## Questions

### What is a good word error rate?

It depends entirely on the audio. Around 2.7% is achievable on clean read speech, 8 to 12% is normal for real meetings and calls, and low-resource languages can exceed 25%. A number quoted without the material it was measured on tells you nothing.

### Can these tools tell speakers apart?

Not on their own. Whisper performs no diarization; separating speakers is a second model layered on top, and the standard one reports 11 to 19% diarization error on benchmarks and worse with heavy overlap or more than four speakers.

### Is a bigger model always better?

For robustness, largely yes. The reverberation penalty is far smaller on large models. For clean close-miked audio the difference narrows to the point where speed and cost decide it.

### Why do short answers get transcribed wrong so often?

Single-word utterances have the highest error rate of any length, thought to follow from training on thirty-second chunks. In a meeting that means the yes, no and agreed, which are the words decisions hang on.


## Sources

- [Speech to text: file transcription, limits and formats](https://platform.openai.com/docs/guides/speech-to-text) — OpenAI
- [Disfluencies and Human Speech Transcription Errors](https://arxiv.org/pdf/1904.04398) — arXiv
- [pyannote.audio: speaker diarization models and benchmarks](https://github.com/pyannote/pyannote-audio) — pyannote
- [Whisper-RIR-Mega: ASR robustness to room acoustics](https://arxiv.org/pdf/2603.02252) — arXiv

## Screenshots in this guide

- https://peachimp.com/blog/transcribe-a-long-recording/01-whisper.png — OpenAI's file transcription documentation stating that files can be up to 25 MB and listing supported input formats mp3, mp4, mpeg, mpga, m4a, wav and webm (OpenAI platform docs), captured 5 September 2026, from https://platform.openai.com/docs/guides/speech-to-text
- https://peachimp.com/blog/transcribe-a-long-recording/02-wer.png — Bar chart of word error rate by audio condition, showing 2.7 percent on clean read audiobook speech, around 10 percent on real meetings and calls, 31 percent on spontaneous conversation and 25 percent or higher on low-resource languages (Chart, from published benchmark figures), captured 5 September 2026
- https://peachimp.com/blog/transcribe-a-long-recording/03-pyannote.png — The pyannote-audio project page on GitHub, the standard open source toolkit for speaker diarization (pyannote-audio on GitHub), captured 5 September 2026, from https://github.com/pyannote/pyannote-audio

---

By Peachimp · https://peachimp.com/@peachimp
Published 5 September 2026. Last updated 5 September 2026.

Page: https://peachimp.com/blog/transcribe-a-long-recording
More on this: https://peachimp.com/blog/topics/audio