[flac-dev] WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not described

[Martin Leese]

lvqcl wrote:

> Martin Leese wrote:
>> Note that the channel order may not be defined.
>
> IMHO it doesn't matter in this place of documentation (which describes
> default channel assignments for FLAC).

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.

>> 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.

> 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.

The Microsoft specification can be viewed at:
http://www.ambisonia.com/Members/mleese/file-formats/multichaud.pdf/view


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 WAVEFORMATEXTENSIBLE  specification
is better in this regard because the number of
channels and channel assignment are stored
separately (as Format.nChannels and
dwChannelMask).

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".

Regards,
Martin
-- 
Martin J Leese
E-mail: martin.leese  stanfordalumni.org
Web: http://members.tripod.com/martin_leese/