After the decoding (wvunpack.exe 6GB.wv) the decoded file has .wav extension, riff size = 0x900647b4 and data size = 0x90064790. Probably wvunpack should write 0 or -1 into these fields in this case?Or maybe it should default to .w64 output format in this case?
But WriteRiffHeader() is not called here. Looks like wvunpack calls DoWriteFile(outfile, WavpackGetWrapperData (wpc), WavpackGetWrapperBytes (wpc), &bcount) that writes audio header.
I downloaded sources form github, and this version doesn't write progress message with >100% value.
This is a little weird because I have not made any changes in the repository since the alpha release. Could this be a compiler difference (mingw?), or perhaps you didn't really use the same source file or command-line arguments?
Hi David, Many thanks for the update, yep I can confirm all is perfect now, 5gb .wav before = .wav after wavpack & decompress... & the hash's match, amazing stuff! thanks so much
BTW, the definition of CUR_STREAM_VERS differs between include\wavpack.h and src\wavpack_local.h
I am considering dropping support for WavPack files created prior to version 4.0
Is this to be expected or is it a bug?
I thought the raw option would ignore the WAV or W64 restrictions. If I use the raw option it crops my file. This is the output i get:wavpack.exe --raw-pcm=100000,16,2 -hh -x1 --pre-quantize=12 *.wav
Quote from: bryant on 26 May, 2016, 09:05:50 PMI am considering dropping support for WavPack files created prior to version 4.0I don't have any such files but in principle I'm against reducing compatibility. Dropping support for old files forces any self-respecting player to use two versions of the decoder library.
Quote from: Funk on 28 May, 2016, 04:17:55 PMI thought the raw option would ignore the WAV or W64 restrictions. If I use the raw option it crops my file. This is the output i get:wavpack.exe --raw-pcm=100000,16,2 -hh -x1 --pre-quantize=12 *.wavI'm not sure what you mean by "the resulting file is useless". If you use --pre-quantize with --raw-pcm then your header is going to pre-quantized, which it's not going to like. Probably your unpacked file will not be recognized after that, even though the only problem is some corrupt bytes in the header.Anyway, --raw-pcm is not going to get around the 2^32 sample problem, but using "-i" to ignore length in header might (I have to try it), but that would be for archiving only (you could only restore the entire original WAV/RF64 file). Would that work for you? What do you do with these files after you compress them?I considered at one point extending the 2^32 samples limit at one point (there's spare room in the header to do 1 Tera-sample) but I couldn't think of a reasonable use case that would require it – obviously I was not considering megahertz sampling rates! I'll take a look again (although I think it's a little bit of a mess).BTW, another limit I just noticed is that I limit the sampling frequency to around 16.7 MHz. Unlike the other issue, that one's easy to fix...