The ALAC or Apple Lossless codec is a lossless codec developed by Apple and until now a closed standard. Other implementations of ALAC do exist including open source libraries and code written by some audio manufacturers to support the format. Generally though most people preferred to use the open standard FLAC codec as their lossless codec.
The big disadvantage of FLAC for Apple users is that it is not supported by iTunes, or on the iPhone. So someone that used iTunes and also had a streaming Hi Fi system was in a situation where there was not one lossless codec that they could use in all situations. Possibly the best solution here was to maintain two copies of your music, a high quality lossless version for streaming, and a compressed version for mobile use. Not ideal but workable.
If ALAC was widely supported then this would be less of an issue, so what difference will opening the code make?
Firstly, the current non-apple implementation of ALAC are based on reverse engineering of the file format. That is not ideal, but did seem to work OK. One of the issues here though was some uncertainty of the higher quality encodings in ALAC. 16-bit, 44.1kHz was fine and well understood, but higher bitrates were often not supported. The source code that has just been released provides documentation on all the supported formats now, so this is no longer an issue.
The other problem with existing ALAC decoders is the somewhat questionable legal status of them. Apple had been known to prevent manufacturers from including ALAC support in their products, but with this open release this has now changed. The source code is released under a very fair and liberal license. The notable thing about the license is that it includes a clause giving full patent license to users of the code, so Apple will not sue users of this code for any patent infringement. This means that there is no reason to not support ALAC now.
Currently though ALAC is not well supported, so for now sticking with FLAC is still probably a better option, but in the long run I expect that ALAC will be supported in most new products, so the future looks good.
Another question that may come up is which format is technically better? On a basic level both formats do the same job, the bits that come out the end will be exactly the same. Both formats (or their standard containers) have good metadata support too. So for most users the main reason for choosing one format over the other is device support.
One format may be more efficient at decoding than the other. This would require some testing to confirm, but ALAC was designed to be efficient on limited hardware, so results with it should be good. The source code is also very easy to read and understand, which is good.
In the end, opening the source code to ALAC can only benefit us all, so it is a very generous thing for Apple to do. Who knows, maybe AirPlay will be next?
![]()
![]()
![]()
![]()