David Bryant released today WavPack 4.3

WavPack is a high quality, efficient and featureful lossless/lossy/hybrid compressor. It is available for free, including source code released under a very liberal license.

Changelog is available in next post.

Obtain the Win32 binaries and plugins at WavPack's official site:
http://www.wavpack.com/
And compiles for several *nix platforms at RareWares:
http://www.rarewares.org/lossless.html

WavPack release 4.3 changelog:


wavpack.exe (command-line encoder) - 4.3
----------------------------------------
fixed: bug causing termination error with very wide screen widths
added: command-line option (-l) to use low priority for batch operation
added: command-line option (-r) to generate a fresh RIFF header
added: debug mode (rename to wavpack_debug.exe)
added: automatically detect lower resolution data even without -x1
added: src and dst dirs are searched also for tag source files (handy for EAC)
added: wildcard accepted for tag source files (handy for EAC)
added: handle non-standard sampling rates
improved: returns error status for any error
improved: use longer blocks in multichannel files (better "high" compression)

wvunpack.exe (command-line decoder) - 4.3
-----------------------------------------
fixed: very rare decoding bug causing overflow with hi-res files
fixed: bug causing termination error with very wide screen widths
fixed: formatting error in duration display
added: command-line option (-ss) to include tags in summary dump
added: command-line option (-l) to use low priority for batch operation
added: debug mode (rename to wvunpack_debug.exe)
improved: returns error status for any error
improved: more robust decoding of damaged (or invalid) files

in_wv.dll (winamp plugin) - 2.3
nxWavPack.dll (Nero plugin) - 1.2
WavPack_Apollo.dll (Apollo plugin) - 1.3
cool_wv4.flt (CoolEdit / Audition filter) - 2.6
-----------------------------------------------
fixed: very rare decoding bug causing overflow with hi-res files
improved: handle ID3v1.1 tags (now includes track number)
improved: more robust decoding of damaged (or invalid) files
added: handle non-standard sampling rates

foo_wavpack.dll (foobar plugin) - 2.3
-----------------------------------------------
fixed: any error during WavPack file open caused crash if wvc file present
fixed: very rare decoding bug causing overflow with hi-res files
improved: more robust decoding of damaged (or invalid) files
added: handle non-standard sampling rates

WavPack Library Source Code - 4.3
---------------------------------
fixed: very rare decoding bug causing overflow with hi-res files
added: automatic generation of RIFF wav header during encoding
added: new functions to access tags by index (instead of item name)
added: automatically detect lower resolution data during encoding
added: handle non-standard sampling rates
improved: more robust decoding of damaged (or invalid) files
improved: use longer blocks in multichannel files (better "high" compression)
improved: two structures renamed to avoid namespace conflict
removed: legacy code for Borland compiler

WELCOME to the new baby, and a great THANK-YOU to David! (Yes, to you too, Roberto! )

Sergio

Thanks, Roberto.

BTW, another important item not in the changelog is the new plugin for Steinberg's WaveLab 5 that's available. Anyone who got the first one should grab the latest updated beta:

http://wavpack.gl.tter.org/

Thank you David !

Muchas gracias, David!



Now all we need is for Andre to fix the file-extension error in EAC, and voila!, single step rip/compression/cue-embedding!

EDIT: added "rip".

Thank You David.

That -l switch will shure come in handy for archiving the mixes of our show here.

Thanks a lot! There's still the filename bug though, where a file with special chars in its name is "not found":


On another topic, the detection of oversampled content works beautifully. I tested the stereo mix of the R.E.M. - In Time DVD-Audio with wavpack -hm; version 4.2 produced 2.659 GiB worth of data, versus 1.846 GiB for v4.3, for the same encoding time :-)

The file extension issue doesn't stop you doing any of these.

I don't think foobar pays any attention to the FILE command in an embedded cuesheet.

thanks alot for your great work.

Great work bryant! Much appreciated.

Is this next for 4.4?

Great work! Hope WavPack keeps getting better and better.

An early Xmas present. Thank you!

You're right Synthetic Soul, it does work, Muchas gracias!
I had tried it with an already ripped and renamed WAV and it worked, but I thought that going straight from rip to encode to embed wouldn't work because of the extra extension.

