WAV to M4A converter
This route is chosen for the container, not the codec: MP4 carries tags, artwork and chapter markers next to the audio, which is why a phone-first delivery list often asks for M4A even when MP3 would play. The audio inside is AAC, and AAC is lossy.
The target codec is lossy, so the original samples are not restored bit for bit.
Processed on your device. Files aren’t sent anywhere.
Start from the device list
Illustrative: a podcast is mastered as a 48 kHz stereo WAV, and the delivery sheet lists phones, tablets, a smart speaker and an in-app player. Some of those devices read container metadata and ignore MP3 tag blocks, so the delivery format is chosen by the device list rather than by codec preference.
One file per run, up to 60 MiB and 600 seconds of audio; longer episodes are handled in segments.
- Drag the WAV master onto this page; the local FFmpeg worker loads on first use
- Set the bitrate from the delivery target, not from habit
- Convert once and read the reported codec, duration and channel count
- Play the result on the actual device list before publishing
Container versus codec, stated once
The naming confusion here is common enough to settle plainly: the codec decides how the sound is stored, the container decides what travels alongside it.
| Layer | What it decides | Why it matters for delivery |
|---|---|---|
| AAC codec | How audio information is compressed | Quality per bitrate; lossy, so the WAV stays the master |
| MP4 container | Metadata, artwork, chapter markers, packaging | Devices and apps read these; MP3 tag support is less consistent |
| Raw AAC stream | Audio only, no container | Fine for an encoder chain, poor for a listener deliverable |
Sizing the episode
Bitrate is a budget per second, so episode size follows duration. For a 90-minute episode the difference between 96 and 192 kbps is the difference between a streamable file and a heavy download. These figures are illustrative; the encoder's own output is what you should measure.
- 96 kbps — voice-heavy episodes where the app streams on mobile networks
- 128 kbps — the usual podcast setting for mixed speech and music
- 192 kbps — default here; choose it when music matters
- 320 kbps — when the file will be edited again or played on good equipment
What the verification step actually checks
After encoding, the engine probes the new file and compares codec and duration with the source, reporting a failure if duration drifts beyond a small tolerance. It also reports the measured sample rate and channel count. Encoder builds differ in which rates they accept, so read the report rather than assuming your source rate was carried unchanged.
Checking playback on the delivery list
A container that looks correct on the workstation can still behave differently on a phone app. Test the file where it will actually be played.
- Play the first and last minute on a phone, not only on the editor
- Confirm the app shows the episode title from its own metadata pipeline
- Check seek behaviour in the app; some players mishandle long single-file episodes
- Keep the WAV master so a later delivery can be re-encoded without inheriting this loss
When M4A is the wrong deliverable
Pick M4A when a container and its metadata are part of the delivery. Pick something else otherwise.
- Archive: keep the WAV, or use WAV to FLAC, which stores the same samples without spending quality
- Encoder chain: use WAV to AAC for a bare elementary stream a muxer can consume
- Legacy hosts that only accept MP3: encode from the master with WAV to MP3 rather than converting an existing M4A