First off, I am sure it is not a computer problem. Have ran Prime95/Memtest86 and all that jazz for long periods of time. Stock speeds and settings.

WavPack -h or -hx6 seems to work fine on CD audio. But on DVD-Audio, it usually makes 1 or 2 of the songs error out. No matter how many re-encodes, it always errors the same way. Examples are listed below...

(These are 24/96 5.1 rips...)

Metallica - Metallica - 05 - Wherever I May Roam.wv encoded on -h had 2 CRC block errors.

R.E.M. - The Best Of R.E.M. In Time 1988-2003 - 02 - The Great Beyond.wv on -hx6 had 2 CRC block errors.

R.E.M. - The Best Of R.E.M. In Time 1988-2003 - 07 - E-Bow The Letter.wv on -hx6 had 10 CRC block errors.

At first I was using -h, as it offers better compression than FLAC or APE. Then I tried -hx6, this offered a HUGE gain in compression even over -h. For most files this worked fine, 11 of 12 files on the Metallica DVD-Audio were good. But several on the R.E.M. aren't.

I just tried encoding a few more CD albums on -hx6, and can't get any of them to error. So far it is limited to only DVD-Audio.

Hi. I'm at work right now, but I will hopefully be able to respond later on today. It sounds like it's possible that you might have found a WavPack issue and I'd like to get to the bottom of it quickly. Thanks for your patience...

Thanks, I appreciate it!

What are you using to play the files (that is reporting the errors)? If it's a player like foobar, have you tried just verifying the files with the command-line program? Also, I assume that you are using the command-line program to do the packing, right? What program generated the wav file? If you have a .wav file that you can just pack and then verify from the command-line and you get errors then that will make it easier to pinpoint the problem.

It's kinda weird that you are getting such a HUGE gain from the -hx6 option. By this do you mean like 5% or less, or do you mean really HUGE (like more than 10%). Also, do the same number of errors occur no matter what the command line is (for instance, does "fast" mode act the same). Finally, if you could use the -m option with various compression options on the same file it might be interesting to see if the resulting file (and number of errors) is always the same.

Maybe we can figure out what's going on easily. If not, is there any way you could get me copy of a .wav file that doesn't work? I realize these must be pretty big files; maybe a short track...? I wouldn't mind buying the REM, but I'm not sure I could rip it.

Thanks in advance for helping me figure out what might be going on!

Foobar2000 is the player. Yes I have tried verifying the files with the command line program, and it returned that there were anywhere from 1-10 bad CRC blocks per file. PPCMRipper generated the WAV file.

By HUGE gain in compression, I am talking from 7347 Kbps on -h to 4882 Kbps on -hx6.

I could send you the original .WAV file, the correct -h file, and problem -hx6 file if you wanted, just send me a PM and a way to transfer them.

I'm really eager to help you fix this problem, as WavPack is now my codec of choice, over FLAC. It seems to encode faster, and decode faster (or as fast) as FLAC -8. Not to mention smaller filesizes.

Anyways, let me know, and thanks for all the help!

Hmm. That IS a HUGE difference. I'd like to see one of those files just to see what's going on there. So, it sounds like the -hx6 is making it fail, so there's another reason. If you could get me a -h version (that unpacks correctly) that would be great. Unfortunately, these are probably several hundred meg per track which are too big for any account I have. I did find this site some time ago that looks like it might work, but I haven't tried it:

http://www.yousendit.com/

My e-mail address is on the WavPack site. If that doesn't work out for you we could work out something else.

David

I can also provide some GBs of upload space at RareWares if needed.

I am attempting this now. If for some reason it fails, I'll try rjamorim.

bryant, the file finished successfully on Yousendit. Try that and see if it works. Thanks!

I just downloaded the file and am attempting to reproduce the problem (-hx6 is going to take a while!). Unfortunately I have t go to my real job again today!

Thanks again and I'll post again as soon as I find out something...

No problem, glad to be of help

That's what sick days are for!!!

Yeah, maybe I'll try to disappear tomorrow and see if anybody notices!

Anyway, I figured out why the -x switch works so well with this sample. Although it indicates in the header that it's a 24-bit file, only the three front channels are 24-bit. The surround channels are actually only 20-bit and the LFE is 16-bit.

Without the -x switch WavPack just trusts the header and blindly compresses for speed. When the -x switch is used (at any level) then WavPack scans every block to see if any redundancy in the LSBs can be compressed out and gets 11% just from that (in this sample).

As for why the sample fails, I haven't figured that out yet. The track clips (why does 24-bit audio have to clip!), so it might have something to do with that (although I verified that it's not arithmetic overflow). I'll dig a little deeper tomorrow night...

I'm pretty sure it isn't clipping related. Most every track on that DVD-A has a few clips, and Metallica DVD-A is full of clips. Most of the songs on them compress fine, only a few have problems.

Any updates on this? I might could provide more samples if needed. Just let me know!

I figured out the another reason that the -x mode is doing so well with this track. It's lowpassed at around 24 kHz (or it was originally sampled at 48 kHz) and the -x mode is creating filters highly tuned to take advantage of the redundancy. Unfortunately, some of the filters were also a little unstable and the -x code was not correctly detecting this in every case.

I have posted a version 4.21 that should fix this, and doesn't cost too much in compression ratio. If you could try this out on your files that caused trouble I would greatly appreciate it.

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

