MP3 to WAV converter
The workflow fails before editing starts, and the fix is a decode, not a repair. WAV is raw PCM, so the MP3 is rebuilt into samples an editor can measure — but the reconstruction is only what the MP3 stored, and the file grows because nothing is compressed any more.
WAV stores raw PCM, so the file is much larger than the compressed source.
Processed on your device. Files aren’t sent anywhere.
The export that fails before editing starts
Illustrative: Tomas is handed a 128 kbps MP3 of an interview and has to notch out a hum. His editor refuses the compressed file, and the first attempt also fails to show him anything useful in a spectrogram. Converting to WAV solves the first problem and not the second: the hum is visible because it was stored, and the artefacts the encoder invented are visible too.
Two things are being confused here. Compatibility is a format question and a decode fixes it. Quality is a content question and a decode cannot touch it.
Read the symptom as two separate problems
Mixing them is why people convert, watch the file grow, and assume the audio improved. The honest framing is that you now hold an uncompressed working copy of a lossy recording.
What this decode does not do
Does converting to WAV restore lost quality?
Why is the WAV so much larger?
Does 24-bit output recover more detail?
Is the MP3 uploaded anywhere?
What the decoded WAV actually contains
The engine probes the MP3 stream, decodes it, and writes the samples out as PCM. It does not resample or downmix; the reported sample rate and channel count are read back from the result, so a mono MP3 stays mono and the report tells you what the decoder measured.
- The samples are the MP3 reconstruction, not the original recording
- Artefacts the encoder stored arrive with the audio, and are now measurable
- Sample rate and channel count are carried unchanged; there is no resampling
- A truncated or corrupt MP3 is reported as a failure rather than written as a short WAV
Choosing 16-bit or 24-bit output
The sample-depth control decides how the decoded samples are written. 16-bit is the ordinary choice; 24-bit suits an editor that works at that depth. Neither option recovers detail, and neither changes the file beyond the extra bits per sample.
The one hard limit worth stating plainly
Everything downstream inherits the quality of the MP3 you were given. Normalising, filtering and re-exporting all operate on the reconstruction.
A WAV made from an MP3 is a bigger file containing the same loss. Treat it as a working copy, never as the master.
Editor workflow rule
Editing jobs this unlocks
Once the audio is PCM, tools that refuse compressed input can work on it, and measurements become meaningful.
- Notch filters, denoise passes and level normalisation in editors that want uncompressed input
- Spectrograms and level measurements, where artefacts are now visible instead of hidden
- Trimming and concatenation in tools that index raw samples rather than compressed frames
Check the result before you edit
Listen from the first seconds and confirm the length matches what you expected. If the run reported a duration mismatch it failed loudly; do not start editing a file you are unsure about.
What to ask the sender for instead
If the recording matters, the right move is upstream: ask for the original file rather than polishing a compressed copy.
- Ask for the WAV or FLAC master, not the delivery MP3
- If only the MP3 exists, decode it here and treat the resulting WAV as a working copy
- Do not re-encode that WAV back to MP3 repeatedly; each pass spends quality again