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