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: WavPack 4.41 beta available (Read 79880 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.41 beta available

Reply #25 –
Quote from: Synthetic Soul on
Anyway, for now there are my FLAC 1.1.4 results, but I'll try to make a correlation with the others if I can.

Ah, this is perfect! I just wanted to compare the results to something else, and that will do fine. 

Assuming you aren't running anything else on your PC during the tests I wouldn't believe that adding memory would make a difference (assuming it's the same speed memory). Certainly none of these programs are going to approach using even 100 megs, right? It would mean that there would be more disk cache available, but I wouldn't think that would make a difference either because you're not processing the same files over and over again. But I'm certainly no expert...

WavPack 4.41 beta available

Reply #26 –
I checked the CPU-only results of both 4.40 runs (512MB and 1GB RAM) and they were suitably similar.

However, after adding the results for WavPack 4.41 and FLAC 1.1.4 to my CPU+IO comparison table I have seen that the 4.40 times are better than the 4.41!!  Given the the CPU-only times reported I can only assume that this is down to my system - perhaps down to the disk cache that you mentioned?  Anyway, in conclusion, the new CPU+IO results are worthless, until I can get the whole table up to tests run on my 1GB system.

I will try to run some tests on my laptop (AMD Turion 64 Mobile ML-36) to get you some more data.
I'm on a horse.

WavPack 4.41 beta available

Reply #27 –
Quote from: Synthetic Soul on
However, after adding the results for WavPack 4.41 and FLAC 1.1.4 to my CPU+IO comparison table I have seen that the 4.40 times are better than the 4.41!!  Given the the CPU-only times reported I can only assume that this is down to my system - perhaps down to the disk cache that you mentioned?  Anyway, in conclusion, the new CPU+IO results are worthless, until I can get the whole table up to tests run on my 1GB system.


It occurred to me that it might be worth looking into the following items in order to make the CPU-only tests more precise and/or the CPU+IO tests more repeatable:

1. A high performance ramdisk driver for windows.
2. A high performance /dev/null equivalent for windows, if such a thing exists.
3. A means of preloading the system cache with your input file.
4. A means of ensuring the system cache does not have your input file preloaded at all.

Just throwing out some ideas...

-brendan

WavPack 4.41 beta available

Reply #28 –
With a Pentium 4 2.6GHz speed increased like this:
Code: [Select]
switch    encode    decode
-hhx3     19,98%    12,18%
-hh       33,05%    14,72%
-hx3      18,44%    13,60%
-h        24,60%    16,14%
-x3       14,35%    15,76%
           21,99%    16,63%
-fx3       8,48%    10,34%
-f         9,46%    18,43%

(based on process time according to timer.exe)

WavPack 4.41 beta available

Reply #29 –
Wow, the improvements reported by shadowking and gaekwad2 are far more impressive!  Superb.

Also, curious that mine was more apparent in the faster modes but theirs in the slower.  Both their machines are Pentiums, while mine is an Athlon XP +2400.  Unfortunately my laptop is an Athlon also.  Had you seen results from an Athlon previously?  Is it possible that compiler switches are somehow geared toward Intel chips?

Edit: I know it's a little early to be making conclusions, but hey.. I'm bored!

Edit: Bit late, but had to amend that hideous "there's"/"theirs" error...
I'm on a horse.

WavPack 4.41 beta available

Reply #30 –
Sorry if this question is stupid, but I didn't follow discussion about testing the speed - is there a special test suite available for download somewhare or do I have to feed the encoders with my own files?

WavPack 4.41 beta available

Reply #31 –
Please forgive me for first testing the new beta now, and because of little time, then i have only tested one image consisting of 11 tracks(Evanescence - Fallen) and i have only used the -h switch.

For the test, then i used an Intel Celeron 1.7GHz with 256MB RAM(the Celeron 1.7GHz is identical to a P4 Willamete(first P4 generation), except with only a half L2 cache size).

(wavpack = v4.40)

timer wavpack -h test.wav > log.txt

Timer 3.01  Copyright © 2002-2003 Igor Pavlov  2003-07-10

Kernel Time  =    6.699 = 00:00:06.699 =  5%
User Time    =  101.525 = 00:01:41.525 =  83%
Process Time =  108.225 = 00:01:48.225 =  89%
Global Time  =  121.204 = 00:02:01.204 = 100%

timer wavpack441b -h test.wav >>log.txt

Timer 3.01  Copyright © 2002-2003 Igor Pavlov  2003-07-10

Kernel Time  =    6.839 = 00:00:06.839 =  5%
User Time    =    91.351 = 00:01:31.351 =  75%
Process Time =    98.191 = 00:01:38.191 =  81%
Global Time  =  120.473 = 00:02:00.473 = 100%

timer wvunpack test.wv >>log.txt

Timer 3.01  Copyright © 2002-2003 Igor Pavlov  2003-07-10

Kernel Time  =    6.649 = 00:00:06.649 =  7%
User Time    =    65.624 = 00:01:05.624 =  74%
Process Time =    72.273 = 00:01:12.273 =  81%
Global Time  =    88.587 = 00:01:28.587 = 100%

timer wvunpack441b test.wv >>log.txt

Timer 3.01  Copyright © 2002-2003 Igor Pavlov  2003-07-10

Kernel Time  =    6.919 = 00:00:06.919 =  8%
User Time    =    55.289 = 00:00:55.289 =  70%
Process Time =    62.209 = 00:01:02.209 =  79%
Global Time  =    78.383 = 00:01:18.383 = 100%


As always, very nice job, David

CU, Martin.

WavPack 4.41 beta available

Reply #32 –
Quote from: Synthetic Soul on
Had you seen results from an Athlon previously?  Is it possible that compiler switches are somehow geared toward Intel chips?


I've found in the past WavPack had some strange behaviour from this point of view. I used to repeat my test on a PIV, a PIII and a Sempron. When compared to other encoders, WavPack usually showed bad behaviour on the PIII. I think I still should have some tables around...

Anyway, here's some results on an Athlon64 3500+:

Code: [Select]
          4.40.0           4.41.0b      Enhancement     

f     121,9x  152,3x   132,1x  163,3x    8,4%  7,2%
fx1    70,0x  152,3x    77,0x  160,3x   10,0%  5,3%
fx2    50,5x  150,6x    57,5x  159,8x   13,9%  6,1%
fx3    30,7x  149,7x    35,7x  159,3x   16,3%  6,4%
fx4    13,0x  149,7x    15,1x  158,8x   16,2%  6,1%
fx5    10,5x  147,9x    12,2x  158,3x   16,2%  7,0%
fx6     9,0x  146,7x    10,4x  156,9x   15,6%  7,0%
                            
      100,8x  131,1x   111,0x  135,6x   10,1%  3,4%
x1     51,8x  129,5x    60,7x  134,9x   17,2%  4,2%
x2     33,8x  129,2x    41,1x  131,5x   21,6%  1,8%
x3     18,3x  127,9x    23,0x  131,1x   25,7%  2,5%
x4      4,8x  127,6x     5,8x  130,8x   20,8%  2,5%
x5      3,4x  126,7x     4,0x  130,5x   17,6%  3,0%
x6      1,7x  124,8x     2,0x  129,5x   17,6%  3,8%
                             
h      74,5x  100,8x    83,4x  105,5x   11,9%  4,7%
hx1    36,5x  100,4x    43,8x  104,3x   20,0%  3,9%
hx2    21,7x  100,1x    27,0x  102,4x   24,4%  2,3%
hx3    10,9x  100,1x    13,8x  101,4x   26,6%  1,3%
hx4     2,9x   99,7x     3,5x  101,0x   20,7%  1,3%
hx5     2,2x   99,3x     2,7x  100,8x   22,7%  1,5%
hx6     1,5x   98,7x     1,8x  100,1x   20,0%  1,4%
                            
hh     60,5x   80,6x    67,7x   81,8x   11,9%  1,5%
hhx1   26,8x   80,3x    33,5x   81,6x   25,0%  1,6%
hhx2   15,3x   79,9x    19,5x   81,5x   27,5%  2,0%
hhx3    7,4x   79,6x     9,6x   81,3x   29,7%  2,1%


While on the decoding side the improvements are not as dramatic as they are on the tests on the Intel chips above, nevertheless the encoding speed improvements seems very good also on this AMD chip test.

WavPack 4.41 beta available

Reply #33 –
My diminutive test says improvement is tangible  !

Code: [Select]
AMD Sempron(tm) Processor 3400+ (2GHz, Palermo core, 90 nm, socket 754)

C:\WINDOWS\Temp>wavpack -hx3m "02 - Epic.wav"

 WAVPACK  Hybrid Lossless Audio Compressor  Win32 Version 4.40.0
 Copyright © 1998 - 2006 Conifer Software.  All Rights Reserved.

original md5 signature: 4321b3f5d474133547757fab9c7abd34
created 02 - Epic.wv in 31.02 secs (lossless, 32.13%)

C:\WINDOWS\Temp>wvunpack -m "02 - Epic.wv"

 WVUNPACK  Hybrid Lossless Audio Decompressor  Win32 Version 4.40.0
 Copyright © 1998 - 2006 Conifer Software.  All Rights Reserved.

original md5:  4321b3f5d474133547757fab9c7abd34
unpacked md5:  4321b3f5d474133547757fab9c7abd34
restored 02 - Epic.wav in 3.80 secs (lossless, 32.13%)

02 - Epic.wav 51.849.884 bytes
02 - Epic.wv  35.192.996 bytes

C:\WINDOWS\Temp>wavpack -hx3m "02 - Epic.wav"

 WAVPACK  Hybrid Lossless Audio Compressor  Win32 Version 4.41.0-beta
 Copyright © 1998 - 2006 Conifer Software.  All Rights Reserved.

original md5 signature: 4321b3f5d474133547757fab9c7abd34
created 02 - Epic.wv in 24.66 secs (lossless, 32.13%)

C:\WINDOWS\Temp>wvunpack -m "02 - Epic.wv"

 WVUNPACK  Hybrid Lossless Audio Decompressor  Win32 Version 4.41.0-beta
 Copyright © 1998 - 2006 Conifer Software.  All Rights Reserved.

original md5:  4321b3f5d474133547757fab9c7abd34
unpacked md5:  4321b3f5d474133547757fab9c7abd34
restored 02 - Epic.wav in 3.75 secs (lossless, 32.13%)

02 - Epic.wav 51.849.884 bytes
02 - Epic.wv  35.192.996 bytes
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100
 

WavPack 4.41 beta available

Reply #34 –
Quote from: bryant on
Of course, now, when I want to speed things up, I realize that some of the compromises I made for simplicity now are costing in efficiency. I could create a new mode specifically for lossless that would achieve the same compression at greater speed (and be more MMX'able) but that's what I was trying to get away from.

That's also my experience: Highly optimized code and a good neat design don't go together...

Quote from: bryant on
BTW, I haven't been following all the TAK discussion closely enough to know whether you are using any hand-coded assmebler in there. I remember at one point you said that it was pure Delphi, but I was wondering if that was still the case (I know you must at least be using some intrinsics for MMX). And if not, do you think you'll be able to get further speed gains if you ever tried that?

TAK contains highly optimized MMX-assembler code. I wrote it in 1997 when i got my first Pentium 200 MMX. Without the speedup achieved from the MMX-code, my tests and evaluations would have lasted intolerably long...

But there is also a switch to disable the MMX-optimizations. Presets Turbo and Fast are performing quite well without MMX (about 40 percent less encoding speed on my P3), but the stronger presets with higher predictor orders are getting much slower without MMX.

Unfortunately the MMX-usage also makes some transformations of the data neccessary, which probably are eating up the advantage for at least the turbo preset.

And for cpu dependency: My MMX-code is optimized for my P3 and should also work very well on the newer Intel cpus, which are quite similar to the P3. But the P4 is a strange beast (i never liked it...): My code is using many register moves and they are incredibly slow on a P4 (can be different for the latest revisions of the P4). A latency of 6 clock cycles for a simple Movq! A Pmaddwd doesn't take longer...

Quote from: bryant on
BTW, if you'd like to send me your code I would be happy to look it over and let you know what I think. I bet Josh would even help me and I'm sure we could come up with some good ideas for you! 

Thank you!

  Thomas

WavPack 4.41 beta available

Reply #35 –
Quote from: Synthetic Soul on
Also, curious that mine was more apparent in the faster modes but there's in the slower.  Both their machines are Pentiums, while mine is an Athlon XP +2400.  Unfortunately my laptop is an Athlon also.  Had you seen results from an Athlon previously?  Is it possible that compiler switches are somehow geared toward Intel chips?
It turns out that the faster modes vs. slower modes difference makes some sense. There are two components to WavPack (and other lossless audio for that matter) compression. The first is decorrelation where the redundancy in the audio samples is [almost] removed so you only have [ideally] noise of varying amplitude. Then the noise (sometimes called the residuals) is sent to the entropy encoder that turns it into a bitstream by [essentially] removing all the unneeded bits (because these numbers tend to be quite small).

The higher modes of WavPack are created by having the decorrelator make more passes over the data (2 for fast mode, 16 for very high mode). The entropy encoder (and some other stuff like JS and CRC) is always exactly the same no matter what the mode. So, in fast mode the entropy encoder (and other constant stuff) is most of the time, while in the higher modes more and more of the total time is in the decorrelator.

In this round of optimization I made improvements in both sections. But, if in your system for some reason only the constant stuff saw the improvement then the fast modes would see the big improvement, whereas in other systems the decorrelation improvements would help the higher modes more. Not a mystery at all! 

My wife's laptop is also a Turion 64 and I saw improvement there also. Not as much as my P4, but more than your AMD. In any event, I am beginning to think the improvements are certainly worth it based on the other results. Yours are of course still greatly appreciated... 


Quote from: Sebastian Mares on
Sorry if this question is stupid, but I didn't follow discussion about testing the speed - is there a special test suite available for download somewhare or do I have to feed the encoders with my own files?

With some encoders it might make a difference, but WavPack should pretty much always run the same regardless of the source material. Use whatever you need to encode anyway... 

WavPack 4.41 beta available

Reply #36 –
Quote from: TBeck on
TAK contains highly optimized MMX-assembler code. I wrote it in 1997 when i got my first Pentium 200 MMX. Without the speedup achieved from the MMX-code, my tests and evaluations would have lasted intolerably long...

But there is also a switch to disable the MMX-optimizations. Presets Turbo and Fast are performing quite well without MMX (about 40 percent less encoding speed on my P3), but the stronger presets with higher predictor orders are getting much slower without MMX.

Unfortunately the MMX-usage also makes some transformations of the data neccessary, which probably are eating up the advantage for at least the turbo preset.


I see. I imagine that the faster modes benefit less from MMX because more time is spent in the entropy coder (which I assume is not easily MMX-able, although I haven't thought about it too much).

Anyway, however you're doing it is certainly working incredibly well! 

Quote
And for cpu dependency: My MMX-code is optimized for my P3 and should also work very well on the newer Intel cpus, which are quite similar to the P3. But the P4 is a strange beast (i never liked it...): My code is using many register moves and they are incredibly slow on a P4 (can be different for the latest revisions of the P4). A latency of 6 clock cycles for a simple Movq! A Pmaddwd doesn't take longer...

Yeah, I've heard other places that the P4 is an admitted Intel blunder (especially the early ones). Maybe it's not the best for me to be optimizing for! I also notice that mine seems to slow down significantly after just a minute or so of running WavPack, which makes benchmarking frustrating! Maybe I should make sure the fan is clean...

Quote
Quote from: bryant on

BTW, if you'd like to send me your code I would be happy to look it over and let you know what I think. I bet Josh would even help me and I'm sure we could come up with some good ideas for you! 

Thank you!
I hope you know that this was my poor attempt at a joke... 

WavPack 4.41 beta available

Reply #37 –
Quote from: bryant on
I too am interested to see what happens on other systems. This optimization business can be kind of a circus with all the different CPUs and compilers and their switches. Sometimes I'd come up with an improvement and it would be 20% faster on my primary system, then I'd try it at work and it would be much slower! What I finally came up with was faster on all three systems I tried, so my fingers are crossed... 


In next rough and absolutely not ultimate table, you can see a few random encoders performances on a PIV2.8HT, a Tualatin1.56ghz and a Sempron1.83ghz.
In the last columns you can see PIV to PIII performance comparison and PIV to Sempron performance comparison.
On the average row you can see the PIV being 41% (encoding) and 29% (decoding) faster than the PIII (on an average base) and 6% faster (encoding) and 1% slower (decoding) than the Sempron (on an average base).

Code: [Select]
                      PIV Speed    PIII Speed   Sempron Speed  PIV to PIII  PIV to Sempron

OptimFrog   Normal  17,8x  22,9x  11,2x  15,8x  15,5x  22,2x  59,0%  45,5%  14,7%   3,3%
Flac 1.1.2  -8       9,5x  99,1x   7,5x  77,1x   9,5x 115,7x  26,5%  28,6%   0,7% -14,3%
Flac 1.1.2  -5      49,6x  99,1x  29,2x  81,6x  46,3x 115,7x  69,6%  21,4%   7,1% -14,3%
Monkey      High    35,6x  31,5x  27,5x  25,7x  38,0x  34,7x  29,5%  22,7%  -6,4%  -9,1%
Monkey      Normal  40,2x  33,0x  32,7x  30,2x  42,7x  38,6x  23,2%   9,5%  -5,8% -14,3%
MP4ALSGarf  -a-o32  38,6x  59,1x  24,8x  44,1x  34,3x  57,8x  55,6%  34,0%  12,5%   2,1%
MP4ALSGarf  -a-o4   89,5x 111,0x  61,7x  86,8x  75,0x  95,7x  45,2%  28,0%  19,4%  16,0%
Yalac0.05   Normal  23,5x  95,7x  16,9x  71,2x  21,9x  86,8x  39,0%  34,5%   7,6%  10,3%
Yalac0.05   High     9,2x  99,1x   7,6x  71,2x   9,1x  86,8x  19,8%  39,3%   1,0%  14,3%

                                                  Average     40,8%  29,3%   5,6%  -0,7%


Now, in next table you can see the same numbers on a few WavPack tests. As you can see the PIV is not less than 147% faster (encoding) and 50% faster (decoding) than the PIII (WavPack based), and 42% faster (encoding) and 14% faster (decoding) than the Sempron (WavPack based).

Again, those are not enough numbers to be considered ultimate, I only mean to show a possible behaviour.

When confirmed, this should mean that, in a comparison with other codecs, WavPack likes the PIV better than the Sempron and it likes the PIII much less than the other two chips. The PIV is encoding -hx3 over three times faster than the PIII and over 50% faster than the Sempron!

Code: [Select]
                      PIV Speed    PIII Speed   Sempron Speed  PIV to PIII  PIV to Sempron

WavPack 4.3 -hx3     1,9x  60,3x   0,6x  42,1x   1,2x  52,4x 191,7%  43,5%  51,3%  15,2%
WavPack 4.3 Default 81,6x  99,1x  43,4x  63,1x  64,6x  89,5x  88,2%  57,1%  26,5%  10,7%
WavPack 4.3 -fx4    15,0x 115,7x   5,7x  77,1x  10,2x  99,1x 161,1%  50,0%  47,6%  16,7%

                                                  Average    147,0%  50,2%  41,8%  14,2%

WavPack 4.41 beta available

Reply #38 –
Finally, here's the results for my laptop (AMD Turion 64 Mobile ML-36):

Code: [Select]
         |           |     4.40.0     |      4.41      |    Benefit
Setting  |   Comp %  |   Enc     Dec  |   Enc     Dec  |   Enc     Dec
======================================================================
f        |  61.020%  |  101x    119x  |  115x    128x  |  114%    107%
  x      |  60.485%  |   68x          |   79x          |  115%    
  x2     |  60.369%  |   50x          |   59x          |  118%    
  x3     |  60.303%  |   30x          |   35x          |  119%    
Default  |  59.715%  |   89x    104x  |  100x    108x  |  113%    104%
  x      |  59.470%  |   50x          |   61x          |  120%    
  x2     |  59.398%  |   33x          |   41x          |  124%    
  x3     |  59.369%  |   17x          |   22x          |  127%    
h        |  59.058%  |   66x     83x  |   75x     85x  |  114%    102%
  x      |  58.918%  |   34x          |   43x          |  125%    
  x2     |  58.841%  |   20x          |   26x          |  129%    
  x3     |  58.841%  |   10x          |   13x          |  132%    
hh       |  58.760%  |   54x     68x  |   62x     69x  |  115%    102%
  x      |  58.674%  |   25x          |   33x          |  129%    
  x2     |  58.639%  |   14x          |   19x          |  132%    
  x3     |  58.627%  |    7x          |    9x          |  135%



NB: Different corpus to other test - no comparitive results (these are the first tests that I have run on my laptop).

Pleasing figures though.
I'm on a horse.

WavPack 4.41 beta available

Reply #39 –
Quote from: bryant on
Quote
Quote from: bryant on

BTW, if you'd like to send me your code I would be happy to look it over and let you know what I think. I bet Josh would even help me and I'm sure we could come up with some good ideas for you! 

Thank you!
I hope you know that this was my poor attempt at a joke... 

Huch... ......  Ahh...  .... I've got it! 

WavPack 4.41 beta available

Reply #40 –
Quote from: Josef Pohm on
When confirmed, this should mean that, in a comparison with other codecs, WavPack likes the PIV better than the Sempron and it likes the PIII much less than the other two chips. The PIV is encoding -hx3 over three times faster than the PIII and over 50% faster than the Sempron!

This is very interesting, thanks for presenting it!

I guess there are just two possibilities. The first is that because I have done my optimization on a P4 (although a much older one than yours) the decisions have all been skewed towards that processor. The second is that something about the WavPack algorithm itself is more suited for a P4, like maybe the multiple passes over the samples. I don't know enough about the CPU differences to say, but I'd bet on the first guess.

It seems like the P3 decoding speed results are close to what I normally see in comparisons with WavPack "fast" just about matching FLAC. But the P4 results show the default WavPack mode matching FLAC and WavPack "fast" significantly faster than anything else!

Oh boy, more work to do... 

WavPack 4.41 beta available

Reply #41 –
Quote from: Synthetic Soul on
Finally, here's the results for my laptop (AMD Turion 64 Mobile ML-36):

[..snip..]

NB: Different corpus to other test - no comparitive results (these are the first tests that I have run on my laptop).

Pleasing figures though.
Yes, I am perfectly happy with these results! 

In fact, after looking over all the results I believe that this is certainly worth a release, especially considering that there doesn't seem to be regression anywhere.

Thanks again to everyone for their great help! 

WavPack 4.41 beta available

Reply #42 –
Yup no regression my side with hardcore punk, metal and ska so far (about 1500 files).

Silly question: any probs using your copytags.exe little proggy with this release too?

Thanks for your superb work, appreciated!
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack 4.41 beta available

Reply #43 –
my short test

Code: [Select]
test on 70 short files (1cd):
-------------------------------------------------------
type.........................size....... | render time
-------------------------------------------------------
!orig\.....................1.502.251.352 |  x
flac114_5\...................521.737.686 | ~3min
flac114_8\...................516.297.252 | ~7min
frog46ex_default\............480.359.971 | ~9min
wavpack441beta_default\......536.306.866 | ~2min
wavpack441beta_h\............528.509.776 | ~2min
wavpack441beta_hx\...........518.291.598 | ~5min


encoding times are aprox., decoding times not tested.
p.s. none of the encoders seems to use my two cpus.
p.s.2. sysinfo:
Property   Value
Number of CPU(s)   2 Physical Processors / One Core / 2 Logical Processors
Vendor   GenuineIntel
CPU Full Name   Intel Xeon
CPU Name   Intel® Xeon™ CPU 2.80GHz
CPU Code Name   Prestonia
Technology   0.13µ
Platform Name   Socket 603/604
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

WavPack 4.41 beta available

Reply #44 –
Here's my quick test using the 'Finding Nemo' soundtrack on my P4 3GHz, 1MB RAM, XP Pro, default compression levels for all:
Code: [Select]
Original File: 638,775,020 bytes test_image.wav

flac 1.1.3
test_image.wav: wrote 329,487,790 bytes, ratio=0.516

Kernel Time  =     3.546 = 00:00:03.546 =   2%
User Time    =    62.890 = 00:01:02.890 =  48%
Process Time =    66.437 = 00:01:06.437 =  50%
Global Time  =   130.422 = 00:02:10.422 = 100%

flac 1.1.4
test_image.wav: wrote 328,246,889 bytes, ratio=0.514

Kernel Time  =     3.625 = 00:00:03.625 =   2%
User Time    =    49.406 = 00:00:49.406 =  40%
Process Time =    53.031 = 00:00:53.031 =  43%
Global Time  =   123.281 = 00:02:03.281 = 100%

wavpack-4.40.0
created test_image.wv (336,278,676 bytes) in 66.75 secs (lossless, 47.36%)

Kernel Time  =     1.953 = 00:00:01.953 =   2%
User Time    =    35.265 = 00:00:35.265 =  52%
Process Time =    37.218 = 00:00:37.218 =  55%
Global Time  =    66.828 = 00:01:06.828 = 100%

wavpack-4.41.0-beta
created test_image.wv (336,278,676 bytes) in 64.36 secs (lossless, 47.36%)

Kernel Time  =     2.187 = 00:00:02.187 =   3%
User Time    =    33.156 = 00:00:33.156 =  51%
Process Time =    35.343 = 00:00:35.343 =  54%
Global Time  =    64.422 = 00:01:04.422 = 100%


IMO, wavpack has very impressive performance on my system.  Josh, if you want to see any other tests, just yell.

John

WavPack 4.41 beta available

Reply #45 –
If it's of any interest I have now updated my online comparison.

As I had to redo all encoders (I dropped some, like LA, and MA Insane) I am now reporting CPU-only times, which I'm pleased about.

Append ?all=1 to view the 4.41b results

http://www.synthetic-soul.co.uk/comparison...index.asp?all=1
I'm on a horse.

WavPack 4.41 beta available

Reply #46 –
Quote from: Synthetic Soul on
If it's of any interest I have now updated my online comparison.

As I had to redo all encoders (I dropped some, like LA, and MA Insane) I am now reporting CPU-only times, which I'm pleased about.

Thank you very much!

And fine that you are reporting CPU-only times!

Hopefully preset Turbo will be about 5 % faster in the next TAK version (No, this isn't the new dedicated Turbo codec...). This tiny improvement would hardly be noticeable with disk io times...

  Thomas

WavPack 4.41 beta available

Reply #47 –
Kudos to Synthetic Sould and both of you TBeck and bryant and the FLAC developers, too, of course.

This chart really shows very well how exciting the lossless codec developments are at the moment.

WavPack 4.41 beta available

Reply #48 –
Quote from: Synthetic Soul on
If it's of any interest I have now updated my online comparison.

As I had to redo all encoders (I dropped some, like LA, and MA Insane) I am now reporting CPU-only times, which I'm pleased about.

Append ?all=1 to view the 4.41b results

http://www.synthetic-soul.co.uk/comparison...index.asp?all=1

Thanks again for your work and results, and I also agree that CPU-only speeds make the most sense.

I just wish I could get a few more percent on the decoding speed to break 100x. The way it looks now it's easy for people to get WavPack mixed up with the riff-raff! 

WavPack 4.41 beta available

Reply #49 –
 LOL @ riff-raff.  Considering WavPack is the second favourite encoder on this board (according to the poll) I don't think you need to worry about that.

I don't really understand the MMX, SSE stuff; however would I be right in saying that, due to the integer arithmetic nature of WavPack, SSE code is pointless?  Anything else up your sleeve?

-f is so close to 100x decoding speed with this beta.  Although, of course, not too much credance should be given to my single comparison - these tests kinda hit that home to me.

Anyway, I'm sure all your users will agree, the extra benefit provided by this beta with no loss in compression is extremely welcome.  Many thanks for your continued efforts.
I'm on a horse.