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 (http://www.wavpack.com/wp440b.zip)
Linux source package (http://www.wavpack.com/wavpack-4.40.0-beta.tar.bz2)
Complete sources under SVN (http://svn.slomosnail.de/wavpack)
Cheers!
edit: grammer, swapped links
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
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!
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 ?
Awesome. I quiver with anticipation for the final build.
Keep up the great work because WavPack rocks my Lossless world!!
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 Company4.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 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?
svn revision 41 was packaged for rarewares/debian already !!!
later
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
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
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.
I think adding -x will more or less close the gap:
-hhx
Very true...
but, David had said that the
old "high" mode has been renamed "very high" (-hh)
So, shouldn't -h in v3.41 be the same as -hh in v4.40?
Just wondering....
~esa
[...]but, David had said that theold "high" mode has been renamed "very high" (-hh)
So, shouldn't -h in v3.41 be the same as -hh in v4.40?[...]~esa
Nope: http://www.hydrogenaudio.org/forums/index....st&p=422986 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=47389&view=findpost&p=422986)
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.
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
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.
Plug-in bundled with 4.40.0 beta:
(http://img506.imageshack.us/img506/1117/inwvpl6.th.png) (http://img506.imageshack.us/my.php?image=inwvpl6.png)
The old version (2.3) reports only MSJAVA.DLL as missing but works fine.
i could be wrong, but it seems that you're missing Microsoft's C++ Runtimes(version 8)
Dowloaded "msvcr80.dll" from DLL-files.com, still not working and anyway the previous version doesn't seem to require that.
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).
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.
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(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).
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?
i believe that the C++ 8 Runtimes are installed by default when you install the .NET Framework 2.0(and maybe even 3.0). otherwise, you can get them here.
http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en)
Thank you for your work bryant.
You converted me to lossless.
I've always thought San Francisco could only produce cool things.
i believe that the C++ 8 Runtimes are installed by default when you install the .NET Framework 2.0(and maybe even 3.0). otherwise, you can get them here.
http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en)
Thanks buddy, it worked, tho Winamp takes a little bit more time to load now.
Pardon my ignorance, I'm no dev, but isn't there a way to embed those libraries into the plug-in?
Finally, should't those runtimes be listed as system requirements or are they really common in normal WinXP SP2 installs?
those runtimes are only needed if WavPack or anything else is compiled using Visual C++ 2005(As far as i'm aware). if one were to compile it with another compiler like Intel C++ or MinGW, then the plugin won't use those runtimes.
but in the end, it might result in a bigger dll. it also might be possible to not use those runtimes when compiling with VC++ but i don't currently know how.
i believe that the C++ 8 Runtimes are installed by default when you install the .NET Framework 2.0(and maybe even 3.0). otherwise, you can get them here.
http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en)
Thanks buddy, it worked, tho Winamp takes a little bit more time to load now.
Pardon my ignorance, I'm no dev, but isn't there a way to embed those libraries into the plug-in?
Finally, should't those runtimes be listed as system requirements or are they really common in normal WinXP SP2 installs?
Sorry you had trouble with this (although that's what a beta is for)...
Anyway, I'm glad you're going now, and thanks for bringing it to my attention.
It is possible to build the DLL to not require MSVCR80.DLL, but then it grows to 200K (which I think is a little absurd for a stupid winamp plugin). I thought that the way I did it would be okay, but I didn't try it on enough systems. I could just point people to the Microsoft link and have people install it, but I would prefer that it work out-of-the-box. I expect that at some point all systems will have MSVCR80.DLL just like they all have MSVCRT.DLL now.
Another solution would be to build the winamp plugin on VC 6.0 using the library I build on VC 2005 (I'll probably have to do this for the Nero plugin also). I assume that will work, but with Microsoft one never knows since they claim VC 6.0 is not supported (like Windows 95).
I'm almost sorry I upgraded to VC 2005. What were the advantages again...?
using new runtimes j/k
it could also be possible to compile WavPack using Intel C or even GCC(i personally want to build WavPack under GCC 4.1.1 but stupid MinGW doesn't want to compile it )
btw, is there a Makefile in the SVN? i can only find a Makefile.am which links to a "Makefile" which does not get downloaded.
edit: as for VC++ 2005, i think the only advantages that you can get are in C++(not C). last time i tried C++ with it, it used a "_tmain" function instead of a regular main and the compiler was also complaining about a few things when i was compiling WavPack(fileno in particular).
i personally want to build WavPack under GCC 4.1.1 but stupid MinGW doesn't want to compile it
No problem here...
btw, is there a Makefile in the SVN? i can only find a Makefile.am which links to a "Makefile" which does not get downloaded.
You have to run autogen.sh first (autoconf, automake, libtool needed) to generate the appropriate files. Then configure, make.
I have tested the new version by encoding 124 different files (my FLAC corpus (28), TAK corpus (50) and the RW corpus (46)) using 28 different compression settings. I have compared the MD5 hash of the source WAVE with the hash of the decoded file and all have matched.
I have also tested the new WVSELFX.EXE with embedded cuesheets, and it works as expected (although I would still like to see the cuesheet FILE command corrected upon extraction, at some point in the future ).
Thanks for your continuing hard work David.
Correct as in point to the new [filename].wav?
Correct as in point to the new [filename].wav?
Yes. This has been discussed before when the idea was first raised; I believe that it is on David's todo list, but I think there are higher priorities at the moment. I'm just keeping him on his toes.
Edit: I should point out that for many people it will not
need amending. It has also previously been raised that perhaps it should just be the responsibility of the encoder (user) to ensure that the cuesheet points to a WAVE of the same name before embedding, which makes a lot of sense. If it's a real headache to check and amend the cuesheet upon extraction then I would rather Mr Bryant spent his time on more important things.
i believe that the C++ 8 Runtimes are installed by default when you install the .NET Framework 2.0(and maybe even 3.0). otherwise, you can get them here.
http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en)
Thanks buddy, it worked, tho Winamp takes a little bit more time to load now.
Pardon my ignorance, I'm no dev, but isn't there a way to embed those libraries into the plug-in?
Finally, should't those runtimes be listed as system requirements or are they really common in normal WinXP SP2 installs?
Sorry you had trouble with this (although that's what a beta is for)...
Anyway, I'm glad you're going now, and thanks for bringing it to my attention.
It is possible to build the DLL to not require MSVCR80.DLL, but then it grows to 200K (which I think is a little absurd for a stupid winamp plugin). I thought that the way I did it would be okay, but I didn't try it on enough systems. I could just point people to the Microsoft link and have people install it, but I would prefer that it work out-of-the-box. I expect that at some point all systems will have MSVCR80.DLL just like they all have MSVCRT.DLL now.
Another solution would be to build the winamp plugin on VC 6.0 using the library I build on VC 2005 (I'll probably have to do this for the Nero plugin also). I assume that will work, but with Microsoft one never knows since they claim VC 6.0 is not supported (like Windows 95).
I'm almost sorry I upgraded to VC 2005. What were the advantages again...?
And that's what beta testers/Guinea pigs are for !
Your work is superb, I'm glad if I can help a little.
Outta curiosity, what about the missing MSJAVA.DLL reported by both WA plug-in versions? Does that belong to the discontinued MS Java VM?
Once you get to work on the Nero plug-in I'd like to test the dependency free WA one too if you ever allocate time to that, thanks.
P.S.
There ain't nuffin' stoopid 'bout a Winamp plug-in !
EDIT: Grammar.
Thank you for your work bryant.
You converted me to lossless.
I've always thought San Francisco could only produce cool things.
Thanks. I believe that FLAC was written in this area also, so you may be right!
I have tested the new version by encoding 124 different files (my FLAC corpus (28), TAK corpus (50) and the RW corpus (46)) using 28 different compression settings. I have compared the MD5 hash of the source WAVE with the hash of the decoded file and all have matched.
I have also tested the new WVSELFX.EXE with embedded cuesheets, and it works as expected (although I would still like to see the cuesheet FILE command corrected upon extraction, at some point in the future ).
Wow, that's almost 3500 files! I think that's probably more than I've done...
Thanks, Synthetic Soul, and thanks for testing out the self-extraction also. Yes, I remember about the filename stuff...
Outta curiosity, what about the missing MSJAVA.DLL reported by both WA plug-in versions? Does that belong to the discontinued MS Java VM?
Once you get to work on the Nero plug-in I'd like to test the dependency free WA one too if you ever allocate time to that, thanks.
P.S.
There ain't nuffin' stoopid 'bout a Winamp plug-in !
I have no idea what that MSJAVA thing is; there's certainly no Java in my plugin. Also, since it doesn't show up when
I run Dependency Walker, and you see it with the previous plugin also, I think I'll not worry about it. That is, unless someone has a clue what it might mean.
I didn't mean to imply that winamp plugins are stupid in general. Just
my winamp plugin!
Hello mates.
until now i was using Easy Cd-Da Extractor to encode my cds in Wavpack.
Today i have DL Wavpack frontend and i'll use that one.
Now, excuse me if this is a stupid question, but please tell me what "extra options" should i use. Or, should i use some? If yes, pls tell me what. I want to encode my cds in WavPack.
Also, should i use this beta version for my encodings?
Thank you
this beta should be pretty safe. WavPack also stores an MD5 checksum inside to make sure that the data inside is not corrupted.
as for the extra modes, why bother using them? the only thing they do is increase encoding time(quite drastically at x4-6) and they lower the filesize by about maybe 1 or 2 percent. IMO, x2 or x3 should be sufficient for you since Mr. Bryant recently made them fast enough to actually be usable
i personally use x6 on my comp due to the fact that i mostly use WavPack for storage.
ok. then i will only start Wavpack frontend, add the tracks and click Go!
Thanx
this beta should be pretty safe. WavPack also stores an MD5 checksum inside to make sure that the data inside is not corrupted.
Isn't the -m switch required to compute and store the MD5? If so I would recommend adding that to the command line.
as for the extra modes, why bother using them?
...
IMO, x2 or x3 should be sufficient for you
...
i personally use x6 on my comp due to the fact that i mostly use WavPack for storage.
Confusing.
I would probably recommend
-hxm, which is probably the switches I will be using.
-x modes ( even 4~5) have huge compression gains on some samples like extreme artificial. The gains are less when using the high modes, but are still there.
ok, in conclusion: should i use some switches?
witch one? why?
thank you very much. i'm not into wavpack. i'm just starting
Isn't the -m switch required to compute and store the MD5? If so I would recommend adding that to the command line.
yeah i believe it is. right now, i don't even understand why there even is a switch like that. WavPack should always store an MD5 by default
Guess you are out for lossless encoding for archiving purposes on a pc.
In this case try hx3 to hx5 and use the maximum setting that is done with tolerable speed for you. hx6 is real pain, and I'd avoid it with lossless encoding.
I am personally into lossy encoding and did use hx6 so far. Don't care too much about the extreme time as I don't encode very much. But I reconsider it and I'm not sure myself yet what to do in the future (thinking of hx3 so far, but also considering normal mode x5 for the sake of my DAP's battery drain. Guess I'll do some tests when final comes out).
Could somebody explain me in a few words what hx means.
what the switches are doing? is there any difference in quality (like Lame presets for example)?
any difference in quantity, time?
yes i wanna encod for archiving purposes. i had around 30 dvds with wavs and yesterday i have tested one of them (princo ) and they have a lot of errors. so i won't burn them again as wavs, i have choosed to kill you guys with my stupid questions
cheers
http://www.wavpack.com/wavpack_doc.html (http://www.wavpack.com/wavpack_doc.html)
@yulyo!: I was a total WavPack noob a while ago, but these amazing forums gave me a hand, just browse this thread: http://www.hydrogenaudio.org/forums/index....showtopic=40055 (http://www.hydrogenaudio.org/forums/index.php?showtopic=40055)
EDIT: Grammar as usual...
In this case try hx3 to hx5
As advise for someone new to WavPack, beside the link (http://www.wavpack.com/wavpack_doc.html) Synthetic Soul posted, I would keep it simple.
Try options:
-m (normal)
-m -h (high)
(-m -hh very high in >4.4)
In CDex and foobar2000 add -i (for compatibility reasons).
If you like to try the "extra" modes, just add -x as that gives the optimal number of extra processing.
Forget about -x
n (
n=number) as that will change in 4.4 (soon to be expected).
No, don't forget about -x#, rather experiment with -hx3m.
http://www.hydrogenaudio.org/forums/index....st&p=434911 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=47389&view=findpost&p=434911)
http://www.hydrogenaudio.org/forums/index....st&p=435146 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=47389&view=findpost&p=435146)
EDIT: Swapped links to my posts with ones to the way more useful Synthetic Soul's ones.
I'll be a dissonant voice in this: why not sticking with the default for a start? try the default mode or -h or even -hh
i guess people love their compression ratios
as for -h vs -hh, i've heard that -hh gives only a few bits more compression than -h at the cost of longer decoding time. i personally use -hx6 in my command line since i like big compression but not a big fan of slow decoding.
I'm using hhx3 for stereo files. What I've been even more impressed with is the new --optimize-mono switch, which makes a nice difference with my audiobook masters.
cuesheet extraction from command-line and during self-extraction
great!
will this also be possible for embedded .log?
cuesheet extraction from command-line and during self-extraction
great!
will this also be possible for embedded .log?
Oh boy, I didn't realize there might be more of those!
Maybe I can come up with some generic way of doing this that isn't too complicated. One of the problems is that there is no way to specify options for the self-extraction.
Oh boy, I didn't realize there might be more of those!
Maybe I can come up with some generic way of doing this that isn't too complicated. One of the problems is that there is no way to specify options for the self-extraction.
i think that self extration should just extract everything that has been included before. imho options would make things too complicated.