WavPack 4.40 has been released. 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
• all new documentation on library use and file format details

Many thanks to all the beta testers!

WavPack download page

thanks, david!

i packaged svn r57 for rarewares/debian yesterday.

should be a few days/weeks before the debian devs wake up


later

Thank you very much, David.
Wonderful christmas present.

Great news!! Thanks, David.

Thx a lot David!

Thank you.

Thankyou!

Fantstic! Thank you very much!

Could you share what you're going to concetrate on for the next update please?
I mean, clearly after the holidays at least !

Perhaps them, but not ours: https://launchpad.net/distros/ubuntu/+sourc...4.40.0-0ubuntu1

Thank you, David! This coincides well with my plan to (eventually) re-rip my CDs using the new reference offset . . . That should be fun.

Thanks, David. I've posted an announcement on the Rockbox forums as I believe that this will certainly be of interest to Rockbox users.

Ha! So you're one of the Ubuntu devs, eh?

, no. Just a silly remark. It happens rarely that stuff appears in Ubuntu earlier than Debian.

Many thanks!

it looks like ubuntu needs to add to libwavpack-dev.install:
debian/tmp/usr/lib/libwavpack.la /usr/lib


later

Thank you sir.

RE: http://www.hydrogenaudio.org/forums/index....st&p=451360
The Winamp plugin is now 196 KB uncompressed, does it mean MSVCR80.DLL/VC 2005 Runtimes are no longer necessary please?

RE: http://www.wavpack.com/wavpack_doc.html
WavPack consists of two complimentary executable programs, WavPack and WvUnpack.
I prolly mean complementary, tho they're surely complimentary too ...

EDIT: Docs part.

Awesome release and it contains a lot of great improvements. WavPack just keeps getting better and better. Hopefully, a DAP company will notice and make a player with native wavpack support.

Thanks a lot for update, David. Excellent as always.

And also a question. Some time ago you said something about possibility to improve noise shaping in hybrid mode for lower bitrates. Do you still have such plans ?

Thanks!

I grabbed it and used it to encode a few CDs. They sound great of course.

How much extra compression in lossless mode does -hh give you over the default lossless parameters on average?

http://www.hydrogenaudio.org/forums/index....mp;#entry434911
http://www.hydrogenaudio.org/forums/index....mp;#entry435146

I'm relatively new to WavPack...

Thus far it's worked flawlessly for me. I've been making lossless images of all my discs using v4.31... a few hundred of them actually. Would there be any reason to transcode to the new version? From what I understand... if I use the -hh switch instead of -h, things will be the same... is that correct?

Thanx for the prompt and succinct response. If I'm reading the first chart correctly it looks like you only gain ~1% greater compression with -hh vs the default lossless parameter. OTOH the encode/decode times increase roughly 50% over default.

It looks like it's pretty well tuned for lossless encoding at the default settings and that's how I'll use it.

Thanx again.

Here are some of the things I am thinking about, although I could certainly end up never getting to some of them:

• handling W64 and/or RIFF64 files to get over 4 gig WAV limit, and also updating the library to accept a 64-bit WavpackStreamReader to allow WavPack files over 4 gig (this would be done in a backward compatible way)
• add binary APEv2 tag fields to the library and wavpack.exe (for album art embedding)
• MMX and other possible optimizations to improve decoding and encoding speed on x86
• smart noise-shaping in lossy mode, perhaps a simple quality-based VRB mode (based on tonality)
• winamp plugin enhancements: specify output resolution, multichannel output (if someone can tell me how) and (maybe) tag editing
• audition plugin enhancements: write RIFF info to APEv2 tags, write cues to embedded cuesheet
• add option for new CRC covering raw block data (for decoding robustness & quick verify)
• accept WavPack files as sources to wavpack.exe (with tag copying)
• option to wvunpack to decode a specified time range (or track, if cuesheet present)
• raw encode

and also these related things:

