Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Apple Lossless analysis? (Read 35217 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Apple Lossless analysis?

I've been seeing posts that talk around the aspects of Apple's new lossless codec on various forums, so I thought I would toss this up to see if anyone has bothered to do actual analysis yet.  With that in mind here are a few of the questions it would be nice to know.

What exactly is the codec?  Is it wholly original?  Did they reuse another codec and slap DRM on it?

How does it perform?  What's the total compression other than "about 50%" (ratio)?  How's the encode time?  More importantly how's the decode time?  Is it streamable?

And of course, how does it stack up against FLAC and the other lossless codecs already analyzed at http://flac.sourceforge.net/comparison.html?  I don't really have any intention of switching to it since I detest Apple's closed source andf proprietary bent.  However, I'd like to see some further information just out of curiosity.

Thanks,
rt

p.s.  I presume ALE will eventually make its way into the FLAC comparison list for reference?

Apple Lossless analysis?

Reply #3 –
Quote
p.s.  I presume ALE will eventually make its way into the FLAC comparison list for reference?

I am almost sure the correct name is ALAC (Apple Lossless Audio Codec). Not ALE as you use. 

By the way I am also interested in finding what its based on, and how it performs.
I am switching to Mac OS X next week and wonder if I should stick with FLAC or convert to ALAC...

Solaris

Apple Lossless analysis?

Reply #4 –
The Apple lossless codec is in-house developed. A proof of this is it's efficiency, unlike any other lossless codec (it's bad). According to Speek's comparision, it is only better than Shorten on compression - but Shorten is much faster neverthless.

These are the best up-to-date non-biased lossless encoder comparisions I know of:

Hans Heijden's:
http://web.inter.nl.net/users/hvdh/lossless/lossless.htm

Speek's:
http://members.home.nl/w.speek/comparison.htm

And no, they are not using MPEG4 lossless. That format isn't even frozen yet.

Apple Lossless analysis?

Reply #5 –
Quote
Quote
p.s.  I presume ALE will eventually make its way into the FLAC comparison list for reference?

I am almost sure the correct name is ALAC (Apple Lossless Audio Codec). Not ALE as you use. 

The official name is "Apple Lossless Encoder." So ALE it is.

Apple Lossless analysis?

Reply #6 –
Quote
The official name is "Apple Lossless Encoder." So ALE it is.

OK, I am sorry! 
But can you then tell me what ALAC is? Cause it is mentioned several times in this forum...

Apple Lossless analysis?

Reply #7 –
Quote
But can you then tell me what ALAC is? Cause it is mentioned several times in this forum...

Apple Lossless Audio Codec. Whatever.

You guys like semantics

Apple Lossless analysis?

Reply #8 –
to add to the confusion, the chunk IDs (or whatever they are called in whatever container they are using) in the file say "alac".

Josh

Apple Lossless analysis?

Reply #9 –
Quote
The Apple lossless codec is in-house developed. A proof of this is it's efficiency, unlike any other lossless codec (it's bad). According to Speek's comparision, it is only better than Shorten on compression - but Shorten is much faster neverthless.

In fact on my PowerBook G4 1GHz it's freaking fast, it took me 2m50s to encode 550M CD with 47% compression. And flac in a contrary even in fastest mode was more than twice slower. So I'd say this more like matter of CPU optimization. Which just proves your point - ALAC indeed looks like Apple's in-house development

Apple Lossless analysis?

Reply #10 –
Yeah but I don't know whether I would point to encoding time as a good benchmark of this new codec.  As long as it isn't RIDICULOUSLY long encoded time means squat for me; I encode an album once and will happily suffer an additional 2 minutes per album when I encode.  Basides, FLAC isn't known for having particularly strong encoding speeds; it gets beaten by Monkey's encoding by like two minutes if I remember correctly.

What I'd really like to know is how fast ALE/ALAC decodes, what kind of ratio it gets with whatever decode speeds it attains, and how its performance stands up in a head to head comparison with other codecs under the same conditions with the same waves.