Haha, just a day after I finished archiving my dvd-a rips with 4.2 =)

I'll give it a run and see how it will handle them compared to 4.2.

What a timing

OK, I reconverted one of them, and went from 4678 kbps (4.2) to 4671 kbps (4.3). Using the same settings (lossless, high).

Am I missing some kind of special switch used specifically for hires audio here?

I use -hx6 for MAXIMUM compression of DVD-Audio. I don't care how long it takes to encode, and it plays back as fast as -h that I can tell.

Extra modes should actually be slightly faster (decoding) than -h.

Interesting. I guess thats what I get for using a frontend and not checking properly the documentation. I'll try to redo it with -hx6 and see if there are any big differences.

Could anyone explain what are these new features for and how do they work?

If you specify "-w CUESHEET=@cdimage.wv.cue" WAVPACK will look for cdimage.wv.cue in three folders (in addition to the folders in PATH):

1. The folder in which WAVPACK resides
   
2. The folder in which the source WAVE resides
   
3. The folder in which the WV file is to be created

Edit: obviously if you are using STDIN or STDOUT then only two folders are valid.Wildcards can be used like "-w CUESHEET=@*.cue". This will only work if there is one .cue file in the folder. It is useful when the cuesheet name changes per image, but you don't want to have to change your command line every time you rip.

I rip to a "clean" directory from EAC, so it is useful to me.

By using "-w CUESHEET=@*.cue" WAVPACK will first check the folder in which WAVPACK.EXE resides for a cuesheet. When unsuccessful it will check the directory in which the temporary WAVE file resides - where it should successfully find the cuesheet EAC just created.

May I suggest using -hx only. I have encoded few albums with -hx and -hx6 and there was only 1-2 kbps difference in bitrate but the encoding time difference was like 3x or something.
EDIT: With albums, I mean normal audio CD's.

Honestly, I believe hx6 is madness. It takes ages to encode and won't do much better than, say, hx2 - that is several times faster.

I agree. I've always used -hx2m for encoding any audio. It's encoding speed is speed comperable to flac and compresses a good bit better in some cases. x6 is way too slow. Generally if it takes longer than the length of the track I would consider it too slow unless it really made difference. Glad to see 4.3 released, been busy re-ripping some stuff I ripped wrong using wavpack. Looking forward to any improvements in speed and compression in 4.4.

Just for the record, I still recommend using the -x option by itself, with no numeric parameter. In the past there was some logic to using -x1 because it would detect low-resolution files, but now this is handled by default, so there's no reason for that anymore. Please refer to this post:

http://www.hydrogenaudio.org/forums/index....ndpost&p=286569

There's nothing wrong with using the numeric parameter, but using -x by itself assures that you're probably getting the best "bang for the buck" for all the extra time you're using. The only exception to this is -hx6 if you absolutely must have the maximum compression and truly don't care how long it takes (like Kazuma).

or me.

...or me, for high res audio.

-hx6 took about 14 hours to encode but the bitrate went from 4671 to 4526 here.

Well, I have time to spare for encoding...

Have you tryed plain -hx ? I have no HiRes audio to test with.

24 bit, 96 kHz stereo sample

Hi, I can't seem to find a way to export the MD5 hashes created by wavpack to a text file.

Is this possible? How do I do it?

thanks.

I've tested -h vs. -hx with a upsampled CD track to 24bit/96kHz.

24bit/96kHz - 156 MB
WavPack -h - 95,5 MB
WavPack -hx - 78,8 MB

not bad for -hx ... but it took a long time on my P3-700

.halverhahn

Apparently this sample isn't available any more...

Do you think this is representetive of true 24/96 material in terms of samples distribution?

Sergio

maybe i was searching for the wrong thing as i only found a few results but if you want some hi res stuff you could try this link

just figured it out

wvunpack -s "wavpack file path and/or name here" > "text file path and/or name here"

i've been using flac mainly so i have a question about this option.

wouldn't it be better to have an option to not store any particular riff headers in the first place? and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?

to me this is a slight distinction between a compressed file (wavpack) vs. a compressed audio format (flac, ...).