• add WavPack support to SlimServer so I can finally use my SqueezeBox with my favorite format
• repackage tiny_decoder to get out the improvements from Rockbox (including ColdFire and ARM assember code) and some TMS stuff I did for someone else
• release a tiny_encoder that I did for someone else
• do assembler optimization of Rockbox encoding and maybe add lossy encoding too
• add lossy file handling and perhaps seeking support to ffmpeg (if they'll accept my patches...)

Yes, I took the dependencies out of both the winamp plugin and the audition plugin. I may try to build with MSVC 6 at some point in the future, but this is easier for now.




No, I meant that the two programs are very polite and they compliment one another all the time!

Thanks, I'll fix that...



With this release I changed the -hh mode back to be identical to the old -h mode. However, you could transcode to the new version with a -hhx which goes pretty quick and would probably give you another 0.2 percent or so (with no decode penalty). But I wouldn't bother...

Edit: added 4 items to "to do" list that I forgot.

With my test corpus I actually get about 1.5% improvement from default to -hh, so it does depend a little on the type of music (my corpus has a little of everything).

However, with this release, I would recommend using either -x or -hx. They improve the compression over the default about 0.5% (with no decode penalty) and 1.25% (with 1/2 the decode penalty of -hh), respectively. The -x about doubles the encode time, but it's still faster than most rippers.

My top goals for this release were to greatly reduce the use of -hh and greatly increase the use of -x (that's why you see what you see in the "short" help version).

BTW, thanks to everybody for the support!!

I used -hm in the last version before 4.40 and that was equal to the new -hh. The -x is asymmetric favoring decode time over encode.

Compared to LAME encode times, WavPack only encodes for several seconds on my machine anyway even with the -hh equivalent. It flat out flies compared to LAME, but then LAME is shrinking my files to ~15% of their original size even at very high quality VBR.

So it looks like -hxm would get me the most bang for the buck compression/decompression wise and with a md5 checksum.

Thanx David. This program is amazing and after I did some research early this year, I decided WavPack was the best lossless codec for me. I don't even bother ripping CDs with lossy anymore except when compiling mp3 CDs for the car. Then I just transcode the .wv files.

Here's my cmd line for EAC/WavPack v4.40. Please point out any errors.


What does %s %d do BTW?

They're placeholders for the source and destination file locations respectively.

I'd add a comment (-w "Comment="xxxxxxxxxx") with the WV version used and the exact compression switches ("-hxm" in your case).

Like this?

No, it needs not. See https://launchpad.net/bugs/75436

@shadowking, David, and whoever can help:

With new 4.40 I'm about to reconsider which lossy setting to use in the future (so far I have a bias towards new h mode, a higher x value like x5, no noise shaping, and using something in the 320...360 kbps range). I did some trials last night and took up again the idea to use a positive noise shift like s+0.5. This was quite valuable with the problematic samples I tried, and so far I couldn't see a problem with more regular music at 320...360 kbps.

I know from earlier posts that 'normal' music should suffer from a positive noise shift, and I'd like to learn what this exactly means. Can somebody provide one or more samples please?

Thanks!

I used to use the -xml swtch, but with your new friendly -h switch i decided to try -htxml instead. My encoding times have now dropped from 900 seconds to 90 seconds in average for a normal CD. Didn´t expect this.

This is great!

Thanks again David.

.zamel

PS
I really hope to see wavpack on the slimdevice someday
DS

Halb27:

Positive shift helps artificial samples with hf noise (furious, 41secs, keys, velvet) , but most normal stuff works better with negative shift (solo instruments etc). I think in normal situations you might not hear the hiss even with positive shaping +0.5 (rock,metal,pop), but when noise approaches threshold then positive shaping will be worse (classical or solo) - you might have to use 200~250k to attune yourself to effects of positive shifting. +0.5 might be a compromise if you have a rare CD collection with strong mid-high HF noise. Also -x 4 or 5 will give you more security with extreme synthetic samples and extra compression in lossless mode. Maybe David can explain it better, but he said something about it in earlier posts.

Personally I am looking forward to the smart shaping algorithm in 4.3 alpha branch and VBR quality modes. Hopefully vbr will simplify things by eliminating bitrates, h/x modes etc etc. I haven't decided what on settings for 4.4 so I 'll use -s0hhxb320 which is the same as my 4.31 settings.

audioaficionado:

I believe that he meant a COMMENT tag, i.e. "COMMENT=WavPack 4.4 -hxm" (replace the gray text with whichever format you wish to use to store the codec/settings data). I personally wouldn't have a need for such a thing, but many people may find it useful.

Not quite, rather like this:

-w "Artist=%a" -w "Title=%t" -w "Album=%g" -w "Year=%y" -w "Track=%n" -w "Genre=%m" -w "Comment=WV 4.40" -hxm %s %d


It's pretty handy when a new version comes out and you want to convert all your files to it as the benefits are worth the trouble (like better DAP support in this case) but you don't have the whole of your archive encoded with the same previous release, with such a comment differences can by spotted rather quickly via a mere tag editor without a deeper file analysis.

Thanks for the answer. This is what I learnt from earlier posts from you and from David. It's plausible to me, but to really get an opinion towards that I have to hear the problem for myself. That's why I hoped I can get a sample with known issue. Will try and find one/some tonight using low bitrate as you suggest.

The idea behind it is:
a) though I don't care very much about extreme samples like badvilbel I do care enough not to accept very audible deviations from the original. That's why I will never use a bitrate below 300kbps though b288x3 is good enough to me with regular music and even not-too-extreme problem samples as I found out last night.
I don't care about each extremely problematic sample in the same way, not so much for electronic music for instance, but samples like Atemlied are of concern to me. I absolutely dislike the deviations there.
b) On the other hand if deviations from the original sound more or less like noise from a tape recording, and if this noise has very low volume, and hopefully it is audible only in rare cases, I can accept this behavior quite well.

