Transcribe Audio File: What a Six-Second Gap Does to the Words

The clip and how we cut it

We built a 14.1-second reading of four sentences - 44 words, 16 kHz mono WAV - and uploaded it as-is. It came back in 2.0 seconds with 247 characters. Then we rebuilt the same four sentences with a silent gap between each pair, using seven gap lengths, and uploaded all seven. Every one returned HTTP 200 and success: true.

How we put the gaps in

We cut the four sentences apart and spliced digital silence between them, three gaps per file, so the only thing that changed between uploads was the length of the pause. Silence here is true silence - a stream of zeros, not a quiet room - which is what you get when a recording app writes a gap or when an editor inserts one. Real room tone is messier, and we say so below.

Where a five-second gap comes from

Five seconds sounds like a lot until you think about where files get made. A phone recorder you forgot to stop. A call where one side goes quiet while they look something up. A voice memo where you paused to find your next sentence. A clip stitched together from three takes. None of those are exotic, and all of them sit comfortably on the safe side of the line we found - which is why most people never see this problem and the ones who do can't work out what they did differently.

Up to five seconds, nothing moves

A 0.2-second gap is what a normal pause looks like. A five-second gap is a long, awkward pause between sentences. Both returned the same 44 words in the same order, 247 characters, and the gap didn't cost anything measurable - the five-second version took 2.3 seconds, the same as the clean clip.

• 0.2-second gaps: 247 characters, 44 words, 2.0 seconds.
• 1-second gaps: 247 characters, 44 words, 2.6 seconds.
• 3-second gaps: 247 characters, 44 words, 2.3 seconds.
• 5-second gaps: 247 characters, 44 words, 2.3 seconds.
• The five-second file is 29.1 seconds long and still returns the same text as the 14.1-second one.

At six seconds the transcript explodes

The six-second version is only three seconds longer than the five-second one. It came back 2,077 characters and 223 words - five times the words the clip actually contains - and it took 14.3 seconds instead of 2.3. The first 247 characters are the real transcript, word for word. Then it starts: "Thank you very much." 29 times, then "I'm sorry," 111 times, running to the end of the response.

• 6-second gaps: 2,077 characters, 223 words, 14.3 seconds.
• The clip contains 44 spoken words. The transcript contains 223.
• Nothing in the response marks any of it as uncertain.

Seven and ten seconds return the same 2,077 characters

We expected longer gaps to produce a longer loop. They don't. The seven-second file and the ten-second file both came back with exactly 2,077 characters, and the text was character-for-character what the six-second file returned. The junk has a ceiling, and it hits that ceiling the moment the gap crosses the line.

• 7-second gaps: 2,077 characters, 15.5 seconds.
• 10-second gaps: 2,077 characters, 15.3 seconds.
• Same 29 "Thank you very much." and same 111 "I'm sorry," as the six-second run.

A file with nothing in it

For the endpoint case we uploaded 14 seconds of pure digital silence, no speech at all. It returned 1,829 characters in 16.7 seconds: the same two loops, minus the 247 real characters. Nothing failed, nothing was empty, and success was true. If you hand this a file with no speech in it, you don't get a blank page - you get text.

That's the part worth repeating. An empty result is easy to spot. A confident, fluent, entirely invented paragraph is not.

Why this happens

The endpoint doesn't cut the audio on silence before it hands it over. If it did, a ten-second gap would simply get trimmed and you'd see the clean 247 characters. Instead the whole file goes through, and the stretch with nothing in it gets filled with the most likely continuation the model knows - a sign-off, then an apology - repeated until the window ends. The loop is the same every time because the input that triggers it is the same every time.

How to catch it before you quote it

You don't need to read the whole transcript to catch this. Compare the word count with the length of the recording. 223 words from 14 seconds of speech is impossible - a fast talker does about three words a second. If the transcript claims more than that, scroll to the end and look for a sentence that repeats. Then cut the file at the gaps and send the pieces separately; a 14-second clip with the pauses removed gives you the clean 247 characters every time.

• Sanity check: words divided by seconds should land near three or below.
• Repeated phrases at the end are the fingerprint, not extra content.
• Splitting at long gaps removes the trigger entirely.

The arithmetic that catches it

You can catch this in about five seconds without reading the transcript. Take the word count and divide by the length of the recording in seconds. Our clean clip was 44 words in 14.1 seconds, so 3.1 words a second - already at the fast end of normal speech. The broken run claimed 223 words from the same 14.1 seconds of speech, which is 15.8 words a second. No human talks at 15 words a second. If you see a number above four, stop and look for a repeated phrase before you use any of it.

The limits of this test

One clip, one voice, one language, seven gap lengths. We found the break between five and six seconds on this recording; a noisier room or a longer silent stretch before the first sentence could move that line. We also haven't tested gaps that fall inside a sentence rather than between two of them, and we used synthetic silence, which is cleaner than a mic left running in a quiet room.

What happens to your file

Your file leaves the browser. It goes to /api/transcribe over an encrypted connection, gets decoded in memory, and the audio is processed there. When the response goes out, the file is dropped. We keep no copy, we don't store transcripts, we don't train on what you send, and there's no account involved.