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.

10 of 294 comments (clear)

  1. Pardon me for asking... by winstonmeister · · Score: 5, Interesting

    ...but I just don't see why Apple felt it was necessary to make another lossless format. While Apple in the past has been accused of often suffering from NIH (Not Invented Here) syndrome, it seemed like they were improving in this area: the iMac helped popularize USB, the open-source core of OS X has its roots in BSD, iTunes supports MP3s, their web browser gives source back to Konquerer, etc. Anyone have any theories as to why they didn't just use FLAC? After all, the work was already done for them...

    1. Re:Pardon me for asking... by crazney · · Score: 5, Informative

      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
    2. Re:Pardon me for asking... by Anonymous Coward · · Score: 5, Informative
      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

    3. Re:Pardon me for asking... by cbrocious · · Score: 5, Informative

      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.
    4. Re:Pardon me for asking... by DavidTC · · Score: 5, Informative
      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.

      --
      If corporations are people, aren't stockholders guilty of slavery?
  2. Small correction by bajo77 · · Score: 5, Informative

    This initial release is version is 0.1, not 1.0

  3. Re:Stream Ripping? by crazney · · Score: 5, Informative

    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
  4. Well, I won't use it by maynard · · Score: 5, Funny

    Because Apple is the New Microsoft. They use courts to squelch free speech rights of those who would impart Apple trade secrets to the public; they legally commit restraint of trade by mixing proprietary hardware with proprietary software so competitors can't break into their non-monopoly markets with alternative products; and they don't give all their code away for free, but instead select to give away or hold secret that which maximizes profit for their shareholders. Evil bastards! *cough!* --M

  5. How long before... by Foolomon · · Score: 5, Funny

    ...they combine the two formats to get the AFLAC format. "It's the format with additional benefits!"

  6. KAAAAAHHHNNN! by John+Fulmer · · Score: 5, Funny

    Hmph. I moved to a Mac mini a few weeks ago, and decided that I would finish up ripping all my CD's. Up to then, they had all been ripped as flac, and I was converting from flac -> ogg as necessary.

    Now, with iTunes on my main PC and my wife's laptop, i thought 'Wouldn't it be great if we could use a daap server and stream all our music?' So, I thought I would use iTunes to rip the rest of my cd's, and maybe convert my current flac files to ALAC. Then I could convert to ogg, and SURELY i could stream those.

    That's when the drums of doom started playing.

    First, I found that iTunes couldn't handle streaming off files. The Quicktime ogg plugin works okay for playing off the local hard drive, but no nice streaming from my daap server.

    No problem, I'll convert to AAC and stream those.

    (The drums started playing louder)

    Then, I found there is no way to really get iTunes to play or convert FLAC files. There's a plugin, but I can't for the life of me get it to work. And , I found there was no ALAC -> anything, so I ran the risk of being locked into a format that was non portable.

    No problem, I'll just find an opensource ripper to convert to FLAC, the to AAC.

    (The drums started playing MUCH louder)

    I started using 'abcde', a rather nifty shell script that rips and converts cd's to any of a number of formats, including FLAC. It even uses Freecddb for the track information.

    But... On OSX, the only real way to easily rip CD tracks is to copy the AIFF files that OSX presents to you when it mounts the audio CD.

    And FLAC does NOT like the particilar AIFF files OSX presents.

    (The drums are deafening)

    24 hours, a bunch of research and hacking on FLAC, I make a custom flac binaries that can handle the AIFF files. And there's the opensource 'faac' program that can convert the flac files to AAC.

    Except.... the AAC files faac creates can't be streamed or played by iTunes. Something about the MP4 headers faac generates aren't compatable.

    (THE DRUMS ARE IN MY HEAD!)

    Another 24 hours of researching, and I come up with the MPEG4IP project at Cisco, which has a nifty little program called 'mp4creator', which is designed to create or modify mp4 files. It has an '--optimize' function which modifies the headers of an existing .m4a (aac) file so something iTunes can handle.

    I threw everything into a script, and now I can rip files on my Mac mini, store them as FLAC, and then convert and play them as AAC/M4a files via iTunes.

    But Apple could have made things MUCH easier by making iTunes more open to other codecs or providing more information for others to creat iTunes codecs.

    And now I find someone has written an ALAC converter, so I could have used the ALAC format to being with.

    well THANK YOU. THANK YOU SO BLOODY MUCH!