Can't you store headers of whatever format you support - be it WAV, AIFF or MKA - and still offer format independency?

Or are you buying into Coalson's arguments not to offer RIFF storage support?

personally, i haven't encountered any riff header information that i'd want to keep. that's because i mainly deal with lossless as a format for cd backups.

of course there's the argument of treating files vs. treating pure audio data and i have to agree i like flac's approach.

edit: additionally, i think that metadata should be transferred to the format's own metadata format instead of storing the original file as-is.

Many people have use for the extended RIFF info, mostly people dealing with audio editing and mastering.



What's the difference for end user? IMO, WavPack just caters to a wider audience with native header storage support. For the usual CD ripping guy, using either format leads to the same experience.



And indeed, it is stored in special locations inside the WavPack file, and if appropriate - E.G, in the lite decoder - the unnecessary data is ignored. That's how I understand it, at least.

that's true if you are not one of those people (i.e. me) that don't like storing redundant or unnecessary data.

one could argue that using a compressor that gives larger files is against that doctrine, but i think that's another issue.

anyway, my question was not to promote flac's approach. i just think that an option to either store or not store riff headers at encode time would be a better approach than an option to remove them upon decoding. that is assuming the option only works on decoding.

Check it again under which program this option is listed.

*blush* so that means wavpack throws away any existing riff headers, generates a new one and stores that instead of just storing nothing and generating a fresh one upon decompressing?

Yes

I too plan to start using the new switch on my encodes from now on, as I too have no use for extra header data.

Not realy but the upsampled CD-Track contains nothing above 22050hz. You see how good WavPack perform with bandlimited HD-Source material.

This idea that WavPack and FLAC are fundamentally different because one compresses files and the other compresses audio is no longer true. The current native WavPack format is not tied to a particular audio file format. It is the case that the command-line compressor only accepts wav files and the unpacker only generates wav files (or raw audio data), but this is because not a single person has ever asked for any other format. I could easily add other formats without breaking anything.

I have dedicated two metadata field ids for storing images of the RIFF data so that a wav file can be perfectly recreated (one is for RIFF data that comes after the audio). But these fields are not required to interpret the audio information, are ignored by plugins (except Audition which uses them), and do not restrict the format in any way. A similar mechanism could be added to FLAC so that it too could, if desired, make perfect copies of wav files. Certainly this would not hobble the format or detract in any way; it would simply be an additional feature. (I am, of course, not suggesting this be added to FLAC. Given the enormous popularity of FLAC, I need every niche I can find! )

It would have been nice if I had set up wvunpack to create a basic wav header if there wasn't one in the WavPack file, but I didn't. So now all WavPack files must contain at least a 44 byte wav header because I think it would be silly to break old wvunpack versions to save 44 bytes, and the encoding library now transparently generates this if the application does not supply it.

While it is correct that in a perfect world I would interpret all the RIFF subchunks and convert them into some internal representation, this is simply not tenable. First, there are simply too many different ones to handle, new subchunk types are constantly being added, and some people have simply defined their own. Also, in some cases, converting back to RIFF might not be lossless because there is some flexibility in writing the subchunks (for example, the order or whether or not items are collected into a LIST chunk).

Obviously nobody would complain if an MP3 encoder discarded RIFF data. However, because archiving is one of their primary uses, I believe that lossless audio compressors are different. That extra RIFF information is part of the archive, and the fact that FLAC discards those unknown subchunks simply makes it unusable for some (albeit rare) applications. The fact that WavPack saves them does not similarly make it unusable for any current or future application (except maybe for the guy that specifically wanted them discarded, for whom I have now provided an option).

Just a quick question: does the encoder support WV input? To recompress from one compression ratio to a higher one without decoding to wav first.

No, sorry, wavpack.exe does not accept WavPack files right now.

There are a couple ways around this. You can use pipes so that no intermediate wav file is created but you'll need to do one file at a time and you'll have to copy tags using another app.

A lot of people use foobar (or other transcoding tools) to accomplish this, and in some cases these programs use pipes so that no wav file is stored.

Another elegant solution would be dbpoweramp.