[flac-dev] WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not described

[lvqcl]

Martin Leese wrote:

> Your proposed wording was:
>    0000-0111 : (number of independent channels)-1. The channel order
> follows SMPTE/ITU-R recommendations. The assignments are as follows:
>
> The channel order might not follow SMPTE/ITU-R
> recommendations, so this proposed wording
> seems misleading to me.

But this text describes only those 4 bits in frame header.
IMHO this sectoin should not describe WAVEFORMATEXTENSIBLE_CHANNEL_MASK,
it should be described somewhere in vorbis comments section.



>>> So the WAVEFORMATEXTENSIBLE channel
>>> mask is saved ONLY when the channel order
>>> does not follow SMPTE/ITU-R recommendations.
>>
>> Not quite true.
>
> Then the changelog at:
>     https://xiph.org/flac/changelog.html
>
> is incorrect.

Yes, but the changelog is not a formal documentation anyway.
Maybe it's better to fix the current flac commandline encoder,
or maybe it's better to allow the existence of this tag even
when it is unnecessary.



>> The channel mask implicitly contains the number of channels;
>> but such files probably won't be compatible with all existing
>> decoders. What's better: a sound with incorrect channel assignment
>> or no sound at all?
>
> As I described, Microsoft's own specification
> for WAVEFORMATEXTENSIBLE includes an
> example containing six channels but a channel
> mask of zero.  Clearly, the channel mask does
> not always implicitly contain the number of
> channels.  Not every FLAC or
> WAVEFORMATEXTENSIBLE file will contain
> speaker feeds.  The FLAC specification needs
> to allow for this.

I don't understand why FLAC needs it.
Current commandline encoder doesn't support arbitrary WAV channel maps.
If channel_mask == 0 and the number of channels is 1 or 2 then the encoder
treats such files as ordinary mono (FC) or stereo (FL+FR) files (apparently
for compatibility with old/broken software). Otherwise the number of bits
in the channel mask must be equal to the number of channels. And nobody
complains about this.



> The underlying problem is that FLAC has got
>  itself into a mess over channel assignments.
> The number of channels is specified in the
> METADATA_BLOCK_STREAMINFO, but
> using only three bits.  (Three bits is insufficient
> for the channel assignment, even though this
> information is STREAMINFO.)  The number of
> channels is repeated in the FRAME_HEADER,
> this time using four bits.  It appears that these
> four bits were then used to specify the channel
> assignment.  The channel assignment can then
> be repeated in a WAVEFORMATEXTENSIBLE
> channel mask tag.

The problem IMHO is that there's no place inside a frame header
to store arbitrary channel map.



> What is required, I would suggest, is a simple
> and unambiguous way for an application reading
> a FLAC file to navigate this mess.  There needs
> to be a way to tell the application, "Don't look
> here for the channel assignment, look there".

IMO the most important thing is compatibility with
the current decoders. Also, there are many programs that
already properly use WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag,
so the best thing is to document their current behavior.