1. Java version of WavPack decoder

This was written by Peter McQuillan (who also wrote the WavPack plugin for the Rokulabs HD-1000) and is based on the WavPack tiny decoder. Like the rest of the WavPack sources, it's released under the modified BSD license and is available on the WavPack download page here.


2. WavPack command-line encoder enhancements

I have added a couple of features to the command-line encoder. The first is to support multichannel WAV files that do not have the WAVE_FORMAT_EXTENSIBLE header and do not use the standard Microsoft channel order. I have done this with an option --channel-order that allows the user to exactly specify the included channels and their order (use the --help command to see list of speaker names). For example:

Note that this is done before any other processing, so that if the resulting WavPack file is restored using WvUnpack then it will have the new channel order and will not match the original file. It might be a good idea to use the -r switch when packing (or -w when unpacking) to force the creation of a new WAVE_FORMAT_EXTENSIBLE header (although this will discard any extra RIFF information that might be contained in the original file).

BTW, one could even use the WavPack output piped to WvUnpack to just reorder the channels in existing WAV files and/or append the extended format header.

I have also, as promised months ago, ported the dynamic noise shaping feature from an earlier experimental version. The option is --dns and is currently available with hybrid lossy mode only (i.e., it doesn't work with correction files). Its purpose it to improve the quality of WavPack lossy mode in those cases where large high frequency content causes too much audible noise to be added to the midrange. It accomplishes this by detecting these cases and (as its name suggests) dynamically changing the noise shaping profile to shift more noise upward in frequency where it will hopefully be masked by the content.

This is not a perfect fix, but I think it does make a significant improvement in those cases that have proven to be the Achilles heel of WavPack lossy (e.g., the "furious", "keys" and "bibilolo" samples). I have also implemented this in such a way that the "extra" mode works well with it and provides an additional improvement in most cases.

I have also found that using shorter blocks in conjunction with the "extra" mode makes another significant improvement in some cases, probably because it can then respond more quickly to audio changes. A blocksize of 4410 works well and adds less than 10 kbps to the resulting output.

http://www.wavpack.com/files/wavpack442a.zip


3. Winamp plugin enhancements

In case some people haven't noticed, there is an alpha version of the winamp plugin for WavPack that has several improvements:

• Unicode support for info box and media library
• added option to pass multichannel audio to output
• added option to pass all audio as 16-bit (for better compatibility)
• added option to output 24-bit audio when ReplayGain is active
• changed high-resolution output from 32-bit to 24-bit (allows winamp EQ to work, and probably other things)
• fixed bug that caused the seek bar to sometimes vacillate when moved
• performance enhancement from 4.41
• added genre display to info box

http://www.wavpack.com/winamp_alpha3.zip


4. Cowon A3 PMP support

The new Cowon A3 PMP, which was just shown at the big European consumer electronics show IFA last week, contains support for many audio and video formats including WavPack! The support for WavPack is very complete also, including lossless and hybrid lossy files in all modes and bitdepths (including float) and even handling legacy files back to version 1.0 and WavPack embedded in Matroska! I have not found an official announcement in English, but here's a description with specs on the Cowon Germany site.

Cheers!

David

edit: fixed link

Thanks David for all the good work and its great that Wavpack hardware support is growing.

Thank you very much, David. Great news!

As for the benefits of shorter blocks when using -x mode: Do you use shorter blocks internally or do we have to specify explicitly a shorter blocksize like 4410 on the commandline?

I also found A3 specifications on official russian cowon site:

I just did a short test using -fb400x6mi -dns with the wavPack hard samples and some more.
Great quality ! Even fast mode does the job at 400 kbps.
Ooops, not exactly. I happened to have the -c switch on. Great quality this way - correction files seem to work. Not exactly the same picture without the correction files. I'll repeat my test.
I just did a short test using -hb400x4mi --dns --blocksize=4410 with the wavPack hard samples and some more.
Great quality (except for bibilolo but we can't expect miracles to happen).
I also tried normal and fast mode, and quality is adequate with these lower quality settings IMO.

I'm glad to see a well-known manufacturer supporting WavPack so well. I guess you're very happy too :-)

Furious & aps killer sample sound really good . I used --dns x4 b320.. I'd have to be in an abx to tell them apart. i'll post more later on.

A very small test at the smallest (and not recommended) bitrate with a problem sample for WavPack lossy: --dns increases a lot the audible noise, especially at the beginning of the sample. Could someone check it (and maybe try at different bitrate)? I have to go now.
download link:
http://rapidshare.com/files/54409437/S37sample.zip

Hard stuff. Extremely bad at 200 kbps with and without --dns, but worse with --dns.
At 300 kbps things are still bad (I tried -b300x4mi with and without --dns). But at the spot which is worst to me (sec. 2.0 ... 4.0) --dns is not very annoying whereas not using --dns is.

Yeah I have that sample for a while now. A note about quality / bitrate: I find that the quality bump from 200 - 230k is huge, below 230k quality drops rapidly and is not worth using or testing.

I tried b320x4 --dns blocksize=4410 and it sounds perfect without trying too hard. Its another sample that need high compression setting:


-fx : 59.91 %
-fx3 : 61.06
-fx4 : 61.36
-x : 61.38

-x4 : 64.38
-hx : 64.25
-hx3 : 65.49
-hx4 : 65.65

IMO wavPack lossy should not be used below ~ 250 kbps. It's not competitive with mp3 & co.
From ~250 kbps on it is attractive for the practical minded who care about average behavior and don't care about worst case behavior.
But the real benefits against mp3 & co starts at a bitrate considerable higher. It's a personal decision where to put the sweet spot average behavior against worst case behavior. After all it's lossy.

The good news with David Bryant's current success is: wherever you put the sweet spot in the 300+ kbps range, it looks like you have a significant quality robustness advantage compared against what we had so far.

At 320 kbps --dns considerably lowers the amount of audible noise. It works with -b320, -b320x & -b320x4.
ABX test was nevertheless still very easy with -b320x4 --dns:


-b400x4 --dns improves quality a lot; it's now close to transparency but I can still ABX one part (3.80...4.50):


Comparison between -b400x4 --dns and -b400x4 is nevertheless easier: --dns has a clear positive effect here.

Conclusion: this sample is still a serious problem for WavPack lossy.

Yes, MartenotWaves is a wavPack hard sample , and I could abx it 10/10 using -hb400x5mi.
Using an explicit blocksize of 4410 doesn't really improve things (8/10, but I did it before not using an explicit blocksize so wasn't so much acquainted to the sample).

