I have added two new features for this second alpha. The first is the --dns (dynamic noise shaping) feature now works in hybrid lossless mode (i.e., with correction files). This was quite an undertaking because to make it work well I had to introduce variable length blocks to make the shaping closely track the source. There is some loss of compression efficiency with some material, but it seems to be less than 0.5% on average, and maybe 1%-2% on worse case samples. The upside of this is that it seems to work particularly well with the “extra” mode because the block boundaries tend to be at actual transitions in the audio. I left the option name the poorly chosen --dns because I suspect that I will remove the option altogether and simply make it the default (it will be possible to defeat it by specifying a numeric shaping value with -s).

Variable length blocks have always been in the WavPack specs but obviously haven't been tested much before now. I tested these files with Rockbox and Cowon and FFmpeg, but there still could be a problem with something (hmm, maybe I should test with the Java decoder...)

Once I had variable length blocks going, I had an idea for using them with the lossyWAV output (described here and here). WavPack becomes less efficient with shorter blocks because of the almost 100-byte overhead for each block, which is why it gets pretty bad (compared to other compressors) with blocks of only 512 samples. But, in the case of lossyWAV, consecutive blocks are likely to have the same redundancy (especially as the block length gets shorter) so I thought that if I could combine blocks of the same redundancy into longer blocks (but still reserve the ability to have an isolated short block if it was worth it) then I could have the best of both worlds. The new option to accomplish this is called --merge-blocks and is only available in the pure lossless mode and when you have specified a block granularity with --blocksize. It's possible to specify very small blocks (like 32 samples!) and still get very good results without even knowing what the native block size is on the lossyWAV file.

I have put a warning in this version about not using it for important stuff because it's a lot more modified than the previous alpha and I don't know if these variable length blocks are going to cause any trouble.

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

Thanks in advance for any testing or comments...

David

Great work, David, thank you very much.

I'm pretty busy with the lossyWav project, but I will encode part of my archive and put it on my DAP (Rockbox armed iRiver H140). I will report on it.

Codec_block_size is currently under review in the lossyWAV project. Taking into account what you have just said, it would be sensible to require that codec_block_size in lossyWAV is required to be a multiple of 32 samples.

Great work David.

Thanks, guys!

Actually, a multiple of 32 is not a necessity.

Ideally you would tell WavPack the actual block size to use, like 512 or 1024, but it could be any size, like 777.

However, I was thinking of the case where someone had forgotten the block size that lossyWAV generated, or they had added or deleted some samples from the beginning of the track so that it had unknown alignment. Then you could specify a very short block size (like 32) and WavPack would work pretty well at figuring out where the boundaries were (with a granularity of 32). But if you know the size is 512 and you specify 32 then you're not gaining anything and actually wasting some time doing extra searching.

On the subject of lossyWAV, I wrote up a batch file for use with foobar2000 to convert stuff to lossyWAV+WavPack. With the assumption that you're going to be sticking the files into a portable player, bruteforcing a -1dB peak isn't really *that* destructive for the sake of compressability. *prepares to be crucified*



I used sox to apply a 0.88 volume scaling, but that's just an approximation of -1dB. If anyone knows any other method that doesn't feel like so much brute force, do feel free to tell me.

EDIT: Hmm... it looks like I might have posted too soon - it seems to choke on filenames with spaces in them despite quotes being used properly in all of the command lines...
EDIT2: Fixed the issue

In foobar2000, when you choose convert, you can adjust the volume in the "Replaygain Processing" options

ah i forgot to let you know, david, that i checked out 4.42a2 and packaged wavpack & the new xmms-wavpack plugin for rarewares/debian.

thanks!

Howdy, any news? Still in alpha state? Thanks.

Yes, it's still in alpha. However, it has proven to be extremely stable and I don't think that anyone should be hesitating to use it just because it's not released (unless, of course, they don't know about it).

Unfortunately I've been so busy at the startup company I joined that I haven't had time to make an official release, but I should be able to squeeze it in sometime this month.

Thanks for the interest!

What?!? You're favoring paid work over our sucking up and appreciation??! Unbelievable...