Skip to main content
Topic: Opus and replay gain (Read 14618 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opus and replay gain

Reply #25
If the output gain is the Album Gain, but the player developer and/or the user doesn't understand the significance of this, then Opus files will play back about 15dB quieter than mp3s (both ripped from the same 2014 CD), and there's nothing the user can do about it.


Consider this scenario for a second here. You're assuming the user has (1) ReplayGain tagged Opus files yet no understanding that they are...from what source would those appear exactly? (2) MP3 files that are not ReplayGain tagged or a player that doesn't have ReplayGain support.

This scenario is identical to someone CURRENTLY plugging ANY ReplayGained file into a player that DOES support ReplayGain and wondering why it's quieter than his other files.

So you're preaching doom over a scenario that already exists outside Opus.

Quote
How soon before someone writes a tool to batch re-set the output gain on a bunch of Opus files to 0, or creates a player that ignores the output gain by default (hence breaking the Opus spec)?


In both of these cases, they'll learn why the gain is there, and there's good chances that they offer a proper option for it. So a win in my book.

Quote
Quote
If you know that playing at the right loudness will cause clipping, there's no right way to play back the music.
You know there are two ways to mitigate this.


And they both suck, hence "no right way to play back the music" in that case.

Quote
can never have the "just play it a bit quieter but without damaging the audio" option.


Unfortunately this (peak normalization) isn't actually very good at totally preventing clipping in practice, and you're losing the benefit of ReplayGain in the first place when doing so. So no, I don't think it's worth it.

Quote
This makes no sense. If you called the Output Gain "Album gain", specified that it was either absent or correctly filled by the encoder, specified that every player must apply it by default (they can add a user option to disable it if they want), and also included peak information - then you'd have exactly the benefits that you seek, but avoid most of the drawbacks. Specifically, not including peak information isn't a required step to get to where you seem to want to. It's not a necessary cost. It's a pointless mistake.


Adding complexity to a system is always a cost. Your description is just "I want a pony", and terribly non-constructive. What was designed in Opus is a system that will bring the benefits of ReplayGain (sans clipping prevention, which I believe to be senseless and would have required player support) to every player, even if they have no ReplayGain support. This is a huge win over the situation with Vorbis.

Opus and replay gain

Reply #26
First, how could one add accurate peak information to Opus files knowing that decoders don't produce bit-exact output?

All fields can be filled with bogus values including ReplayGain tags. So all solutions will depend on non-100%-dependable assumptions anyway.

If I was presented with this problem as a developer, I would:

1- Use -23LUFs (as default) globally for consistency.
2- Ignore ReplayGain tags if Opus gain is set.
3- If Opus gain is not set, respect ReplayGain tags even if their values are probably inaccurate.

Note: ReplayGain tags in OGG Opus files will probably be the result of tag copying. So their values wouldn't be accurate as the operation was lossy and Opus decoders are not bit-exact.

Opus and replay gain

Reply #27
It is a relatively simple task to copy across Vorbis Comment tags of any sort from Flac or Ogg files into Opus files and plenty of tools will do that for you.  They are not gains calculated for the Opus file but closer than anything else available to most people.  So if they occur I'm going to at least give the option to respect them.  There is a reference Opus gain tool under development, but I haven't checked in to see where that it at.  Right now the only place I see non-zero Opus output gains is on some streams.  And not others!  Respecting them causes violent loudness swings between different streams, exactly the situation that replay gain is intended to avoid.

More importantly seems to be the attitude that the Opus standard should be respected in its entirety wrt gain.  That is simply unworkable in a music player.  While "just works" is a laudable goal, in this case it is "just works for most people that don't care".  The standard says the output gain must *always* be applied.  The suggestion is that it *may* be an album gain, or it may not.  How can a gain that *must always* be applied be an album gain?  What if someone doesn't want an album gain, or any volume correction gain?  If the output gain was an album gain then it should be ignored, but if it isn't an album gain then there is no album gain.  I appreciate that the codec was not developed with audiophile players at the head of the customer list, but it is simply broken in this respect.

As for peaks and scaling, I'm not a huge fan of it.  Apart from anything else, it just messes up the rest of the replay gain adjustments, often for no good (ie. audible) reason.  Still, if the tags exist (with compatible gain tags) I will at least give the option to apply them.  Good music players offer the option of peak scaling or not and I don't see any reason not to respect that decision using the best information I have available.

Opus and replay gain

Reply #28
Garf, I know you get pleasure from arguing things, and I know it would make life easier if the Opus spec was right on this, but it simply isn't. Your arguments that it's all fine are totally unconvincing...

If the output gain is the Album Gain, but the player developer and/or the user doesn't understand the significance of this, then Opus files will play back about 15dB quieter than mp3s (both ripped from the same 2014 CD), and there's nothing the user can do about it.


Consider this scenario for a second here. You're assuming the user has (1) ReplayGain tagged Opus files yet no understanding that they are...from what source would those appear exactly?
I think most people have audio files that they didn't create themselves. I bet the majority of audio files in the world are in the hands of people who didn't create them.

Quote
(2) MP3 files that are not ReplayGain tagged or a player that doesn't have ReplayGain support.

This scenario is identical to someone CURRENTLY plugging ANY ReplayGained file into a player that DOES support ReplayGain and wondering why it's quieter than his other files.
It's far from identical because there's one critical difference: In most players, ReplayGain is off by default until you switch it on. In Opus players, Output Gain is applied by default (and usually non-defeatable).

So no one hit this problem before, unless they intentionally switched ReplayGain on. Whereas with Opus, anyone who hits this problem can't switch the bl**dy thing off!


This raises yet another problem with the Opus specification: With all other formats, if some files have ReplayGain information, and some files don't, you can set a separate pre-amp for the non-ReplayGained files to avoid being blasted out by them. Players can do this because they can see which files have ReplayGain tags, and which files do not. This is really useful, because it saves having to ReplayGain scan every podcast and test track that comes through your player - your player can just turn them down by, say, 8dB automatically. However, with this Opus problem where Output Gain might be a ReplayGain value, or it might not be, you've killed this useful functionality as well.


I think we've now got five scenarios where the Opus implementation goes wrong.

Quote
Quote
Quote
If you know that playing at the right loudness will cause clipping, there's no right way to play back the music.
You know there are two ways to mitigate this.


And they both suck, hence "no right way to play back the music" in that case.
Clipping is what sucks most, and that's all you're left with in the Opus implementation. A slightly lower volume or a compressor are both preferable to clipping.

During this discussion, I think maybe you have in mind clipping in typical pop tracks, especially clipping caused by inter-sample overs or lossy compression. In the default Opus scenario (-23LUFs reference Output Gain), that's not what we're talking about at all. We're talking about really wide dynamic range classical pieces getting the peaks of the crescendos cut right off. Some compression, or a lowered level, is vastly preferable in this case.

Quote
Unfortunately this (peak normalization) isn't actually very good at totally preventing clipping in practice
Do you mean inter-sample overs? That's almost a red herring in this scenario. The kind of mastering that suffers most from inter-sample overs is going to be peaking at about -15dB FS when loudness normalised to -23LUFs. Even so, you can store the peak in accordance with EBU R128 inter-sample over calculations if you want.

Quote
Adding complexity to a system is always a cost. Your description is just "I want a pony", and terribly non-constructive.
Suggesting a way that fixes the problems I've identified is non-constructive? Storing a peak value in a system that's already running an EBU R128 loudness calculation is "adding complexity"?! That's like saying we should stop writing full stops at the end of sentences to save ink.

Quote
What was designed in Opus is a system that will bring the benefits of ReplayGain (sans clipping prevention, which I believe to be senseless and would have required player support) to every player, even if they have no ReplayGain support. This is a huge win over the situation with Vorbis.
That would be grand if it worked, but there are just so many ways in which it doesn't.

Cheers,
David.

Opus and replay gain

Reply #29
The standard says the output gain must *always* be applied.  The suggestion is that it *may* be an album gain, or it may not.  How can a gain that *must always* be applied be an album gain?
I think you've summarised the worst problem perfectly.

There are workarounds (you could always install fb2k just to see what it's doing  ), but they are easily broken.

Cheers,
David.

 

Opus and replay gain

Reply #30
Well I'm fairly settled on what to do about the "worst" Opus gain issue.  I simply give the user an option to decide whether the output gain is an album gain or not.  There just isn't any information I can use to make that decision inside the code, and the consequences of not making it aren't acceptable in the context of a quality music player.

I'm still slightly struggling with the peak scaling issues.  I'm working within a player that treats lack of any peak information as if the peaks are exactly 1 (full scale).  So, assuming that scaling is chosen, all positive gains are essentially ignored.  If there are REPLAYGAIN* tags and peaks, and if I'm using them in preference to Opus gain settings, then all is straightforward just as with any other codec.

However when using Opus gains, I can't realistically use any REPLAYGAIN* peaks so the assumption is that the peak is at full scale.  Much of the time this isn't a problem, because Opus gain values tend to be negative, but using a preamp gain (or the automatic reference loudness correction option) to correct for the inherent quietness of Opus gains means it is easy to end up looking like a track will clip.  I guess that's just tough, and people shouldn't use that setting (to scale back from peak clipping) if they want to boost the gain when they don't have any peak information (or even if they do have peak information!).  It also isn't immediately obvious whether an implicit full scale peak should be assumed with or without the Opus output gain.

Fingers crossed I've handled the other four Opus gain issues adequately.  I've lost track of what they all were

Opus and replay gain

Reply #31
Meanwhile, there is still no opusgain tool 


No but I recenty re-encoded my entire collection to opus (I have archival flac) and I did some experiments.

With the reference encoder in Linux anyway, if the flac source has an album gain that gain will be aplied before encoding. So there is no need for an album gain, only track gain, if you follow what appears to be their model.

What I assume to be the difference between album gain and track gain is then written as R128Gain.

If the flac file has no replay information, opusenc does nothing. But if you have the replaygain tags in the source flac, they are applied so that you don't need a separate album gain.

When listening in album mode, no gain needs to be applied.
When listening in random mode, then the track gain is there (though R128 not ReplayGain)

So it appears their model is apply the gain before encode, and then only use a gain value if the track gain differs from album gain.

I actually like that model because it does not depend upon clients to add the gain for it to be a reasonable relative volume to other media in the library.

So I am not sure a separate tool is really needed unless you reject their model and don't calculate the gain before encoding to feed to the encoder.

-=-

OT: Is it just me or is the opus encoder much faster than vorbis encoder?

EDIT - after reading another thread, I guess what it actually is doing is putting the album gain in that hidden playback header and not applying it the decoded flac. Same end result I guess.

Opus and replay gain

Reply #32
Correct, the R128 track gain is the difference between the track gain and the album gain (aka Opus header output gain).  You would apply both to get the correct track gain adjustment.  Do you know if opusenc bumps the Flac replay gain values down by 5dB or just copies them across as is?    My version of opus-tools doesn't transcode direct from Flac.  To follow the spec, audio plus Opus gains should be quieter than audio plus Flac (REPLAYGAIN*) gains.

The big gotcha is of course that now you can't turn off replay gain on your Opus tracks.  They will always play with at least the album gain applied.  Hence my endless questions

Although the Opus header gain is not stored in a tag, it is stored separately from the audio.  So the audio is still encoded unchanged and the gains applied after (or during) decoding.  It is even possible to tell the library not to apply either of the gains (even the "mandatory" output gain) and just play the audio as it was originally.

The Opus encoder is pretty fast considering, but it varies a great deal depending on the settings it is used with.  Same for Vorbis.

Opus and replay gain

Reply #33
The Opus encoder is pretty fast considering, but it varies a great deal depending on the settings it is used with.  Same for Vorbis.


Okay I feel silly, I've been encoding Opus at 64 kbps because I am toying with starting an icecast server so I wanted to test out 64kbps - but when I encoded vorbis I usually use quality of 6 or 7.
Yeah, that explains it.


Opus and replay gain

Reply #35
Thanks for posting that link. It's a good step in the right direction.

Cheers,
David.

Opus and replay gain

Reply #36
Yes, I think the new tag allows a sensible implementation of gain for Opus tracks.  It leaves more questions than I expected about exactly how much of the output gain, if any, is replay gain and what to do about the rest, but it is possible to come up with a workable implementation without bothering the user with endless questions.

Re: Opus and replay gain

Reply #37
Ugh, i'm still confused about the format of these tags.

According to the RFC, its a Q7.8 value in DB similar to ReplayGain (as Garf stated, ReplayGain - 5). Except then they say (in the next paragraph) that its a maximum 6 character, 16-bit integer with no "dB" in it (i'm assuming its a scalefactor not in dB at all). Which the hell is it??

https://tools.ietf.org/html/rfc7845#section-5.2

Re: Opus and replay gain

Reply #38
Its a Q7.8 value in dB :)  Which is 16 bits (signed), hence an integer in the range -32768 to 32767.  The dB is assumed and not present in the encoding, only the number.  The integer can be converted back to dB by dividing by 256 (ie. shifting by 8 bits).

 
SimplePortal 1.0.0 RC1 © 2008-2019