Slashdot Mirror
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.
This initial release is version is 0.1, not 1.0
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.
stuff
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.
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.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
stuff
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
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
ALAC is different. Apple needed it because FLAC is too good -- it takes too much time/CPU power to encode. I think they would have used FLAC if they could have, but it's too heavy to work in the (original) iPod and the Airport Express.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
That's a lie.
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
stuff
Not yet. There are people working to integrate it into ffmpeg/libavcodec... from there it should work in MPlayer at least.
Disconnect and self-destruct, one bullet at a time.
http://members.home.nl/w.speek/comparison.htm
http://flac.sourceforge.net/comparison.html
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.
This space unintentionally left unblank.
How exactly does a company avoid patent infringment by writing their own code, instead of using and contributing to someone elses code? Apple could well be infringing on any number of patents with ALAC (Not that I think they are), just as easily as they could with FLAC (Again, not that I think FLAC infringes). In todays climate, any code can easily infringe and large companies like Apple have legal departments whos job it is to perform patent searches for any code they're working on. It is just as easy to perform a search on a peice of Open Source code as it is on their own in house code.
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.
Disconnect and self-destruct, one bullet at a time.
There are only a handful of ways a proprietary format can remain proprietary:
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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.
If corporations are people, aren't stockholders guilty of slavery?
Go ahead and name the patents and copyrights that have been violated
...
+ Patents on MPEG-2 and MPEG-4 audio and video
+ MP3 patents
+ Micrsoft WMV patents
+ Micrsoft codec bundle, warez download from the mplayer site
+ Real codec bundle, warez download from the mplayer site
+ Apple codec bundle
Not so hard.
They needed cheap transcoding to a lossless format for the AirPort Express. Read the streaming sound section of this article.
I have a website. It's about Macs.
FLAC is too good -- it takes too much time/CPU power to encode.
Not quite according to this post. Do you have any references that say otherwise? I've never used ALAC myself so I can not comment.
Bad boys rape our young girls but Violet gives willingly.
Go to MacUpdate to download the plugin if you don't have it.
It's also worth noting that if you convert the FLAC files into WMA lossless, iTunes will convert them automatically for you into ALAC (apple lossess) and preserve tag information.
You might want to look into Air Foil. It allows you to stream any audio to AP Express.
It's OS X only at this point, unfortunately for users of other OSes.
It's not offtopic, dumbass. It's orthogonal.
Of course, I don't know if the cores are symmetric, and I think the iPod Linux stuff only supports the primary core, so in its current state, no, it probably isn't possible....
At least conceptually, to get decent performance you want to do something like the following:
- Set up a worker thread on the main core (under Linux or whatever) that fetches blocks from the disk and places them in a ring buffer at a fixed memory location.
- Halt the second core, load a program into memory that does the decoding of a particular audio type from the ring buffer, set the PC of the second core to that program, and run it.
- The second core will shove raw audio data at the hardware, or if it can't access the hardware directly (not sure), you might end up doing a second ring buffer.
- Power manage the heck out of the primary core. Nap it unless it is doing something.
Once you get that working, -then- work on real-time Ogg decoding. It should be a lot easier to get real-time decoding if you aren't trying to do all your work on a single core....Check out my sci-fi/humor trilogy at PatriotsBooks.
Look, you crazed Apple fag... as has already been pointed out, ALAC uses more CPU and memory than FLAC. Apple did it so they can control the format -- ala Microsoft. Get over it.