Problem with large multichannel file, 7 channels, 24-bit @ 48 kHz, & 3:48:18.77 Options

[xslig]

The uncompressed file is ~12.9 GB and the "wavpack -f" file is ~6.8 GB

#$ wavpack -f --raw-pcm=48000,24,7 --channel-order=FL,FR,FC,LFE,BC,SL,SR fellowship.raw

WAVPACK Hybrid Lossless Audio Compressor Linux Version 4.60.1
Copyright © 1998 - 2009 Conifer Software. All Rights Reserved.

created fellowship.wv in 1116.22 secs (lossless, 78.56%)
#$ wvunpack -ss fellowship.wv

WVUNPACK Hybrid Lossless Audio Decompressor Linux Version 4.60.1
Copyright © 1998 - 2009 Conifer Software. All Rights Reserved.


file name: fellowship.wv
file size: 2960974266 bytes
source: 24-bit ints at 48000 Hz
channels: 7 (FL,FR,FC,LFE,BC,SL,SR)
duration: 3:48:18.77
modalities: lossless, fast
compression: 78.56%
ave bitrate: 1729 kbps
encoder version: 4
file wrapper: 68 byte RIFF header

I can play the file in DeadBeef (it uses libwavpack instead of ffwavpack), but can't seek past ~92 minutes. DeadBeef will play everything beyond ~92 minutes as long as I start playing the file before ~92 minutes.

I've compressed similarly large 24-bit but 6-channel files before, and this didn't happen.

The source file is the lossless audio from the "Lord of the Rings: The Fellowship of the Ring: Special Extended Edition" blu-ray

[xslig]

I tried hybrid lossless compression at ~1792 kb/s.

I could play and seek throughout the whole file, but there was much digital "stuttering" throughout the file when being played.

[bryant]

It’s weird that you’ve had good luck with WavPack files that big in the past. The library really shouldn’t be able to seek in files over 4 GB, so if that was working at some point it’s pure luck.

Another weird thing is that on my Linux distro (Ubuntu 8.04; I know it’s old ) I can’t even create or open(!) files over 2 GB with the command-line tools. What distro are you using? Did you create a custom build or something?

In any event, all these problems will be fixed once I finish the development I’m working on with large file support (all the limitations are in the implementation and library...not the format). Before that, any seeking on files over 4 GB is a crap shoot.

I’m not sure about the stuttering on hybrid lossless either. Especially in “fast” mode you should not be running out of CPU...does it play better if you rename or move the correction file so it’s not used? That might be an interim solution...you can keep the correction file as an archive, but not use it during normal playback (assuming the main file has enough bits to be transparent).

David

[xslig]

Another weird thing is that on my Linux distro (Ubuntu 8.04; I know it’s old ) I can’t even create or open(!) files over 2 GB with the command-line tools. What distro are you using? Did you create a custom build or something?

I was using the version from Debian Stable. http://packages.debian.org/stable/sound/wavpack
I also tried the version from Debian Unstable, but got the same results. http://packages.debian.org/unstable/sound/wavpack

I’m not sure about the stuttering on hybrid lossless either. Especially in “fast” mode you should not be running out of CPU...does it play better if you rename or move the correction file so it’s not used?

Heres a sample. http://www.mediafire.com/?15jms455cpxxpj6
I used "wvunpack -i" to produce this sample. (The uploaded sample is the lossy compressed as lossless.) Using "wvunpack" (using the correction file) also produced these results. In the sample, you'll notice that only the channels that are paired together (FL+FR, SL+SR) are affected by stuttering.
The lossless (not hybrid lossless) decompressed correctly.

In any event, all these problems will be fixed once I finish the development I’m working on with large file support

It may be possible that some of the previous files I've compressed may be affected by this (but I don't think so, because I check them after encoding; also this is also my first file of >6 channels that I've encoded.) Would I have to re-encode them for proper playback once you implement large file support? (All of the files should be in matroskas if that matters.)

When is the library that can handle larger files schelduled to be released?

Thank you for your response.

[bryant]

Heres a sample. http://www.mediafire.com/?15jms455cpxxpj6
I used "wvunpack -i" to produce this sample. (The uploaded sample is the lossy compressed as lossless.) Using "wvunpack" (using the correction file) also produced these results. In the sample, you'll notice that only the channels that are paired together (FL+FR, SL+SR) are affected by stuttering.
The lossless (not hybrid lossless) decompressed correctly.

Ah, I did not realize that this was happening with even wvunpack decoding...that sounds like it could be a bug. Unfortunately I was not able to reproduce it. It is possible that you could try this on a short raw file and see if it still happens? You should be able to use the md5 function to verify that the data had been corrupted (and that would actually be an interesting result in itself). Of course, if it only happens on very large files then I'll have to figure out how to make one. I would appreciate any help you can give me at reproducing this!

It may be possible that some of the previous files I've compressed may be affected by this (but I don't think so, because I check them after encoding; also this is also my first file of >6 channels that I've encoded.) Would I have to re-encode them for proper playback once you implement large file support? (All of the files should be in matroskas if that matters.)

You would probably not have to re-encode because the problem with large files is just the playback seeking (assuming you are able to make the files in the first place).

I'm not sure I follow you about matroska though. When WavPack files are put into matroska containers, the headers are stripped off and all the seeking is then done by the matroska demuxer (and libwavpack is just used in "raw" mode to decode individual blocks). Assuming that all works, that would solve your problem without any need for any new WavPack code.

When is the library that can handle larger files schelduled to be released?

Ah, there's the rub! Unfortunately I have been swamped for years with work from a startup I work for and have not been able to work as much as I would like on WavPack. My goal is to get this finalized sometime this year, but that's what I said last year!

[bryant]

See solution here:

http://www.hydrogenaudio.org/forums/index....showtopic=95889