I guess using a positive noise shift works in this direction. Last night's experience makes it plausible concerning a) - though I have to learn more.
b) is the more critical point to me as I don't have any experience so far. But when I will try a lot of samples and won't find an issue that's experience too.
Maybe my restricted HF listening abilities are a point for a positive shift too (when trying to find problems with 16 kHz limited Helix mp3 I just found one spot with missing HF after listening to many tracks - and it was not annoying).

I once tried smart shaping and was not very happy with it. I preferred s0. Searching for this this morning I also found some warnings against adaptive noise shaping - sounds like the change in noise shaping can cause an audible issue.
To me the idea of ATH curve related noise shaping sounds more promising. But I'm not an expert.

As for the benefit of x5 for extremely problematic samples I can confirm this from my last night's experience.

I see that the latest Winamp still has no Wavpack input plugin out-of-the box. That should really help Wavpack's popularity. Especially that the latest Winzip employs Wavpack to compress audio files.

So, David, have you get in touch with the Winamp guys like MedO, benski, & others?

I have uploaded the three samples that I believe den provided when he first started hearing that noise. I also believe that there was no negative shaping at that time, so these would have been with no shaping. Keep in mind that the noise in these tracks is very high in frequency, completely different from the midrange noise that gets improved with positive shaping. If your hearing drops off at 15 KHz like mine, you probably won't be able to hear it (I don't think I ever did). Also, den used to refer often to the high volume he was using. It should be easier to hear with +0.5 shaping (he said that made it worse). The samples are here.

Good luck!

I haven't, but maybe one of them will be reading this thread.

Obviously having WavPack come with winamp would be great, but I never would guess that it was just a case of "he never asked"...

Thank you very much. Will try them tonight.
As my hearing drops as well at such high frequencies this is the very idea behind it: put the noise where I don't hear it. (and why I'd prefer a ATH curve related NS approach).
So far from intensive listening to 'simple' piano, guitar, flute and vocal music with a lot of 'space' around the notes s+0.5 was okay to me. The few spots I found that weren't perfect weren't really problematic and I will find out tonight if s0 is better on them (so far I tried just s+0.5).
BTW I also tested guruboolez' bruhns with blizzard hiss as he called it (using s0 and s0.5). To me the blizzard hiss is gone which I remember I could hear easily. Was 4.40 tuned towards bruhns?

I am not sure what could contribute to improved lossy quality. I certainly didn't concentrate on that this time or tune for any sample. With the -x modes there should be less switching between TS and JS for samples that are on the cusp, and there was a bug fixed that would have (in 4.3x) caused the noise to be improperly balanced when TS and JS switched. Perhaps those are contributing.

