Convert M4A to AAC

This is the distinction the pair exists to explain, and it is the one most converter pages get wrong. AAC is a codec — standardised as ISO/IEC 13818-7 in 1997, the designed successor to MP3, and the thing that actually compresses the sound. M4A is a container: an MP4 file, used by Apple since iTunes 4 in 2003, holding a single audio track that is normally AAC. Almost every `.m4a` on a disk and almost every `.aac` on a disk hold the same codec, and the difference between the two files is everything wrapped around it.

The MP4 header is not decoration. It records how long the audio is, how many channels it has, where every sample begins so a player can seek to an arbitrary second, and a metadata block for the title, the artist and the cover image. A `.aac` file normally has none of that, and the following sections are about what you gain and lose by throwing it away.

A bare `.aac` file is an ADTS stream, which is a continuous run of frames each opening with a seven-byte header describing that frame and nothing beyond it. The design target was broadcast, where a receiver may join a transmission at any moment and must be able to find a frame boundary and start decoding without ever having seen the beginning.

That gives ADTS two genuine properties. Any byte range of the file that starts on a frame boundary is itself a valid file, which is why HLS can deliver audio as a sequence of `.aac` segments. And two ADTS files can be joined by concatenating them, with no header to rewrite. Those properties are why streaming and embedded systems want it, and they are bought by giving up everything a file-level header provides.

The tidy story about this pair is that since both files hold AAC, the conversion is a rewrap — lift the frames out of the MP4, wrap each one in an ADTS header, write them out, lose nothing. That is a real technique and the underlying library supports it.

This converter does not use it. A bitrate is supplied to the encoder for every compressed target, which disables the library's stream-copy shortcut, so the audio is decoded to samples and encoded again. The practical consequence is a second lossy pass on audio that was already lossy: real, usually inaudible at a sensible setting, and not nothing. Pick High quality, which writes 192 kbps — the AAC ceiling among the three bands offered — if the result matters. Where a bit-exact rewrap is genuinely required, a command-line tool that can copy the stream is the correct instrument, and saying so is more useful than pretending.

Firmware and embedded decoders are the main case. A chip with a frame-level AAC decoder and no MP4 parser wants exactly this: hand it frames and it plays them. DSP evaluation boards, in-car and industrial audio modules, and a good deal of set-top and IP-camera firmware are built that way.

The others are ingest and legacy APIs. Some streaming ingest paths take an elementary stream and do their own packaging. Older Android and Java audio interfaces read ADTS directly. Encoder test harnesses and conformance suites work at frame level by definition. If you are not in one of those situations, the M4A you already have is the better file and this conversion will make your life worse.

Three things, and each of them is visible immediately. The duration disappears, because ADTS has no field for it — a player estimates from the file size and the first frame's bitrate and is wrong whenever the encoder varied. The sample table disappears, so seeking means guessing a byte offset and scanning for the next sync word, which is why scrubbing jumps and the progress bar drifts.

And the metadata block disappears, along with the well-defined place for cover art. What replaces it is an ID3v2 header bolted onto the front — the same mechanism MP3 uses — which is a convention rather than part of the AAC specification. Desktop players generally read it. Embedded decoders frequently do not, and some will treat the ID3 bytes as corrupt audio, which is a reason to test the very first file on the actual target device.

The Quality control resolves to real bitrates and AAC is offered a fixed set: Small file writes 96 kbps, Balanced writes 128 kbps and High quality writes 192 kbps. There is no 256 or 320 option, which is a limitation of the encoder path rather than of the codec.

For this pair the choice is easy: High quality, nearly always. You are re-encoding audio that has already been compressed once, and the only defence against the second pass being audible is to give the encoder enough room that it adds almost nothing of its own. The size difference between 128 and 192 kbps is 50 percent on a file that is already small, and the reasons people need a raw stream are rarely reasons to economise on bytes.

The registry lists both AAC and ALAC as codecs for M4A, and a file ripped from a CD in iTunes may well hold Apple Lossless. ADTS cannot carry ALAC at all — it is an AAC frame format — so there is no version of this conversion that preserves a lossless source.

What happens in practice is that the file stops rather than being silently transcoded: ALAC is not among the codecs available on this decoding path, so the conversion reports that nothing in the file could be converted. Size will tell you in advance which kind of M4A you have — four minutes of AAC is three to five megabytes against twenty to thirty for Apple Lossless — and if it is ALAC, the honest answer is that a raw AAC stream is the wrong destination for it.

ADTS headers carry a channel configuration and a sampling frequency index per frame, so mono stays mono, stereo stays stereo, and the sample rate of the source is written through unchanged — including the unusual ones an embedded target may specifically require.

The frequency index is a fixed table rather than an arbitrary number, which is the constraint to be aware of when a device specifies a rate. The standard values are covered; an exotic rate outside the table has no ADTS representation. And where a source configuration cannot be encoded at all, the conversion falls back to two channels at 48,000 Hz rather than failing, so check the first output against what the target expects before flashing a batch of files onto anything.

This is the pair where a trial run pays for itself most reliably, because the destination is usually a device rather than a person. Convert one file, put it on the target, and confirm three things: that it plays at all, that it plays from the first frame rather than skipping, and that the ID3 header at the front does not upset the decoder.

Once that works, batches are straightforward — drop a folder, get a ZIP, with a 100 MB ceiling per file, a hundred files to a batch, and no upload at any point. The decoding uses your own device's codecs and the AAC encoder runs in the tab, natively where the browser has one and as a WebAssembly package where it does not, since Firefox ships no AAC encoder. The network tab will confirm that nothing carrying the audio is ever sent.