Opensource Apple Lossless Decoder Released

Cody Brocious writes "David Hammerton has released version 1.0 of an ALAC decoder. This allows users of operating systems not supported by iTunes/QuickTime to listen to their Apple Lossless files, a proprietary competitor to FLAC. This is a large leap forward in audio codec interoperability, and paves the way for an ALAC encoder." The site also asks for additional help on the project.

Comments

Small correction

[bajo77]

This initial release is version is 0.1, not 1.0

Re:Stream Ripping?

[crazney]

Hey,

I'm the author of the decoder in quesiton.

I originally started doing the decoder so I could have my own little Airport Express emulator.

However, Apple have (for once) secured their system pretty well, and I have been unable to break their encryption so far. I know exactly what I need to do, and I'm fairly confident that I'll be able to do it... But first I actually need to get one of these devices.

So yeah, It's certinately on the table. Shouldn't be too far off.

Re:Pardon me for asking...

[SuperQ]

According to an article by a developer of the Rio Karma, they needed something that could be decoded by the iPod's CPU.

The Rev 1-3 iPods have a smaller CPU cache than the Rio Karma, or the iPod Rev 4 and the iPod Mini. The preformance hit for accessing memory while decoding is too great, so you must fit the decoder in the cache.

ALAC was designed for the simple reason that it has a smaller decoder on the iPod than FLAC.

Same reason why OGG can't be used on iPod Rev 1-3. (and for consistancy, not on the other two) Not enough CPU cache to decode.

Re:Pardon me for asking...

[mrchaotica]

In addition to SuperQ's answer regarding the iPod, they needed a codec that could be encoded in realtime, to work with the Airport Express. FLAC is significantly smaller, but it takes significantly longer to encode so it wasn't suitable for their purpose.

Re:Pardon me for asking...

[crazney]

I don't really believe that. As I mention on the web page, ALAC is very similar to FLAC - however it is slightly more complicated, not less. It requires more CPU power to decode ALAC than it does to decode FLAC. That said, it should generally have a better rate of compression.

If you think they've been doing that "lately",

[mcc]

Then you really weren't paying attention to Apple before that point where all the slashdot editors bought powerbooks. Apple Legal has always* fallen on any and all leaks in their wall of silence like rabid dogs on a barbeque-sauce-covered Pre-K student. It's just that the media's never actually paid attention before this latest event, so if you're only listening to the media it seems like this is a new development.

But as far as this project goes, if they performed their reverse engineering in a proper manner they shouldn't have anything to worry about.

* At least since Spindler left. But even before that Apple Legal wasn't nice

Re:Pardon me for asking...

[damiam]

Same reason why OGG can't be used on iPod Rev 1-3

I wouldn't say that quite so authoritatively. At the moment, the reason Vorbis can't be played on the ipod is because no one's put much effort into optimizing the decoder. It may be that it's impossible, but I've heard several Vorbis and iPodLinux developers say they think the iPod has the potential to play Vorbis, albeit maybe with reduced battery life.

Re:Stream Ripping?

[crazney]

Nope. That's the public key that's been hacked - that lets you encrypt data. Decrypting data requires the private key. This has not been hacked yet.

David

Re:questions

[cbrocious]

Not yet. There are people working to integrate it into ffmpeg/libavcodec... from there it should work in MPlayer at least.

Re:Pardon me for asking...

[Anonymous Coward]

I don't really believe that. As I mention on the web page, ALAC is very similar to FLAC - however it is slightly more complicated, not less. It requires more CPU power to decode ALAC than it does to decode FLAC. That said, it should generally have a better rate of compression.

Huh? Comparison tests have found that ALAC compression is, on average, slightly worse than FLAC.

http://members.home.nl/w.speek/comparison.htm
http://flac.sourceforge.net/comparison.html

Re:Let us rejoice!

[znu]

I get so tired of people misunderstanding QuickTime.

QuickTime is not a codec. It's a media architecture. The MOV file format can theoretically embed arbitrary numbers of tracks (of audio, video, 3D, animated sprites, vector graphics) in any format, and QuickTime supports several dozen formats of various sorts out of the box. ALAC, like every other codec Apple implements on OS X, is just a QuickTime plugin.

Not much of the QuickTime content you find around the web uses it, though, so I don't see how this is going to help QuickTime movie playback on Linux much. But Apple is really pushing MPEG-4 these days, so if Linux has a good MPEG-4 implementation, compatibility problems should go away eventually.

Re:Pardon me for asking...

[cbrocious]

You're very, very far off.

