flac dev - Jul 2015 - WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not described

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/

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.

Op 16-07-15 om 17:58 schreef lvqcl:
> 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.
I would propose: 0000-0111 : (number of independent channels)-1. 
The channel order is defined through the 
WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If 
no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the channel 
order follows SMPTE/ITU-R recommendations, which are as follows:

Martijn van Beurden wrote:
> Op 16-07-15 om 17:58 schreef lvqcl:
>> 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.
>
> I would propose: 0000-0111 : (number of independent channels)-1.
> The channel order is defined through the
> WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If
> no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the channel
> order follows SMPTE/ITU-R recommendations, which are as follows:
This looks like an excellent proposal.  I
suggest *where* in the FLAC spec the
WAVEFORMATEXTENSIBLE_CHANNEL_MASK
vorbis comment is described also needs to be
stated .  It needs be described somewhere
because it is not obvious how a single 32-bit
word should be stuffed into "a short text
comment".

The Vorbis comment could be described in the
FLAC spec under FRAME_HEADER, under
METADATA_BLOCK_VORBIS_COMMENT or
in a new section in the general spiel near the
top.  I would suggest in the general spiel.  (At
the moment, the METADATA section does little
more than point to the Ogg Vorbis I format
specification; the detail of this particular Vorbis
comment should not be in the Vorbis spec.)

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

On 7/16/15, Martin Leese <martin.leese at stanfordalumni.org> wrote:
> Martijn van Beurden wrote:
>> I would propose: 0000-0111 : (number of independent channels)-1.
>> The channel order is defined through the
>> WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If
>> no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the channel
>> order follows SMPTE/ITU-R recommendations, which are as follows:
>
> This looks like an excellent proposal.
I tried to find the specific SMPTE/ITU-R
recommendation on channel order.  I found a
reference to "ITU-R BR.138", but this is not
available from the ITU-R Recommendations
website.  Does anybody have a copy of this?

I found lots of places which state the
SMPTE/ITU-R recommendation on channel
order.  But all these are only for 5.1, and
are the usual front left, front right, front center,
LFE, surround left, surround right.  I therefore
suspect the SMPTE/ITU-R recommendation is
only for 5.1.

With this in mind, I now propose the following
wording in the FLAC spec:
0000-0111 : (number of independent channels)-1. The channel assignment
and order is defined through the WAVEFORMATEXTENSIBLE_CHANNEL_MASK
FLAC tag. If no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the
channel assignment and order follow SMPTE/ITU-R recommendations (where
defined) and are as follows:

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