With bibilolo the 4410 blocksize makes things worse to me compared to not using an explicit blocksize.

Anyway --dns does a great job.

Before this very version the biggest problem was that due to wavPack hard situations there was chance that noise made into the sensitive midrange area and was unmasked there, and as a consequence sounded more like distortion than like noise/hiss even at high bitrate.
This was why I preferred a strong positive noise shift and very high bitrate.

This problem is gone using --dns.
The remaining problems with bibilolo or MartenotWaves are that of noise/hiss as is to be expected with extreme situations also at a bitrate of 400 kbps.
More important, as it's not too obvious noise/hiss it can be easily accepted IMO for such extreme situations. In normal listening situations outside ABX it may well go unnoticed (bibilolo's problem is very easily audible only when volume is turned up. That's the usual problem with low-volume samples. It's still a problem at normal volume, but not so easily audible).

I'm absolutely happy with such a great quality at 400 kbps with the lossy variant of a lossless codec.

And who knows - one day David may surprise us with a quality control which allows for an average bitrate of say 350 kbps normal mode while keeping track of perfect quality in so extreme situations as with bibilolo or MartenotWaves.

About a --dns option of Wavpack 4.42, I feel like not working for some reason well.

It is described to appoint it with --dns in Help, but a practice result of noise shaping is not displayed even if I do the option and appoint it.

C:\wavpack442a>wavpack.exe -hb200 -j0 --dns D:\フラジリア.wav d:\fra--dns.wv
WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.42.0-alpha
Copyright © 1998 - 2007 Conifer Software. All Rights Reserved.

