Trim Audio File: What Cutting One Clip Into Three Does to the Transcript

One clip, four ways

The source is a 36.4-second English recording, mono at 16 kHz, encoded to 64 kbps MP3 for upload. We cut it three ways with ffmpeg and uploaded each version, plus the whole file as a control.

• Whole clip, 36.432 seconds, 292,364 bytes: HTTP 200 in 7.10 seconds, 671 characters, 132 words.
• First 12 seconds, 97,100 bytes: HTTP 200 in 2.32 seconds, 241 characters, 44 words.
• Middle 12 seconds, 97,100 bytes: HTTP 200 in 2.32 seconds, 245 characters, 48 words.
• Last 12.432 seconds, 100,556 bytes: HTTP 200 in 2.24 seconds, 190 characters, 40 words.
• Three pieces added up: 676 characters, 132 words, 6.88 seconds of upload time.

The word count survives, the seams don't

What it does cost is one word per seam. The first piece ends "which felt generous until he remembered the bank clothes", and the original sentence runs "until he remembered the bank closed at noon on Saturdays". The second piece then opens with "posted noon on Saturdays", which is what the tail of "closed" sounds like on its own. Two cuts, two mangled words, and both of them sit exactly where the scissors went.

Half a second earlier fixed it

The rule is simple: cut in the gap between sentences, not in the middle of one. If you can't find the gap by ear, pull the cut back half a second. You'll pick up a little silence, and silence costs you nothing - we measured that too.

Stream copy and re-encode came back the same

So use -c copy when you can. It's faster on your machine and it doesn't cost you anything at the endpoint, as long as you're fine with the cut landing a frame or two off from where you asked.

Silence in front of the clip is free

That's the answer to "should I trim the dead air off the start?" You don't have to for accuracy. Do it for speed and file size if you're uploading on a phone, but a little lead-in silence won't change the text.

Stripping silence out saved 1.28 seconds

Don't read too much into the size difference; that run only removed 0.1 seconds of audio. The time gap is consistent with what we see across lengths, and it's the reason trimming a long recording down to the part you need is worth the one command.

Numbers can change shape between runs

We're telling you this so you don't chase it. If you're pulling numbers out of a transcript - prices, dates, counts - read them against the audio. The model decides how to write a number each time, and it doesn't always decide the same way.

What three uploads cost you instead of one

The real cost isn't bytes or seconds, it's that you now have three transcripts to join. Budget for that: paste them into one document in order, then read across each join to catch the word the cut ate. With three pieces that's two seams to check, and it takes under a minute.

What we didn't measure

One English clip, one synthetic voice, four cuts. We didn't test cutting a file with music under the speech, or a clip with two speakers where a seam can split an exchange between them. We didn't push past three pieces, so we can't tell you what twenty cuts would do. These files are ours, built with ffmpeg today, and every number here came off our own endpoint.

What happens to each piece you upload

Each piece is a separate upload to /api/transcribe, sent over an encrypted connection, decoded in memory and dropped when the response goes back. We don't keep it and we don't stitch the pieces together for you, so joining three transcripts into one is your job - and it's easier if your cuts landed between sentences.