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 36561 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus and replay gain

Reply #50 –
Quote from: yindesu on
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 –
Quote from: doccolinni on
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 –
Quote from: Garf on
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.

Quote from: Garf on
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.

Quote from: Garf on
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.

Quote from: Garf on
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.

Quote from: Garf on
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 from: Garf on
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...

Quote from: Garf on
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".

Quote from: Garf on
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 from: Garf on
Quote from: doccolinni on
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.

Quote from: Garf on
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.

Quote from: Garf on
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:
Quote from: doccolinni on
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.)

Re: Opus and replay gain

Reply #54 –
Quote from: Porcus on
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.

Re: Opus and replay gain

Reply #55 –
I'm running into some strange issue with ReplayGain metadata from FLACs influencing the playback gain in an Opus encoding of said FLAC file using opusenc. I'm trying to wrap my head around why reading this thread and a few others and how I could work around this since all software (audio players and even DAWs) respect the playback gain, as they should, and end up having (heavily compressed?) very loud tracks.

For example, my test file (happens with every song in my library) has some ReplayGain/R128 info in the original FLACs metadata (thanks loudgain :) )
Code: [Select]
[dave@cream ~]$ mediainfo ~/test.flac
General
Complete name                            : /home/dave/test.flac

Album replay gain                        : -6.75 dB
Album replay gain peak                   : 1.032246

REPLAYGAIN_ALBUM_RANGE                   : 7.35 dB
REPLAYGAIN_TRACK_RANGE                   : 3.86 dB

Sampling rate                            : 96.0 kHz
Bit depth                                : 24 bits
Replay gain                              : -7.08 dB
Replay gain peak                         : 0.980921
Normal right?
now when encoded using opusenc (opusenc --music --comp 10 test.flac test.opus), the metadata and/or encoded file ends up with
Code: [Select]
[dave@cream ~]$ opusinfo test.opus 
Processing file "test.opus"...

New logical stream (#1, serial: 7f496ba4): type opus
Encoded with libopus 1.3.1, libopusenc 0.2.1
User comments section follows...
        ENCODER=opusenc from opus-tools 0.2
        ENCODER_OPTIONS=--music --comp 10
        REPLAYGAIN_ALBUM_RANGE=7.35 dB
        REPLAYGAIN_TRACK_RANGE=3.86 dB
        R128_TRACK_GAIN=-84
        Playback gain: 95.25 dB

I ran the same FLAC without the ReplayGain tags, and it was at a normal gain level both audibly and in the metadata. Here is a screenshot in Bitwig Studio which I find baffling since the gain really is that loud.

Is there anyway to run opusenc without the ReplayGain tag copying so I can just add the tags later with loudgain, or some way to just make opusenc apply the tags without adding playback gain?

Thanks guys.

Re: Opus and replay gain

Reply #56 –
Quote from: dweee on
For example, my test file (happens with every song in my library) has some ReplayGain/R128 info in the original FLACs metadata (thanks loudgain :) )
Can you show all the tags, e.g. with:
Code: [Select]
metaflac --list --block-type=VORBIS_COMMENT ...
In particular if it has REPLAYGAIN_REFERENCE_LOUDNESS tag.

Quote from: dweee on
Is there anyway to run opusenc without the ReplayGain tag copying so I can just add the tags later with loudgain, or some way to just make opusenc apply the tags without adding playback gain?
You can try opusenc with --discard-comments option.

Re: Opus and replay gain

Reply #57 –
Quote from: danadam on
Can you show all the tags, e.g. with:
Code: [Select]
metaflac --list --block-type=VORBIS_COMMENT ...
In particular if it has REPLAYGAIN_REFERENCE_LOUDNESS tag.
[/quote]
Code: [Select]
[dave@cream ~]$ metaflac --list --block-type=VORBIS_COMMENT test.flac 
METADATA block #2
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 2614
  vendor string: Mutagen 1.45.1
  comments: 21
    comment[10]: REPLAYGAIN_ALBUM_GAIN=-6.75 dB
    comment[11]: REPLAYGAIN_ALBUM_PEAK=1.032246
    comment[12]: REPLAYGAIN_ALBUM_RANGE=7.35 dB
    comment[13]: REPLAYGAIN_REFERENCE_LOUDNESS=-18.00 LUFS
    comment[14]: REPLAYGAIN_TRACK_GAIN=-7.08 dB
    comment[15]: REPLAYGAIN_TRACK_PEAK=0.980921
    comment[16]: REPLAYGAIN_TRACK_RANGE=3.86 dB
Quote from: danadam on
You can try opusenc with --discard-comments option.
It works, however it obviously throws away all metadata and tags which is an issue.

Re: Opus and replay gain

Reply #58 –
Quote from: dweee on
Code: [Select]
    comment[13]: REPLAYGAIN_REFERENCE_LOUDNESS=-18.00 LUFS
That's what I thought. Support for reference in lufs was added only about a year ago, see issue 2361 - opusenc adds distortion-causing playback gain when encoding flac with replaygain tags. You probably have an older version. I think if you remove this tag it should be fine.

Re: Opus and replay gain

Reply #59 –
Quote from: danadam on
You probably have an older version. I think if you remove this tag it should be fine.
seems that there is no tagged release after this commit. Currently installing the -git version of all opus related packages. Should work then. Also I'm using [flac-mass-transcode](https://github.com/moex3/flac-mass-transcode) hence why I knew it was opusenc messing up.

EDIT: problem fixed! now time to re-encode my whole mixed lossy/lossless library into all lossy Opus and not transcoding lossy files :)
Thanks danadam!

Re: Opus and replay gain

Reply #60 –
Quote from: dweee on
Quote from: danadam on
You probably have an older version. I think if you remove this tag it should be fine.
seems that there is no tagged release after this commit. Currently installing the -git version of all opus related packages. Should work then. Also I'm using [flac-mass-transcode](https://github.com/moex3/flac-mass-transcode) hence why I knew it was opusenc messing up.

EDIT: problem fixed! now time to re-encode my whole mixed lossy/lossless library into all lossy Opus and not transcoding lossy files :)
Thanks danadam!

Very general question. Why would one use metaflac? Isn't fb2k capable of handling any tags in flac? Or am I thinking too much in FB2k/Windows dimensions, ie not everyone uses it?

Re: Opus and replay gain

Reply #61 –
You can use metaflac in scripts to manipulate tag information, including passing that tag information to other programs for automation purposes.