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