27 October, 2011, 07:47:32 PM

Quote

The Apple Lossless Audio Codec (ALAC) is an audio codec developed by Apple and supported on iPhone, iPad, most iPods, Mac and iTunes. ALAC is a data compression method which reduces the size of audio files with no loss of information. A decoded ALAC stream is bit-for-bit identical to the original uncompressed audio file.

The Apple Lossless Audio Codec project contains the sources for the ALAC encoder and decoder. Also included is an example command line utility, called alacconvert, to read and write audio data to/from Core Audio Format (CAF) and WAVE files. A description of a 'magic cookie' for use with files based on the ISO base media file format (e.g. MP4 and M4A) is included as well.

This won't greatly affect Mac users, but this should be extremely helpful for Windows users. Either way, it's good to have these technologies in the open.

This doesn't help anyone but Apple.

ffmpeg and libavcodec have supported ALAC decoding for approximately three years. These technologies have been in the open for a while despite Apple.

Yes, but they're reverse-engineered codecs that are incomplete and not 100% compliant due to unknown or little-known syntax elements. It is great just to have some official documentation (which seems to be pretty good from what I've glanced at so far). Now other implementations can ensure they're compatible.

Some people are saying on the MacRumors-forum that one of the reasons Apple developed ALAC was that it is less power-hungry than FLAC and other lossless codecs, and therefore is better to use on battery-driven iPods etc.

This is good news but whatever the motive of Apple is, it is a few years too late.

It's not too late. The lossless market is still open, also in terms of formats. FLAC might be the most popular, but overall not many people care about lossless right now anyway.Also - and this is partly based on a rumor I read a few months ago - Apple might start selling [magical] lossless music through iTunes in 2012.

Given the popularity of iTunes that could easily make ALAC the most used format. Open sourcing it is a logical step towards domination, people like open source and it's easier for manufacturers. Well, I don't know what the licensing terms were until now for ALAC implementation, if and how much manufacturers had to pay.. even if they did and Apple now loses a few bucks there (due to competing hardware), at the end of the day the main source of profit are iTunes sales, which would increase.

Why do I not like this? Mostly because ALAC is technically a redundant format and also because it would give Apple an unfair advantage, in a way (very few non-Apple devices support it right now). I'm equally bothered by Microsoft and their WMAL, but MS doesn't have the reach Apple has with iTunes.

Some people are saying on the MacRumors-forum that one of the reasons Apple developed ALAC was that it is less power-hungry than FLAC and other lossless codecs, and therefore is better to use on battery-driven iPods etc.

Any truth to this?

Not really. ALAC's frames are a lot like FLAC's LPC subframes, so the speed of decompression is similar. But because ALAC decoding adjusts the coefficients and Rice parameter based on the residual, it may actually be a little more CPU intensive than FLAC - which does all of that work on the encoder side.

Some people are saying on the MacRumors-forum that one of the reasons Apple developed ALAC was that it is less power-hungry than FLAC and other lossless codecs, and therefore is better to use on battery-driven iPods etc.

Any truth to this?

Though the ALAC decoder in rockbox is based on reverse-engineered code, and is probably not as efficient as the FLAC decoder, the codec performance comparison shows that FLAC is more efficient than ALAC on rockbox by quite a margin.

Some people are saying on the MacRumors-forum that one of the reasons Apple developed ALAC was that it is less power-hungry than FLAC and other lossless codecs, and therefore is better to use on battery-driven iPods etc.

Any truth to this?

No that is nonsense.

Quote

Yes, but they're reverse-engineered codecs that are incomplete and not 100% compliant due to unknown or little-known syntax elements.

Yes, but they're reverse-engineered codecs that are incomplete and not 100% compliant due to unknown or little-known syntax elements.

Source? I haven't heard of this.

I know ffmpeg's reverse-engineered codec doesn't handle multichannel quite right. If you look at its source code, there's a 3-bit channels field on line 373, and a 3-bit "end-of-frame" marker on line 488. But that's actually the same 3-bit field. A value of 0 or 1 means to read another 1 or 2 channels, and a value of 7 means to stop reading frames and assemble all the channels read - a bit like how WavPack handles multichannel streams with its "initial block in sequence" and "final block in sequence" flags in the block headers.

Stuff like the decoding algorithms is likely correct, but it's good to have a reference implementation to check this sort of stuff against.

Within the audio domain, there are many possible subdomains. For example: low bitrate speech, high-bitrate multi-channel music, etc. FLAC itself does not target a specific subdomain but many of the default parameters of the reference encoder are tuned to CD-quality music data (i.e. 44.1kHz, 2 channel, 16 bits per sample). The effect of the encoding parameters on different kinds of audio data will be examined later. (Official FLAC FAQ)

Which one looks better?

Quote

The FLAC and Ogg FLAC formats themselves, and their specifications, are fully open to the public to be used for any purpose (the FLAC project reserves the right to set the FLAC specification and certify compliance).

FLAC is no industry standard. There is no committee, where interested parties could participate according to an open, defined protocol. It's just a bunch of guys who created a (good) format, gave it into the public domain, and now reserve the right to certify and shape the future of the standard.

Why should Apple accept the sovereignty of outside community developers to decide whether Apple products are FLAC compliant or not? Why should they let them decide how and when they want to support multichannel and additional bitrates and whether this breaks existing Apple compatibility. What about Apple users trying to use embedded cue-sheets with meta data, there is no unambiguous definition available.

Apple wants this to just work, without users having to think about the details. And I don't see them doing a bad job concerning ALAC.

Come on guys, stop complaining. Whatever the reason, we get a 100% open source and compatible ALAC codec from Apple itself.

Aside of WebKit (which wasn't really Apple's, to start with), I don't know of any successful Open source project comming from Apple. And as a counter argument, there is the example of Darwin / OpenDarwin (Which is delusional )

And I mean open source projects that have beneffited other than Apple itself, of course.(Most, if not all of the applications that Apple shows in open source that Mac OS includes is precisely open source projects *incorporated* into Mac OS).