Convert FLAC to M4A

Apple standardised on its own pair of formats early: AAC for compressed audio and ALAC for lossless, both wrapped in the MPEG-4 container that gets the .m4a extension. FLAC arrived from a different world — Xiph.Org, open specification, RFC 9639 — and Apple never added it to the library side. Applications will play a FLAC; the library will not adopt one.

That is why this conversion exists and why it is so common. It is not a quality decision, a storage decision or a preference. Somebody assembled a collection in the format the rest of the internet standardised on and then bought a phone that wanted the other one.

People converting from FLAC are, by definition, people who cared enough to choose a lossless format. It is worth saying plainly that the M4A produced here is AAC, which is lossy, and not ALAC, which would be the like-for-like Apple equivalent. The extension is the same either way, which is exactly how the confusion starts.

That is a defensible outcome as long as it is a decision rather than a surprise. The collection stays lossless because the FLAC files stay where they are; the M4A files are a derived set for a device with finite storage and earbuds attached. What you should not do is convert to M4A, delete the FLACs, and believe you still have a lossless library.

The control offers three bands — low, medium and high — with medium as the default. What will not appear on this page is "128 kbps" or any other figure, and the omission is deliberate: the encoding library resolves the actual number per codec, our code does not fix it, and publishing a figure would claim a guarantee that is not ours to make.

That does not leave the choice arbitrary. The high band is worth it for live recordings, orchestral and choral music, and anything with sustained cymbals or long reverb, which are where a lossy encoder shows its working. For the rest of a collection heard on a phone or in a car, medium is the ordinary choice. When in doubt, convert one album at each and listen on the earbuds you will actually use.

This is a place to be precise rather than reassuring. The conversion gives the container-writing library no tag instructions, so what happens to title, artist, track number, year and cover art is that library’s default behaviour, not something asserted here. Nothing here promises everything comes across, because deciding that is not in our code.

The practical result is the same advice any experienced tagger would give: convert one album, add it to the library, and look before doing two hundred. The fields that go missing first are rarely title and artist — composer, disc number, sort-order fields and grouping are the ones that carry a classical collection and the ones worth checking. Fixing a whole batch with a tag editor afterward is routine; noticing after two hundred albums that the composer field is empty is not.

Both work, and M4A is the better answer for an Apple-only destination: AAC sounds better than MP3 at the same bitrate, and the container carries Apple’s metadata fields natively. If everything you own is Apple, there is no argument for MP3.

MP3 wins the moment anything else is involved. A car head unit from 2012, a cheap portable player, a friend you are sending an album to, a USB stick going into a hire car — MP3 is the format that never has to be tested. Converting a collection twice is a waste, so decide what the files are for before starting rather than halfway through.

A FLAC holds every sample of the original, so the AAC made from it is a first-generation encode working from complete information. That is materially better than converting from MP3s of the same albums, where the second encoder has to work around damage it cannot identify.

It also means the derived set can be regenerated at will. A different bitrate, a different format, a different device in three years — all of it comes from the FLAC library, not from the M4A files. Making the derived set disposable is what allows every other decision on this page to be low-stakes.

Music software often carries an option to downconvert higher-bitrate songs when copying them to a device, usually presented as a way to save space. If that setting is on, a carefully made AAC file gets decoded and encoded again on its way to the phone, which is precisely the compounding this page has spent its effort avoiding.

It is worth looking at once, before the first sync, because the damage is silent and the files on the device look correct. Turn it off if you have already chosen a sensible bitrate here; leave it on only if you deliberately want a smaller copy on the device than in the library.

The real reason for this conversion is usually that the collection does not fit on the phone, and the honest answer is that it will fit far better: FLAC compresses without discarding anything and AAC discards, so the difference runs to several times over, not a fixed percentage. What will not appear here is the exact fraction, because it depends on the bitrate the encoder chooses and that is not ours to set.

There is a way to know that is also the only one that describes your music: convert one album representative of the collection at the band you plan to use, and compare the folder size to the original. Five minutes of testing produces a figure for your library instead of an average that describes nobody’s.

Drop up to a hundred FLACs and each is encoded separately before the set comes back as a ZIP, with a 100 MB ceiling per file — about seventeen to twenty minutes of FLAC, which covers songs and most single movements.

Because the audio never leaves the tab, a large library costs processor time rather than bandwidth and joins no queue. Two or three drops will move most collections, and the browser can be left to work through them while you do something else.