flac dev - Jul 2015 - A couple of questions about channel mapping

Sorry for the delay; I have been waiting for
SourceForge to come back on-line.

lvqcl wrote:
> 1) It seems that some programs (eac3to) write the value of
> WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag with uppercase 'x' (e.g. 0X3)
> (see <http://forum.doom9.org/showthread.php?p=1728852#post1728852>)
>
> Also, from MediaInfo changelog
<https://mediaarea.net/MediaInfo/ChangeLog>:
> Version 0.7.74, 2015-05-25
> x VorbisComment: WAVEFORMATEXTENSIBLE_CHANNEL_MASK "0X"
("x" in uppercase)
> is accepted now
>
> In flac we have:
>      if(strncmp(p, "=0x", 3))
>          return false;
> so it's case-sensitive. Should it be changed to case-insensitive
> FLAC__STRNCASECMP?
Yes.  Off hand, every programming language I
can think of that recognizes 0x... also
recognizes 0X....
> 2) Previously flac accepted mono files with 0x0001 channel mask; mono files
> with correct value (0x0004 = front center) were rejected without
> --channel-map=none option.
> (see <http://sourceforge.net/p/flac/feature-requests/96/>)
>
> It was fixed, but now flac accepts mono files with three different channel
> masks:
> 0x0001 (FL), 0x0002 (FR), 0x0004 (FC).
>
> Should flac reject the first two masks when there's no
--channel-map=none
> option?
Why place restrictions on which speaker a
user can use?  The Microsoft spec for
dwChannelMask (WAVEFORMATEXTENSIBLE_CHANNEL_MASK)
includes the following:

Should nChannels be less than the number of bits set in dwChannelMask,
then the extra (most significant) bits in dwChannelMask are ignored.
Should nChannels exceed the number of bits set in dwChannelMask, then
the remaining channels are not assigned to any particular speaker
location.
...
Having nChannels exceed the number of bits set in dwChannelMask can
produce inconsistent results and should be avoided if possible.

If, for example in a multi-channel audio authoring application, no
speaker location is desired on any of the mono streams, the
dwChannelMask should explicitly be set to 0.

So, the FLAC encoder should definitely reject
a dwChannelMask where the number of
channels in the file (specified in the
STREAMINFO block) exceeds the number of
bits in the mask (except when dwChannelMask
= 0x0).  There is an argument for also rejecting
a dwChannelMask where the number of
channels in the file is less than the number of
bits in the mask.

Finally to answer your question, for a
single-channel file, FLAC should accept any
one of the three masks 0x00000001 (FL),
0x00000002 (FR), 0x00000004 (FC), plus any
one of the 15 other single-bit masks, plus zero.

Hope this helps to clarify things.

The Microsoft spec for
WAVEFORMATEXTENSIBLE is available at:
https://sites.google.com/site/mytemporarydownloads/

Scroll down to "The WAVE and WAVE-EX file
formats" and look for "multichaud.pdf".

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

Martin Leese wrote:
> Why place restrictions on which speaker a
> user can use?
> Finally to answer your question, for a
> single-channel file, FLAC should accept any
> one of the three masks 0x00000001 (FL),
> 0x00000002 (FR), 0x00000004 (FC), plus any
> one of the 15 other single-bit masks, plus zero.
>
> Hope this helps to clarify things.
But that's not how FLAC currently works. It accepts only WAV files
with channel maps equivalent to its own default channel assignment.

For example, the default channel assignment for 4-ch audio
is front left, front right, back left, back right.
The command-line encoder accepts 4-channel WAV files with channel
masks 0x33 (FL, FR, BL, BR) and 0x603 (FL, FR, SL, SR). To encode
other files '--channel-map=none' option is required.