M4A to WAV converter
The file arrived in a shape your workstation cannot ingest: M4A is an MP4 container around AAC audio, and both layers have to be unwrapped before an editor or transcription script can read it. Decoding gives you PCM; it does not give back detail AAC already discarded.
WAV stores raw PCM, so the file is much larger than the compressed source.
Processed on your device. Files aren’t sent anywhere.
The arriving file and the tool that rejects it
Illustrative: a journalist phones an interview and the phone saves it as a 12-minute M4A. The workstation editor and the transcription script both want plain WAV, and the recording is sensitive enough that a cloud converter is not an option. Decoding is the bridge between the phone's format and the workstation's expectations.
- Drag the M4A onto this page; the local FFmpeg worker loads on first use
- Choose the WAV sample depth your editor expects — 16-bit by default
- Convert, then read the reported codec, duration, sample rate and channel count
- Open the WAV in the editor and run the transcription script against the same file
Before you decode the recording
Why does the workstation reject the M4A?
Does decoding recover what AAC discarded?
Is the interview uploaded to a server?
Why is the WAV so much larger?
Can I decode several recordings at once?
Two layers get unwrapped, and neither is restored
It is worth separating the container from the codec, because the failure message usually names only one of them.
| Layer | What decoding does | What it does not do |
|---|---|---|
| MP4 container | Removes packaging and metadata framing | Does not carry tags into the WAV — WAV has no such fields |
| AAC codec | Reconstructs playable PCM from the compressed stream | Does not restore audio information AAC discarded |
| WAV output | Stores raw PCM an editor can read | Does not stay small; the file grows several times |
The editing chain after decoding
Decode once, then work on the WAV, then encode a deliverable from the edited WAV. Skipping the decode and editing the M4A directly is what produces tools that refuse the file.
- Decode to WAV for editing, level fixes and transcription
- Edit the WAV; keep it as the working file for this project
- Encode the deliverable from the edited WAV — MP3 for a host, M4A for an app
- Never re-edit an already-encoded deliverable; each lossy pass adds loss
What the verification report tells you
After decoding, the engine probes the new file and compares codec and duration with the source; a duration drift beyond a small tolerance is reported as a failure rather than handed over as a shortened recording. It also reports the measured sample rate and channel count, which is worth reading because encoder builds differ in the rates they accept.
Batch discipline for a folder of recordings
Phone recordings arrive with names like Audio 007.m4a, which is useless downstream. Convert one file per run and rename as you go.
- Rename on conversion: date, subject, take — not the phone's counter
- Keep the original M4A untouched beside the decoded WAV
- Note in the project log which files were decoded rather than recorded natively
What you will not get back
A phone recorder is a lossy encoder with modest settings. Decoding gives you a file you can work on, not the recording the phone never made.
- If detail matters — a transcript, a long interview, a measurement — record natively next time
- Keep the master uncompressed so the next delivery encodes once instead of twice
Decoding is a shape change, not a repair: the WAV is honest about the audio that survived, and silent about everything the recorder threw away.
The rule that keeps a decoded file from being filed as a master