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

[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