Skip to main content
Topic: WavPack 4.40.0 beta available (Read 40193 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.40.0 beta available

I have released the beta for WavPack 4.40 and uploaded a zipfile with the 3 command-line programs for Windows plus the winamp and Audition / CoolEdit plugins. This is a list of what's new (since 4.32):
  • new hardware-friendly "high" mode compresses almost as well as old "high" mode but decodes significantly faster (works better on Rockboxed iPods)
  • old "high" mode has been renamed "very high" (-hh)
  • "extra" mode levels 1-3 completely revamped, now fast enough to be usable
  • --optimize-mono option added to improve compression of mono material in stereo files (requires at least version 4.3 decoder)
  • cuesheet extraction from command-line and during self-extraction
  • wav header generation on decode for files with missing RIFF information, or forced with -w option
  • expanded summary information including wrapper info and channel assignments
  • other improvements for more robust decoding of corrupt files
  • winamp plugin now quietly skips deleted files in playlist
  • Windows 95 no longer supported (except for self-extraction)
  • source code organized to create a standard library that should more easily integrate into other applications
I have beaten on this pretty extensively, but any further testing is appreciated. I expect this will make it quickly to full release as I plan only a couple minor changes, along with any bug fixes. Thanks for everyone's patience!

Windows binaries

Linux source package

Complete sources under SVN

Cheers! 

edit: grammer, swapped links

WavPack 4.40.0 beta available

Reply #1
just so you know, the windows binaries link which you posted contains no binaries; only sources.

Great Job btw! i've been compiling a few builds myself and WavPack just gets faster with each revision

WavPack 4.40.0 beta available

Reply #2
just so you know, the windows binaries link which you posted contains no binaries; only sources.

Great Job btw! i've been compiling a few builds myself and WavPack just gets faster with each revision

Oops, I had the links backwards! 

Thanks for letting me know; it's fixed now!

WavPack 4.40.0 beta available

Reply #3
I tested the new x-modes and high mode using lossy modes with the -n switch to see the differences in compression and noise. I tested many normal samples inc hard to compress stuff that need high + x modes like furious, badvilbel, martenotwaves, velvet etc etc

-hx is close to -hhx. -hx2 is often neck to neck with -hhx with similar encoding speed to -hhx and -hx3 sometimes even exceeds -hhx !

-x3 normal mode can be competitive with the high modes on most samples with similar encoding speed to -hhx but with nearly half decoding time. -x4 normal mode is often neck-to-neck with the high modes, but encoding is slower.

What does it mean ? The old high is looking less attractive and the new high can bridge the gap between compression / quality and speed. The old high is still fast for PC use and is handy for acheiving highest compression / quality with minimal encode time. The normal mode does well at -x3 and is really competitive with the high modes at -x4.

Also -x3 seems to be the sweet spot for all modes in terms of encoding time penalty vs compression. -x4 does offer some improvements especially in normal mode and to a lesser extent with the high modes. -x5 is marginal on normal mode, not really useful on highs and -x6 not usefull on anything I tested.

David this is good work. Do you think my testing is representitive of yours ?
wavpack 4.8 -b256hx6c

WavPack 4.40.0 beta available

Reply #4
Awesome.  I quiver with anticipation for the final build. 

Keep up the great work because WavPack rocks my Lossless world!! 
Zune 80, Tak -p4 audio library, Lossless=Choice

WavPack 4.40.0 beta available

Reply #5
Wonderful news, Bryant!  Thanks for continuing to improve my favorite lossless codec.   

One question, though...

You wrote:
  • old "high" mode has been renamed "very high" (-hh)
...however, when comparing the two, -hh (in 4.40b) consistently creates files that are slightly larger than the old -h (4.31).

e.g.:
Bad Company - Bad Company
4.31 -h:  214,901,242 bytes
4.40 -hh: 215,026,988 bytes

PJ Harvey - Is This Desire?
4.31 -h:  224,660,506 bytes
4.40 -hh: 225,045,634 bytes

It's not really so much of an increase to be concerned with, but I'm just wondering if there's any explanation for this?  Any ideas?

Thanks!

~esa
Clowns love haircuts; so should Lee Marvin's valet.

WavPack 4.40.0 beta available

Reply #6
I tested the new x-modes and high mode using lossy modes with the -n switch  ...

Also -x3 seems to be the sweet spot for all modes in terms of encoding time penalty vs compression. -x4 does offer some improvements especially in normal mode and to a lesser extent with the high modes. -x5 is marginal on normal mode, not really useful on highs and -x6 not usefull on anything I tested.
...

Sounds very good cause I do want to lower my setting a bit for use on my mobile DAP. At what bitrate were
you testing? Besides noise statistics did you do some listening tests especially with the extremely problematic samples?
lame3995o -Q1.7
opus --bitrate 140

WavPack 4.40.0 beta available

Reply #7
svn revision 41 was packaged for rarewares/debian already !!!


later

WavPack 4.40.0 beta available

Reply #8
Wonderful news, Bryant!  Thanks for continuing to improve my favorite lossless codec.   

One question, though...

You wrote:
  • old "high" mode has been renamed "very high" (-hh)
...however, when comparing the two, -hh (in 4.40b) consistently creates files that are slightly larger than the old -h (4.31).

e.g.:
Bad Company - Bad Company
4.31 -h:  214,901,242 bytes
4.40 -hh: 215,026,988 bytes

PJ Harvey - Is This Desire?
4.31 -h:  224,660,506 bytes
4.40 -hh: 225,045,634 bytes

It's not really so much of an increase to be concerned with, but I'm just wondering if there's any explanation for this?  Any ideas?

Thanks!

~esa


I think adding -x will more or less close the gap:

-hhx
wavpack 4.8 -b256hx6c

WavPack 4.40.0 beta available

Reply #9

I tested the new x-modes and high mode using lossy modes with the -n switch  ...

Also -x3 seems to be the sweet spot for all modes in terms of encoding time penalty vs compression. -x4 does offer some improvements especially in normal mode and to a lesser extent with the high modes. -x5 is marginal on normal mode, not really useful on highs and -x6 not usefull on anything I tested.
...

Sounds very good cause I do want to lower my setting a bit for use on my mobile DAP. At what bitrate were
you testing? Besides noise statistics did you do some listening tests especially with the extremely problematic samples?


I did do some for 4.31 and no differences on most stuff between high mode and normal (x). Only on stuff like vilbel there is a difference. On 4.4 new high is about 0.5 db worse than old high - too little difference to hear. I am pretty sure that at 350k you easily get away with normal mode + x3 ~ 4
wavpack 4.8 -b256hx6c

WavPack 4.40.0 beta available

Reply #10
First of all thanks a bunch for all the time you put in thsi superb encoder David, appreciated.

Now, iIs it me or the Winamp plug-in doesn't work?
With version 5.31 it doesn't even get detected (doesn't appear in Input plug-ins).

One more thing: with the latest alpha the best compression with the new -h mode could be achieved by adding x3, now it seems we have further options, could you please clear up if any of the remaining x modes is the equivalent to the old best compression x6? Thank you.
WavPack 5.1.0 -b384hx6cmv / qaac 2.68 -V 100



WavPack 4.40.0 beta available

Reply #13
Also -x3 seems to be the sweet spot for all modes in terms of encoding time penalty vs compression. -x4 does offer some improvements especially in normal mode and to a lesser extent with the high modes. -x5 is marginal on normal mode, not really useful on highs and -x6 not usefull on anything I tested.

David this is good work. Do you think my testing is representitive of yours ?

Yes, I have switched to using -x3 and -hx3 for most things because it's just about right on my machine to keep up with EAC. The old high mode just doesn't make sense anymore except in those cases where compression ratio is the only criteria. Of course, if you're never going to try to play your files on battery powered hardware and rarely use them as a source for transcoding, then it's still nice to have the little extra. I only briefly considered removing it altogether...

BTW, thanks again for your extensive testing. It makes me feel much better about a quick release! 


Now, iIs it me or the Winamp plug-in doesn't work?
With version 5.31 it doesn't even get detected (doesn't appear in Input plug-ins).

One more thing: with the latest alpha the best compression with the new -h mode could be achieved by adding x3, now it seems we have further options, could you please clear up if any of the remaining x modes is the equivalent to the old best compression x6? Thank you.

Is anyone else having trouble with the winamp plugin? I admit that my version of winamp is pretty old, so I'll get a newer one and test it out. There were virtually no code changes in the winamp plugin, but it is built with the new MS Visual Studio. Hopefully that's not the problem... 

Yes, the "extra" levels 4-6 are pretty much the same as the old levels 4-6. I say "pretty much" because they're not identical, but in most cases they should produce very similar results (sometimes a little better and sometimes a little worse). In the "very high" mode -x6 is actually closer to the old -x5 speed-wise, but because of some other changes it should do better.


You wrote:
  • old "high" mode has been renamed "very high" (-hh)
