I'm currenty more interested by lossless than lossy encoding. I've therefore 'tested' several audio format at different profiles, like Speek or Hans Heijden. Big difference: I've only tested classical music CD (20 albums - 26 CD).

Test is currently written in french, but I'll soon translate some essential part of it. Nevertheless, no need to understand french for reading a table

http://www.foobar2000.net/lossless

P.S. I've asked to Speek the permission to use his webpage as model. I'm still waiting for the answer. His model is cleaner than any excel html translation. Speek, if you're reading this and don't agree, I could change the main page.


Complete stats are also available here:
http://foobar2000.net/lossless/details.htm

Hi Guruboolez,

Sorry, I've never seen your question. I've probably deleted it together with all the spam I receive. But I'm flattered that you want to use the same layout And I like the colours you added.

I'm very glad to read this. Thank you very much

babelfish english translation:
http://babelfish.altavista.com/babelfish/t...ex.htm&lp=fr_en

some points:
- your note about shorten is right, it has no interchannel decorrelation
- wavpack has come a long way!
- looking at the detailed results, apple lossless sizes and computational asymmetry are so close to FLAC, it's eerie.

Josh

Very nice and detailed comparison ... as a FLAC user (and about to compress my whole CD collection to lossless, including some 50+ classical masterpieces), I can clearly see that there is no sense in using FLAC Q8 over FLAC Q5.

Thanks guruboolez - your testing does rock !

thanks for the nice chart guruboolez ... for flac -8 v flac -5. I see slightly smaller disk space requirements at the expense of slightly more decoding time. Disk space is cheap but that's precisely why I chose -8. Encoding time doesn't really matter.

Personally I think -6 is a better option than -5 if the encoding speed turns you off.

<troll>

You could upgrade to Wavpack, too.

</troll>

I've long been partial to -4 as the best tradeoff between encoding time and compression. Although I was first convinced by my own tests, I think it shows up most clearly in HansHeijden's graph. Also, I recently stumbled upon a comment by Josh on the subject.

In any event, I enjoyed the comparison, guruboolez. Any chance of getting the spreadsheet in something more linux-friendly than 7zip?

--John

(Takes the bait)

In what way is Wavpack an upgrade from flac? The compression ratio is a little better but not enough to really force a switch. I like wavpack but I'm still using flac for hardware compatibility reasons.

This is a serious question - what's the benefit to the casual end user of wavpack over flac?

Well, I'm pleasantly seeing that Wavpack 4.2 (beta) -fast beats or matches FLAC -5 (default) in every aspect in this test, especially in encoding speed. That's a very welcome progress for Wavpack, since FLAC used to be unbeatable in decoding speed up to now. It would be interesting to see if this is consistent in some other genres...

the compression ratio gap between encoders is usually greater with classical music because there is less noise, which is uncompressible.

josh

Offtopic: In the lossy chart, why does "LAME" turn into "BLADE" on the babelfish translated page?

Offtopic reply: Lame is French for blade

I'm actually surprised at Shorten's performance here. Though it has the "worst" compression, the encode and decode times are insane. WavPack is also looking pretty good.

This would make them very attractive for portable MP3 players to offer due to the obvious low processing required. I have an iAUDIO M3, which has just offered FLAC support through a firmware update, but looking at these stats, I'm wondering why Shorten isn't more "popular" for portable uses.

FLAC looks like it's falling behind the competition, so to speak

shorten is actually very popular, just not around here. it may still be more popular than even FLAC on the legal trading networks (etree, furthurnet, etc.)

but the format was not designed to be general-purpose. seeking had to be tacked on by other people. it has no error recovery and frames can't be independently decoded, you need the results of a previously decoded frame to decode the current frame (I think the seek tables hack around that by storing some samples of the previous frame).

wavpack's decode complexity can be low enough for hardware implementations, but the decode complexity range is wide enough to be a problem. a hardware maker could add wavpack support only to get a bunch of complaints from people who encoded with the wrong mode and are wondering why their device can't play it.

Josh

I don't think that is an issue. Even at high mode it doesn't decode much slower than AAC and WMA pro, according to Guru's tables. I bet a slightly optimized version would run on all modes on your average TI or Motorola DSPs powering DAPs.

OFF TOPIC

We would be happy if this was true...
/OFF TOPIC

Well, nice job Mr Guruboolez...

