It's almost identical to the already open source and very widely used FLAC codec.
Cupertino has open sourced its Apple Lossless Audio Codec (ALAC), seven years after first introducing it. The ALAC can reduce the amount of storage needed for audio files by as much as 50 per cent, but without losing any of the fidelity of the original recording. This is unlike lossy formats like MP3 and AAC, which strip out …
… but FLAC has a lot more hardware support than ALAC.
- Apple iPod
- Apple iPhone
- Apple iPad
maybe a few others…
The thing is, most people who listen to music (on the move, at least) have one of the first three devices you mention. Which don't support FLAC.
The huge numbers of FLAC supporting hardware are actually in the minority.
Not that I think ALAC being open source is a particularly big deal. The massive majority of people couldn't care less if their music was lossless of 128kbit MP3, and I doubt many of them could tell the difference.
@RichyS: "most people who listen to music (on the move, at least) have one of the first three devices you mention"
Most people who listen to music have an Apple iSomething? I hear tell that there are a handful of folks in Africa, Asia, and some of our other fine continents who 1) don't have the disposable income for things like a regular supply of electricity, but 2) nonetheless listen to music.
I suppose for the typical Reg commentator, "most people" really means "most people who matter, or in other words most people who are very much like me".
For that matter, even some of us rich white dudes don't own any Apple crap. Why bother, when there are alternatives that don't come with an Apple-brand surcharge?
You just hit on a very pertinent point… most of those Apple music device users are content, with AAC or MP3… quite a number are blissfully unaware what their devices use.
So FLAC, ALAC? Same as MP3 right?
The technically minded would either have come to the decision they don't care — non-noise cancelling moderate quality earbuds and ambient noise would make it very difficult to pick the difference. Those that do care, would probably have voted with their wallet, or looked at alternative firmware such as Rockbox to give them cross-device lossless audio anyway.
It's been reverse engineered for so long, it makes sense to open it up. ALAC does have advantages over FLAC - particularly that ALAC files are less processor-intensive to decode than FLAC files.
Now, the next step is to get the embedded system-on-chip guys to implement it. FLAC is already on most streamers, adding ALAC would open the market to iTunes-using audiophiles.
You say that ALAC is less processor-intensive than FLAC. However, the hydrogenaudio.org wiki page[*] comparing lossless formats rates FLAC decoding as "very fast" whereas ALAC only gets a "fast" rating. If the best advantage you can come up with is actually not in ALAC's favour at all, then why would I want to use ALAC over FLAC? Or do you have some other evidence to support the claim that ALAC is less processor-intensive?
Something that wasn't mentioned in the article was whether Apple claims to have any patents covering ALAC. I'd be very interested in finding out whether they do. I find it quite hard to believe that there aren't some strings attached to this freeing up of the format. TBH, though, even if they'd released it under something like GPL3 with a "no patent" slant, I doubt there'd be any incentive for the majority of people to switch from FLAC to ALAC...
The Apache license Apple used includes a patent grant clause, so yes it's pretty much no strings attached.
I remember seeing that page a few days ago and it matched with what I remembered seeing when I was in the market for a new lossless format a few years ago. But I thought I'd do a test with a few of the CDs I have in lossless format.
I picked 5 CDs, mostly randomly, with one from each of five types of music, just to see if some codecs performed better on different types of music. I compressed each of the five CDs by tracks with a bunch of tag info on each track. I used ALAC, FLAC: Level 0, FLAC: Level 5, FLAC: Level 8 and wave formats for each disc.
Genre ........ Artist/Album Name .................................................. Run Time ........ # of Tracks
Classical ... Brahms: Symphony #1 ............................................ 1:07:55 ............ 5
New Age .... Arkenstone: In the Wake of the Wind ....................... 1:00:58 ............ 16
Piano ........ Mozart: Piano Sonata in B-flat Major & C Minor ........ 57:44 ............... 7
Pop ........... Branch: The Spirit Room ........................................ 42:25 ............... 11
Rock ......... KoRn: Issues .......................................................... 53:17 ............... 16
The size was a simple check to see how large Win7 reported the files as. The simpler the type of music, the better it compresses apparently. Overall, the four compression algorithms are close together in size. Sensibly, FLAC level 8 had the best compression and FLAC level 0 had the worst. ALAC was about halfway between the FLAC algorithms. FLAC 5 performed comparably to FLAC 8 with only 1-2MB of difference between them.
Size ........ ALAC .... % ...... FLAC(0) .. % ...... FLAC(5) .. % ..... FLAC(8) .. % ..... WAVE
Classical . 294 MB . 43% ... 303 MB ... 44% ... 289 MB .. 42% .. 288 MB ... 42% .. 685 MB
New Age .. 331 MB . 54% ... 342 MB ... 56% ... 320 MB .. 52% .. 318 MB ... 52% .. 615 MB
Piano ...... 196 MB . 34% ... 198 MB ... 34% ... 182 MB .. 31% .. 180 MB ... 31% .. 582 MB
Pop ......... 311 MB . 72% ... 324 MB ... 76% ... 301 MB .. 70% .. 300 MB ... 70% .. 429 MB
Rock ....... 378 MB . 70% ... 391 MB ... 73% ... 361 MB .. 67% .. 359 MB ... 67% .. 537 MB
Total .......1510 MB . 53% . 1558 MB ... 55% . 1453 MB .. 51% . 1445 MB ... 51% . 2848 MB
The speed test checked to see how fast the entire disc could be decoded. I used dbPowerAmp's "Test Conversion" with no speed limit and highest quality decoding selected. Each set of files was decoded once (I'm lazy and didn't want to sit here 'till morning). Computer is a C2D 2.53GHz with 8GB RAM and a 160GB 5400 RPM 8MB disk drive. This time, ALAC consistantly came out well ahead, though the FLAC versions didn't take too much longer to decode. The FLAC versions seem to require about the same amount of time to decode. On none of the tests did any of the decompressions force the CPU above 90% or above 33% RAM usage. Generally, the decoders stayed around 15-25% CPU usage, though ALAC used 45% to decode the Piano disc. From the looks of it, the bottleneck for both algorithms is the hard drive. Still ALAC decoded faster, which is probably due to the simpler codec
Speed ........ ALAC ...... FLAC (0) ....... FLAC (5) ....... FLAC (8) ....... WAVE
Classical .... 24 s ......... 46 s .............. 33 s .............. 55 s .............. 47 s*
New Age ..... 29 s ......... 37 s .............. 37 s .............. 33 s .............. 48 s*
Piano ......... 17 s ......... 19 s .............. 18 s .............. 22 s .............. 47 s
Pop ............ 24 s ......... 33 s .............. 33 s .............. 33 s .............. 33 s
Rock .......... 32 s .......... 44 s ............. 41 s .............. 40 s .............. 38 s
Total ..........126 s ........ 179 s ........... 162 s ............. 183 s ............ 213 s
* The first two tests for wave decoding completed in a mere 2s and 4s, so they were repeated.
Really, I wouldn't suggest that someone choose between either of these codecs based on the compression size or speed. They're both reasonably close from a practical standpoint. The best reason to choose one over the other is probably which format your devices / OS already have good support for. As other people have pointed out, Apple's iOS devices don't play FLAC media, and ALAC support can be pretty scarse outside of Apple. The one other drawback I can think of, is that many of the existing non-Apple decoders for ALAC don't support high-resolution audio yet. So, if you have DVD-audio discs or HDCDs, you're probably better off with FLAC for now. If you really need to save drive space for your entire collection, you're better off looking at the ape or tak formats instead. Both of those produce smaller file sizes, though they're not as popular right now.
Good post on the benches of various settings of the two options (ALAC and FLAC) although 2 things do come to mind here.
1) Let us know if we are about to hit the wall.
2) Formatting, formatting, formatting. The post had me trying to read the lines properly and failing each time for a moment.
@El Reg - Can we get a Great Wall of Text icon please?
RE: 
They released it under Apache 2, which includes a patent grant, so no issue there.
As to processor-intensiveness, yep, ALAC is generally seen as being worse than FLAC. ALAC's main advantage over FLAC (besides being supported on all 250million iOS devices; first-party support for FLAC is pretty rare, though I think Android 4.0 will include it), is that it's a bit more tolerant of data corruption.
good only for win7 benchmark?
Your benchmark essentially contradicts http://flac.sourceforge.net/comparison.html , where it provides these figures, in particular:
Codec Total CPU Total CPU Size Avg.ratio
FLAC 1.2.1 (-3) 7:23.77 3:47.42 5:31.15 2:19.07 412.42 MB 54.57%
Apple Lossless (iTunes 4.5) 19:53.27 19:53.27 10:01.86 10:01.86 414.45 MB 54.96%
So, compared to ALAC., when encoding to the codec, FLAC takes about 3 times shorter (7:30 min vs. 20 min) with roughly the same compression ratio.
I myself use shntools backend (Linux/FreeBSD) for all of my encodings and find FLAC to be great and better than ape. Nowadays all decent music players consume close to non CPU to play flac (reasonable default ratio).
Right now with clementine listening to flac encoded "Concerto pour violon n° 12 en mi majeur RV265 - I. Allegro". It occupies 2% cpu time + 5% of 1.5 GB RAM (with 219G mostly in flac music collection! ) on 64bit Ubuntu LTS, Pentium 4 CPU 3.00GHz.
Even cut and paste into notepad fails to align the collumns
Thanks for posting the numbers - I'd read similar tests back when ALAC was new, and the difference was greater then. ALAC's advantage is in lower decoding complexity, but you pay for it with a slightly larger file. On a portable music player, conserving battery life was (and is) more pressing than storage space, so this was a big deal at the time. FLAC's decode performance has improved a lot in the intervening years, and now there's not a whole lot of difference between the two.
Still, some people just don't like to see anything good said about Apple, and others don't like anything bad said against open source software...
Nero's free encoder..
Already does an excellent job generating either AAC lossy or ALAC lossless files.
Smart move by Apple though.
Although it doesn't have a great deal of impact personally, I applaud this unexpectedly altruistic move.
Who would have thunk.
Either they didn't patent ALAC, or their patent is nearing expiration.
It's hardly altruistic; they're trying to do battle with FLAC which is dominant outside of Apple. I'd be more impressed if Apple finally added support for FLAC in iTunes and iPods, which is long overdue.
ATRAC Advanced Lossless was nice, tho I dont think it was unspun when they ditched the format a few years back. Afterwhich I just decided on 320 mp3 for everything, if I want the full experience I'll put the CD in the CD Player. Handy thing, physical media :)
"if I want the full experience I'll put the CD in the CD Player"
You still have a CD player? How quaint :) All my CD collection is in FLAC on a RAID hard disk, protected against fire (many of the CDs are now out of print, irreplaceable).
ps: 'Medieval CUE Splitter' makes FLAC archiving really easy... I use CDex to RIP the whole CD side to a FLAC file. It takes about 3-4 minutes a CD..
What is this C-D you speak of? Can you torrent that?
Though I do have a vague and distant memory of a company called A-O-L burying me in free ones..
CDs? How modern!
I still use LPs!
Backed up on FLAC and Vorbis however. ;-)
Why do people rip FLAC into a big single file? What is wrong with separate files for all the songs like an mp3? Who wants one giant file with a cue sheet? Stupid if you ask me.
Haves vs Have Nots
I still have a CD player too. It's almost a requirement since I don't own any form of portable music player. Though I do have the collection ripped to mp3 for a computer attached to my home stereo. I can live with the loss at 320kbps. My mp3s also reside in a RAID hard disk configuration, though that offers zero protection against fire as I haven't found a fireproof computer case yet.
Yes, I'm still part of that ever decreasing group that likes to have physical media for things I purchase. Accidents can happen, no matter how rare (fire, lightning, and various forms of human stupidity, etc). For music that I purchase online, it gets burnt off as an audio CD as well. I stick with the mp3 format because I plan on replacing a couple of car stereos with newer ones that have USB ports and mp3 compatibility, and my home stereo is not impressive enough to notice the loss at 320kbps.
Cool, a couple of years ago I made the decision to rip all my CDs to FLAC as a "gold" reference, it being the only open lossless solution. This has meant running a FLAC capable, transcoding DAAP server (Firefly & now forked-daapd) behind iTunes.
ALAC might make life a little simpler but I like a challenge & I've a number of (legitimate) FLAC media sources now.
Choice is good. If I care to burn a few days CPU cycles & help heat the house I could transcode all from FLAC to ALAC.
Given Apples miserly record ...
one has to wonder if Saint Tim has lost his marbles?
Apple rarely gives much away, unless there is an ulterior motive.
You won't hear much about it, but Apple are a pretty big supporter of open-source projects - GCC, LLVM clang, WebKit, CUPS, ZeroConf (Bonjour) are the ones that come to the top of my head. The OS X kernel is also open sourced, but as most people run Linux, it's hardly a mainstream project.
I'm not saying that they're the only contributor to these projects, but their contributions are significant. WebKit and CUPS in particular have benefitted greatly from Apple's efforts.
If you don't like commercial companies benefitting from open source software, you should re-read Stallman's justifications for the GNU project again. It's precisely the situation he envisaged - system vendors contribute to open source OS components, which other vendors can use as well - in the case of WebKit, both Nokia (who, in fairness have contributed as much to the project as Apple) and Google (who, well.. haven't) compete with Apple in the mobile market, using the same browser engine in their products.
It's not in Apple's interest to *tell* the public that it uses open-source software, but they do contribute because *doing* it is in their interest. Contrast that to Google, who never shut up about how much they support open-source software, but once you dig into it, the story gets less believable.
Are you sure?
Have you seen how many open standards Apple have contributed to? And how much open source software has Apple's dabs on it?
is the open source community. Lots of Apple code out there, this is just another on a big pile.
Apple is still primarily a hardware business.
If you've ever used Google's Chrome...
... or any other WebKit-based browser, you might be surprised to learn that Apple built WebKit and released it as Open Source some years ago.
Apple have being doing Open Source for years now: http://dss.macosforge.org/
(No, they don't tend to use the GPL series of EULAs, but that's not a requirement for Open Source, despite Stallman's protestations to the contrary.)
It's just good business
Same with any company, they don't give anything away unless they have something to gain.
Maybe ALAC and FLAC could be merged...
...to create: AFLAC
AFLAC - quack! quack! quack!
ALAC is based on an early version of FLAC, I believe. It could be said that all they had to do was change the Free to Apple, store your email address within the file, and scramble it, and they had invented ALAC.
Lossless audio eh ?
£10 says there some aural homeopather out there that swears they can hear the difference.
To be fair, you probably can't tell the difference on an onboard AC97 chipset driving a £5 pair of speakers.
You can however certainly notice the difference on a decent setup.
Wow - really!
You have some sort of magical gift then.
Can you also tell the difference between a raw binary file and one that has be ZIPped and then unzipped? You should market that skill.
The clue is in the word 'lossless'.
I think you may be confusing digital quality vs analoge
If you zip a file and then unzip it then it's lossless, since zipping a file doesn't randomly remove parts of music any more than it deletes random words from text documents. I think you may be confusing compression with simply removing information to make the track smaller.
Lossy audio formats do actually remove parts of the sound, though to be fair as I have said, the sort of people using lossy formats on an onboard AC97 audio chip and a £5 set of speakers will not be able to tell a difference since that sort of system is not actually capable of reproducing the sounds that are being cut in the first place.
If you start with a high quality recording in FLAC and then re-encode in a lossy format like MP3 you can most certainly tell the difference between them on a decent sound setup.
Pretty much it makes not much difference which lossless you use at the end of the day, any decent processor can convert tracks from one to the other in not very much time.
I would suddenly become an Apple customer if they decided to actually sell ALAC albums though.
There's always a motive
Easy: Apple portable hardware supports ALAC, so greater sales.
What miserly record? Do you mean CUPS which all 'nix's now use for printing? Or Webkit which many of us browse with, on Mac and 'nix.
But seriously, do you think any company with shareholders gives stuff away for no reason?
Re: There's always a motive
"Or Webkit which many of us browse with, on Mac and 'nix"
And is originally a fork of the KDE khtml rendering engine...
Anything that helps boosting widespread lossless audio compression support is welcome - even if it comes from Apple.
how does alac handle track gaps? i am used to atrac on my walkman which is seamless but in my car the gaps in mp3 tracks is infuriating....
ALAC is. So is AAC. Also MP3s encoded with LAME support gapless playback.
Don't trust 'em
It's a trap! After everyone's changed to, and become reliant on the ALAC system, Apple will introduce licensing charges and rip us all off again.
You may want to change whatever you smoke. The release cannot be reversed, and besides, there is no way Apple would pull a stunt like that. They're not Google, the product is not called Android, the license is different and they never said they would do no evil. The fact that someone feels the need to state that ought to worry you more..
Can't see the need for this - just pressure them to support FLAC on ifad devices instead (to save me having to use VLC on my iPod touch).
Weird down-votes again!
What's with the weird down voting - even when 2 people are just trying to figure out some technical aspects ? fanbois (of both sides) turbo charged today ?
What's the use?
When we already have the superior FLAC?