WAV vs MP3, and what MP3 to WAV really does

Two searchers land here. One thinks converting to WAV will improve a file they already have. The other has been told by an editor, a DAW or a transcription tool to supply WAV and wants to know what they are giving up. Both need the same explanation.

WAV is uncompressed and MP3 is not, so the same recording is about seven times larger as a WAV than as a 192 kbps MP3, and eleven times larger than as a 128 kbps one. That size buys you nothing if the audio is already an MP3. Converting an MP3 to WAV writes out the samples the MP3 decoder produced and nothing more, so the detail the encoder threw away is still missing — it is just missing in a 600 MB file instead of a 60 MB one. WAV is the right answer when a program demands it, when you are about to edit and re-export, or when the recording has never been through a lossy encoder. Everywhere else it is storage spent on nothing.

What each one actually is

WAV is a container around raw PCM: a header, then every sample of the waveform written out in order. There is no cleverness in it. A CD-standard WAV holds 44,100 samples per second per channel, two bytes each, both channels — 176,400 bytes for every second of audio, which works out at 1,411 kbps.

MP3 is a perceptual codec. It models what a listener can hear, discards the parts it decides are masked by louder content nearby, and stores what is left as a set of coefficients. At 192 kbps it keeps about an eighth of the 1,411 kbps the same audio needs as PCM, and most people cannot pick the result out of a blind test against the source — whether you can hear the difference between bitrates puts numbers on that. The judgement is permanent. Nothing downstream knows what was removed.

MP3 to WAV: what happens to the bytes

The conversion is a full decode. The MP3 frames are turned back into samples, and those samples are written into a WAV header. The output is an honest representation of what the MP3 sounds like — and that is the whole of it. No converter can restore the frequencies the first encoder decided you would not miss, because the file never contained them to begin with.

Photocopying a photocopy onto larger paper gives you a bigger sheet with the same smudges. What you gain is a copy that will not smudge any further, which is the whole point of the exercise when you are about to work on it.

One trap catches a lot of command-line advice. FFmpeg will happily copy an AAC stream into a WAV container without decoding it and exit reporting success, because WAV's format tag is arbitrary. The file it produces plays in nothing. Our converter keeps its own list of which copies are legal rather than trusting the tool to refuse, so an M4A going to WAV is always properly decoded. Copies are only allowed where the codec is already valid in the target container — 16-bit PCM in one WAV to another, for example, which is carried over untouched and finishes in about a second because no encoder runs.

When WAV is genuinely the right answer

• Something refuses to open anything else. Old DAW versions, hardware samplers, some transcription pipelines, a lot of scientific and forensic tooling. Audacity is the common case — it needs an optional import library for M4A and will refuse the file without one, which is why converting first is usually faster than fixing the plugin.
• You are about to edit. If a clip will be cut, layered, levelled and exported again, working from WAV means every intermediate save is exact. Only the final export goes through a lossy encoder, so the audio survives one generation instead of four. Video editors are the same case from another angle: Premiere accepts an MP3 but decodes the whole file on import, and a variable-bitrate one can drift out of sync afterwards, which is why the preset that fixes it is 16-bit PCM.
• The source has never been compressed. Audio straight off an interface, an ADAT tape, a field recorder or a vinyl capture has nothing missing yet. Keep it in WAV or FLAC and encode only when you deliver.
• Speech recognition on a short file. Most speech engines resample to 16 kHz mono internally anyway, so WAV rarely transcribes better than a decent MP3 — but it does remove a decode step, and for a two-minute clip the size is irrelevant. What each transcription service asks for covers the ones that name a format.

What is not on that list: making an old download sound better, preparing something for a phone, emailing a recording, or archiving music you bought as MP3. In all four, WAV multiplies the size and changes nothing you can hear.

Why WAV files are so big, arithmetically

There is no mystery and no setting to tune. Sample rate, times bit depth in bytes, times channel count, gives the bytes per second. Everything else follows.

A one-hour podcast episode you downloaded at 128 kbps occupies about 55 MB. As a 16-bit WAV the same episode is about 605 MB, an elevenfold increase for audio that is identical, sample for sample, because it came out of the same decoder. If the problem you actually have is a file that is too large, the fix runs the other way; the size reducer shows the resulting size before you commit to a bitrate.

Sample rate and bit depth, briefly

44.1 kHz is the CD rate and the default for music. 48 kHz is the video and broadcast rate; every camera, phone video and NLE timeline uses it. Neither sounds better than the other, but mixing them inside one project makes the software resample on the fly, which is where drifting sync and odd artefacts come from. Match the timeline you are delivering to.

16-bit gives about 96 dB of dynamic range and is what almost everything expects. 24-bit gives headroom while recording, so a peak that would have clipped is recoverable. It is only worth writing if the source was captured at 24-bit — promoting a 16-bit file to 24 adds fifty per cent to the size and eight zero bits to every sample. Our converter offers both depths when the target is WAV or AIFF, with 16 preselected for that reason.

One MP3 quirk falls out of this. MP3 only defines a handful of sample rates: 32, 44.1 and 48 kHz, plus the half and quarter rates below them. Feed an encoder a 96 kHz WAV and it must resample to 48 kHz first. That step is fine, but it means the sample rate you get is not always the one you gave.

The ceiling a long WAV recording hits

WAV stores its chunk lengths in unsigned 32-bit fields, so the format cannot describe a file larger than 4 GB, and a surprising amount of software gives up at 2 GB. At 16-bit and 44.1 kHz in stereo that ceiling arrives after roughly six hours and forty-five minutes. At 24-bit and 48 kHz it arrives after about four hours and ten minutes. Field recorders sidestep this with RF64 and Wave64, which are WAV with wider fields, and which some editors will not open.

FLAC does the same job at half the size

FLAC compresses losslessly. Decode a FLAC and you get back every sample that went in, bit for bit, in roughly half to two thirds of the space WAV needs. For archiving, for a lossless copy of a CD rip, and for any long recording that would otherwise run at the 4 GB wall, it is simply the better container. ALAC is the same idea in an .m4a, which Apple software prefers.

The one thing FLAC is not is universally accepted. If a program has asked you specifically for WAV, give it WAV; if it has asked for "uncompressed" or "lossless" without naming a format, FLAC will usually do and will cost you far less disk. Either way, the converter writes both, and it decodes properly rather than pretending a copy is possible.

What to pick, in one line each

• Listening, sharing, sending to a podcast host: MP3 at 192 kbps, or M4A if the destination accepts it.
• A program demanded WAV: WAV, 16-bit, matching the project's sample rate.
• Editing then re-exporting: WAV while you work, one lossy encode at the end.
• Archiving something that was never compressed: FLAC, or ALAC in Apple software.
• Trying to make an existing MP3 sound better: nothing will do this, and WAV least of all.