I am finally nearing completion of WavPack 4.3 and I really appreciate everybody's patience. Since so many things have changed I have decided to make a beta available while I build all the other tools and update the documentation and sources. As always, any and all testing is welcome...

Thanks to gl.tter, Kazuma, Synthetic Soul, Martin H, Guruboolez, BoraBora, shadowking, JohanDeBock, and anyone else who contributed to this release that I forgot about.

Here's what's new:

Both Programs

• new command-line option (-l) to use low priority for smoother multitasking
• fixed bug causing termination error with very wide screen widths
• debug mode (rename to xxxxpack_debug.exe) causes the command-line args and other useful information (and any errors) to be dumped to the console and appended to a file named c:\wavpack.log.
• returns error status for any error

WavPack.exe

• new command-line option (-r) to generate a fresh RIFF header (discarding extra chunks)
• automatically detect lower resolution data even without -x1 (handy for MLP sources)
• use longer blocks for multichannel files (improves "high" mode compression)
• source and destination directories are also searched for tag source files (handy for EAC)
• wildcard accepted for tag source file (must match 1 file only; handy for EAC)
• handle non-standard sampling rates

WvUnpack.exe

• new command-line option (-ss) to include tags in summary dump
• decoding overflow bug fixed (encoder fixed in 4.22)
• more robust decoding of damaged (or invalid) files
• handle ID3v1.1 tags (now includes track number)
• fixed formatting error in duration display

Here's the zip:

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

edit: formatting

Nice
Are there improvements for mono encodings in this beta? If no, is it planed for a next release?

Thanks

Maybe this is a stupid question, but I'm going to ask bryant about it.
Is it possible to increase the overall compression ratio of the codec, how much will it be and is it planned for the future at all ?

Thanks

Hi Guru,

I have implemented the mono improvement, but just in the decoder for now. After 4.3 is released I plan to include the encoding portion in a 4.4 beta soon afterward. Sorry it's been so long since you first sent me those files!

I also have not implemented shadowking's noise-shaping improvement because I wanted to do it in a backward compatible way (which was more work). But it's scheduled.

As for Leo's question, I am always working on possible improvements in compression ratio as long as they don't seriously degrade decoding speed or complexity (I have no interest in super-slow "archive" modes). Also, to consider an improvement that would break old decoders there would have to be a pretty dramatic improvement. However, I believe that the existing -x mode could be overhauled in a way that would give a significant improvement to compression of real music without the huge speed penalty that exists now. Well see...

Thanks...

David

WavPack is a multiplatform application, but the 4.3b you shared are MS Windows only.
So I have to ask when you plan to release this version to us non-Windows users?

Or maybe you only want feedback from a limited user base?

** waiting **

Don't worry: I'm glad to see that you found a way to improve the encoder. And with lossless, I can encode a second time my files with 4.4 or even with WavPack 5 if needed

Thanks again David. I really appreciate that you continue to take users' suggestions on board.


I feel it's worth highlighting the usefulness of this, especially when encoding using EAC, or transcoding using foobar.

By adding the command:

-w "CUESHEET=@*.cue"

... to your command line you can easily embed the cuesheet without worrying about the name, or path, of the file. Very useful if your cuesheets have differing names, or you want to work from various directories without constantly amending your commandline.

Bear in mind that there must only be one .CUE in the directory - but I store all my images in an album/disc-specific directory, and always use a "clean" directory when ripping with EAC, so it works for me.

I believe this originated from a suggestion by Martin H - so many thanks to him also.

I'm not in that list because, instead of telling David what to add, I told him what not to add :-P

Woohoo! Thanks again Bryant

This is great news for me! Thanks a lot!

Many, many thanks, Bryant! Wavpack was already the best for me and it keeps getting better. You do wonders!

As always thanks very much for the beta and hopefully a release will soon be around the corner. I personally especially like the part of lower resolution detection without the -x switch as I know one day I'll have some DVD-A discs to rip and I might as well squeeze as much size out of them as I can.

Thank you for your great codec once again

I already have a bug report for this beta. I have a WavPack I want to decode to a .RAW. Well it starts decoding to .RAW ... but there is NO progress meter, and it is just sitting there doing nothing.

Example:

wvunpack -r "c:\11 - kitchenware & candybars.wv"

restoring 11 - Kitchenware & Candybars.raw,



Hopefully you understand my poor description.



Edit: WavPack 4.22 has no problem with the file, however...

restored 11 - Kitchenware & Candybars.raw in 7.89 secs (lossless)

No slight to users on other platforms was meant. I simply develop on Windows and so that version is always done first. My next step is to get the non-windows ports up-to-date (hopefully by this weekend) and do the full release with sources.