Well, it seems FLAC is definitely not the best in terms of compression. =P Thing is, though, is it really worth the extra compression when decode performance goes way down as well? Most of what I do with my lossless colletion is either transcode it to lossy for portable use or listen to it in the background while I'm doing somethign else... In the first case, the decode performance would hold up the lossy encode, and in the second case, it would be sucking cycles from my main application. I am impressed by the performance of Wavepack in this test, though. Same approximate size at FLAC, but has it beat in encode and decode performance.

it won't be an issue for many codecs if you're writing to the hardware. but that hasn't helped with adoption. having C code you can compile to any target that is fast enough does help. as far as I know, none of the hardware that supports FLAC has any specialized code, it's straight libFLAC. if it required customization to run fast enough I don't think FLAC would have been adopted. manufacturers wouldn't spend all that extra effort on a fringe format.


well, not at the same time, at least according to this test, there is still a tradeoff. but wavpack does seem to have a "compression bang for the buck" as good as monkey's audio now.

Josh

Check out this port of 7-Zip for Unix: p7zip

Still, it is unfriendly for MacOS users or people that don't want to be arsed to install another archiver on their PC.

Guru: could you provide the files in .rar? rar, at least, has decompressors for nearly all platforms and is also supported nearly everywhere.

Actually, even .zip performs quite well on those files. And the OpenOffice file could be offered unpacked since it's already compressed.

But... but... it's true.
lame: strip of wood, metal etc; razor, saw, tongue etc blade; lame de rasoir - razor blade

But enough of this OT junk... the page looks quite informative. Thanks, Guruboolez!

Good compression was why I switched from FLAC to Monkey's Audio (high setting) a few months ago. At first glance the savings may not seem like much, but it adds up to gigabytes worth very quickly. I certainly wouldn't categorize Monkey's Audio as taking up huge amounts of CPU cycles either. In fact, CPU usage was always pretty much zero on my system, same as FLAC (at least as near as I could tell anyways). I could easily play a game while music was playing in the background for example. Unfortunately I just finished transcoding my entire collection back to FLAC because I ordered two Rio Karma's a couple of days ago. Not a big deal really, though it does mean I'll be having to buy a larger drive sooner than expected. I wanted to put this off as long as possible, mainly because of how over time capacity increases while prices drop.

Inreresting comparison indeed. Thank you for the good job .

Just as an idea [actually something I saw and liked on another comparison, but I fail to remember which one, sorry ] : maybe two graphs could be added, first for encoding speed and second for decoding speed, both vs compression rate and showing all codecs.

Sounds good to me to visullay "position" each of them between those opposite targets.

Thanks for all replies
I can't update anything for the moment, but I'll change very soon two things:
• 7zip -> zip (I thought that 7z was open-source and cross-plateform)
• TTA decoding speed (a developer sent me a new component for foobar2000, and decoding speed is now x~22 (instead of x16).

It is open source. But not cross platform. It won't even work at big endian machines at its current state.

La is still a compression leader, though I'm surprised at OptimFROG. It's really moved forward in leaps and bounds (pun intended )

page updated.
I've also add alternative sorting (by decoding speed/encoding speed/format-preset):
http://foobar2000.net/lossless/encoding.htm and follow other links on bottom

Wavpack 4.2 decoding speed looks really impressing on this test, beating even FLAC (although by a very small margin). However, I just did the decoding test on a trumpet album (André Maurice, Mit Pauken und Trompeten) and I am consistently getting about ~18% lower speed with wavpack 4.2 -fast than with Flac 1.1 -6...
Could this be due to my much more limited sampling (just one album) or to processor differences (I'm using an Athlon 64)?

part of the decoding speed difference can be attributed to having to read less encoded data from disk if the compression is greater, but how much is hard to quantify.

Josh

I doubt that would have an impact, since guruboolez buffered the files into memory...

Yes, exact. I used foobar2000 with buffering up to 250000 kb. Difference in filesize is really too small (-1...2%) to explain such difference (5...10%).

Assuming that's the only thing that matters to you. It's like saying miles per gallon is the only thing that matters on your car ... that might be true for a few people, but not for most, there are several factors that go into the decision. And even one person might use different approaches for different needs. See the many other threads.

As always, it depends on the use. Are you just doing the encode for yourself, or is it for wide sharing (a live music show, for example). If lots of users are going to be sharing the file, you might spend a little more time getting the encode smaller, since it's encoded only once but shared (and decoded) lots of times.

People here have underestimated Shorten for years. It's still probably the most widely used lossless format, because so much live music was encoded into shn.