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: another lossless performance comparison (Read 26919 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

another lossless performance comparison

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

another lossless performance comparison

Reply #1 –
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.

another lossless performance comparison

Reply #2 –
I'm very glad to read this. Thank you very much

another lossless performance comparison

Reply #3 –
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

another lossless performance comparison

Reply #4 –
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 !
The name was Plex The Ripper, not Jack The Ripper

another lossless performance comparison

Reply #5 –
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.

another lossless performance comparison

Reply #6 –
<troll>

You could upgrade to Wavpack, too.

</troll>

another lossless performance comparison

Reply #7 –
Quote
Personally I think -6 is a better option than -5 if the encoding speed turns you off.

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
 

another lossless performance comparison

Reply #8 –
Quote
<troll>

You could upgrade to Wavpack, too.

</troll>
[a href="index.php?act=findpost&pid=246536"][{POST_SNAPBACK}][/a]


(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?

another lossless performance comparison

Reply #9 –
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...

another lossless performance comparison

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

josh

another lossless performance comparison

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

another lossless performance comparison

Reply #12 –
Quote
Offtopic:  In the lossy chart, why does "LAME" turn into "BLADE" on the babelfish translated page? 
[a href="index.php?act=findpost&pid=246595"][{POST_SNAPBACK}][/a]

Offtopic reply: Lame is French for blade
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

another lossless performance comparison

Reply #13 –
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 
<==== Hydrogen Audio Bomb

another lossless performance comparison

Reply #14 –
Quote
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.
[a href="index.php?act=findpost&pid=246604"][{POST_SNAPBACK}][/a]

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

another lossless performance comparison

Reply #15 –
Quote
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.[a href="index.php?act=findpost&pid=246613"][{POST_SNAPBACK}][/a]


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.

another lossless performance comparison

Reply #16 –
Quote
Quote
Offtopic:  In the lossy chart, why does "LAME" turn into "BLADE" on the babelfish translated page? 
[a href="index.php?act=findpost&pid=246595"][{POST_SNAPBACK}][/a]

Offtopic reply: Lame is French for blade
[a href="index.php?act=findpost&pid=246597"][{POST_SNAPBACK}][/a]

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

Well, nice job Mr Guruboolez...

another lossless performance comparison

Reply #17 –
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.

another lossless performance comparison

Reply #18 –
Quote
Quote
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.[a href="index.php?act=findpost&pid=246613"][{POST_SNAPBACK}][/a]

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.
[a href="index.php?act=findpost&pid=246615"][{POST_SNAPBACK}][/a]

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.

Quote
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.
[a href="index.php?act=findpost&pid=246624"][{POST_SNAPBACK}][/a]

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

another lossless performance comparison

Reply #19 –
Quote
Any chance of getting the spreadsheet in something more linux-friendly than 7zip?

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

another lossless performance comparison

Reply #20 –
Quote
Quote
Any chance of getting the spreadsheet in something more linux-friendly than 7zip?

Check out this port of 7-Zip for Unix: p7zip
[a href="index.php?act=findpost&pid=246631"][{POST_SNAPBACK}][/a]


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.

another lossless performance comparison

Reply #21 –
Quote
OFF TOPIC
  
We would be happy if this was true...
/OFF TOPIC
[a href="index.php?act=findpost&pid=246619"][{POST_SNAPBACK}][/a]

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!
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

another lossless performance comparison

Reply #22 –
Quote
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.
[a href="index.php?act=findpost&pid=246624"][{POST_SNAPBACK}][/a]

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.

another lossless performance comparison

Reply #23 –
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.

another lossless performance comparison

Reply #24 –
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).