...however, when comparing the two, -hh (in 4.40b) consistently creates files that are slightly larger than the old -h (4.31).

e.g.:
Bad Company - Bad Company
4.31 -h:  214,901,242 bytes
4.40 -hh: 215,026,988 bytes

PJ Harvey - Is This Desire?
4.31 -h:  224,660,506 bytes
4.40 -hh: 225,045,634 bytes

It's not really so much of an increase to be concerned with, but I'm just wondering if there's any explanation for this?  Any ideas?

The reason for the difference is that the filters are very slightly different. I compared the two on my test corpus and they were both 45.97%, but when I look at the actual sizes the new version is 0.002% bigger. Your differences seem bigger than that and it's trivial to go back to the old filter, so maybe I'll do that for the release just to avoid confusion. But anyway, that's the reason and, yes, -x will surely put the new version over the top (my corpus goes to 46.18%).


svn revision 41 was packaged for rarewares/debian already !!!

Cool! 

And thanks to everyone for your testing.

WavPack 4.40.0 beta available

Reply #14
Thanks for the info, DARcode and bryant.

 

...go back to the old filter...
Please let us know if you decide to do this.

Thanks!

~esa
Clowns love haircuts; so should Lee Marvin's valet.

WavPack 4.40.0 beta available

Reply #15
Now, iIs it me or the Winamp plug-in doesn't work?
With version 5.31 it doesn't even get detected (doesn't appear in Input plug-ins).

If it doesn't even show up, it usually means that some imported DLL is missing.  If you load the DLL into Dependency Viewer (depends.exe, should be hiding somewhere in the visual studio directory) you can look at which DLLs it imports.  At the same time, you can verify that it's exporting winampGetInModule2.

WavPack 4.40.0 beta available

Reply #16
Plug-in bundled with 4.40.0 beta:

The old version (2.3) reports only MSJAVA.DLL as missing but works fine.
WavPack 5.1.0 -b384hx6cmv / qaac 2.68 -V 100

WavPack 4.40.0 beta available

Reply #17
i could be wrong, but it seems that you're missing Microsoft's C++ Runtimes(version 8)

WavPack 4.40.0 beta available

Reply #18
Dowloaded "msvcr80.dll" from DLL-files.com, still not working and anyway the previous version doesn't seem to require that.
WavPack 5.1.0 -b384hx6cmv / qaac 2.68 -V 100

WavPack 4.40.0 beta available

Reply #19
It is not possible to install msvcr80.dll manually you have to run the microsoft redist install (assuming the wvpack dll is not statically linked to the ms libs).

WavPack 4.40.0 beta available

Reply #20
It is not possible to install msvcr80.dll manually you have to run the microsoft redist install (assuming the wvpack dll is not statically linked to the ms libs).
I see, couldn't spot the redist package on the M$ website, do you have a link to it please?
Also, I'd like to know if this is a new requirement of the latest in_wv.dll. thanks.
WavPack 5.1.0 -b384hx6cmv / qaac 2.68 -V 100

WavPack 4.40.0 beta available

Reply #21
I've just wanted to say: GREAT GREAT WORK! 

The only thing that a lil bit "difficult" to handle in  hybrid/lossy-extra mode was encoding speed, and now it's fixed 
I thought this codec is awsome, and now it's becoming perfect!


Quote
QUOTE(DARcode @ Nov 20 2006, 19:42)

Now, iIs it me or the Winamp plug-in doesn't work?
With version 5.31 it doesn't even get detected (doesn't appear in Input plug-ins).


If it doesn't even show up, it usually means that some imported DLL is missing. If you load the DLL into Dependency Viewer (depends.exe, should be hiding somewhere in the visual studio directory) you can look at which DLLs it imports. At the same time, you can verify that it's exporting winampGetInModule2.


Yes, in most cases the included in_wv.dll in the wavpack4.4b ZIP should work perfectly with winamp. If it is copied into the plugins folder of the winamp destination, it should work (usually).
FB2K,APE&LAME

WavPack 4.40.0 beta available

Reply #22
I know how to handle WA plug-ins, thanks, this one isn't working for me, don't have any probs with the previous version, so does everybody in this thread who can actually use it have Visual Studio 8 installed please?
WavPack 5.1.0 -b384hx6cmv / qaac 2.68 -V 100


WavPack 4.40.0 beta available

Reply #24
Thank you for your work bryant.
You converted me to lossless. 

I've always thought San Francisco could only produce cool things.

 
SimplePortal 1.0.0 RC1 © 2008-2019