created d:\fra--dns.wv in 19.44 secs (lossy, 199 kbps)

When I appoint an option with -dns and encode it, a result of Noise Shaping is displayed.

C:\wavpack442a>wavpack.exe -hb200 -j0 -dns D:\フラジリア.wav d:\fra-dns.wv
WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.42.0-alpha
Copyright © 1998 - 2007 Conifer Software. All Rights Reserved.

ave noise = -34.95 dB, peak noise = -26.32 dB
created d:\fra_-dns.wv in 18.22 secs (lossy, 199 kbps)
deleted source file D:\フラジリア.wav

It's very gratifying to see a major manufacturer work to make so many different codecs available, even on a high-end device like this. I think that HA members should reward Cowon for this behavior and buy A3s when they become available (I'll be getting one, obviously). Perhaps they'll extend some of this to the iAudio line!



After reading this (and halb27's struck post above) I realized that making the option --dns was a bad idea because someone could accidentally type -dns instead, which is very bad because it actually enables three options (-d for delete source, -n which displays noise, and -s which turns off noise shaping)!

In your first example you should be getting the dynamic noise shaping, but there is no special message displayed to verify it. If you add the -n option you will see the noise measurements and you should see some difference if the --dns is activated (and at that bitrate you should probably hear it). However, for many samples without lots of high frequencies the mode may actually not do anything.

I was originally going to make the option --dynamic-noise-shaping but I thought that could get a little annoying. If it proves to be generally useful, I suspect that I'll just make it on by default (for appropriate sample rates) and allow the -s option to disable it.



Thanks for the sample (and results); I have added it to my test corpus.

This is an interesting one because it doesn't have that much high-frequency component and the --dns only really activates at the 3.5 to 4.2 seconds area. As shadowking suggests, just adding -h to your -b400x4 --dns reduces the noise at that bad spot by over 6 dB and (I believe) completely fixes the sample (although I know you are concerned about decoding speed).



Yeah, I believe that there are two answers to this issue. After some testing (and feedback here), I believe that something like -hb512x6 --dns --blocksize=4410 would probably provide transparency in virtually all cases. However, this is a big waste of bitrate when many samples are transparent at 320 kbps (and some are at 256 kbps). The trick is to figure out some way to determine the "problem" samples and crank up the bitrate for those, and I believe that something as simple as an FFT-based tonality estimator would work very well for this. However, it's still a rather ad hoc, brute force solution that is probably prone to being broken from time to time.

A more intelligent solution, I suspect, would be something along the lines that David Robinson is pursuing with the so-called lossy FLAC, and I am now looking into implementing something along those lines. I already have some of the groundwork done from when I abandoned the "quality" mode of WavPack lossy, so this should not be starting from scratch. The only missing ingredient is sufficient time...

Anyway, thanks to everyone for your testing and feedback!

Sounds very, very good.
So far I'm very happy with your great --dns method.
Thank you very much.

If you like, you can call it --dyn-ns (in the next alpha)?

YES!

I was getting an A3 and was sort of sad that I was going to have to encode all my wavpack files into FLAC. But now I don't! Awesome!

And for the record, who called it?

Fantastic news! Mighty glad for the Cowon support!

Will start testing the new alpha pronto.

Could it be the new alpha is slightly faster?

More testing needed or approaching beta stage?

I'm currently working on getting the --dns mode to work in hybrid lossless mode also (i.e., with correction files). Then I'll be ready for the beta, or another alpha (because this involves some bigger changes than the pure lossy version). Should be a few more weeks...

As for the performance difference, there certainly isn't anything different on purpose. However, I find that there is a little random variation between versions, so it's not unlikely that it might be a little faster in some modes (although it might be a little slower in others).

David

Apparently the delivery on this slipped a little, but it is now described on the official Korean Cowon site:

http://product.cowon.com/

Click on the picture of the A3 and then scroll down. Most of the text is Korean, but there's a WavPack logo in one of the pictures!

I also hadn't noticed before that it also has HD component video output. Pretty cool!