[matroska-devel] Re: Audio ACM compatibility

Steve Lhomme steve.lhomme at free.fr
Tue Feb 18 14:34:00 CET 2003

En réponse à Moritz Bunkus <moritz at bunkus.org>:

> Hi.
> > Remember we're not building smething for a demo and change everything
> after !!!
> > We're building something that is going to last. So please stop doing
> this kind
> > of ugly hack !
> So using A_MS/ACM is strongly discouraged and we should use A_* if
> there is one for the current audio codec. Then we store what private
> data the codec has in KaxCodecPrivate. This could be:

I agree with the 'if' but there is a 'else'. Else we use "A_MS/ACM" we don't
just drop an assertion saying this codec should not go in matroska...

>  - the data after the WAVEFORMATEX as given by the cbSize member

Why do you want to store a Microsoft structure in something that has *nothing*
to do with any Microsoft system (ie CodecID != A_MS/ACM) ?

>  - other data as produced by the audio codec, e.g. headers, comment
> and setup packets produced by the Vorbis encoder

Yes, native matroska IDs should define for each what to put in KaxCodecPrivate.
We need to have a list of these IDs and the description of what to put in the
KaxCodecPrivate field.

> All fields of WAVEFORMATEX can be reconstructed from the Matroska
> elements, even the wFormatTag, you just need a mapping from the
> KaxCodecID to the wFormatTags.

That's it.

> So how do we save more than one packet in KaxCodecPrivate? As
> mentioned
> Vorbis needs three packets. So we have three possibilities:
>  - create sub elements for KaxCodecPrivate, insert as many as you need
> and define the order in which they have to appear (for Vorbis it's
> easy: just take the order the Vorbis headers appear in an Ogg file:
> headers, comments, setup data)
>  - insert as many KaxCodecPrivate elements as you need and define the
> order in which they appear
>  - use a well-known struct and save that in KaxCodecPrivate, e.g.
> (pseudocode) 
> int32 length1;
> char data1[length1];
> int32 length2;
> char data2[length2];
> int32 length3;
> char data3[length3];
> int32 length4; // stop when a length field is 0
> What do you propose?

I really prefer the last option ! The other ones make things complicated for no

More information about the Matroska-devel mailing list