Convert M4A to FLAC

M4A is a container, and the registry lists two codecs for it: AAC, which is lossy, and ALAC — Apple Lossless — which is not. The extension is identical and the icon is identical, and the entire value of this conversion turns on the difference. Anyone about to convert a library should spend two minutes on this and then never think about it again.

Size settles it faster than any tool. A four-minute AAC track is four to eight megabytes; the same four minutes as ALAC is twenty to thirty. On a Mac, select the file and press Command-I and Get Info names the codec outright. In the Music app, adding a Kind column labels every row as "AAC audio file" or "Apple Lossless audio file". Collections are almost always uniform, so a sample of five files tells you about all of them.

FLAC is lossless in a precise and limited sense: it reconstructs bit for bit whatever it was given. It has no opinion about whether what it was given was any good. Hand it audio that AAC already stripped down and it will preserve that stripped-down audio perfectly, forever, in a file three to five times the size.

The instinct behind the mistake is understandable — you are standardising on a lossless library, so everything should be lossless. But a FLAC made from a 256 kbps AAC is a lossy recording wearing a lossless label, and it is worse than the M4A in two ways: it is larger, and it now looks like a master to anyone browsing the library later, including you. Leaving the AAC as an AAC is the honest and the smaller option.

ALAC and FLAC solve the same problem with comparable efficiency: both reconstruct the original samples exactly, and both land somewhere around half the size of the equivalent WAV. Converting between them loses nothing at all — not a subtle amount, none — because each stage is exact.

What changes is who will read the file. FLAC was released by Josh Coalson in 2001, taken over by Xiph.Org in 2003 and standardised as RFC 9639, and it is what Plex, Jellyfin, Navidrome, foobar2000, Roon, Audacity, most network streamers and effectively all Linux tooling expect. ALAC is read well inside Apple's ecosystem and unevenly outside it. If you are moving a ripped collection off iTunes and onto a media server, this is the correct conversion and there is no downside to it.

People consolidating a library often consider WAV instead, and FLAC beats it on every axis that matters for storage. It is roughly half the size for identical audio. It carries a checksum, so a file that has rotted on a disk or been damaged in transfer can be detected rather than silently played back wrong — the registry records that property, and it is the reason archivists prefer it.

It also holds metadata properly. Vorbis comments carry title, artist, album, album artist, track and disc numbers, genre, date, comment and lyrics, and PICTURE blocks carry cover art. WAV's RIFF INFO chunk holds seven fields in Latin-1 and no artwork at all. For a library that has to be browsable in five years, that difference is not cosmetic.

Take a thousand four-minute tracks. As AAC M4A at the 256 kbps iTunes rate that is roughly eight gigabytes. Converted to FLAC — with no improvement whatsoever — it becomes twenty-five to thirty, because FLAC cannot compress decoded lossy audio as tightly as it compresses a real recording; the encoder's predictors do worse on material that has already been shaped by a psychoacoustic model.

The same thousand tracks as ALAC would be twenty-five to thirty gigabytes, and as FLAC they will be about the same. That is the honest comparison to make before starting: a migration that keeps your storage roughly flat and improves compatibility, against one that triples it and improves nothing.

The decoding here uses your device's own codecs by way of WebCodecs, and ALAC is not among the codecs available on that path. So an Apple Lossless M4A dropped onto this page does not produce a bad FLAC — it stops, with a message saying that nothing in the file could be converted and that it may use a codec this browser cannot read.

That is worth stating on the page rather than letting people discover it. For an ALAC library the right instrument is a desktop tool that carries its own decoder: FFmpeg, dBpoweramp on Windows, XLD on a Mac. The conversion is lossless in all of them. What this page can do for an ALAC owner is tell them that the migration is correct and what to run.

There is a narrow exception to everything above, and it is worth naming because it is the only one. If you are going to edit the audio repeatedly — cut it, normalise it, apply processing, export, reopen, export again — then each intermediate save in a lossy format compounds the damage, while each save as FLAC does not.

So converting a lossy source to FLAC as a working file, doing the passes, and encoding once at the end to whatever the delivery format is, avoids generation loss even though the starting point was already compressed. That is an editing decision with a defined end, not an archival one. When the work is finished, the FLAC intermediate has served its purpose and can go.

FLAC's Vorbis comment block takes the common fields directly, so a converted file arrives in a media server with its title, artist, album, album artist, track and disc numbers, genre, date, comment and lyrics intact, and with its cover art as a PICTURE block that Plex and Jellyfin will display.

What does not transfer is the Apple-specific layer: purchase records, store identifiers, custom atoms and any iTunes field with no Vorbis equivalent. Those are dropped rather than written as junk keys, which is the right choice — but if your library depends on a field you added yourself in iTunes, convert one album and inspect it in your media server before converting nine hundred.

Drop up to 100 files at once; each converts on its own and they return as a ZIP, with a 100 MB ceiling per file, because the work runs on your processor rather than on anyone's server. That hundred is the whole batch, not a suggestion — a file past it is listed and left alone — and it is about the right number anyway, because FLAC encoding is real computation and a tab working through a hundred tracks is busy for a few minutes.

The privacy point here is not abstract. A music library is a fairly complete record of what somebody bought, listened to and cared about over fifteen years, and handing it to a conversion site means handing over that record. Nothing on this page leaves the tab; open the network tab of your developer tools during a conversion and you will see the page and its advertising and no request carrying your audio.