I am trying to use the java WavPack encoder in one of my projects and I am getting an error on some of my test wav files. The spot in the code where it throws an error is checking the format chunk. It is expecting to read exactly 16 bytes. This wav file, which encodes fine using the windows command line version, happens to have 18 bytes in the the format chunk.

Here's the code:



If I comment the "bcount != 16" code out, it encodes successfully, but only at a 25% reduction where the command line encoder approaches 60%. The 25% compressed file decodes fine and plays fine. Other files get virtually identical compression rates between the windows version and the java version.

Anyone have any insight into why I get the error and why the compression seems to be compromised as a result.

Thanks.

First, let me apologise that you're having problems with the code.

I'm not sure why I'm using the 'magic number' 16 in this section of the code (instead of checking against the previously read chunk size), but it does appear to be a mistake.

I don't know why you're seeing such a difference in the encoding compression - would it be possible to upload a small section of the file (say maybe the first 30 seconds) to a file sharing site or something like that?
Also, when you refer to the windows command line version, I presume you mean the standard WavPack encoder (wavpack.exe)?

No worries. I'm happy you took the time to code it up at all. Thanks for the unexpectedly prompt response

I uploaded one of the wavpacked (using wavpack.exe) test files to: Test File (29MB)

I thought it might be better just to post the whole thing. The java version compresses it to about 54MB, about the same as the standard zip algorithm.

Yes, when I say, "windows command line version," I am referring to wavpack.exe version 4.5.0.

Thanks for your help.

I compared the compression ratios between the standard encoder and the tiny encoder on your file, and they differed by 33.36%, so that was a pretty obvious clue!

What's going on is that the 24-bit file has zeros in the 8 least significant bits, like it's really just an upconverted 16-bit file. The regular WavPack encoder scans for redundant bits and encodes more efficiently. For the tiny encoder this was one of the things I took out because the emphasis was on simplicity, and figured that an embedded application would not be processing such "phony" 24-bit data.

If this is something that your application will actually be running into often, it wouldn't be hard to add that to the Java encoder (which is identical to the tiny encoder in this respect).

David

Again. Thanks for the help. This makes sense now. I think when I rendered the file I probably mistakenly left a dithering plug on the master buss, so even though it generated a 24bit file, it really had, like you said, only 16 bits worth of data. I don't think this will happen too often. Not often enough that I would feel motivated to try and change the encoder code. Also, probably not worth changing your design philosophy of simplicity either, but that's up to you.

Thanks for your time.

Just as a followup to this. I have made a new 'official' release of the Java WavPack encoder code with the bug fix and have sent it to David. It should hopefully be available on the WavPack website in the next few days
Thanks to majortom for pointing out the bug, and sorry again for the hassle it caused you!

I have posted the new Java encoder on the WavPack site, or you can just grab it here.

Thanks again to majortom for pointing out the bug and Peter for the quick turnaround!

David