As for ATH noise-shaping, I don't remember whether I tried that in the past (need to start taking notes). It certainly would not be a big deal for lossy only (but hybrid lossless would not be compatible). My concern is that the predictor won't work as well with that HF noise in there, and the overall gain in noise would partially offset the reduction of noise in the audible range. You can actually see that now if you encode a track with noise shaping of, say, -0.75 and +0.75 and measure the total noise with (-n). Those two should be identical, but the one with positive shaping will generally have more noise.

In fact, one of the reasons that the noise shaping is where it is now (-0.5) is that in many cases it's almost free. In other words, the reduction of noise at the high end improves the prediction so much that there's virtually no overall increase in noise. Of course, when the material has lots of HF material anyway, this advantage disappears (which is what the smart shaping is supposed to handle).

I finished my test.

As suggested by shadowking I first tried to hear the difference s0.5 gives against s0 at 200 kbps.
I did listen only to a few tracks cause quality was real bad, not just hiss, but inprecision all over the place. Using s0.5 made things considerably worse than s0.

Then I decided to go halfway up to 320 kbps and tried 260 kbps.
Quality was remarkably good to me, and it took me some time to find samples with audible noise. With these s0.5 made things worse (for instance with George Winston's Carol Of The Bells at the very start). However it was not a lot worse and without abxing I guess it would go unnoticed, at least by me. Moreover it really resembled noise from tape recordings.
With your samples, David, I couldn't hear a problem, but thank you anyway.

I went up to 320kbps and 350kbps with these samples. I could not significantly abx the problems in this range, but I must say I was pretty often sure to hear the difference and it was true.

So it makes me a bit uncomfortable to use s0.5, also because I've learnt from your post, David, that prediction behaves worse with a positive noise shift so that total noise increases (though it's an interesting question to what extent this is audible).

As I want to play it safe cause I don't use a lossless archive in parallel I will not use s0.5.
I will do a compromise and use s0.2, and new h mode as well as x5 at 350kbps.
This makes Atem-lied very acceptable (which is important to me as the Atem-lied noise sounds like an artifact). I didn't retest again the s0.5 samples with added noise (I'm absolutely fed up with abxing right now), but because of the s0.5 results which weren't abxable by me things should be fine using s0.2.

Thanks again for all your help, David and shadowking.

Thanx for the clarification of both questions.

Can you also add other -w "Comment=" strings too? What is the limit on comments?

The limit is one. If you want to add multiple items then I would simply separate them with commas (or something):

-w "Comment=EAC V0.95 beta 4, secure mode, WavPack 4.40 -hxm, etc."

This started out as a simple test of foobar2000 decoding speeds on a laptop I have access to, that I did to decide where the "sweet spot" was for my particular likes in music and choice of system and player, but I think it might provide a useful reference to other users -- even if there are better lossless comparisons out there.

This is with WavPack 4.40 final, and the maximum setting is -hhx6, the high setting is -hx6, and other settings are the default.

Thank you for the release and all your work.

I've added results for some other lossless decoders with my simple test corpus but without the decoding speed results since there is no foobar2000 support for these formats:

LiteWave - 63.9 -> 43.3MB = 32.24% reduction
RKAU l1 - 63.9 -> 37.9MB = 40.69% reduction
RKAU l2 - 63.9 -> 37.8MB = 40.85% reduction
RKAU l3 - 63.9 -> 37.7MB = 41.00% reduction

I want to test the open-source bonk codec, and I'd love to test TAK, but I don't have the time to properly do such yet. I'm considering using my own testing script to test on two other sample corpuses I have. I can do so if anyone is really interested in yet another lossless encoder comparison ™.

It works like a charm and even shows up in Winamp file info.

This is a great program! Thanx again David for sharing it with us.

Well, with FLAC the problem was the GPL license. After Josh changed the license and tell the Winamp guys, the next Winamp installer has FLAC support built-in.

I don't see anybody noting that development builds of the OS X program Max incorporate Wavpack ver 4.4:
http://svn.sourceforge.net/viewvc/macaudio...p;revision=1093