[Matroska-devel] WavPack in Matroska

David Bryant dbryant at impulse.net
Sat Jul 3 22:18:01 CEST 2004


I have been reading this discussion and thought it was about time to jump in
and offer some clarification about the hybrid mode of WavPack (even though I
don't exactly understand all the issues from your end).

First of all, the "correction" data is stored in WavPack blocks just like
the regular data, and there is a one-to-one correspondance between the lossy
blocks and the correction blocks. The high-level code in wavpack.c puts the
blocks in different files, but they could just as easily be put into the
same file (although the playback code would have to know about this). There
is no way to (even accidentally) play a correction file by itself; the
decoder will refuse. Also, the lossy file created is identical whether a
correction file is created at the same time or not.

To the low level unpacking code (in unpack.c) you simply pass the blocks (in
memory) for decoding. If you pass just a regular lossy block then you get
lossy decoding, if you pass a lossy block and its matching correction block
then you get lossless decoding. BTW, WavPack blocks are relatively small;
usually < 100k. There is an undocumented option (-kn) in the WavPack
command-line program to set the block size (in samples) to any number you
want if you want to experiment (I don't check bounds so you might get a
crash if you put in funny numbers).

I also thought about having them (the correction blocks) stored in the same
file. Obviously, this has no advantage over standard lossless except that a
program could be made that would split them (or put them back together) very
quickly. However, I have not run into inconvenience in having two files for
every track. I store my music with one album per folder, so all the files
get copied or moved when I copy or move the folder. Playback or decoding
automatically finds the correction files. If I want to make a copy to
transfer to someone else (for, you know, testing) then I simply don't copy
the .wvc files and I have only 1/3 the data. The only time you would run
into trouble would be if you used a renaming program that was not wvc-aware.

Of course, if your system is not set up to having the two matching files
then it can be a mess. I ran into something like that with the foobar
plugin. Foobar wants to pass me an input instance that I use to get my file
data for playback (including seeking). This is nice in a device-independence
sort of way, but it makes it difficult for me to try to find my correction
file. The OptimFROG (which also has a hybrid mode called "dualstream")
author simply decided that the correction files would only be usable from
the command-line decoder; all plugins would simply play the lossy stream.
And I imagine that in some applications (DirectShow?) this may simply be the
only way it can work. And it's not a disaster; even at 256 kbps the lossy
files sound fine, but it's nice to use them if they're right there.

Unrelated to this discussion I was thinking that there are two nice features
in WavPack that might make it very attractive for video editing. First, the
fact that WavPack blocks may contain any number of samples makes it easy to
delete are add small numbers of samples without having to re-encode the
whole rest of the file. Also, I imagine that you guys are thinking of the
lossless mode for editing because you don't want the normal accumulation of
artifacts with repeated encoding and decoding of lossy codecs. However, the
lossy mode of WavPack is much less subject to this, in fact you can go
through dozens of encode-decode cycles at the 512 kbps (stereo) bitrate with
no audible degradation. This will become even more an issue with higher
bitdepths and sample rates. Just a thought...

----- Original Message -----
From: "Steve Lhomme" <steve.lhomme at free.fr>
To: "Discussion about the current and future development of Matroska"
<matroska-devel at lists.matroska.org>
Cc: "David Bryant" <dbryant at impulse.net>
Sent: Saturday, July 03, 2004 6:37 AM
Subject: Re: [Matroska-devel] WavPack in Matroska

Steve Lhomme a écrit :

> The idea is that it should be stored as if it was a basic lossless file
> (ie both in the same file). And when needed you can only keep the lossy
> part only in another file (like peeling for Vorbis).
> Which leads to another problem. If we store all the data in the same
> track (see previous email) we have to have a codec interaction when we
> want to create a lossy-only version of the file. So it might be a good
> idea to have it at the container level instead... I couldn't imagine a
> clean DShow graph if it was at the codec level, but it's easy on the
> container level.

IMO, we should add a new element for such a case. It's not a
CodecPrivate data for each frame, but rather a secondary stream that
makes sense only with the first one... So we have 2 choices :

- add a track property to state that the track is not to be played and
correspond to data for track XYZ. IMO that's not very clean and not
backward compatible.

- add a new element to the BlockGroup with a SecondaryData item. That's
clean. But it only makes sense if the complementary data in WavPack is
on a frame/block basis. David ??? This way it would be easy to have an
option in mkvmerge like --strip-secondary to get only the lossy part of
a content (could apply to other things too). If we go this way, we
should investigate a bit more if it could be generalised to more

robUx4 on blog <http://robux4.blogspot.com/>

More information about the Matroska-devel mailing list