Call transcription what five minutes of hold music does to a call recording, measured on the clock and on the words

Questions people actually ask about this phrase

How accurate is phone call transcription?

It depends more on the recording than on the vendor claim, and almost nobody tells you the second half. Fifteen of the 43 readable pages in this family print an accuracy figure: Aircall "a minimum of 85% accuracy", Audiototext 99%, Transkriptor 99%, Riverside 99%, Sonix 99%, Notta "up to 98.86%", Transcription US ">98%", Speechnotes "can easily reach 95%" and so on. None of the fifteen states how many words the number was computed over, what audio it was computed on, or whether the audio arrived over a phone line. Our own reference: the same 72.454 s of read speech scored 20 wrong words out of 189 (10.58%) before any waiting was added, and 20 again after five minutes of hold music and ringback — and a rerun of the identical audio, in a different container, produced two more. The waiting did not cost accuracy here; it cost time.

Does hold music or a ringback tone break a call transcript?

Not in this measurement. We added 30, 60, 150 and 300 seconds of synthetic hold music and ringback to the head of the same recording. All four transcripts have the identical SHA-256 prefix 3c6ff85d409fffca and 20 wrong words: the music and the ring tone produced no text of their own, and the speech behind them was transcribed word for word as in the un-padded file (identical prefix acc0191de14d0fc2 apart from four words that move on every run). If you expected a hold-music bed to wreck the transcript, the measurement disagrees and we are printing the disagreement.

Is a longer call file slower to transcribe?

It is slower in seconds and much faster per minute. The 72.454 s call took 53.4 s; the 372.454 s call, which is the same speech behind 300 s of waiting, took 86.2 s. That is 44.2 seconds of processing per audio minute for the short file and 13.9 for the long one. The short number is inflated by a one-off cost: the first run of the session downloads the 63 MiB model plus a 21.5 MiB runtime, and its status line spends 21 seconds on that before any segment is decoded. Later runs in the same profile start transcribing within 6 seconds. Read the long file's number as the steady-rate figure and the short file's as the one that carries the download.

Can I upload the call recording my recorder app saved?

Yes, if you have the file. Our page takes MP3, WAV, M4A, MP4, WebM, OGG, AAC and FLAC, up to 30 minutes of audio and 512 MiB per job, so a 372-second call is one job and a two-hour conference recording is four. Two caveats worth knowing before you start. First, we do not accept AMR, which is what a lot of call-recorder apps export by default — Audioscribe answers the same question the same way, "the tool doesn't accept AMR", and tells you to convert first. Second, we do not record calls: this is a file you already have, and the model runs inside your browser tab, so the audio is not uploaded anywhere.

Does call transcription need speaker labels?

Only if you are going to quote it. Seventeen of the 43 readable pages advertise speaker labels, diarisation or "who said what", and not one of them gives a number for how often the labels are right. We do not offer them: the recogniser on this site is Whisper-tiny and does not do speaker separation, so the transcript is one stream of text. If you need to attribute a line to the agent or the customer, the practical answer is the one Vonage describes on its API page — split the recording into two channels, one per side, and keep them apart — which is a property of how the call was recorded, not of the transcriber. One page in the 43 mentions channel splitting.

Why are half the results for call transcription business phone systems?

Because the phrase mostly describes a feature of a phone platform, not a job you do to a file. Of the 43 readable pages, 17 are vendors selling telephony, call-centre or meeting software — Aircall, Dialpad, Gong, Vonage, Twilio, Quo, Otter’s notetaker, Notta’s call tool and their comparison posts — and several of them transcribe as the call happens, on their own infrastructure, because they carried the call. The other side of the family is a hand: conference call transcription services that publish per-minute rates and human transcriptionists. Between them, very little is written for someone holding a finished recording on a laptop, which is the case this page measures.

What about video calls and conference calls?

The same arithmetic applies, with one more variable. A video call is still one file per recording, and the waiting is still waiting; what changes is that the participants are mixed into one track unless the platform kept them separate, and that the platform’s codec is usually wideband rather than the 8 kHz a dial-in leg gets. On our own site the same speech through a wideband chain and through a G.711 8 kHz phone chain scored 19 and 23 wrong words out of 189 — a four-word difference, measured on 2026-10-23 and published in the same repository. Four words is not the size of the problem people pay to solve, and none of the 43 pages here puts a number on it.