I'd do the test myself but I'm not sure I'm equal to the "serious analysis" I really want.

-rt

Apple Lossless analysis?

Reply #11 –
Quote
Yeah but I don't know whether I would point to encoding time as a good benchmark of this new codec. As long as it isn't RIDICULOUSLY long encoded time means squat for me; I encode an album once and will happily suffer an additional 2 minutes per album when I encode.

Sure for you maybe  , but encoding time is still an important issue for others, particularly with older hardware. A two minute differential on a newer processor could balloon to twice that using an older 500MHz Pentium III or G4.

It's an interesting question how well optimized for PPC (and Moto/IBM SIMD) the competing encoders are, and likewise how well optimized ALE (via QT) is for x86 as zebub alluded to.

If you check out Speek's page that roberto linked to, ALE is both slower to encode and decode with a worse compression ratio, using Speek's athlon (classic) box and (presumably) QT for windows. Zebub reports exactly the opposite for encoding on his G4.

I still wonder why Apple wouldn't just use FLAC (seeks fast) or another prexisting lossless codec and optimize the hell out of it for Altivec or whatnot and work it into Fairplay rather than developing their own?

I suppose if Speek's and zebub's encodings are representative, the encoding time difference between a PPC processor and an x86 processor using ALE could be used as a marketing tool to sell G5's.....but would Steve Jobs be that cynical?

Apple Lossless analysis?

Reply #12 –
Good points.  I'm also kind of left wondering why Apple would bother making their own when something like FLAC is openly available and has obvious advantages.  I imagine we'll see some kind of press release or article in coming weeks giving the "inside scoop" on Apple's choice.

Okay, back to my OGG packed Karma and network FLAC server.

-rt

Apple Lossless analysis?

Reply #13 –
Ok, I've retested all things with precise times. flac 1.1.0 all defaults. Disk is "Take Bach - Jacques Loussier Trio, Güher & Süher Pekinel", Jazz.

Time for flac was 3:40, for iTunes 2:23. The funny thing are compression ratios - looks like Apple used default flac as benchmark for their codec

267668   FLAC total
267592   ALAC total
565288   AIFF total

63104 01 Concerto For 3 Pianos In D Minor BWV 1063 - I - Allegro.aif
29344 01 Concerto For 3 Pianos In D Minor BWV 1063 - I - Allegro.flac
29280 01 Concerto For 3 Pianos In D Minor BWV 1063 - I - Allegro.m4a
65428 02 Concerto For 3 Pianos In D Minor BWV 1063 - II - Alla Siciliana.aif
24136 02 Concerto For 3 Pianos In D Minor BWV 1063 - II - Alla Siciliana.flac
24288 02 Concerto For 3 Pianos In D Minor BWV 1063 - II - Alla Siciliana.m4a
63216 03 Concerto For 3 Pianos In D Minor BWV 1063 - III - Allegro.aif
31788 03 Concerto For 3 Pianos In D Minor BWV 1063 - III - Allegro.flac
31500 03 Concerto For 3 Pianos In D Minor BWV 1063 - III - Allegro.m4a
51664 04 Concerto For 2 Pianos In C Minor BWV 1060 - I - Allegro.aif
27688 04 Concerto For 2 Pianos In C Minor BWV 1060 - I - Allegro.flac
27656 04 Concerto For 2 Pianos In C Minor BWV 1060 - I - Allegro.m4a
53224 05 Concerto For 2 Pianos In C Minor BWV 1060 - II - Adagio.aif
21596 05 Concerto For 2 Pianos In C Minor BWV 1060 - II - Adagio.flac
21876 05 Concerto For 2 Pianos In C Minor BWV 1060 - II - Adagio.m4a
40476 06 Concerto For 2 Pianos In C Minor BWV 1060 - III - Allegro.aif
21084 06 Concerto For 2 Pianos In C Minor BWV 1060 - III - Allegro.flac
20952 06 Concerto For 2 Pianos In C Minor BWV 1060 - III - Allegro.m4a
79188 07 Concerto For 2 Pianos In C Major BWV 1061 - I - Allegro.aif
43416 07 Concerto For 2 Pianos In C Major BWV 1061 - I - Allegro.flac
43264 07 Concerto For 2 Pianos In C Major BWV 1061 - I - Allegro.m4a
53016 08 Concerto For 2 Pianos In C Major BWV 1061 - II - Adagio.aif
24060 08 Concerto For 2 Pianos In C Major BWV 1061 - II - Adagio.flac
24364 08 Concerto For 2 Pianos In C Major BWV 1061 - II - Adagio.m4a
61476 09 Concerto For 2 Pianos In C Major BWV 1061 - III - Fuga.aif
33144 09 Concerto For 2 Pianos In C Major BWV 1061 - III - Fuga.flac
33124 09 Concerto For 2 Pianos In C Major BWV 1061 - III - Fuga.m4a
34496 10 Jesus Bleibet Meine Freude BWV 147.aif
11412 10 Jesus Bleibet Meine Freude BWV 147.flac
11288 10 Jesus Bleibet Meine Freude BWV 147.m4a

