matroska: channel mapping info ... where/how it is stored ?

[spectrvm]

I was browsing through the specification documentation and I can't figure out where/how channel mapping info is stored on matroska files.

I'm assuming (correctly ?) that for a given (multi-channel) audio track there should be some flag/tag/element which states the corresponding mapping for the following data and that this flag/whatever is to be set by the muxing app creating the matroska container from the source file (such as a wav whether it is WAVEFORMAT, WAVEFORMATEX, or WAVEFORMATEXTENSIBLE)

Can anyone provide some links or point me in the right direction ?

[nevcairiel]

Matroska does not have a generic channel mapping field.

The information is stored specific to the codec used
- Most modern codecs have this information in their own bitstream, and the decoder will extract it.
- Or a codec specific private data format which contains this information, the decoder will also know how to read this
- The A_MS/ACM type for generic WAV audio storage has a WAVEFORMATEX in the private data

[spectrvm]

First and foremost thanks for your reply :)

I am well aware of the specifics of channel mapping for many codecs; however, reading your reply it struck me as very oddly that matroska does not have such a field. Do you know why the matroska developers choose not to include a generic field ?

I mean, for example, for an audio track:

- you can have (generic) language field
- you can have (generic) sampling frequency, channel count, and bit depth fields

- so, why is channel mapping considered private when every audio track should have it ?

- won't it be far easy to have a (at least optional) generic channel-mapping to avoid such things as to stuff a container within a container in order to just keep the channel-mapping flag ? eg: WAVEFORMATEXTENSIBLE[PCM] as being done in makeMKV ?

- won't it be far easy for a player to map channels according to this flag (which should be set at creation time by the muxing app) instead of executing many lines of hard-coded methods for each codec floating around and ... worse yet; to have to update such code every time a new codec comes around the corner ?

- ain't the primary function of a container to state metadata of the data that is following ?

These are my initial thoughts but I suppose the developers have good reasons to make it this way and certainly I will like to know a little bit more about this one. If you know of some documentation or discussions or anything you consider I should know please, let me know.

THANKS A LOT :)

[spectrvm]

A_MS/ACM type for generic WAV audio storage has a WAVEFORMATEX in the private data

moreover; while this is being possible, and widely used, mkvToolNix can't even extract a track with A_MS/ACM, it's a one way, you put it in there, and that's the end to it

[Mosu]

We haven't done it because nobody thought of it. And nobody has shown any interest in doing the work for it; hence Matroska doesn't have such a field yet.

mkvmerge can also not create such tracks (with CodecID = A_MS/ACM); it can only re-mux such tracks from other Matroska files in its dumb pass-through mode.

[spectrvm]

We haven't done it because nobody thought of it

Thanks for your clarification on the lack of channel-mapping metadata in matroska. Lately I have been travelling a lot unable to follow some of my last posts.

The reason I was asking for such a feature is that I am trying to simplify my media collection discarding as many codecs as I can (lossless that is) beacuse I am really tired of dealing with each codec settings/preferences/filters/whatever. I leave the video track as is while decoding every audio track to uncompressed PCM from TrueHD, DTS-HD MA, etc. Cons for this approach are (needless) increased file sizes but with storage getting cheaper each day I rather prefer having 1/2 additional GB per disc than having to deal/check/remember each codec issues. I started with FLAC but now I decided going the uncompressed way so the only things I should worry about are matroska and video (codec) compatibility, period.

This brings to the point what I was asking for to begin with: I didn't know how channel info was managed by matroska for multiple LPCM tracks.