Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#4743 : Hybrid Wavpack .WV playback should use .WVC when available



FS#4743 - Hybrid Wavpack .WV playback should use .WVC when available

Attached to Project: Rockbox
Opened by jbthiel (jbthiel) - Monday, 27 February 2006, 22:10 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To No-one
Operating System Iriver H100 series
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Hybrid Wavpack file made from 24/96 source with -b320 -c producing a 432kbps .wv file, plus a .wvc file.

On playback on rockbox/h120, the bitrate is reported as 432kbps, even when the .wvc is present in the same directory on the iriver. Therefore, presumably the .wvc correction file is not being used to recreate the sound.

When the hybrid .wvc file is present, it should be used with the .wv for the best lossless reproduction.

Also tested with wavpack from a 16/44 source, with the same effect: specifically, the self-contained .wv will play as "955K vbr", but the .WV+.WVC combo plays as "403k vbr"
This task depends upon

Closed by  Christi Scarborough (christi-s)
Sunday, 19 March 2006, 12:22 GMT
Reason for closing:  Invalid
Additional comments about closing:  .wvc playback is unsupported. Please submit a feature request.
Comment by Paul Louden (darkkone) - Tuesday, 28 February 2006, 06:44 GMT
As far as I know, it's basically been decided that the wavpack correction files can't be used in hybrid mode on these portable devices effectively. Because of the fact that it needs to find two different points in two different files, and that they both need to be in RAM, it would be ineffective.

432 is also a very high bitrate for a lossy format on a portable device (not to mention Rockbox only plays back audio in 16/44 anyway) so the skipping you encountered is to be expected, all things considered.
Comment by jbthiel (jbthiel) - Tuesday, 28 February 2006, 21:18 GMT
I see what you're saying Paul about the 2 streams -- that's a totally different paradigm than probably every other codec, so maybe isn't worth the special case coding, or at least could be Low priority or a future enhancement.

But regarding 432kbps, note that hybrid .WV from 16/44 plays fine at 403 kbps. And pure .WVs from 24/96 source are playing fine at 2900 kbps! It is just the case of hybrid from 24/96 at 432 kbps that is skipping (in normal/high compression; fast is almost ok on h120). So I hope there is some room to tune the hybrid decoder. <redirect to: >

In general, I'm of the idea that Rockbox should not limit itself to "lossy format" thinking, but should aim for the best reproduction, which definitely includes all lossless formats, and scaling up to 24/96 as devices get more powerful cpu's in future.
Comment by Daniel Stenberg (bagder) - Wednesday, 01 March 2006, 08:08 GMT
Rockbox is in no way "lossy format thinking". It supports more lossless formats than any other portable music player software.
Comment by jbthiel (jbthiel) - Thursday, 02 March 2006, 01:06 GMT
I know it, Daniel, was not suggesting otherwise. Specifically *because* the support for lossless formats is so excellent, I would like to see it continue and extend in that vein.

I agree that practically speaking, it's an unusual (and maybe pointless) case for a user to have the .wv + .wvc combination on a portable device, when they could just as well choose just a single file, either lossy or lossless.

However, it's hard to envision all potential use cases -- and given features like the optical I/O on the H100 series, it would be a shame is a user inadvertently degrades his lossless signal (e.g. by playing a .wv+.wvc out the optical port, which will only play the lossy .wv part currently). From a theoretical correctness viewpoint, it would be best to support the .wv+.wvc case if possible.
Comment by Thom Johansen (preglow) - Thursday, 02 March 2006, 11:25 GMT
We have discussed this on the developers mailing list, and we agreed it will be a major hassle. Please read the following reply from the Wavpack coder himself:

In short, we'd love it, but it would require great surgery to the playback system for a feature (albeit a great one) just one format currently employs.