ALAC has absolutely nothing to do with the MPEG-4 lossless encoding. (I should know, as I worked on the decoder as well. See the authors list on the site)
This is a common misconception that having an opensource decoder (and encoder soon... I have a prototype already) will hopefully fix.

Honest answer

[mcc]

Nah. "Proprietary format" just means "the real world doesn't know how to decode it yet". There isn't some inherent right for proprietary formats to remain proprietary.

There are only a handful of ways a proprietary format can remain proprietary:

1. License agreements. This is the most common one, and almost certainly Apple is using this one. The idea is that if you give someone a document describing how your formats work you say "if you don't agree to use this information only in certain ways you can't have it", or if you give someone a decoder for the format you say "if you don't agree not to take apart this decoder and see how it works you can't have it". I'd guess the iTunes clickthrough agreement says something like the latter. But this is sort of the entire idea of cleanroom reverse engineering; license agreements like those on iTunes really are no hindrance whatsoever to a reverse engineer, so long as they choose to do that reverse engineering in a way that doesn't violate the license agreement. And that's not really that hard. Pretty much just don't use a disassembler and you're fine.
2. Patents. I'm pretty sure this one really doesn't work. As far as I am aware-- I can't find an explicit cite for this in a brief google search, maybe someone else can give us one-- reverse engineered implementations created for purposes of compatibility can provide protection against patent claims. Since "formats" and "compatibility" are almost the same word, this makes it often implausible to use patents as a block on unauthorized use or interpretation of a format, such as an audio codec or a video game API. Apple probably has some sort of patent on ALAC-- like all research-oriented commercial software developers, they patent absolutely everything they do-- but I've never known Apple to use patents in this exact fashion and as far as I can tell their success would be incredibly questionable even if they tried. I'd ask the guy who reverse engineered the decoder to look through apple's entries in the USPTO database to see if he can find anything that might refer to ALAC, but he really shouldn't, since hilariously you're safer from patent damage claims if you culture a state of blissful ignorance as to what patents exist out there.
3. The Digital Millennium Copyright Act. This one is scary, as it grants powers which are essentially stronger than copyrights or patents to anyone who can construe what they do as involving in some way "DRM". The DMCA seems to assert that "mechanisms which effectively control access to a copyrighted work" have some sort of inherent right to remain unbroken. This seems to imply people with proprietary formats do have a right to keep them proprietary so long as they can pretend there's "DRM" in it. However there's a few problems here. It has been questioned whether the nature and implementation of the law is enforceable against a serious challenge, and some uses of the law-- for example putting some kind of "DRM" in a printer cartridge and then using the DMCA to shut down anyone who makes compatible printer cartridges-- have already been smacked down by the courts. Apple has already used the DMCA to keep down software which removes the "DRM" from iTunes Music Store purchases, though the best they can do is force that software to use hosting providers outside the U.S.. But, well, even though the law is wrong, that's actually sort of exactly what the letter and intent of the law are intended to do-- protect things like Fairplay. But attacking unauthorized use of ALAC would follow neither. Attempting to claim ALAC is covered by the DMCA is simply laughable; as has been observed elsewhere in this discussion, it is not and does not contain "DRM" and it provides no limitations on the flow of copyrighted material whatsoever.
4. Technical barriers. The idea here is, as Microsoft does with SMB or Word, you design your format in such a way as to naturally resist reverse engineering. This is sort of a moot point with ALAC. The decoder's alre

Re:Pardon me for asking...

[DavidTC]

To keep people from having to read that, FLAC is not significantly smaller (1), but a hell of a lot faster if you use it right.

The important stats:
FLAC at 8 took 55:02 to encode, 7:07 to decode, at a ratio of 1:0.5437.

ALAC took 19:53 to encode, and 10:01 to decode, at a ratio of 1:0.5496.

So, yes, FLAC at the tightest takes much longer than ALAC. (Alghought it's only 3/4th the CPU to play!)

However FLAC at 5 took 12:54 to encode and 7:08 to decode, at a ration of 1:0.5459. Much faster than ALAC, barely smaller, and decodes much easier than ALAC.

So, yes, if you ramp FLAC all the way up it takes much longer to encode, and slightly longer to decode, and you don't gain anything. So obviously doing that is a bit silly unless you're talking about long term storage.

If you leave it at the default, though, it beats ALAC in every single way, unless there's some differences in CPU architechure that changes the relative decoding difficulties between an iPod and a PC. Which isn't that impossible. But I have to point out that a lot of people use iTunes sans iPod, on a PC.

1) No lossless compression is significantly smaller than anything else. All the serious contenders are between 1:0.56 and 1:0.48 or so.