lvqcl wrote:
> 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.
Please note that the above should have read:
|| 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), any
|| one of the 15 other single-bit masks or zero.
That is to say, for a single channel file any one
(but only one) or zero bits can be set.
>> 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.
So change it. FLAC has got itself into a mess
over channel masks, so there is a need for a
re-think. There is also a need for the new
FLAC to not reject WAVE-EX files that were
previously accepted. Other than that, I do not
see a barrier to change.
I am also puzzled why anyone would want
FLAC to reject a valid WAVE-EX file. I
suggest the new FLAC should accept all valid
WAVE-EX files (with the restriction that the
number of bits in the channel mask should
match the number of channels, a restriction
WAVE-EX does not enforce).
> 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.
The FLAC default channel assignment for a
four-channel file is "front left, front right, back
left, back right". The channel mask 0x33
complies with this, 0x603 does not as it
substitutes SPEAKER_SIDE_LEFT and
SPEAKER_SIDE_RIGHT.
Let's start afresh and consider channel
assignments in general. The FLAC spec at:
https://xiph.org/flac/format.html
states:
Again, since a decoder may start decoding at an arbitrary frame in the
stream, each frame header must contain some basic information about
the stream because the decoder may not have access to the STREAMINFO
metadata block at the start of the stream. This information includes
sample rate, bits per sample, number of channels, etc.
So, for a FLAC file to be streamable then the
four "Channel assignment" bits in
FRAME_HEADER must actually repeat the
number of channels (initially specified in the
STREAMINFO block). The "Channel
assignment" bits in FRAME_HEADER also
contain the Channel assignment and, when
these two uses of the same four bits are in
conflict, a different channel assignment can
be specified in the FLAC tag
WAVEFORMATEXTENSIBLE_CHANNEL_MASK.
(If the two uses of the "Channel assignment"
bits in FRAME_HEADER do not conflict then
the FLAC tag serves no purpose.)
So, in your example above, the FLAC tag
containing the channel mask 0x33 is
redundant while 0x603 is not.
The WAVEFORMATEXTENSIBLE_CHANNEL_MASK
also specifies the channel order. From the
Microsoft spec for WAVE-EX:
The channels specified in dwChannelMask must be present in the
prescribed order (from least significant bit up).
The FLAC default channel assignments all
comply with this channel order.
This description also agrees (I believe) with the
FLAC change log at:
https://xiph.org/flac/changelog.html
where it states:
AC 1.1.3 (27-Nov-2006)
Now properly supports AIFF and WAVEFORMATEXTENSIBLE multichannel
input, performing necessary channel reordering both for encoding and
decoding. WAVEFORMATEXTENSIBLE channel mask is also saved to a tag on
encoding and restored on decoding for situations when there is no
natural mapping to FLAC channel assignments.
Regards,
Martin
--
Martin J Leese
E-mail: martin.leese stanfordalumni.org
Web: http://members.tripod.com/martin_leese/