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/ _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev