ALAC

Apple Lossless Audio Codec

{{{icon}}}
Filename extension(s)	.m4a, .caf
Media type
Developed by	Apple Inc.
Initial release	2004
Latest release
Type of format	Lossless audio codec
Container for
Contained by	MPEG-4 Part 14
Extended from
Extended to
Standard
Open format?	Yes
Website

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. Maybe 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 market 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. 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, could be the worst among lossless formats except the more obscure TTA. The ALAC codec provides for no detection (and thus no protection) against corruption, although it is possible to create detectable corruption in a frame header, or by corrupting bits essential to the MP4 container – potentially rendering the file completely unplayable.
  • 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 enjoy 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, FLAC and TAK would in their defaults beat ALAC at both size and encoding time and decoding CPU load. It would spend twice as much time encoding as the the lightest WavPack modes to be on par at compression and decoding load. The "fast" ALAC mode saves only encoding time – decoding is slower in "fast mode" – but still loses to WavPack's default on all three parameters, producing five percent bigger files.

Said study used the refalac 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. 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 and battery consumption on Android might depend on encoder used.

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 ffmpeg conversion to WAVE/AIFF requires an audio stream-specific workaround to be lossless when source is > 16 bits: ffmpeg -i infile 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.

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 streaming platform offers a reasonably-sized lossy.

There are two common 32-bit PCM formats. ALAC (like FLAC) supports the integer variant, which is like CDDA but spending 4 bytes rather than 2.

• ffmpeg cannot encode to 32-bit ALAC; given 32 bit input, it will perform a lossy conversion to 24-bit. It does decode 32-bit ALAC.
• The lack of 32-bit float support 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). However the user must be cautious when converting from float to an integer-only format, as conversion between 32-bit float and 32-bit integer is lossy – both ways – and sometimes badly so, due to clipping:
  • Upon conversion from float to integer, some applications might clip, possibly without warning – ffmpeg being the most prominent. It might be safer and more recommendable to use a different target format like ALAC/FLAC. WavPack can handle float losslessly, but even a lossy format that works in float and avoids clipping – like AAC/MP3 – might sound better when the source exceeds digital full scale.
  • 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 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