Recording to Text: How Short a Clip Can Be Before the Words Stop

Seven cuts, 0.2 s to 10 s

Every piece below is the same recording, cut from the start, saved as 16 kHz mono WAV and uploaded on its own. Nothing was refused and nothing was slow.

• 0.2 s - 6,478 bytes: 200 in 0.92 s, 1 word.
• 0.5 s - 16,078 bytes: 200 in 0.77 s, 1 word.
• 1 s - 32,078 bytes: 200 in 0.96 s, 3 words.
• 2 s - 64,078 bytes: 200 in 0.80 s, 8 words.
• 3 s - 96,078 bytes: 200 in 1.91 s, 10 words.
• 5 s - 160,078 bytes: 200 in 1.13 s, 14 words.
• 10 s - 320,078 bytes: 200 in 1.37 s, 28 words.

The two shortest clips are made up

The recording opens with "Today is Tuesday and I need to remember four things." At 0.2 seconds you can hear the very start of "Today" and nothing else, and what came back was "You". At 0.5 seconds, "today." - one word, with a period, and a lowercase first letter. Neither word is what the speaker says at that point.

• 0.2 s, uploaded three times: "You", "You", "You" - 0.74 s, 0.74 s, 0.85 s.
• 0.5 s, uploaded three times: "today.", "today.", "today." - 0.80 s, 0.93 s, 0.95 s.
• 1 s, uploaded three times: "Today is Tuesday." every time - 0.83 s, 1.07 s, 0.72 s.

The repeats matter here. A made-up word that changes every upload is noise you'd spot straight away. These didn't move - three uploads, three identical answers - so a short clip can hand you a confident, wrong, repeatable result. One second was enough to get the first three real words every time.

Nothing refuses a short file

People expect a minimum-length error and there isn't one. HTTP 422 shows up when a file has no speech in it or no audio track at all. It never appeared on this ladder, not even at 6,478 bytes, because the file always had a real audio stream with some signal in it.

• HTTP 422: no speech or no audio track - not a length error.
• HTTP 400: a filename the endpoint doesn't accept, checked in under 0.1 s.
• HTTP 200 with invented words: what a very short clip actually gets you.

How many words per second

The ladder gives you a rough rate you can plan with. Ten seconds returned 28 words, and the full 31-second recording returned 87, so this speaker runs at about 2.8 words a second. Double that for a fast talker and you're near the top of what a short upload is worth.

• 1 s: 3 words.
• 3 s: 10 words.
• 10 s: 28 words.
• 31 s: 87 words, in 5.00 s.

Time doesn't track length closely at this size. The 3-second cut was the slowest on the ladder at 1.91 seconds while the 10-second cut came back in 1.37. Under about ten seconds, overhead dominates, and the spread between uploads is wider than the difference between the rungs.

When cutting is the wrong move

Splitting a long recording into short pieces doesn't make the transcript better, and it costs you two things. Each piece comes back on its own, so nothing stitches them into one document - you paste them together yourself. And every new start is a place where the model can invent an opening word, as it did twice at the bottom of this ladder.

• Upload the whole recording when you can; one pass beats ten.
• If you must cut, keep every piece longer than a second.
• Check the first few words of each piece against the audio.
• Paste the pieces together yourself - there's no merge step here.

Why every cut is a WAV

Each piece was saved as 16 kHz mono WAV so the bytes scale exactly with the seconds - 16,078 bytes for half a second, 32,078 for one, 320,078 for ten. Nothing else changes between rungs: same recording, same encoder, same start point. Whatever differs in the results comes from the length alone.

What the first second sounds like

The recording opens with "Today is Tuesday and I need to remember four things." At 0.2 seconds only the attack of the first word is on tape. At 0.5 seconds you can hear "Today" and the start of "is". By one second the first three words are clear, and that's exactly where the transcript starts being correct.

• 0.2 s: the beginning of one word - came back "You".
• 0.5 s: "Today is" - came back "today."
• 1 s: "Today is Tuesday." - came back correct.

Invented text versus an error

A file that has no speech in it behaves differently from a file that's too short. The empty one gets refused: HTTP 422, no words, in a fraction of a second. The short one gets filled: 200 with a confident word in it. That second case is harder to catch, because nothing in the response tells you it happened.

• No speech at all: HTTP 422, nothing to read.
• Too short: HTTP 200 with a word that was never said.
• The check is the same either way - play the clip and compare the first line.

How to sanity-check a short clip

Two habits cover most of it. Give every piece at least a second of real speech at the start, since that's the point where the results turned correct on this ladder. Then read the first three words of each piece against the audio before you paste anything into a document.

• Cut at a word boundary, not mid-word.
• Keep each piece over one second.
• Read the opening words back against the audio.
• If a piece returns one word, treat it as nothing.

What short clips are good for

Very short files aren't useless, they just have a narrow job. A clip under a second can settle one word - a name, a place, a figure you couldn't catch - as long as you read the answer as a hint and not as a transcript.

• One spoken word, checked against what you think you heard.
• A device check: does this file have a real audio stream? It will return 200.
• Timing checks - any short file comes back in about a second.
• Not for anything you plan to quote: below one second the words can be invented.

For anything you're going to quote, hand over at least a second of clean speech, and ideally the whole sentence around the words you need. That's what the ladder above argues for: the step from 0.5 s to 1 s is the difference between a made-up word and the real one.

What happens to the file

The clip is posted to /api/transcribe over an encrypted connection, decoded in memory, and dropped once the text goes back. Nothing is stored, nothing trains anything, and no account is attached to the upload. Short files come back fast for the same reason long ones take longer - the audio is read once, start to finish.

• Uploaded: yes, the file leaves your machine.
• Written to a disk: no.
• Kept after the reply: no.
• Account required: none.