But I figured that between now and then I could get some free testing from Windows users (and it looks like it already paid off, thanks Kazuma! )

I would suggest you display, after encoding is finished in wavpack.exe, the speed times real-time. (like, "5.7x real time encoding")

Thank's for all your hard work David, it's trully appreciated

-Martin.

I'm looking forward to the new version!

Ok, I didnt know.
Sounds great! Cant wait to check it out.

You really want to be in that list, don't you

Of course! My best catch line with chicks is "I influence WavPack development"

They melt on spot, I tell you!

Will this version renew compatibility with shntool ?

EDIT: Oops, sorry, I forgot that the problem lies with shntool not WavPack.

i'm curious about the new -r switch. where could i find more info?

In the manual. Oh wait, I didn't do that yet!

I got an e-mail request a few weeks ago from someone who wanted an option to throw away extra RIFF chunks (like FLAC does). He wanted this because a program he was using to create wavs was putting stuff in the RIFF chunks that he didn't want to distribute in the WavPack file.

Because I was already adding the functionality to the WavPack library to automatically create a wav header for the application, this became an easy feature to add (and besides I needed a way to test the new functionality).

When you use the -r option, the original wav header (and any RIFF data after the audio) is discarded and a "fresh" header is generated (an extended header is generated for multichannel). This way you know that no hidden information is going out.

Of course, the only time the wav header is used is when wvunpack.exe generates a wav file. It has nothing to do with regular playback because all the information required for playback is native to the WavPack file.

In the future I could easily expand this option to allow reading "raw" audio files by allowing specification of the audio format.

I enjoy your sarcasm from time to time, Roberto...

Well, -x is usually pretty slow for me anyway. Does the mono fix you have incorporated break decoder compatibility?

Yes, -x (and especially -hx) is very slow. I think there is a good chance these could be speeded up enough that people might use them more often.

On the mono enhancement, the decoder has not been broken because there is no way to use the feature yet. First, I will put the encoding feature into a beta. Later I will put it into the released code but it will require an command-line option because the resulting files will not play on pre-4.3 decoders.

This all assumes that Pioneer does not announce a new CD player that supports WavPack. In that case I won't change a thing!

Bryant, a small request: could you add exit return codes in wavpack? For example:

0 - success
1 - mild warnings
2 - severe warnings (don't know if you have this)
3 - encoding/internal errors
4 - input format errors
5 - I/O error (file not found, output not writable etc)
6 - command line usage errors

You could of course return 0 on warnings.

Great when used in batch to check results, using errorlevel N tests.

Thanks.

Sorry about this. Until recently I actually thought I was returning valid error codes but it was pointed out to me that it was not too consistent.

This beta should be better than 4.22 and the 4.3 release will always return an error when there is one.

I had not thought about having different error codes for different types of errors, but I can see why that might be handy. I'll look into that for the future (for now I just return 0 or 1).

Thanks for the suggestion.

1 for errors and 0 for success is good enough for most purposes anyways. Thanks a bunch.

Okay, I have finished up 4.3 and posted the *nix sources here:

http://www.wavpack.com/wavpack-4.3.tar.bz2

Please let me know if there's any trouble building. I will put up everything else tomorrow (which I guess is later today for most of you...)

you are nothing short of amazing bryant. thanks for the fast development, it is really encouraging. any significant diferences from the beta?

Thanks!

The only two changes of any significance were fixing Kazuma's bug for raw decoding and making sure that all error paths result in an error status being returned (after Tycho's suggestion).

Most of the work was testing and documentation...

Excellent!
I compiled static binaries on Mac OS 10.4.3, using GCC 4.0.0 (build 5026) without any trouble. Testing remains though.

Thanks a lot!

Sure, lots of trouble building. So much trouble, I built for these platforms:

FreeBSD-x86
NetBSD-x86
HPUX-HPPA
MacOSX-PowerPC
Linux-x86
Linux-ia64
Solaris-SPARC
Solaris-x86
Tru64Unix-Alpha



Edit: I also did quick tests on all of them (encoding lossless and hybrid, decoding lossless and hybrid, CD material)

Any information for which version a command line replaygain utility is planned?

The WavPack website is now updated with all the 4.3 release.

Thanks eveyone for your testing and patience!

I have a couple weeks available this month; I may be able to put the ReplayGain scanner together soon.

Is this the location?: http://www.wavpack.com/files/wavpack-4.3.zip

Because I don't see the updated page.

EDIT: Sorry, I was seeing my browser's cached page

Awesome, thank you!