MP3 vs WAV for Transcription and Podcasting: Which Format Should You Use?

Quick answer

WAV is uncompressed, lossless audio: big files, no quality loss, ideal for recording and editing. MP3 is compressed, lossy audio: small files, some detail permanently discarded, ideal for distribution. For transcription, the format matters much less than people expect. Clear speech in a reasonable MP3 transcribes about as well as the WAV it came from.

The practical rule: record and edit in WAV (or FLAC), transcribe from a 16 kHz mono copy or a decent MP3, publish in MP3 or AAC.

The three numbers that describe digital audio

Before comparing formats, it helps to know the three settings that determine how much information a file holds.

Sample rate

How many times per second the audio is measured. Common values:

• 44.1 kHz: the CD standard, common in music.
• 48 kHz: the standard for video and most professional recorders.
• 16 kHz: the rate many speech recognition models are trained on. It captures frequencies up to 8 kHz, which covers the important parts of speech, though it sounds dull for music.
• 8 kHz: traditional telephone audio. Speech is intelligible but consonants like "s" and "f" get muddy, and recognition accuracy usually drops.

Bit depth

How precisely each sample is stored. 16-bit is CD quality and is plenty for listening and for speech recognition. 24-bit gives more headroom while recording, so a quiet or unexpectedly loud speaker is easier to fix in editing. Bit depth applies to uncompressed formats like WAV; MP3 doesn't store it the same way.

Channels

Mono (one channel) or stereo (two). Speech recognition generally works on mono. If you record a two-person interview with each person on their own channel, keep that separation: some transcription services can use it to tell speakers apart, which is more reliable than guessing from a mixed track.

Bitrate

For compressed formats like MP3, the bitrate (kilobits per second, kbps) controls how much data is kept. For uncompressed audio, bitrate is just sample rate times bit depth times channels.

File size math

You can estimate any uncompressed file's size yourself:

bytes per second = sample rate x (bit depth / 8) x channels

CD quality WAV:   44,100 x 2 x 2 = 176,400 bytes/s  -> about 10.6 MB per minute
16 kHz mono WAV:  16,000 x 2 x 1 =  32,000 bytes/s  -> about 1.9 MB per minute
MP3 at 128 kbps:  128,000 / 8    =  16,000 bytes/s  -> about 0.96 MB per minute
MP3 at 64 kbps:    64,000 / 8    =   8,000 bytes/s  -> about 0.48 MB per minute

This is why file format suddenly matters when you upload to a transcription API: many have file size limits, and a long WAV recording can exceed them where the MP3 would not.

Lossy vs lossless, in plain terms

Lossless formats (WAV, AIFF, FLAC, ALAC) keep every sample. WAV and AIFF are uncompressed; FLAC and ALAC compress the data the way a ZIP file does, so you get the exact original back.

Lossy formats (MP3, AAC/M4A, Opus, Ogg Vorbis) use psychoacoustic models to throw away sound humans are unlikely to notice. At high bitrates the loss is hard to hear. At low bitrates you hear swirly, metallic artifacts, especially on "s" sounds and in noisy recordings.

Two consequences matter for anyone working with speech:

1. Loss is permanent. Converting MP3 to WAV does not bring anything back. It only makes the file larger.
2. Loss compounds. Edit an MP3, export as MP3, and you have compressed twice. Do that a few times and artifacts build up. That is why editors keep a lossless master.

What speech recognition actually needs

Modern speech-to-text engines are trained on huge amounts of real-world audio, much of it compressed. As a result:

• A clean 16 kHz mono signal is enough. Many engines resample to around 16 kHz internally, so sending 48 kHz stereo mainly costs you upload time.
• Moderate MP3 compression rarely hurts. Accuracy problems usually come from the recording, not the codec.
• Very low bitrates and telephone audio do hurt. Heavy compression smears consonants, which are exactly what the model needs to tell words apart.
• The recording matters most. Microphone distance, room echo, background music, crosstalk and clipping have far bigger effects than WAV vs MP3.

If accuracy is poor, fix things in this order: microphone and room, overlapping speakers, background noise, clipping or very low levels, and only then file format. Our speech-to-text API guide covers audio preparation and how to measure accuracy properly.

Other formats you will meet

Most speech-to-text APIs accept a wide range of these, but supported formats and size limits vary by provider and change over time, so check the current documentation.

Recording format vs delivery format

The cleanest mental model is that one piece of audio has three jobs, and each job has a natural format:

1. Recording and editing: WAV or FLAC, 48 kHz (or 44.1 kHz), 24-bit if your recorder supports it. You want headroom and no generational loss.
2. Transcription: a 16 kHz mono WAV or FLAC, or an MP3 at a sensible bitrate. Smaller files upload faster and stay under API limits.
3. Publishing: MP3 or AAC at a bitrate that fits your content. Spoken word sounds fine at lower bitrates than music, which is why many podcasts publish mono or modest-bitrate stereo files.

Converting with ffmpeg

ffmpeg is the free, standard command-line tool for audio conversion. A few commands cover nearly every transcription workflow:

# Any input to 16 kHz mono WAV for speech recognition
ffmpeg -i input.m4a -ar 16000 -ac 1 output.wav

# WAV master to MP3 at 128 kbps for publishing
ffmpeg -i master.wav -codec:a libmp3lame -b:a 128k episode.mp3

# WAV to FLAC (lossless, smaller)
ffmpeg -i master.wav -c:a flac master.flac

# Compact speech file with Opus
ffmpeg -i input.wav -ac 1 -c:a libopus -b:a 32k speech.ogg

# Extract the audio track from a video without re-encoding
ffmpeg -i lecture.mp4 -vn -acodec copy lecture-audio.m4a

# Split a long recording into 10-minute chunks for API limits
ffmpeg -i long.wav -f segment -segment_time 600 -c copy chunk_%03d.wav

If you split audio into chunks, overlap them slightly or cut at silences so you don't slice a word in half, and keep track of each chunk's start time so you can stitch timestamps back together.

Common myths

• "Higher sample rate means better transcripts." Past roughly 16 kHz, extra samples carry little that matters for speech recognition.
• "Always send WAV to your transcription service." Send the smallest file that keeps speech clean. Often that is FLAC or a reasonable MP3.
• "MP3 is outdated." AAC and Opus are more efficient, but MP3 remains the most compatible format for podcast feeds and general sharing.
• "Converting to WAV fixes a bad recording." It doesn't. Noise reduction and better microphones do.

When the audio is already on YouTube

A lot of speech worth transcribing already lives on YouTube: talks, interviews, lectures and podcast episodes. In that case you can skip downloading and converting entirely. YouTubeTranscript.dev pulls the existing captions, or AI-transcribes the audio when there are none, and exports TXT, SRT or VTT. If you're processing many files, the API handles bulk jobs. For your own recordings, the format advice above still applies: record lossless, transcribe from a lean copy, publish compressed.