Apple Lossless analysis?

Reply #14 –
Some guy reporting missing frames or some such nonsense in another posting.  But it got me worried so just to be sure I did some testing.  I took a WAV, converted it to ALAC, then converted it back to WAV all in iTunes.  Then I jumped into my terminal (OS X) and did:

ip68-**-***-**:/users/ryandavis/Desktop ryandavis$ diff -s Dizzy1.wav Dizzy2.wav

(in case you are unaware 'diff' is a unix command that compaires two files)

The output was:

Dizzy1.wav and Dizzy2.wav are identical

Thats a nice feeling

-= neoshroom =-

Apple Lossless analysis?

Reply #15 –
Quote
Some guy reporting missing frames or some such nonsense in another posting. But it got me worried so just to be sure I did some testing. I took a WAV, converted it to ALAC, then converted it back to WAV all in iTunes. Then I jumped into my terminal (OS X) and did:


Speek reported such problems using QT Pro 6.5.1 in this comparison that rjamorim linked to above:
Quote
Decoding of the Apple Lossless files was done with QuickTime Pro 6.5.1. The decoded files were not bit-identical to the original WAVE files. Comparing the WAVE files with Exact Audio Copy showed that the decoded Apple files were a few (less than 100) samples shorter than the original files.

Whether this is the fault of user error, EAC or QT on windows is unknown. Speek knows what he's doing a lot better than me, so I'm tempted to rule out the first possibility.
It would be quite interesting if it's reproducible.

Apple Lossless analysis?

Reply #16 –
Quote
The Apple lossless codec is in-house developed. A proof of this is it's efficiency, unlike any other lossless codec (it's bad). According to Speek's comparision, it is only better than Shorten on compression - but Shorten is much faster neverthless.

hm interesting, maybe you should conduce a lossless listening test to crealify this
(joke of course  )

btw where does all this "apple could have used flac" talk come from? did anyone from apple ever said that they are thinking about it?
I know, that I know nothing (Socrates)

Apple Lossless analysis?

Reply #17 –
Even though I'm a Mac FreeBSD fan and user I think that the ALE is bullshit, just like I think wma is bullshit. Stick with FLAC. Yes ALE is very fast on PPC's (I have a Windows box I only use when I have to) but anything that is not cross platform is nonsense.

Apple Lossless analysis?

Reply #18 –
Quote
...but anything that is not cross platform is nonsense.

Actually, it is cross-platfrom given that it works on macs and Windows. It's just that it's proprietary and not as cross-platform as you'd like it to be

Apple Lossless analysis?

Reply #19 –
Quote
btw where does all this "apple could have used flac" talk come from? did anyone from apple ever said that they are thinking about it?


No one has questioned whether Apple "was thinking about it" or considered using FLAC as the base for their own lossless codec (like their route with AAC).  I think the comment you refer to (and my own concuring comment) were simply stating the fact that its a shame Apple didn't use FLAC since its:

- open source
- free
- equally multi-platform
- highly efficient
- generally considered the best lossless codec available

