Latest revision as of 13:47, 19 May 2024

The Apple Lossless Audio Codec (ALAC), sometimes also known as "Apple Lossless Encoder" or simply "Apple Lossless", is a lossless audio codec. First introduced in 2004, Apple has since 2011 provided a free open-source encoder/decoder. ALAC is supported natively in Apple's own operating systems and Windows 10/11, and is ported to other platforms like Rockbox-endabled portable players, and through FFmpeg's encoding and decoding support. Other third-party implementations are available.

Being pushed in the Apple ecosystem, lossless music in ALAC format is sold by several music vendors, making it second only to FLAC (and MLP if files on silver discs are counted) in popularity among lossless compressed audio formats. ALAC in itself does not provide a file format, but is commonly delivered in an MPEG-4 container with .m4a file extension; this has led to a common misconception that ALAC itself is related to AAC (also offered by Apple through iTunes).

The Wikipedia entry offers some information not covered in this article.

Features

Arguably, it is the integration with the Apple ecosystem that might be ALAC's selling point, and not the features; while the codec enjoys several of the more common properties noted at HA Wiki's Lossless Codec Comparison, it falls short on others. Arguably the closest it gets to any unique feature could be for applications tied to the MP4 container, since FLAC in MP4 might be less supported in practice.

This section is largely based on what is available for ALAC in an MP4 container, which will provide for seekable and streamable playback, and tags. ALAC can also be fit in the Matroska container and Apple's CAF container, and the MP4 container's predecesor format QTFF(.qt/.mov).

ALAC can handle 16/20/24/32 bits signals in 1 to 8 channels. Officially, sampling rates up to 384 kHz are supported, but "any WAVE" sampling rate (4 GiHz – yes gigahertz, > sixteen octaves above audible) could well work, if the decoder isn't capped lower. This does in principle make ALAC the "biggest player that can handle radio frequencies", if that is a desired use.

"Large" data are supported – i.e., exceeding WAVE/AIFF's limits of 4 GiB uncompressed – and handled well in e.g. the refalac implementation, which will automatically invoke the RF64 extension of WAVE when needed.

Although it was speculated that ALAC could accommodate DRM though the MP4 container, nothing such has surfaced. Whether that would be a "feature" is certainly up to opinion.

Limitations

• Only a limited channel configurations are supported. For example, 3 channel ALAC is assumed to be 3.0 and not 2.1.^[1] There is no support for WAVEFORMATEXTENSIBLE channel mask information (which is mandatory in WavPack and has long been supported in FLAC) for alternative configurations.
• Bad error handling,^[2] could be the worst among lossless formats except the more obscure TTA.^[3] While it is possible to create detectable corruption – ostensibly by corrupting bits essential to the MP4 container – ALAC itself provides for no detection (and thus no protection) against corruption.
  • Furthermore, unlike most other lossless formats, there is no provision for an audio checksum. The user will have to resort to 3rd-party hacks to store an audio checksum as an ordinary tag.
• 8-bit audio is not supported, and embedding it in 16 bits by padding up with zeroes, will compress very bad.
• 32-bit integer is supported, but (like FLAC) not 32-bit float. See below subsection on 32-bit signals.
• ALAC is an "audio-only" compressor, it has no ambition to store non-audio chunks from the source files. Storing such chunks might be essential to serve e.g. audio editing software (which might use them for metadata), and formats like WavPack, TAK, OptimFROG and Monkey's Audio provide for full file restore (the latter even mandates it), while FLAC can be set to store such chunks in the reference implementation. Users might note that such a property is irrelevant for CD rips. Contrary to a common misconception, CD audio is not stored as WAVE – nor in any sort of file. Thus, using a "full file compressor" gives no more "true" copy of a CD, than storing the audio in e.g. ALAC.

ALAC might not the same hardware player support as e.g. FLAC. It is of course supported by players running iOS (also Rockbox or ffmpeg-based code), but for for example in-car units one should be cautious about trusting a statement claiming ".m4a" support, as that might be restricted to the AAC codec. Compare to how players claiming " .wma" support would rarely play WMA Lossless.

Performance – file size, CPU load (tested on Windows)

When ALAC was launched in 2004, both storage and computing power were more expensive, and so compression ratios and CPU load were more of an issue than today. By 2024, one might not be as concerned that ALAC isn't quite up to par performance-wise: In Martijn van Beurden's comparison studies,^[4] FLAC and TAK would in their defaults beat ALAC at both size and encoding time and decoding CPU load. It would be on par with the lightest WavPack modes on two out of three parameters, but spend twice as much time encoding. The "fast" mode saves only encoding time, but still lost to WavPack's default on all three parameters, producing five percent bigger files.

