Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Opus and replay gain (Read 22400 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus and replay gain

Reply #50
My point remains that even today, it is far more difficult to get loudness normalization to work correctly with Opus files than it is to get it to work with other common music file formats like mp3/m4a/ogg/flac on Android.

I'm not sure what pointing to a few buggy libraries is supposed to prove. With MP3 and MP4, you have tools that rewrite and change internal gain values (with limited granularity) to a single setting- those tools don't even exist for Vorbis (AFAIK). For everything else, you rely on the player correctly implementing the tag handling. It's the same for Opus, except that if the latter isn't present, you can still use the "internal gain" method but it has good granularity. So you get the best of all the previous formats.

I'm a bit baffled by your claim and I can't make much sense of it. If developers get the channel order wrong (this was an issue with Vorbis too! You don't remember because it was fixed so long ago, but the Winamp plugin had a workaround for it), or can't tell signed from unsigned values, I'm afraid that there's nothing we could have done in the format spec to prevent that.

Re: Opus and replay gain

Reply #51
Well it shouldn't, because that is literally against the spec.

Foobar2000 has volume control, and - once again - straight from the spec:
Quote
       If 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.
By being able to have volume control and not apply the header output gain, foobar2000 is literally breaking the spec.

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.

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, 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!). This very exact point is literally *spelled out* in the spec revision here: https://mailarchive.ietf.org/arch/msg/codec/zctRSJ84-Gd5G3XSUcNB-lAGSO0/

Re: Opus and replay gain

Reply #52
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.

Quote
Furthermore, "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.

Quote
       If 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
Quote
       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:
Quote
       any volume adjustment
Do 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, 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 qualifies 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.

Re: Opus and replay gain

Reply #53
As for language lawyering:
Furthermore, "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. Whether that is true or not remains in a bit of a logical limbo, because the standard states:
Quote
       Players and media frameworks SHOULD apply it by default.  If 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.
The very first sentence makes it seem like a player can indeed decide not to apply the header output gain ("SHOULD").
However, the very next sentence means that any player that does any volume control whatsoever (i.e., any player) can not decide not to apply the header output gain ("MUST").

No disagreement that they SHOULD default to applying the gain (but always some disagreement on precisely what "SHOULD" means).
The rest is about how to interpret a second sentence saying "in addition to this" in the presence of the first. At least the following interpretations are possible.
(1) Your interpretation - correct me if I am wrong: any other adjustment must be applied in addition to the "SHOULD" thing, something that is impossible to achieve without it being observed and honoured - so the presence of a volume knob effectively upgrades it to a "MUST".
(2) First sentence says that this gain SHOULD be applied from the tag. If - for whatever reason that would be valid to reject a "SHOULD" thing - this tag or its value is not observed, then: pretend it is zero and proceed to next sentence.
(There is support for pretending this field to be zero, see next paragraph about muxers.)
(3) The second sentence is vacuous if the output gain tag is not observed. (That is: not even a requirement to pretend it is zero.)
(4) Second sentence prescribes how a volume adjustment and a gain tag should be read together "in order to achieve playback at the normalized volume", it applies to that specific purpose. However if and when an application handles the file without an ambition to achieve playback at the normalized volume, the sentence is vacuous.
(The discretion of the "SHOULD" part would be interpreted according to purpose anyway.)
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

 

Re: Opus and replay gain

Reply #54
No disagreement that they SHOULD default to applying the gain (but always some disagreement on precisely what "SHOULD" means).
The rest is about how to interpret a second sentence saying "in addition to this" in the presence of the first. At least the following interpretations are possible.
(1) Your interpretation - correct me if I am wrong: any other adjustment must be applied in addition to the "SHOULD" thing, something that is impossible to achieve without it being observed and honoured - so the presence of a volume knob effectively upgrades it to a "MUST".
(2) First sentence says that this gain SHOULD be applied from the tag. If - for whatever reason that would be valid to reject a "SHOULD" thing - this tag or its value is not observed, then: pretend it is zero and proceed to next sentence.
(There is support for pretending this field to be zero, see next paragraph about muxers.)
(3) The second sentence is vacuous if the output gain tag is not observed. (That is: not even a requirement to pretend it is zero.)
(4) Second sentence prescribes how a volume adjustment and a gain tag should be read together "in order to achieve playback at the normalized volume", it applies to that specific purpose. However if and when an application handles the file without an ambition to achieve playback at the normalized volume, the sentence is vacuous.
(The discretion of the "SHOULD" part would be interpreted according to purpose anyway.)

The way I see it, the wording and meaning of that section of the spec are entirely unambiguous.

The first sentence specifies that any player/decoder SHOULD apply the header output gain, i.e. that its application is encouraged/recommended, but technically not mandatory.

The second sentence specifies the conditions under which a player/decoder MUST apply the header output gain, i.e. the conditions under which its application is mandatory. The second sentence unambiguously specifies that those conditions are satisfied if a player chooses to apply any
  • volume adjustment, or
  • gain modification.
Now, while this is unambiguous, it is also redundant - "gain modification" is a type of volume adjustment, so just "volume adjustment" would have sufficed, as gain modification would have been included in that.

But regardless of that, the point is that while gain modification is a type of volume adjustment, it is not the only type of volume adjustment. A volume slider or volume increase/decrease buttons are also a type of volume adjustment. Therefore, if your player/device features one of those, it applies a type of volume adjustment, thereby satisfying the conditions specified by the second sentence.

If that's not the intent of the spec authors, the spec should be modified/updated. But as it is written, that's what the spec specifies.