How to transcribe an MP3 to text, and what the bitrate costs you
Transcribe MP3 to text in your browser, and see what bitrate, mono or stereo and re-encoding really cost you once the audio is mixed down to 16 kHz mono.
To transcribe an MP3 to text, drop the file on the home page. The browser decodes it, mixes it to mono, resamples it to 16 kHz and writes out the words, and nothing is uploaded. What the file’s bitrate buys you is the more interesting question. Everything above 16 kHz mono is thrown away before the speech model sees a sample, so a 320 kbps stereo export spends most of its bits on detail the model never gets, and a small mono voice file is often perfectly good.
What happens to your MP3 before the model hears it
The speech model never sees your MP3. The file is read in slices, decoded by the browser’s WebCodecs audio decoder through a library called Mediabunny, mixed to one channel and resampled to 16,000 samples per second. Only then does audio reach the model, in windows of about a minute, each cut at the quietest moment near the minute mark so a sentence is not sliced in half.
The 16 kHz figure is not our choice. The paper behind OpenAI’s open-source Whisper model is explicit: “All audio is re-sampled to 16,000 Hz”, and the model reads an 80-channel log-magnitude Mel spectrogram computed on 25-millisecond windows with a 10-millisecond stride.
A 16,000 Hz sample rate carries frequencies up to 8,000 Hz and nothing above. Your MP3 is very likely 44,100 Hz stereo, so the upper half of its frequency range and one of its two channels are gone before the first word is recognised. Bits the encoder spent up there were spent for your ears, not for the transcript. That makes most arguments about MP3 quality irrelevant here, and leaves one worth having: how low you can go.
Bitrate is where an MP3 throws things away
MP3 is a lossy format, and bitrate is the dial deciding how much goes. MDN’s audio codec guide lists what the format allows: in MPEG-1 mode, 32 to 320 kbps at sample rates of 32, 44.1 or 48 kHz; in MPEG-2 mode, 8 to 160 kbps at 16, 22.05 or 24 kHz. Audacity’s exporter offers the same span, “bit rates from 8 kbps to 320 kbps”.
Fewer bits per second means the encoder keeps what a listener would most likely notice and drops the rest. What goes first tends to be quiet and high, and the quiet, high part of speech is where consonants live. “Fifteen” and “fifty” are separated by a fricative, as are “can” and “can’t” at conversational speed. Those are the errors in a transcript of a heavily compressed file, and the ones a quick skim misses.
So the honest shape of it: below some point, bitrate costs you accuracy, and above some point, it buys you nothing the model will ever see. We have not measured where that lower point sits and will not invent a number for it. What can be pointed at is what Apple asks of podcast audio. Apple’s audio requirements for Podcasts Connect accept a mono MP3 at 32 kbps as the minimum and recommend 96 to 128 kbps. For stereo the minimum is 64 kbps and the recommendation 128 to 256 kbps. For audio delivered through an RSS feed, Apple recommends 64 to 128 kbps for mono.
Read those against the 16 kHz mono pipeline. A 320 kbps stereo file carries more than three times the data of a 96 kbps mono one and arrives in exactly the same shape: larger, slower to decode, no more accurate. A 32 kbps mono file, the minimum Apple accepts, is very probably fine here too, and it is the one case worth listening to first: if the consonants sound smeared to you, they will be smeared to the model.
Mono and stereo matter less than the file size suggests
Speech recognition works on one channel, and our decoder averages every channel in the file into one before anything else happens. A stereo MP3 of one person talking into one microphone is usually two near-identical channels, so the stereo half of the file has been paying for a copy.
Audacity’s stereo MP3 export always uses joint stereo, which shares information between the channels rather than encoding each in full. Sensible for music, beside the point for a voice file about to be merged.
There is one case where stereo carries real information: an interview recorded with two microphones routed to separate channels. Mixing to mono puts both people in one stream, which is what would happen regardless, since the transcript carries no speaker labels. Our post on two-speaker interviews covers what you can and cannot get back. If you have not recorded yet, record mono at a moderate bitrate. The recording habits post covers what actually moves accuracy, most of it before the encoder is involved.
Re-encoding an MP3 costs more than the first encode did
Every lossy encode discards detail permanently, and a second encode works on what the first one left. The Audacity manual puts it flatly: “If you import an MP3 into Audacity, edit it then export it as an MP3, you will lose quality twice.” The second pass also has to re-describe artefacts the first pass introduced, so bits go to encoding damage rather than to speech.
So the file you want is the one the recorder wrote, not a tidied copy. Trimming an MP3 in an editor and exporting a new MP3 is the usual way this happens. If a file has been through two or three hands, ask for the original before concluding that transcription is not working.
Where the MP3 came from tells you what to expect
Knowing where an MP3 came from tells you whether a better copy is worth chasing.
| Where the MP3 came from | What it usually looks like | What to do |
|---|---|---|
| Phone or desktop voice recorder app | Mono, 44.1 kHz, moderate bitrate | Transcribe it as it is |
| Podcast episode you downloaded | Stereo, 44.1 kHz, 128 kbps or higher | Transcribe it as it is, the stereo gets merged |
| Export from an audio editor | Whatever you picked, often 320 kbps stereo | Fine, but export mono at a moderate bitrate next time |
| A copy re-encoded somewhere on its way to you | Lower bitrate, sometimes mono | Ask for the original if the transcript reads badly |
| Converted from a WAV to save space | A lossy copy of something lossless | Use the WAV instead |
| Audio ripped out of a video file | Depends entirely on the video’s audio track | Skip the rip and drop the video in directly |
Two rows deserve a note. Podcast downloads need nothing done to them, though the workflow around them is its own job, covered in turning an episode into show notes. And iPhone recordings usually are not MP3: Voice Memos writes M4A, and a separate post covers getting those onto a desktop without re-encoding on the way.
Transcribe MP3 to text without uploading the file
Open the home page, drag the MP3 onto it or pick it with the file button, and text starts appearing after the first window rather than at the end. On the first run the browser downloads the model, whisper-base.en, about 200 MB, and caches it, so the next file starts immediately. Export TXT, SRT or VTT when it finishes; the export formats post explains which one you want.
Where this stops. It runs on desktop Chrome or Edge with a working WebGPU adapter, so Firefox, Safari and phones are not supported yet, and it is English only. No export carries speaker labels. The base model gets names, technical terms, heavy accents and noisy rooms wrong more often than a larger one would, the trade-off explained in model sizes. Read the transcript before relying on it.
Nothing is uploaded at any point: the file is opened by the page, decoded in a worker and discarded as it goes. If you have an MP3 in a downloads folder, drop it on the home page and see what the encoding cost you.
Frequently asked questions
Does a higher bitrate MP3 give a better transcript? Up to a point, then no. The audio is reduced to 16 kHz mono before the model reads it, so bits spent on high frequencies and on the second channel are discarded. Going from a very low bitrate to a moderate one can help, because low bitrates blur the consonants that distinguish similar words. Going from 128 kbps to 320 kbps changes nothing the model sees.
Should I convert my MP3 to WAV before transcribing it? No. A WAV made from an MP3 is a large, exact copy of audio the encoder already thinned out, and the conversion restores nothing. If you still hold the recorder’s original WAV, use that instead, since it never went through a lossy encode.
Does it matter whether the MP3 is mono or stereo? Not for accuracy. Every channel is averaged into one before the audio reaches the model. Stereo doubles the file for no gain in the transcript, and costs you only in the unusual case of two people recorded to separate channels, where merging puts both voices in one stream.
Is there a size or length limit on the MP3? No length limit and no upload limit, because there is no upload. The file is read in slices and only about a minute of decoded audio is held at a time, so memory stays flat whether the file runs four minutes or four hours. A long file just takes longer.
Sources, checked 15 September 2026
- https://arxiv.org/html/2212.04356 - Radford et al., “Robust Speech Recognition via Large-Scale Weak Supervision”: section 2.2 for “all audio is re-sampled to 16,000 Hz”, the 80-channel log-magnitude Mel spectrogram, 25 ms windows and 10 ms stride
- https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Audio_codecs - MDN audio codec guide: MP3 listed as lossy, MPEG-1 sample rates 32/44.1/48 kHz and bit rates 32 to 320 kbps, MPEG-2 sample rates 16/22.05/24 kHz and bit rates 8 to 160 kbps
- https://podcasters.apple.com/support/893-audio-requirements - Apple Podcasts audio requirements: MP3 mono minimum 32 kbps and recommended 96 to 128 kbps, stereo minimum 64 kbps and recommended 128 to 256 kbps, RSS feed mono recommendation 64 to 128 kbps
- https://manual.audacityteam.org/man/mp3_export_options.html - Audacity manual, MP3 export options: “bit rates from 8 kbps to 320 kbps”, stereo export always uses joint stereo, and “If you import an MP3 into Audacity, edit it then export it as an MP3, you will lose quality twice”