Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WavPack 4.42 alpha2 available (Read 16406 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.42 alpha2 available

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

WavPack 4.42 alpha2 available

Reply #1
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.
lame3995o -Q1.7 --lowpass 17

WavPack 4.42 alpha2 available

Reply #2
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.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

WavPack 4.42 alpha2 available

Reply #3
Great work David.

WavPack 4.42 alpha2 available

Reply #4
Thanks, guys! 

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.
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.

WavPack 4.42 alpha2 available

Reply #5
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*

Code: [Select]
REM usage in foobar2000:
REM extension = .wv
REM addl params = %s %d
REM program = whatever you name this batch file
@echo off

REM reduce the volume of full range clips to -1dB at highest,
REM to prevent lossywav from complaining about clipping, etc
REM i had sox in PATH, so you may have to specify a full path
sox -v 0.88 "%~f1" "%~dpn1.vol.wav"

REM tested with lossywav 0.60
REM i had lossywav in PATH, so you may have to specify a full path
lossywav "%~dpn1.vol.wav" -3

REM the -x is for a bit extra compression, not really necessary
REM requires wavpack 4.42 alpha 2 to work
REM i had wavpack in PATH, so you may have to specify a full path
wavpack442a2 -x --merge-blocks --blocksize=512 "%~dpn1.vol.lossy.wav" "%~dp1%~2"

REM removes the intermediate files that sox and lossywav create
REM foobar removes the original temp wav, but not the others
del "%~dpn1*"


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

WavPack 4.42 alpha2 available

Reply #6
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. 

In foobar2000, when you choose convert, you can adjust the volume in the "Replaygain Processing" options 
In theory, there is no difference between theory and practice. In practice there is.

WavPack 4.42 alpha2 available

Reply #7
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!

WavPack 4.42 alpha2 available

Reply #8
Howdy, any news? Still in alpha state? Thanks.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack 4.42 alpha2 available

Reply #9
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! 

WavPack 4.42 alpha2 available

Reply #10

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... 
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100