Fitting a long recording under a transcription size limit

They have a two-hour meeting or lecture and a tool that refuses it. Every answer they find says "use ffmpeg", which assumes a command line they do not have. They also may not want a confidential meeting passing through an extra service on the way.

Two settings solve almost every case: mono and a low bitrate. A one-hour interview saved as a 16-bit stereo WAV is roughly 635 MB. The same hour as a 32 kbps mono MP3 is about 14 MB, and a speech-to-text model will read it just as well, because the first thing most of them do is downmix to mono and resample to 16 kHz before they look at a single word. Convert first, and only split the recording into parts if it is still over the limit afterwards. Both steps can be done in this tab, on a file that never leaves the machine — which matters more than usual when the recording is a client call.

The order to do it in: compress, then split

People usually reach for splitting first, because the limit is framed as a size and cutting the file in half obviously halves the size. It is the wrong first move. Splitting multiplies the work: more files to submit, more transcripts to stitch, and a seam in the middle of a sentence to repair. Re-encoding costs one pass and usually ends the problem outright.

So, in order:

1. Convert to mono at a speech bitrate. 32 kbps for a clean recording, 48 kbps if the room was noisy or several people talk over each other. For most meetings and lectures this alone gets under the cap.
2. Trim the dead air. Ten minutes of "can everyone hear me" at the start is ten minutes of billed audio and megabytes you do not need.
3. Split, with overlap, only if it is still too big. Covered below, including why the overlap is not optional.

Pick MP3 and the bitrate on the converter, or start from the reduce-file-size tool, which has the stereo-to-mono switch and lets you name a target in megabytes and have the bitrate worked out backwards from it.

Why speech survives a bitrate that would ruin music

A voice occupies a narrow band. Telephone calls have been intelligible for decades at an 8 kHz sample rate, and most of what separates one consonant from another sits below 8 kHz. Music has cymbals, string harmonics and stereo imaging spread across the whole spectrum, which is why a 32 kbps MP3 of a song sounds like a swarm of bees and a 32 kbps MP3 of a person talking sounds like a person talking.

Two of those savings are free rather than lossy in any way the model cares about. Downmixing a spoken-word recording to mono halves the data, and the model was going to sum the channels anyway. Resampling to 16 kHz throws away everything above 8 kHz, and Whisper-family models resample to exactly 16 kHz as their first step, so nothing that the transcriber would have heard is being discarded.

The arithmetic for the rest is one multiplication. Megabytes per hour equals the bitrate in kbps multiplied by 0.45.

Multiply that last column by whatever cap you are working against: two and a half times it for a 25 MB ceiling, ten times for 100 MB. And read the cap off the tool's own error message rather than off an article, including this one. Those numbers move, and a service that counts minutes rather than megabytes will reject a small file for a reason that has nothing to do with its size.

The settings, and the three that cause trouble

What to set:

• Channels: mono. The single biggest saving on a spoken recording, and the one with no cost attached.
• Sample rate: leave it alone. At 32 kbps the MP3 encoder resamples downwards by itself, because 44.1 kHz cannot be encoded well in that few bits. The result lands near the 16 kHz the model wants anyway.
• Format: MP3 or M4A. Both are read by every transcription service worth using. AAC holds together slightly better than MP3 at the very low end, so M4A is the marginally better pick at 24–32 kbps. Which formats each service accepts has the per-service detail if yours is fussy.
• Bitrate: 32 kbps as the default, 48 for a difficult room, 64 if there is music or several overlapping speakers you need separated.

What causes trouble:

• Sending WAV because it is "lossless". It is uncompressed, which is a different thing, and it is roughly forty times the size of a speech MP3 for output a model treats identically. WAV is the format most likely to hit the cap you are trying to get under.
• Going below about 24 kbps. Sibilants start to smear and the transcript begins inventing plausible wrong words. The savings below that point are small and the accuracy cost is not.
• Aggressive silence removal. It shrinks a gappy recording well, but every timestamp in the resulting transcript refers to the shortened timeline, not the original. Fine for a transcript you are going to read; wrong for subtitles you plan to lay back over the video.

Splitting a long file, and the overlap that stops it going wrong

Some recordings are genuinely too long: a full-day workshop, a six-hour deposition. Split those, and give consecutive parts a few seconds of shared audio.

The reason is that a cut lands wherever the clock says, which is usually in the middle of a word. The model at the end of part one hears half a word and guesses; the model at the start of part two hears the other half and guesses differently. You get two wrong words instead of one right one, at every seam. Five to ten seconds of overlap means the whole word exists intact in one of the two parts, and you delete the duplicated sentence when you stitch the transcripts.

Better still, put the cuts where nobody is talking. A pause, a slide change, the end of a question. Then the overlap is insurance rather than repair work.

The audio cutter handles this. Its split mode divides a file into equal parts or at a list of timestamps, and hands the results back as a ZIP. For overlapping parts, cut each one separately with the in and out fields, setting each start a few seconds before the previous end. For MP3 and AAC that cut is a stream copy rather than a re-encode, so it is quick even on a three-hour file and the audio in each part is untouched. Copying rather than re-encoding means the cut snaps to the nearest frame boundary, a few tens of milliseconds on an MP3 — irrelevant when you are already leaving seconds of overlap.

Keep track of each part's offset in the original. If part three starts at 1:45:00, add one hour forty-five to every timestamp the transcript gives you for it, or the merged result will claim the whole meeting happened in the first half hour.

Doing it without the command line

Every answer to this question online is the same two FFmpeg commands. They are good commands, if you have FFmpeg:

ffmpeg -i meeting.m4a -ac 1 -ar 16000 -c:a libmp3lame -b:a 32k meeting.mp3

ffmpeg -i meeting.mp3 -f segment -segment_time 1800 -c copy part%03d.mp3

The first is the compression step; the second cuts the result into half-hour pieces without re-encoding, though with no overlap. If a terminal is not something you have or want, this site is the same engine: FFmpeg compiled to WebAssembly, running inside the page. The controls set the same flags. The engine is a 32 MB download on your first visit and cached for a year afterwards, so the first conversion of the day starts slower than the rest.

Be realistic about the encode itself. It is one CPU core in a browser tab, and a two-hour recording takes minutes, not moments. A stream copy — the split step, where no samples are re-encoded — finishes in about a second regardless of length, because it is moving bytes rather than rebuilding them.

Why the file's privacy matters more here than usual

The recordings that hit transcription size limits are rarely trivial. They are board meetings, patient dictation, research interviews with consent forms attached, legal calls. You have already decided to trust the transcription service; there is no reason to add a second company to that list on the way there, just to change a bitrate.

Nothing on this site sends your audio anywhere. The page reads the file from your disk through the file input, converts it in the tab's own memory, and gives you the result back. You can confirm that rather than trusting it: open the browser's Network panel and watch the request count during a conversion, or disconnect from Wi-Fi after the page has loaded and convert anyway. Checking whether a converter really keeps your file local walks through both, and the checks work on any site making the same claim.

One honest ceiling on the browser route: the tab has a hard memory limit near 2 GB, and the converter warns above 300 MB. A six-hour WAV can exceed that. If it does, split it before compressing rather than after — the same cutter, working on the original.