Said study used refalac (a Windows port of Apple's reference code), but other encoders are available. FFmpeg has an encoder which prioritizes speed over file size, and in its default mode creates bigger files faster.^[5] On the other side, CUETools offers an ALAC encoder which may compress slightly better at slightly more time.

Performance tests on Apple platforms are not available at the time of writing, but if ALAC is chosen for integration in the Apple ecosystem, performance issues are likely a secondary concern if any at all. Due to the compression method, ALAC is unlikely to be as CPU-efficient at decoding as a properly implemented FLAC decoder. It is unknown how that would translate to battery life on iOS; on Rockbox it was tested to be 4 to 5 times as CPU intensive as FLAC^[6] and battery consumption on Android might depend on encoder used.^[7]

Using ALAC

Likely, the answer to "how to use ALAC?" is "just play it, and fix tags when you need" – ALAC in MP4 can likely be played back by most modern player applications, and tagged by even more.

For someone who wants to use a Windows computer to migrate to ALAC encodes (say for later use in Appleware), it could be accomplished in various ways:

• By a player. E.g. in foobar2000 with its Free Encoder Pack, that includes refalac. Said player can also convert back and forth between one file per track, and single file + cuesheet.
• CUETools can also do such conversion, but is restricted to CDDA. CUETools can invoke its own ALAC encoder, which may improve compression (potentially spending a lot of time doing so).
• refalac can actually decode FLAC/WavPack/TAK for conversion if the user provides the respective dll (copying it into the refalac folder). refalac supports drag and drop: drag the source file onto the refalac.exe icon and drop it there.
• ffmpeg will transfer tags. For command-line use, you need to specify ALAC as codec in the command-line like ffmpeg -i infile -acodec alac outfile.m4a. BEWARE that converting to WAVE/AIFF is only lossless for 16-bit input: ffmpeg -i infile.m4a outfile.wav will decimate a 20/24/32 bit source file to 16 bits, without any warning.

Conversion from ALAC could be equally straightforward, as long as to a codec that the application need not set up specifically. Monkey's Audio supports all signals one could possibly fit in ALAC; WavPack realistically so, though it might object to certain radio frequencies fifteen octaves above the audible; and in real-world music files, there has been released one publicity stunt at a sampling frequency where FLAC requires its --lax switch.^[8]

Particular notes on 32-bit signals

32-bit signals are not too commonly found in the wild, and the format is arguably not the best suited for delivering music to end-users. There are stores that supply such a format as a kind of PR stunt (or the usual audiophoolery, pretending it to be audibly better) – but it also does happen that some artist exports a file straight out of their digital audio workstation. A platform like Soundcloud will offer a 128 kbit/s MP3 for streaming, but may also at artist's discretion make the original file downloadable, and an artist offering a file straight from their DAW for free is hardly in any obligation to make it more user-friendly when the platform offers a reasonably-sized lossy.

ALAC does support 32-bit integer PCM (like CDDA but spending 4 bytes rather than 2), but not floating-point. This is not any sort of bug or mistake: floating-point is a different animal altogether, and compressing it would take different techniques (WavPack is recommended). Conversion between 32-bit integer and float is lossy both ways.

• Some applications might clip 32-bit float when converting to integer – ffmpeg being the most prominent. Since conversion to ALAC would anyway be lossy, a different format is recommended; even a lossy format like high-bitrate AAC/MP3 might sound better when the source exceeds digital full scale, since these lossy formats work as float and avoid clipping.
• ffmpeg does not convert to 32-bit ALAC.
• Also 32-bit integer could cause some compatibility issues in applications that work in 32-bit internally, as they usually process audio as 32-bit float (because floating-point math is the natural choice for a volume control, and essential for lossy formats like MP3). Playback should be safe if it plays at all – there is no DAC that can convert the lower bits to analog in any case.

Further reading

• macOSforge at Github
• qaac (with refalac) at Github, has refalac usage wiki
• ALAC at Wikipedia
• ALAC at Multimediawiki
• HA Wiki's Lossless Codec Comparison originally by Rjamorim
• CUETools includes an ALAC encoder
• the first reverse-engineered decoder at the Wayback Machine
• Rarewares has Windows and macOS compiles of said reverse-engineered decoder
• An older (2005) performance comparison of lossless audio compressors (archived on October 27, 2015) by Speek, using the iTunes 4.7 encoder

1. ↑ github.com/macosforge/alac with supported audio formats
2. ↑ HA post (2014) reporting on ALAC's lack of error resilience
3. ↑ HA post (2022) on error handling (TTA is arguably worse)
4. ↑ Martijn van Beurden: Lossless audio codec comparison archive, all comparisons in this wiki article consistent with revision 6, 2023, using refalac 1.80
5. ↑ HA forum test with different ALAC encoders
6. ↑ Rockbox: Codec Performance Comparison
7. ↑ HA forum post testing battery life on Android
8. ↑ HA post linking to a free 768/24 track