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: Problem with unpacking (Read 3377 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Problem with unpacking

I'm developing a plugin for 7-zip that allows the user to improve the compression of multimedia files. To compress wav files I use the wavpack library. While testing my plugin on different files I found a file that packs correctly, but fails to unpack it.

Here is the archive with the test files (40Mb):
1) Good files 32bit_float.wav and 32bit_float_p.wav that can be compressed and decompressed without any problem.
2) problem.wav - this file can be compressed and cannot be decompressed.
3) problem.wv - compressed problem.wav file.
All wav files have the same RIFF header.

For wav files from archive I use the following options to call the WavpackSetConfiguration64 function:
Code: [Select]
bitrate:          0
shaping_weight:   0
bits_per_sample:  32
bytes_per_sample: 4
qmode:            0
flags:            FAST_FLAG, MERGE_BLOCKS, PAIR_UNDEF_CHANS, OPTIMIZE_MONO
xmode:            0
num_channels:     2
float_norm_exp:   127
block_samples:    131072
extra_flags:      0
sample_rate:      44100
channel_mask:     0

But when I try to unpack Problem.wv the WavpackOpenFileInputEx64 function terminates with an error "not compatible with this version of WavPack file!".

What I am doing wrong?

Re: Problem with unpacking

Reply #1 –
You must be using the Wavpack library incorrectly, as I can compress problem.wav using wavpack -hh and produce a slightly larger .wv file that verifies just fine. You'll need to post your example code for how you're instantiating Wavpack and how you're configuring it for encoding.

Re: Problem with unpacking

Reply #2 –
Quote from: kode54 on
You must be using the Wavpack library incorrectly
I use the same code for all three files from the archive. All wav files from the archive have the same RIFF header. Two files are packed and unpacked correctly, but the third one is not. If I use the Wavpack library incorrectly, then all three files must be problematic, not just one.

Re: Problem with unpacking

Reply #3 –
Quote
I use the same code for all three files from the archive. All wav files from the archive have the same RIFF header. Two files are packed and unpacked correctly, but the third one is not. If I use the Wavpack library incorrectly, then all three files must be problematic, not just one.
That isn't quite true. What's happening is that you have specified an override (131072 samples) for the default block size. This is normally fine, but it turns out that with the pathological float data (i.e. negative compression), the specified block size causes the generated block to exceed the maximum size of 1 megabyte. The other two files do not contain pathological data and so they are fine.

I appreciate you showing this because you have revealed a bug in the encoder. It's obviously incorrect to generate a block that the decoder is unwilling to decode. I'm not sure what the best fix is, but I should either ignore or override the specified block size, or simply generate an error in this case.

I'm not sure why you attempted to override the block size, but the safest thing would be to leave that field zero and allow WavPack to determine the best size. It's possible to get slightly better compression by increasing it, but there's no way to know how many is too much to avoid overflowing the 1 megabyte limit. The default prevents that from happening.

And thanks for sharing this!   :)

Re: Problem with unpacking

Reply #4 –
Quote from: bryant on
the safest thing would be to leave that field zero and allow WavPack to determine the best size.

Thanks! It solves the problem! Now everything is ok.