[Matroska-devel] Re: Matroska and WavPack

Steve Lhomme steve.lhomme at free.fr
Thu Jan 15 09:41:46 CET 2004

David Bryant wrote:

> Steve,
> This is reference to our discussion started on HA. I don't have an e-mail
> address for "Pamel"; if they're a Matroska developer also perhaps you could
> forward this.

I've forwarded the email to him.

> There seem to be two issues here. The first is what will the WavPack data
> look like when it is contained in Matroska, and the other is how
> multichannel support is to be done. I'll offer my thoughts on both these.
> My suggestion for the first question is that the WavPack block, including
> the 32-byte header, should be stored as-is without stripping (as though the
> header was part of the bitstream). I understand the concept of the container
> handling what it does well and having the codec do its job, but there are
> really only about 12 bytes of stuff in the header that are not required for
> decoding, and I would much rather have to maintain just one function that
> unpacks a WavPack block. This function would obviously ignore the "wvpk"
> field and the other stuff that doesn't apply to a single block.

OK. Well I understand that point of view. Actually we usually strip as 
much unneeded data from any kind of block we store in Matroska. We are 
very size greedy :) And therefore we are used to reconstitute data as 
they should be when passed to the decoder. So from your point of view 
(codec) you will receive data with the 12 bytes as in the original file. 
But in Matroska it may be stored differently. Don't worry about it. As 
soon as we have code from you to play with, we can start muxing/demuxing 
files and you will not be bothered about that :)

Now on the other hand, if the Wavpack header structure evolves it is 
more complicated to follow the changes while it's the job of the codec. 
So it could be a wise idea to store the header as is. I'm still undecided.

> The "crc" field in the WavPack block header applies to the decoded data, so
> there is no quick way to use this to verify a block. Instead, this is used
> internally to test both the integrity of the data storage and to test that
> the encode/decode process was robust. I assume that Matroska has a crc
> mechanism for the stored (encoded) stream and I suggest that this be
> independent from the internal WavPack crc.

OK, we'll keep the CRC.

> Another thought I had is that in future improvements of the encoder I may
> want to divide a block into two (or more) smaller blocks based on some
> analysis of the samples (because, for example, a block must be true stereo
> or joint stereo all the way through). If Matroska was simply storing the
> data block that WavPack passed back then this could be accomplished with
> complete transparency to Matroska.

Alright, another point to store the header as-is :)

> On the multichannel issue I had originally assumed that Matroska would
> divide the multichannel audio into various stereo and mono streams and have
> WavPack enocode them like that. In that case Matroska would keep track of
> the timing and what speakers the streams were supposed to go to. Now that I
> think about it I realize that ideally the codec should handle the
> multichannel data directly because it might want to make bitrate decisions
> based on all the channels, or even store the data as some sort of complex
> matrix. For using codecs that can only handle stereo and mono streams, it
> might still be a reasonable thing for Matroska to be able to do. However,
> WavPack will be able to handle multichannel directly by using multiple
> stereo and mono blocks in sequence (and obviously storing the information
> required to know what goes where during decode, and again transparently to
> Matroska).

Alright, that's the way to go. For all known codecs that's the job of 
the codec to handle the multichannels (not the container) to compress 
data efficiently and, the most important, map the channels to the 
correct speaker. It is possible to have multiple streams playing at the 
same time with Matroska. But in this case the channel mapping might be 

> I am just starting to work with multichannel, so I hope that this makes some
> sense. Perhaps you could point me to an example multichannel codec interface
> (I was simply going to implement storage of WAVEFORMATEX and corresponding
> audio data).

I just know the Microsoft implementation. And I don't think there aren't 
many others in the wild. At least for the channel mapping (in DirectShow).

More information about the Matroska-devel mailing list