IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Problem with large multichannel file, 7 channels, 24-bit @ 48 kHz, & 3:48:18.77
xslig
post Mar 7 2012, 17:09
Post #1





Group: Members
Posts: 20
Joined: 29-September 11
Member No.: 94046



The uncompressed file is ~12.9 GB and the "wavpack -f" file is ~6.8 GB
QUOTE
#$ 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
Go to the top of the page
+Quote Post
xslig
post Mar 7 2012, 22:40
Post #2





Group: Members
Posts: 20
Joined: 29-September 11
Member No.: 94046



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.
Go to the top of the page
+Quote Post
bryant
post Mar 8 2012, 08:21
Post #3


WavPack Developer


Group: Developer (Donating)
Posts: 1292
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



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 smile.gif ) 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
Go to the top of the page
+Quote Post
xslig
post Mar 8 2012, 15:50
Post #4





Group: Members
Posts: 20
Joined: 29-September 11
Member No.: 94046



QUOTE
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

QUOTE
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.

QUOTE
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.
Go to the top of the page
+Quote Post
bryant
post Mar 9 2012, 20:02
Post #5


WavPack Developer


Group: Developer (Donating)
Posts: 1292
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE
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!

QUOTE
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.

QUOTE
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! sad.gif
Go to the top of the page
+Quote Post
bryant
post Jul 5 2012, 23:23
Post #6


WavPack Developer


Group: Developer (Donating)
Posts: 1292
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



See solution here:

http://www.hydrogenaudio.org/forums/index....showtopic=95889
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th November 2014 - 10:10