What the 43 pages do and do not say

• Seven searches, 70 slots, 48 distinct URLs, 43 hosts. Search taken 2026-10-24 via Brave, top ten per phrase. The family is owned by platforms rather than by tools: vonage.com, twilio.com, dialpad.com, otter.ai, audioscribe.io, whispertranscribe.ai and apple.com each hold two slots, and no other host holds more than one. Thirteen of the twenty top-ten slots for call transcription and transcribe phone calls are business-phone, meeting or telephony-API platforms.
• 43 of the 48 pages read. help.otter.ai, dittotranscripts.com and conferencecalling.com returned a 403 or a script shell at three user-agent layers; two reddit threads returned 403 at those same layers. Those are counted as not read and every denominator below is 43.
• Fifteen pages print an accuracy percentage. None of the fifteen gives it a denominator. Aircall “a minimum of 85% accuracy”, Audiototext “99% Accuracy Rate”, a call-recorder app on Google Play “99% transcription accuracy”, Riverside and Sonix and Transkriptor 99%, Notta “up to 98.86% accuracy”, Transcription US “>98%”, Transcription Wave “99% accuracy”, Speechnotes “can easily reach 95% accuracy for good quality dictation or recording”. Test set, ground truth, validation set and sample size appear on one page — ScreenApp's “42,699 calls transcribed in our production corpus to date”, which is a usage count, not an accuracy denominator.
• The waiting inside a call does not exist on these pages. 1 of 43 mentions hold music, and that is the word “on hold” inside a sentence about accountability. 0 of 43 mentions a ringback tone, 0 mentions dead air, and 0 attaches a number to a silence. Four pages use the words silence or pause at all, and all four use them about something else: a phone setting, a text-to-speech timing control, an anti-lag tip for dictation.
• How long a call is comes up three times. Aircall’s “a 10-minute call is ready in around 3 minutes” (its fastest-transcript claim, 30% of call length), Transcription US’s “conference calls can often last from 45 to 60 minutes or more” and one comparison table’s “30-minute call”. None of the three relates the length to accuracy, or to how much of that length was speech.
• The signal itself is absent. Sample rate appears on one page (Riverside, about its own recording setting), kHz and kbit/s on one (a text-to-speech product's audio settings), G.711 / G.722 / narrowband / wideband on zero, codec on zero. AMR is the only call-codec name anybody uses, and it appears as a format the tool will not accept: Audioscribe “the tool doesn't accept AMR, which many call-recorder apps use by default”.
• Seventeen pages sell speaker labels. None gives a number for them. “Speaker diarization identifies who said what” (Sonix), “automatically split by speaker” (Audioscribe), “Speaker recognition labels who said what” (Uniscribe), “Speaker Diarization” as a menu item (ScreenApp), and so on. Not one of the seventeen publishes a diarisation error rate or a per-speaker accuracy. One page describes the mechanical alternative — Vonage’s “split channels between agent and customer”.

Counts are over the pages we could actually read on one day. Where a page returned 403 or a script shell we say so and leave it out rather than guess. Substring hits were checked in context before being called zero — the “alaw” inside “Malawi” on two country lists, and the “wideband” inside Apple’s compliance footer, are not mentions of an audio codec.

Adding the waiting a real call contains

The source is 72.454 seconds of read speech — six existing clips, one speaker, 189 reference words — concatenated and held at a fixed length. That is the speech in the call. Then we built the rest of a call around it: hold music (a four-chord arpeggio at 261.63, 392.00, 440.00 and 349.23 Hz) and a ringback tone (450 Hz, one second on, three seconds off — the European and North American cadence). Five files, one variable:

The transcripts of the last four are the same file: identical SHA-256 prefix 3c6ff85d409fffca, 991 characters, 184 tokens. The music and the ring tone produced no text of their own — no “[music]”, no repeated word, no stray number — and the speech behind them came through unchanged. Between the shortest padded file and the longest there are 270 seconds of non-speech, and the answer to “how many words did it cost” is zero.

That is a narrower finding than “hold music is harmless”, and it is worth saying exactly what it covers. Our music is synthetic and tonal, four sine waves at a steady level — it has no percussion, no vocals, no speech-like formants, and nothing that sounds like a word. A hold queue playing a pop song with a singer in it is a different signal, and the sibling measurement on this site, using a synthetic music bed under real speech, found that a bed 12 dB below the voice added six wrong words where a bed 24 dB below added none. The level is the variable there, not the genre. What this page establishes is that the duration of the waiting is irrelevant to the words, which is the thing nobody publishes.

The waiting does move the clock, and the direction is the useful part

Read down the last column and the shape is the one worth taking away: a six-minute call with five minutes of waiting is cheaper per audio minute than a 72-second call with none — 13.9 against 44.2 seconds per minute, a factor of 3.18. The reason is not the music. The first run of the session pays a fixed cost: its status line reads “Downloading the English speech recognition model (63 MiB, plus the 21.5 MiB runtime)…” and it sits there for 21 seconds before the first segment is decoded, which is 39% of that run's elapsed time. Every later run in the same browser profile starts decoding within 6 seconds.

So the honest version of “longer files are slower” is: they are slower in absolute seconds and faster in rate, and the rate you should plan with is the one on the last line, 13.9 seconds per audio minute — about 4.6× faster than real time. A one-hour call, at that rate, is roughly 14 minutes of processing. The short file's 44.2 is a number about a cold browser, not about a short call.

One run per file, one page load each, in the order shown — so only the first row carries the download. Timing is a single observation per row and the model is Whisper-tiny at the size this site ships; a larger model moves both numbers.

Cutting the waiting does not make it more accurate either — and that is not the same as saying it helps

If adding waiting is free, is removing it a gain? We cut the same 30 seconds of hold music down to 15 seconds and then to 3.75 seconds, changing nothing else. Those two files came back 22 and 21 wrong words — one and two more than every padded file, and both outside the 20-word floor the rest of the set sits on.

That looks like a finding and it is not one. The control for it is on the same page, in the same table below: a file whose audio is bit-for-bit identical to the 30-second-music file for its first 102.454 seconds, but written as PCM where the original is MP3. It came back 22 wrong words too. Same signal, same length, different container, +2. The two short files are inside that. What this recogniser does on fixed material is jitter by about ±2 words, and the four words that move are always the same four — Carker comes back as “Carcure” or “Carcourt”, sitter as “seder”, “sater” or “sitter”, Mr. John Collier loses a letter, and like a shampooer in a Turkish bath comes back as “like a shampoo and a Turkish bath”, “like a shampoo in my Focus bath” or “like a shampoo or my Focus Bath”. No word in those four places is ever right twice in a row across nine runs.

The control is the load-bearing row. Its first 2,318,528 bytes of PCM are byte-identical to the reference file decoded the same way — we checked, twice, and the SHA-256 prefix of both is f3e4945253871c2c. It still produced two more wrong words, in the same four places. That is the size of the noise floor on this material, and it means the only defensible claim on this page is the one about time: waiting costs accuracy nothing, because four separate files with 30 to 300 seconds of non-speech in front of them produced one transcript between them, while a file with no change to its audio at all produced a different one.

What a call recording is, before anything transcribes it

The last file in the set makes the other half of the point. P8 is 299.999 seconds long — the same length as a five-minute call — but the extra time in it is the speech said again, roughly 4.1 times over, followed by 60 seconds of line silence. It came back with 20 wrong words: the file is nearly four times longer than the source and the error count did not move, because the recogniser is scored against 189 reference words and it heard those 189 words four times rather than once. What that tells you is that length is not the unit. The unit is the words, and a real call is mostly not words.

Which is the point none of the 43 pages we read makes. Aircall comes closest, and comes at it sideways: “Aircall transcribes calls as soon as they end, and transcripts are usually ready in about 30% of the call's length, so a 10-minute call is ready in around 3 minutes.” That is a throughput claim, expressed in the same unit as the question a person actually has — how long will this take — and it is the only page in the 43 that puts a ratio on it. Our ratio, measured on the file with five minutes of waiting in it, is 13.9 seconds per audio minute, or 0.23× the call's length. Aircall's is 0.30×. Two different products, two different sizes of model, numbers in the same ballpark — and the other fourteen pages that print a percentage leave you to guess.

What the pages are full of instead is the input format. Audioscribe answers the AMR question directly — “If your recorder saved the call as AMR, convert it to MP3 or M4A first — that format isn't supported here… which many call-recorder apps use by default” — and Whisper Transcribe and Uniscribe both list AMR among the formats they accept. That is the one place the family touches the actual signal, and it touches it as a list of extensions. Nobody says what happens to a call at 8 kHz, because nobody measures it.

Two kinds of page, and neither is for you

17 of the 43 readable pages are phone platforms. Aircall “transcribes calls and voicemails” on its own lines; Dialpad “transcribes calls in real time”; Gong sells conference-call transcription as a revenue tool; Vonage and Twilio document it as an API you wire into your telephony; Ringover, Nextiva, Quo, Aircall again, Otter's notetaker, Notta's call tool, and three “best of 2026” roundups that rank them. In all of those the company carried the call — the audio never had to travel anywhere as a file.

8 of the 43 are the opposite: a person, a queue and a per-minute rate. Transcription US, 1-888-TYPE-IT-UP, Transcription Wave, GMR, Vast Conference, Good Tape's blog. Their copy is candid about the audio in a way the software pages are not — “conference calls typically suffer from poor audio quality due to the sound quality produced by telephone lines” — and then quotes a percentage with no measurement behind it.

Between those two ends, a person holding a finished recording on a laptop is served by almost nothing in this result set. That is the gap this page fills, and the number it fills it with is the one nobody prints: waiting is free and the clock is not.

What these numbers do not cover

• The music and the ring tone are synthetic. Four sine waves and a 450 Hz cadence generator. A real hold queue plays songs with vocals and percussion, and a percussive bed is a different signal from a tonal one. The sibling measurement on this site found a music bed matters by level — nothing at 24 dB below the voice, six wrong words at 12 dB below — not by duration. This page's claim is about duration.
• No real call was recorded, and no phone line was used. The speech is read text from a public read-speech set, one speaker, already an MP3 before we started. Nobody dialled anybody, no recorder app was installed, and the 8 kHz phone chain referenced in the questions above was built with ffmpeg on 2026-10-23, not captured from a carrier. The G.711 and narrowband terms do not appear on this page's own measurements for that reason.
• One run per file. Nine files, nine page loads, each read once. The jitter band (±2 words) is measured across those runs, and it is small enough to see but large enough that a single unpaired file cannot be read as an effect — which is exactly why the identical-audio control is in the table.
• The control is a container change, not a file copy. P9 carries the same PCM as P2 for 102.454 seconds and then 30 seconds of line silence: same beginning, different ending, different decoder. It establishes that this much of the answer moves on its own; it is not a repeat of P2.
• Segment boundaries are 30 seconds. The page splits audio into 30-second segments and the status line counts them: 3, 4, 5, 8 and 13 for the five padded files. Waiting inside a segment is what a hold queue is, so this measurement puts the waiting in exactly the place the product handles it.
• We ran none of the 43 pages. Nothing was uploaded to Aircall, Dialpad, Gong, Vonage, Twilio, Audioscribe, Sonix, Notta, Uniscribe or anyone else, and no figure on this page measures their products. Where we quote a percentage, it is their claim about themselves, unverified.
• One language, one speaker, one accent. All 189 reference words are English read by one voice. Nothing here says how a two-party call with an accent difference behaves, and we have not measured one.

Try it on a call you already recorded

The transcriber is on the front page. It takes the file you already have — MP3, WAV, M4A, MP4, WebM, OGG, AAC or FLAC, up to 30 minutes of audio and 512 MiB per job — and it runs the model inside your browser tab, so the recording is never uploaded. Expect the first run to spend about 63 MiB on the model plus a 21.5 MiB runtime, and after that, measured today, 13.9 seconds per audio minute on a call with waiting in it. You get timestamped text out as TXT, SRT or VTT, wrapped at 42 display-width units a line, and no speaker labels — the recogniser does not separate voices, and this page has just shown that the pages promising labels do not say how often they are right.

Transcribe a file