BTW, the improvement from using -hx6 instead of just -hx is not great (in fact, I've seen -hx6 do worse than -hx!) and it takes more than 5 times more time. Just a thought...

Rock on, you are the man! Will begin testing immediately

It fixed that particular sample I sent you, but other songs are still having problems. If you need one of those, let me know.

Edit: More results below on the new sample song I have...

-h works, 7694 Kbps
-hx works, 5920 Kbps
-hx6 does not work, 5891 Kbps

Really!? That's weird. I'm working on a "complete" solution to this problem, but I thought for sure that what I posted would have fixed all the instances.

Yes, please, could you send me another file that still has the problems (preferably a file with several errors, maybe with just -hx)? The method we used before worked fine for me.

Thanks again...

This particular sample only has 1 CRC block error. I will go ahead and send it anyways. If I do come across a sample with more CRC block errors, I will send that too.

Upload complete, you should be able to grab it. I'll try and get more samples if possible (unless you fix them before I can even encode them )

So far, that is the only track I can get to corrupt ... though I am still encoding quite a deal more. Just thought I'd give you an update.

Well, I went and got more DVD-Audio. I will wait until you release the new fixed version before I go encode crazy again though. Should have quite a few good samples to toss at it

It turns out that the problem was actually on the decode side. I was able to stop it from happening by restricting the -x mode, but even the "corrupt" files were playable without errors once I fixed the decoder.

My plan is to release version 4.22 of wavpack.exe (and a new Audition filter) to make sure that no more "corrupt" files are produced. That should be very soon, like tomorrow.

Since I'll have to release all the plugins to fix the decoder problem, I'll use that opportunity to put in some features that have been requested over the last few months. That should be in a week or two.

BTW, this problem can only affect the 24-bit (and higher) modes, and only when -x is used, so most people should not be affected at all.

Kazuma, I tried to e-mail you several days ago, but I guess you didn't give your real e-mail address to Yousendit...

from my own tests on compressing PCM DVD-A, if it's stereo like 24/192, use Monkeys Audio (by far the best), if it's multichannel, use FLAC, wavpack by far has the worst compression ratio.

has anybody done a comparison w/ various genre's of music that actually use the entire 92khz specturm (not just cut off after 48khz)

Just curious.

-joe

That's my real address, and I got the e-mail. Thanks again for the updates, I appreciate it!

Erukian, I haven't come across any 24/192 content yet. So far all the 24/96 2.0 and 5.1 content I've come across compresses WAY better in WavPack than FLAC, and especially APE which can't even handle multichannel.

OK well I've acquired some 24/192 content

Like said before, I will wait for the new WavPack before I go encode crazy.

I make my own music and currently keep things as 32/96. I can only use WavPack, as flac does not support 32-bit and I doubt APE does, although I haven't checked, it's too slow and CPU intensive for my taste anyway. I've had no issues with WavPack and this content. I have a good selection of 24/96 6 channel tracks as well that wavpack handles fine. No errors at all. FLAC also doesn't seem to like the 6ch wave files Cubase used to make, although I haven't touched it in ages. For normal CD stereo content I use FLAC only half the time now. If there are issues with WavPack I've not experienced any of them, but I hope they are fixed regardless.

Okay, I've finished up version 4.22 of wavpack.exe and a new CoolEdit / Audition filter. They're available here:

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

These should never create files that induce the decoder bug (even in -hx6 mode). Please let me know if they do, or if they do anything else funny. If these work okay for people I'll do an update of the binaries on wavpack.com as soon as possible.

Thanks Kazuma for all your help on this (and anyone else who tests).

Duble0Syx:
Glad you haven't seen these errors, especially with your own music! However, to get it to happen you would need to use -hx and I think it might only happen on lowpassed (or upsampled) material, which you probably would not do with your own music.

If you do happen to find a corrupt track, don't panic because it will be fine once the fixed decoder is ready.

Actually, I've been using -hx2m as my encoder parameters. The difference between x2 and x6 seemed very minimal for the increased amount of time, and x2 seemed to yield signifigant gains over standard -h. Does some wonderful compression on the 24/96 multichannel audio. Looking forward to a new version regardless. I like new software even when there is little difference. It's just nice to know when things are still being developed.

EDIT: I forgot to ask, but it doesn't seem to be mentioned anywhere: How many channels of audio does WavPack support?

OK on the 24/192 content...

APE does pretty good on High/Extra High/Insane ... around 4000 Kbps
WavPack -h doesn't do too well ... around 4800 Kbps
WavPack -hx absolutely destroys APE ... around 2200 Kbps

WavPack -hx6 results will come later, probably only a few Kbps increase over -hx6, but I am still very impressed.

Thank you Bryant, for helping me with these problems, I appreciate it. Looking forward to that new WavPack!

Bryant, just finished encoding quite a few files, including the problem samples, with -hx6. All is working well!

Good question! I hadn't really thought about this lately, so I looked back at the code. The WavPack format itself has no limit on the number of channels because it breaks up the audio into multiple "streams" which can hold only 1 or 2 channels each. In the current implementation there are 8 streams available, so that limits the number of channels to from 8 to 16, depending how they are grouped. Maybe I should bump that up...?

Glad to hear everything is working well now. That improvement on 24/192 sounds almost too good to be true; I assume you verified the result somehow? Anyway, if you've got the patience, I'd love to get my mitts on one of those files!

Sure thing. Yes, it was verified by your commandline unpacker as lossless.

Actually I scanned the 24/192 files in a WAV editor. Some show as actually being 20 bit. Most do not go past 24 Khz for the most part. A few do.

This is why they are compressing extremely well, this isn't even close to real 24/192 content, sadly.

If I find some REAL 24/192, I'll be sure to send it your way. But these files would be a waste.