It's almost identical to the already open source and very widely used FLAC codec.
Apple shifts Lossless Audio Codec to open source
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 …
-
-
-
Monday 31st October 2011 09:57 GMT RichyS
@Stuart Longland
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.
-
Tuesday 1st November 2011 17:11 GMT Michael Wojcik
Most people?
@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?
-
Wednesday 2nd November 2011 15:48 GMT Anonymous Coward
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.
-
-
-
-
Friday 28th October 2011 18:58 GMT Kristian Walsh
Good Move
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.
-
Friday 28th October 2011 20:43 GMT Frumious Bandersnatch
[citation needed]
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...
* http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison
-
Saturday 29th October 2011 03:38 GMT Anonymous Coward
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.
-
Saturday 29th October 2011 04:44 GMT James O'Brien
Hmm
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?
-
Sunday 30th October 2011 15:38 GMT eulampios
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.
-
Sunday 30th October 2011 15:42 GMT Kristian Walsh
Great benchmarking
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...
-
-
Sunday 30th October 2011 15:28 GMT Robert Synnott
RE: [citation needed]
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.
-
-
This post has been deleted by its author
-
-
Friday 28th October 2011 23:52 GMT Dr Trevor Marshall
"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..
-
Monday 31st October 2011 09:17 GMT Killraven
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.
-
-
Friday 28th October 2011 23:51 GMT Wanda Lust
FLACALAC
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.
-
-
Sunday 30th October 2011 15:25 GMT Kristian Walsh
"Miserly record"?
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.
-
-
Sunday 30th October 2011 15:54 GMT Sean Baggaley 1
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.)
-
-
-
-
-
Monday 31st October 2011 22:28 GMT Peter2
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.
-
-
-
-
Sunday 30th October 2011 15:39 GMT Archivist
There's always a motive
@JaitcH
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?
-
-
Monday 31st October 2011 09:17 GMT Anonymous Coward
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..
-
-
This post has been deleted by its author