Channel mask only in Vorbis comments, or define a different metadata type for it? about flac-specification

[ktmf01]

Since the discussion on the formal specification of channel mask handling is still then not completely done

I'm not sure what you're referring to here. As far as I know there is no recent discussion on the channel mask part of the spec.

The spec has progressed too far in the IETF process to make big changes like these without a very good reason. I don't see that very good reason. This behaviour has been around for 17 years already (see xiph/flac@cc5c1d8) Probably using a tag wasn't the best way to do this, but I think it is now too late to change it, not just because of the state of the spec in the IETF process, but in general.

[H2Swine]

Well not so fast - although it is my bad, in a way: Even if it has behaved this way for years, the IETF document does indeed prescribe something "new" to it when the channel allocations are non-standard, which are pointed to Application, 8.6.2 last sentence. Reading 8.4 that it doesn't forbid this nor that, it seems the answer actually is "If a Vorbis comment isn't good enough for you, then go ahead register an Application block - you're on your own of course"
Similar for content when sample rate is set to 0 in Streaminfo, 8.2, then it is recommended (not using caps - deliberate?) to use a Vorbis field or an application metadata block.

Although then, I don't know whether the document is clear enough what metadata a decoder MUST/SHOULD honour, especially when it can read Application and encounters one it does not understand: it could affect playback, at least if sample rate or WAVEFORMATEXTENSIBLE tag is declared as zero. Are they permitted to just skip? SHOULD they skip, if WAVEFORMATEXTENSIBLE equals zero and they cannot read the Application block?

(It likely makes sense to consider whether a decoder may honour unregistered Application blocks - i.e. maybe put a MUST or SHOULD also in the first line of Table 5 in 8.4. I don't know whether it is clear enough as is in the document.
To be clear, both this and the previous "I don't know whether" are literally an "I don't know", it might be that there is an agreed-upon answer and the issue could be closed.
Uh, and 8.4 makes reference flac.exe a "third-party" application :-) That is not making any confusion though.)

[ktmf01]

Well not so fast

I fail to see how this comment relates to the original issue.

As we know, FLAC is being used for way more things than music playback. That last sentence of 8.6.2 was specifically added for decoding ambisonics, which is complicated enough that it would warrant its own RFC. Other uses like multitrack recordings or non-audio signals to name a few, are too diverse to put MUST and MUST NOT stuff around. I simply cannot comprehend all possible use cases.

So, if you use FLAC for music in common formats, than this document is clear enough I think. If you use it for ambisonics, there is a need for additional specification, which the working group cannot provide at this time. If you use it for recordings or measurements, the specification leaves a lot of stuff open, but you probably shouldn't try to play those back in a regular playback application anyway and expect it to work correctly.