In my own mind it just seems shortsighted and stupid.  As any programmer will tell you it is INFINITELY more expensive and complicated to develop proprietary systems.  You pay all the costs of development, you pay all the costs of maintenance, and you reduce your marketability by enforcing limitations on your customers.  Why bother paying so much monet to do something yourself when you can rely on someone else to maintain a BETTER creation for free?  (Or at least at a substantially reduced cost since economies of scale make licensing the less expensive route.)

Yes, you don't always get exactly what you want when you go with an existing solution.  However, from what I've read so far it seems like the only thing Apple actually got with their own proprietary lossless codec is the ability to sue anyone else who uses it.  It isn't nearly as good as FLAC and, because its proprietary, it is more expensive to maintain and less attractive to the customer (who can't use it anywhere but iTunes and the iPod).

Best,
rt

Apple Lossless analysis?

Reply #20 –
Maybe they plan to offer Apple lossless files on the iTunes Music store and this way they can add DRM restictions to the files.

Apple Lossless analysis?

Reply #21 –
Quote
Maybe they plan to offer Apple lossless files on the iTunes Music store and this way they can add DRM restictions to the files.

You could add DRM to FLAC. Easily.

Apple Lossless analysis?

Reply #22 –
Quote
You could add DRM to FLAC. Easily.

The problem isn't about adding DRM to FLAC, but actually stems from the open source license and/or developer wishes:

This page lists the goals for the FLAC project.  There are about 10 total but these 2 are pertinent to this discussion:
1. FLAC should be and stay an open format with an open-source reference implementation.
2. (Anti-Goal) Copy prevention of any kind.

So the developers don't want any copyright protection added to FLAC.  And if Apple ignored that, it would have to make the source of those additions (for DRM) publicly available.  They probably wouldn't want to do this because it would give efforts to circumvent the DRM that much more to work with.  Moreover other companies could leverage their DRM development into competing products.
SIMD: Vectoring to a computer near you.
VLIW: Psychic Compiler Wanted!  Inquire at Intel!

Apple Lossless analysis?

Reply #23 –
Quote
This page lists the goals for the FLAC project.  There are about 10 total but these 2 are pertinent to this discussion:
1. FLAC should be and stay an open format with an open-source reference implementation.
2. (Anti-Goal) Copy prevention of any kind.

So the developers don't want any copyright protection added to FLAC.  And if Apple ignored that, it would have to make the source of those additions (for DRM) publicly available.  They probably wouldn't want to do this because it would give efforts to circumvent the DRM that much more to work with.  Moreover other companies could leverage their DRM development into competing products.

Dude, you are confusing everything and then some.

FLAC will remain open and un-DRMd. But nothing prevents Apple taking the sources, changing them so to make the file format incompatible, and put DRM on it. The license (BSDish) allows that without forcing Apple to release their sources.

The goals you mentioned are for the FLAC project itself. Nothing prevents someone branching, closing source and slapping DRM on it.

Apple Lossless analysis?

Reply #24 –
Quote
[FLAC will remain open and un-DRMd. But nothing prevents Apple taking the sources, changing them so to make the file format incompatible, and put DRM on it. The license (BSDish) allows that without forcing Apple to release their sources.

Actually the GPL (which can be found here) prevents this.  Since FLAC is governed by the GPL, any incorporation of FLAC code into Apple product would mean the Apple code would also have to meet the GPL requirements.  I'll qualify my statements by saying that realistically apple could add DRM to FLAC because that is not covered by the license (as long as they made it open source). If they didn't follow the requirements, and people started comparing ALAC (ALE, whatever) with FLAC and the two generated reasonably identical files, they could have problems.  Apple would be considered an expert in the fields of software development and DRM and imho would not be exercising due care and diligence if they did not adhere to the GPL (aka they could be put into a world of legal hurt).  I think its a shame they didn't use FLAC but when lawyers are involved what is best from an engineering standpoint often cannot be done.
SIMD: Vectoring to a computer near you.
VLIW: Psychic Compiler Wanted!  Inquire at Intel!