Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Opensource Apple Lossless Decoder Released

Posted by Zonk on Sat Mar 05, 2005 03:36 PM
from the alternate-options dept.
Businesses Media Music Apple
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.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Opensource Apple Lossless Decoder Released 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Pardon me for asking... (Score:5, Interesting)

    by winstonmeister (863683) on Saturday March 05 2005, @03:39PM (#11854445)
    ...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...

    • Re:Pardon me for asking... (Score:3, Informative)

      by SuperQ (431) *
      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 o

      • Re:Pardon me for asking... (Score:5, Informative)

        by crazney (194622) on Saturday March 05 2005, @03:51PM (#11854550) Homepage Journal
        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.

        • Re:Pardon me for asking... (Score:5, Informative)

          by Anonymous Coward on Saturday March 05 2005, @05:04PM (#11854960)
          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 [members.home.nl]
          http://flac.sourceforge.net/comparison.html [sourceforge.net]

        • Optimizing at a level that low is counter-intuitive. An algorithm that's more "complicated" might take up less memory or have a more favorable memory access pattern. For example, and I have no idea of the difference between FLAC and ALAC so this is just an example, if a more complicated algorithm has a larger number of stages but they all fit in cache when they're running, it could easily perform better.

          For example, Google for "AlphaSort". Basically, they made a mutli-phase sort where the initial stage fit

          • Re:Pardon me for asking... (Score:5, Informative)

            by cbrocious (764766) on Saturday March 05 2005, @05:36PM (#11855178) Homepage
            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.

          • AirTunes. (Score:3, Interesting)

            by Yaztromo (655250)

            Why bother with reverse engineering ALAC? So far, I have seen / read mention of only one major useful thing that has been learned: ALAC uses adaptive compression algorithms.

            One possible reason would be in order to stream to an AirPort Express with AirTunes. AirTunes uses a standard streaming protocol (RTSP), but streams the data in Apple Lossless format. Because of this, you currently require either a Mac OS X or Windows XP machine running iTunes to steam audio to the AirPort Express.

            Being able to st

      • Re:Pardon me for asking... (Score:5, Informative)

        by damiam (409504) on Saturday March 05 2005, @04:06PM (#11854619)
        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.

        • Two 70 MHz ARM cores. Yeah, should be more than three times the horsepower needed. Reportedly, Tremor can function in as slow as a single 40 MHz core.

          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:

          1. Set up a worker thread on the main core (under Linux or whatever) that fetches block
        • Because the iPod was designed to have just enough CPU power to do what it was designed to do: play MP3s. (In retrospect this was not a smart decision, but most embedded devices don't plan for future upgrades either.) The other codecs were added years later.
            • Actually, the argument that it was designed to have "just enough" CPU power is flawed. The argument, as you reworded it, that Apple uses "just enough" power is, oddly enough, precisely correct, I think. Very fine line.

              ...as in power management.... While the CPU can probably do some serious work at full throttle, there's always a tradeoff between that and battery life.

    • Re:Pardon me for asking... (Score:4, Insightful)

      by gl4ss (559668) on Saturday March 05 2005, @03:49PM (#11854529) Homepage Journal
      there's a better reason than the already mentioned ipod cpu..

      now it's their format - possibly with a compression scheme they got a patent going for, so they own it.

      why did sony keep insisting on atrac so long? because it was their format, their control. if it had made it big then they could have cashed on it.

      true, itunes supports mp3's and ipods do as well - but they have to, nobody would have used them otherwise.

      • Doesn't really compare (Score:3, Insightful)

        by mcc (14761)
        Sony freaks out on their formats because they actually have some kind of power they can gain from those formats. They have an agenda. For example they wanted to turn ATRAC or Minidisc or whatever into a distribution format, one that other people used but that they controlled. They wanted to supplant mp3 and then leverage this to pressure people into using other Sony products. They wanted to control distribution.

        But ALAC isn't even intended or positioned for distribution. There's no power in it. ALACs are c

    • Re:Pardon me for asking... (Score:5, Informative)

      by mrchaotica (681592) on Saturday March 05 2005, @03:51PM (#11854548)
      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.
      • Huh? I could encode flac at over 15x realtime on my old Athlon 900.

        • Dude (Score:3, Funny)

          by Anonymous Coward
          The Airport Express is a router. I don't think it has an Athlon 900

        • Re:Pardon me for asking... (Score:5, Informative)

          by DavidTC (10147) <{moc.xobreven} {ta} {vidav.vidav.hgfdls}> on Saturday March 05 2005, @06:05PM (#11855345) Homepage
          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.

    • They needed cheap transcoding to a lossless format for the AirPort Express. Read the streaming sound section of this article [macdevcenter.com].

  • Yes but... (Score:5, Interesting)

    by FiReaNGeL (312636) <(fireang3l) (at) (hotmail.com)> on Saturday March 05 2005, @03:39PM (#11854454) Homepage
    Will he get sued? Proprietary format... Apple... Lawsuits...

    Also, considering that "Apple never released any documents on the format", its incredible that this guy wrote a decoder. Some people are truly amazing sometimes...

    • Honest answer (Score:5, Informative)

      by mcc (14761) <amcclure@purdue.edu> on Saturday March 05 2005, @05:47PM (#11855261) Homepage
      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

  • Small correction (Score:5, Informative)

    by bajo77 (632115) on Saturday March 05 2005, @03:40PM (#11854459)
    This initial release is version is 0.1, not 1.0

  • though, is it patent encumbered? (Score:4, Insightful)

    by gl4ss (559668) on Saturday March 05 2005, @03:40PM (#11854465) Homepage Journal
    gif-like, could i use it in a real project?

  • Stream Ripping? (Score:4, Interesting)

    by CtrlPhreak (226872) on Saturday March 05 2005, @03:41PM (#11854470) Homepage
    As I understand it, all the wireless Airport express streams use apple lossless codecs. How long before we can have a program to intercept these wireless music streams and then convert to mp3s or whatever you want? Pretty crappy way of getting music, slow etc the more I think about it, but why not?

    • Re:Stream Ripping? (Score:5, Informative)

      by crazney (194622) on Saturday March 05 2005, @03:44PM (#11854495) Homepage Journal
      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. [craz.net]

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

        • Re:Stream Ripping? (Score:3, Interesting)

          by crazney (194622)
          That's not at all true, the only reason I want it for is entirely legitimate.

          I have all my music stored in iTunes, and I'd like to be able to play them on a 'remote speaker'. The remote speaker in question is my media server, connected to my stereo.

          All the computers in my house I have access to, and none of them are DRM-protected music (ie, iTMS purchased music). So there is no reason for me to want to use Airport Express data for any sort of piracy.

            • Re:Stream Ripping? (Score:3, Insightful)

              by crazney (194622)
              I have music in iTunes because that way I can easily sync to my ipod, it's also the best software available to organise music collections.

              Will we ban knives because they are a tool for killing people, and killing people is illegal?

              There is a fine line. If a tool has significant legal (and moral) uses, I see no problem with it.

                • Re:Stream Ripping? (Score:3, Insightful)

                  by 2TecTom (311314)
                  OMG. dood, are you for real? If anyone sucks, well... Actually, the real and only reason for hacking DRM, and the one you are ignoring, is to counter the power that these corrupt corporations have given themselves contrary to the common good. Go ahead, justify greed all you want, however, all it looks like to me, and others, is a closed mind standing by unquestioned assumptions and self serving beliefs.

                  First off, just because it's the "law" doesn't ensure that it's the right or "ethical" thing to do. For i

  • Well, I won't use it (Score:5, Funny)

    by maynard (3337) <.j.maynard.gelinas. .at. .gmail.com.> on Saturday March 05 2005, @03:47PM (#11854522) Homepage Journal
    Because Apple is the New Microsoft [slashdot.org]. 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

  • ALAC on linux, finally (Score:4, Interesting)

    by KingOfTheNerds (706852) on Saturday March 05 2005, @03:54PM (#11854566) Homepage
    We used ALAC all the time at the studio where I worked, but alas, some of our software was linux only and would not compile under OS X. This was very frustrating and required multiple computers. Finally with this system we can move over to this software as a solution. I love linux and would rather use it, but of the people I work with don't want to learn it claiming that it is more complex. Anyway, thats great that we can do the job with ALAC decoder! I'm sure other studios forced to use ALAC will be very happy with all of this.

  • Gstreamer + iTMS (Score:3, Interesting)

    by Goalie_Ca (584234) on Saturday March 05 2005, @04:09PM (#11854640)
    If you're a gnome user you should probably check up on Planet Gnome [gnome.org]. Here's one blog [advogato.org] in particular that may be of interrest.

  • Nice. (Score:3, Interesting)

    by theparanoidcynic (705438) on Saturday March 05 2005, @04:31PM (#11854758)
    I was just thinking this morning how nice it would be if both my iPod and my Linux boxen supported a lossless format besides uncompressed PCM, and here's the solution.

    Desire warping reality? Nah, if my desires warped reality I wouldn't be quite as single. ;)

    Regardless, my compliments on a superb piece of hacking. As near as I can tell the thing works perfectly, and only a few months after Apple released the format.

    I assume that somebody will whip up an XMMS plugin based on the library and/or get it into Mplayer's CVS over the next week or so, but even being able to do "alac file | aplay" is a great improvement in functionality for me.

  • How long before... (Score:5, Funny)

    by Foolomon (855512) on Saturday March 05 2005, @04:49PM (#11854874) Homepage
    ...they combine the two formats to get the AFLAC format. "It's the format with additional benefits!"

  • Why they use their own format. (Score:3, Insightful)

    by stephenisu (580105) on Saturday March 05 2005, @04:59PM (#11854915)
    When you have many embedded devices to program for, it is convenient to have control over the future of the CODEC you are using.

    While FLAC is great, Apple has no controll over what direction FLAC takes.

  • KAAAAAHHHNNN! (Score:5, Funny)

    by John Fulmer (5840) on Saturday March 05 2005, @05:54PM (#11855294)
    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!

    • FLAC quicktime plugin (Score:3, Informative)

      by Qwerpafw (315600)
      I posted a simple guide on Mac Update to using the Quicktime FLAC plugin. I'm working on an Applescript to simplify the process of batch converting FLAC files into various AAC/MP4 files (without QTpro or iTunes) and still preserve the tag information, but I haven't quite ironed out the kinks (it crashes with some tag info, for some reason).

      Go to MacUpdate [macupdate.com] to download the plugin if you don't have it.

      (1) Once you've downloaded and uncompressed the file, you'll see two items in the plugin folder. One

    • If you had used Windows or a Mac, or had used someone else's Mac, then you would need this encoder. The guys who helped make this encoder spent months working on this project, and continue to work on it. This might help push more people to use linux (to switch) and have more univeral applications.
    • I have a Mac as well as several Linux machines, and an ALACFLAC conversion tool would be great for me.

      I actually thought about writing one myself by hooking into Quicktime, but I never got around to learning the API.
    • 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.

    • Re:questions (Score:3, Informative)

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

    • Re:Great applications with high quality audio (Score:4, Interesting)

      by jbn-o (555068) <mail@digitalcitizen.info> on Saturday March 05 2005, @05:08PM (#11854982) Homepage

      Sounds to me like a justification to make and distribute a free software FLAC QuickTime plugin so our friends burdened with the proprietary QuickTime implementation Apple distributes can play streaming FLAC data or play FLAC files.

      I see no technical justification of Apple's Lossless format that convinces me it is superior to FLAC (of course, since Apple's Lossless format is only available in proprietary software, it will always lose for those that care about software freedom). Yet I'm sure people will use it and encourage others to use it because it is distributed with their proprietary software. In this way, it reminds me of the odd stance some people take with Ogg Vorbis versus MP3--they know that the Vorbis codec has performed at least as well as MP3 in many listening tests, they acknowledge that Ogg is a better encapsulation format (allowing for more expressive tags, for instance), and they insist on using "the best tool for the job". But they cave in to popular pressure to conform to using a lesser "tool" and endorse the continued use of MP3, sometimes even exclusively (which is really silly).

      I hope nobody interprets what I'm writing as though this takes away from this new BSD-licensed Apple Lossless decoder. I'm grateful for what has been done here--it was needed and it is a great contribution to the free software community. I think there's a great future for it at archive.org in case anyone submits audio encoded with Apple's Lossless codec. This could allow archive.org to decode that and re-encode it with something else (many archive.org recordings are encoded many ways). However, when I distribute losslessly encoded copies of audio, I'll continue to dismiss Apple's Lossless codec out of hand and prefer FLAC. I help manage the website for a locally-produced talk radio show called "News from Neptune [newsfromneptune.com]" and there you can find copies of the show encoded in FLAC, Ogg Vorbis, and Speex. FLAC serves our needs excellently.

        • Re:Let us rejoice! (Score:4, Informative)

          by znu (31198) <znu@acedsl.com> on Saturday March 05 2005, @05:08PM (#11854986)
          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:Apple Lossless a competitor to FLAC? (Score:5, Insightful)

      by 808140 (808140) on Saturday March 05 2005, @08:05PM (#11856046)
      I don't think so. The truth is, most people who play music on their computer don't know the difference between lossless and lossy, and usually still don't get it very well even after you try to explain it to them. To them, music is mp3, although they may be vaguely aware of other formats such as wma and perhaps (if they own an iPod) AAC.

      The people who use lossless encoding and understand what it is and what its benefits are are a much more technical crowd.

      So while the Mac fanatics will of course use Apple Lossless because it's produced by Apple, many other people already have most of their CD collection encoded in FLAC and are probably happy with FLAC's less (not?) patent-encumbered, open source nature.

      You know, open formats and all that.

      I personally wouldn't even consider Apple Lossless. FLAC is an open, documented format with encoders and decoders that work on every platform imagineable. Not only that, but FLAC is a very competitive format, being as good or better on average than essentially any other lossless format out there for most samples.

      Simply put, FLAC is a well known and trusted brand among people that know about lossless audio compression, why it's good, and why they should use it. Apple lossless is some other proprietary format that might (due to patents, for example) eventually require a license to be able to legally decode.

      And I think I speak for most people that have already encoded hundreds of CDs losslessly for convenience and storage when I say, thanks, but no thanks.

      Free Software for me.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.