Maybe language lawyering over which RFC2119 definition "forbids" corresponds to exactly wasn't the best way to get to a constructive discussion.
Technical specs are intentionally written precisely in a "language lawyering" manner. If you're allergic to language lawyering, maybe you shouldn't engage with technical specs in the first place.
You're assuming here the decoder or player HAS these settings or even knows what ReplayGain is.
Not at all! If the player/decoder doesn't have these settings and doesn't know what ReplayGain is, then the player/decoder doesn't have these settings and doesn't know what ReplayGain is. That sucks I suppose, but it should not be up to the encoder/muxer to figure out how to make a player/decoder that sucks not suck, or do something it lacks the capability to do.
The foobar2000 behavior that you seem to object to is the one that gives the most desirable behavior with the dumbest players (while still working with better ones).
Incorrect/misleading. It gives what the foobar2000 devs have ascertained is the most desirable behavior with the dumbest players, while still working with the players that choose to break the spec by not necessarily applying the header output gain.
If you have a problem with that, that's on you, but don't be surprised that the developers continue to ignore you.
Ok...? I'm not sure what the purpose of this bit is, other than an attempt to be a snarky "gotcha".
Duly noted, I guess.
Going back through the past comments and how the spec evolved, you can actually see that R128_ALBUM_GAIN didn't exist initially...
Yes, I am very much aware of that, as well as the fact that that spec (the one that omits R128_ALBUM_GAIN) has been superseded and deprecated.
QuoteFurthermore, "use by default" out of context is misleading here, because it indirectly implies that the "other tools" can opt to not apply the header output gain.
It doesn't imply any such thing.
Yes it very much does, and that's not even this "language lawyering" you keep moaning about, but plain old elementary English. Something being said to be "use by default" is implied to be opt-out, i.e. the implication is that the decoders/players can choose to ignore the header output gain. And...
It describes what will happen if the user doesn't configure anything, or CANNOT configure anything, because the player doesn't really know about ReplayGain.
Yes, and if the player does know about ReplayGain/R128, then it still - according to the spec - must apply the header output gain, therefore the header output gain is not opt-out, therefore the header output gain is not "use by default".
Arguing that a player having *an option* to ignore parts of the spec is "breaking the spec" is simply not interesting.
I find it interesting and odd that you've elected to object with "not interesting" rather than "incorrect".
I mean, if you want, I can apologise that this has failed to pique your interest (even though your engagement seems to indicate the contrary). However, I fail to see the relevance...?
If this isn't interesting to you, well, then that's how it is I guess, but that's entirely immaterial to whether it is correct or incorrect.
QuoteIf a player chooses to apply any volume adjustment or gain
modification, (such as the R128_TRACK_GAIN (see Section 5.2),) the
adjustment MUST be applied in addition to this output gain in
order to achieve playback at the normalized volume.
I do think you are misunderstanding this. See my last comment: this specifies that the gain tags are being applied ON TOP OF the output gain, and that the need to combine these operations is a hard requirement to get the right result. Hence the MUST for "in addition to...in order to achieve playback at the normalized volume". It's important that the implementer understands these need to stack or they'll get the wrong outcome when switching Track Gain to Album Gain and the reverse.
Yes, that indeed is what this
or gain modification, (such as the R128_TRACK_GAIN (see Section 5.2),)part of that sentence is about. I haven't misunderstood that at all.
What I have also perceived, understood, and taken into account, is this part of the sentence:
any volume adjustmentDo let me know when you do so, as well.
Saying that a player that has a volume control is not spec compliant if it offers an option to ignore that tag is not just uninteresting
Again with this "uninteresting" thing...?
Ok, sure - if it'll make you feel better, I'll concede that it is, indeed, "uninteresting". But it is also correct.
There. Happy? I don't understand what we've achieved. 🤷
it's easily verified as wrong because the spec does use SHOULD and not MUST for applying the gain in the first place (see, I can RFC2119 language laywer too!).
Except that "SHOULD" only applies if the player/decoder doesn't do "any volume adjustment". If it does, then the "MUST" applies. This is elementary reading comprehension. If that's what classifies as "language lawyering" to you... then I don't know what to say.
This very exact point is literally *spelled out* in the spec revision here: https://mailarchive.ietf.org/arch/msg/codec/zctRSJ84-Gd5G3XSUcNB-lAGSO0/
Same remark about the "S-H-O-U-L-D" as the above.