The most recent discussion of this is from 2012 so I thought I'd start a new thread. You can read the old one if you need more background:
http://www.hydrogenaudio.org/forums/index....showtopic=97357 (http://www.hydrogenaudio.org/forums/index.php?showtopic=97357)
I have implemented an Opus plugin, including support for writing metadata (wish the libraries supported that!), and reading it obviously. I am still at a loss for exactly how best to deal with gain adjustments. Although the spec doesn't like the commonly used REPLAYGAIN* comment tags, they seem very likely to occur in Opus files because of the incomplete support for track and album gain and peak values, plus the lack of any tools to supply the gains from the spec. So if I find REPLAYGAIN* comment tags then I use them.
This leaves some issues. If there are Opus-spec gains also then these should probably take precedence. In fact the header gain is applied automatically unless I explicitly override it. However, I suspect in a music player this isn't going to please some people, at least until album gain (and perhaps peak levels) are widely and consistently implemented in Opus tracks. Am I going to need configuration options so people can pick what sort of tags they want to use for their gain adjustment?
I think if this is as good as it gets...
http://wiki.xiph.org/OggOpus#Comment_Header (http://wiki.xiph.org/OggOpus#Comment_Header)
...then it's a mess. I already commented here...
http://www.hydrogenaudio.org/forums/index....st&p=856065 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=101830&view=findpost&p=856065)
There are two flawed ideas:
1. Album gain should be stored in an almost-always-applied gain field that's not called album gain, and therefore sometimes isn't album gain, but is the default way of hard coding a single gain change for that file.
2. You don't need to know the peak amplitude.
I don't know enough about Opus to be sure, but my hunch is to do the following to clear the situation up:
1. Leave output gain alone and separate from ReplayGain. Use it like the frame-level Global Gain field in mp3. Therefore:
2. Always apply the Output Gain
3. Any other gain correction tags (including ReplayGain), should be calculated after the Output Gain is applied, and applied after (or with) the Output Gain.
Follow those rule, and you've simplified things dramatically.
Then it's easy:
R128_TRACK_GAIN = REPLAYGAIN_TRACK_GAIN - 5
i.e. you have those two tags effectively carrying the same data (but in different formats). Write them both. Read either one. If there are ReplayGain tags, I think they should be used in preference to R128_TRACK_GAIN (but then I would say that ) because they carry the full set of information you need. Only fall back to R128_TRACK_GAIN if you have to.
The other three ReplayGain tags carry unique data (in the normal way) - album gain, track+album peak.
The peak values should be the peak after the Output Gain is applied. I know different decoders give a different result. It's still better than having no information at all.
Don't store -23LUFs gains in ReplayGain tags. Do it the way fb2k does it: use the EBU R128 calculation, but use a -18LUFs target, which matches the level used in ReplayGain tags for the last ten years. If people want -23LUFs on playback from ReplayGain, set the RG pre-amp to -5. Job done.
This doesn't break the Opus spec. If someone chooses to put the album gain into Output Gain, it'll just look to all other tools as if the audio is already EBU R128 normalised by album (just like mp3s that have had album gain applied in mp3gain). Running a ReplayGain scanner won't break this.
Cheers,
David.
Have you asked in #opus ?
I still don't understand why the replaygain-field stores the difference to a reference volume. Wouldn't it be a lot easier if just the volume of a track and the volume of the whole album would be stored? Like this it's somehow a mess...
IMHO it should be the player to decide then which reference volume is used.
I still don't understand why the replaygain-field stores the difference to a reference volume. Wouldn't it be a lot easier if just the volume of a track and the volume of the whole album would be stored?
because Human loudness perception depends on absolute loudness and frequency. The Human "Equal Loudness" contours aren't straight or equally spaced at most frequencies. Crank the volume control up by 20dB, and the perceived loudness change might be 25dB for one track, 15dB for another track (though those are extreme examples).
ReplayGain was designed so that the original algorithm could be replaced to get better loudness matching, while keeping the tags and players the same.
If someone invented an artificial loudness measurement that matched human ears perfectly, what it
could tell you is how much to change the gain on a given track to hit a given loudness. It
couldn't perfectly tell you how loud something was unless you told it how loud you were listening, and that's less useful, because as soon as you apply a gain change to hit some wanted level, you're not listening at the loudness level the calculation used.
Let me put it another way. You're assuming that if you want to listen at 83dB, and a tag tells you that the track is 63dB loud (using some measurement), you need a 20dB boost. That's a pretty good estimate generally, but it could be several dB off - tens of dB wrong if the track was really bass heavy. A player can't know what it should really do. Whereas if the tag tells you that, to listen at 83dB, you need to boost it by 15dB, the player knows exactly what to do.
Neither the original ReplayGain, nor EBU R128, take account of the varying equal loudness contours at different loudness level properly, so for both these algorithms you'd always get the same result whether you stored "it's x dB loud" or "it needs to be made y dB louder". But if someone did write an algorithm that took account of the varying equal loudness contours at different loudness levels, only the second approach would work - which is why ReplayGain tags work that way.
Cheers,
David.
Back to the original question
I have been to #opus, but on a different matter. Fastest ever bug fix I've seen!
I haven't discussed replay gain with Xiph, although plenty of others have. Their position is clear, but not especially well suited to the situation with music players. 2Bdecided has summarised the main issues, but I'll describe some specific situations I'm trying to address.
1. Opus header gain may or may not be album gain on a specific track. If it is being used for that purpose and my player is configured to ignore replay gain then I should not apply the header gain. Even though the Opus spec says it should always be applied, it is clearly up to the listener whether they want album gain (or track gain) to be used at any particular time. However, if it is not an album gain then I should apply it in accordance with the spec. So I've already broken 2Bdecided's rule #2 (and implicitly rule #1).
2. If there are separate REPLAYGAIN* tags then I feel they should be used. If the listener doesn't want to use them then they shouldn't have put them in there. However it isn't at all clear that they will have been calculated wrt to levels adjusted by any existing header gain. Maybe they are, maybe they aren't. The spec clearly has nothing to say except don't do it because it will be confusing. So I don't feel that I can rely on rule #3.
I'm not actually calculating replay gain, so I don't have to decide which tags to create. I just copy over whatever I'm given. I can assume the three rules as a default position, but I hope I've explained reasons why I want to allow options for different behaviour. The ability to not apply even the header gain in some situations I feel is essential, whatever the spec might say (if Xiph wanted a header gain that could always be unambiguously used then they should have supplied a separate album gain that could be ignored). I also think that the ability to treat REPLAYGAIN* gains without the header gain is also important, because of the lack of any standardised behaviour (or any behaviour at all!) at this point and just because the results of getting it wrong could be so bad.
I haven't discussed replay gain with Xiph, although plenty of others have.
Are there any links, or were these just on-line chats?
Their position is clear, but not especially well suited to the situation with music players.
There was some confusion surrounding Ogg Vorbis vs ReplayGain in the early days. It was solved by Garf creating a ReplayGain tool that worked, and everyone else followed the tag format it used. Hence it was Garf, rather than Xiph, that created the ReplayGain Vorbis comment tags that are used to this day.
Cheers,
David.
This should give you the gist of it. I'm sure you'll be familiar with the arguments from both sides.
https://www.ietf.org/mail-archive/web/codec...eads.html#02935 (https://www.ietf.org/mail-archive/web/codec/current/threads.html#02935)
At the moment I'm looking at my plugin offering two checkboxes:
1. Treat Opus header gain as album gain (default no?) - yes would mean only apply the header gain if the player is configured to use album gain (and no REPLAYGAIN* tags or configured not to prefer them), no would mean apply the header gain to everything, combined with other gains if necessary.
2. REPLAYGAIN* tags override Opus gains (default yes) - no would mean REPLAYGAIN* tags were ignored when Opus track gain (or non-zero header gain being treated as an album gain?) is present.
The default settings mean that Opus header gain is always applied (even if the player is set not to use replay gain), Opus track gain is applied when track gain is configured in the player and there are no REPLAYGAIN* tags, and the appropriate REPLAYGAIN* tag level is combined with the header gain if present. Other settings allow switching off the header gain and using Opus gain tags even if REPLAYGAIN* tags are present,
I'm still wondering what to do about the level difference between the two types of tag. It is hardly meeting the goal of replay gain if one track/album plays 5-6dB louder than the next because they were tagged under different standards. The alternative is to nudge one of them, and it would have to be the Opus gains that were changed, which leaves me breaking things for people who actually want to play something according to the spec.
I'm still concerned about the different reference levels for the two tagging systems. Of course the problem has been around ever since replaygain moved from 83dB to 89dB, but it was rare for people to have tags from both systems in their files at the same time. With Opus it is (or will be) perhaps less rare. In testing with mixed sets of tags, the gain jump between tracks or between albums can be jarring and certainly defeats the purpose of having the tags in the first place.
I don't want to just override the meaning of the tags and adjust them all to the same target loudness, but I'd like to give the user the chance to do that if they end up with mixed tags and consequently non-levelled loudness. One way would be to let them have an override target loudness. By default, I'd just let the tags do what they say, but if the user insists then I'd adjust them from their explicit or implicit target loudness to the one specified by the user.
Does this make sense? I know it is a bit overkill but these are settings that the vast majority if users won't need and won't ever have to look at.
This should give you the gist of it. I'm sure you'll be familiar with the arguments from both sides.
https://www.ietf.org/mail-archive/web/codec...eads.html#02935 (https://www.ietf.org/mail-archive/web/codec/current/threads.html#02935)
Sorry, you're right, I have seen this before, but forgotten it.
As for the rest, I was trying to see what other software deals with Opus and RG to see if any useful precedent has been set.
fb2k is supporting it, and bumps the R128_TRACK_GAIN up by 5dB before use, to make it match everything else. Not much point having volume-matched files playing 5dB quieter than everything else in a multi-format player just because they happen to be in a different format.
I think you have to make them match, and then give the user the choice to offset the result, which they can do with a pre-amp if they want. Or give them a Reference level switch: ReplayGain 89dB or EBU R128 -23LUFs ("5dB quieter").
I asked Peter (fb2k) what he was doing with/for peak information, but he hasn't replied yet.
Cheers,
David.
I spotted another problem today. It'll be vanishingly rare, but worth mentioning.
If the Output Gain is used to store the ReplayGain Album Gain (calculated to EBU R128 at -23LUFs), and you have a very dynamic album (i.e. one that peaks near digital full scale, but has a measured loudness lower than -23LUFs, hence a positive Output Gain), then you are telling every Opus player to clip it by default.
Seems wrong, but that's the way it is.
Cheers,
David.
I spotted another problem today. It'll be vanishingly rare, but worth mentioning.
If the Output Gain is used to store the ReplayGain Album Gain (calculated to EBU R128 at -23LUFs), and you have a very dynamic album (i.e. one that peaks near digital full scale, but has a measured loudness lower than -23LUFs, hence a positive Output Gain), then you are telling every Opus player to clip it by default.
Seems wrong, but that's the way it is.
Cheers,
David.
Inevitable with that standard, isn't it? Hence good players offer the choice of peak scaling or not with replay gain.
Yes - but also good formats
1. don't confuse the ReplayGain info with something else
2. include peak information in the ReplayGain tags, and
3. good implementations give users the option to use or not use ReplayGain during playback.
Try to set (never mind use!) a ReplayGain album tag in accordance with the Opus specification, and all three of these things goes wrong (by default).
Cheers,
David.
The design rationale of the Opus design was clearly to make at least album gain just work even if the player developer had never heard of ReplayGain. This completely dwarfs your (1), (2) and (3) which are all based on the assumptions (s)he knows exactly how it's supposed to work, and even has the UI available to let the user make sane choices based on it. In the case of hardware players, that's obviously not true - how many do you know with full ReplayGain configuration?
Conversely, in the current specification, it will just work. If your player knows about ReplayGain, you get track gain too.
The point of clipping is true, but that's a problem even IF you know the peak information. If you know that playing at the right loudness will cause clipping, there's no right way to play back the music. FWIW the current Opus libraries contain helper functions to do soft clipping, because clipping is an issue in DAP even if ReplayGain isn't in the picture at all.
I understand what you want. You want a perfect world. We can get some of that if we for example use Vorbis in foobar2000 or selected DAP, but go outside that much and it's a wasteland, and your Vorbis files turn into a pain to use. Opus' version of ReplayGain was designed so it would work everywhere, at the cost of dropping a feature whose benefit is very questionable (peak info).
Although the spec doesn't like the commonly used REPLAYGAIN* comment tags, they seem very likely to occur in Opus files because of the incomplete support for track and album gain and peak values
The spec is very clear here:
To avoid confusion with multiple normalization schemes, an OpusTags packet SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK fields.
This isn't "doesn't like", this is saying it's not a legal at all. If you encounter a file with such tags, that file is corrupted and should be treated as such. How can you treat something "correctly" when it's mere presence is a bug? I recommend not playing them at all so users who are unfortunate enough to use a tool that corrupts their files would notice instantly and can get rid of it.
If you really want to support everything, make it a configurable option whether to apply those gains in addition to or in replacement of correct gain tags. Reminds me a bit of Winamp & foobar2000 having a "broken channel mapping" option when some less-than-attentive developers make Vorbis encodes with the Windows WAV channel mapping instead of the one actually specified in the Vorbis standard.
If you like your clipping you can keep your clipping.
If you like your clipping you can keep your clipping.
Thank you for your enormously constructive argument, which makes it instantly clear what exactly your problem is and allows us to formulate a solution to address it.
I already logged out after my comment when a thought struck me. There is no humor here. I need to go back asap. Ofcourse I find that lo and behold there really isn't.
A solution? Use a volume control. I would.
The design rationale of the Opus design was clearly to make at least album gain just work even if the player developer had never heard of ReplayGain.
Opus is an audio codec.
If you want to see an audio codec built from the ground up to handle loudness normalisation properly, look at AC-3 / Dolby Digital. That works properly when AC-3 is the only audio format in use. This is the de facto position on DVDs, because commercial use of the other two allowed audio formats is almost non-existent.
Once you have other audio formats, it gets quite complicated, and decoders have to follow strict rules to avoid loudness chaos. e.g. see Dolby technical bulletin 11.
Even with these more complicated decoder rules, the content producers have to follow even more complicated rules to make everything work properly. They have to care about dynamic range with and without downmixing. They have to care about clipping prevention at different output levels. They have to care that these parameters are different depending on the audio format in use.
Even broadcasts with multi-billion dollar budgets look at this problem as say "it's too hard - just pass feature film soundtracks through as-is, and produce everything else to EBU R128 -23 LUFs with automated peak compression on downmixes".
Back to Opus, which allegedly is designed from the ground up to support loudness normalisation even if the player developer hasn't heard of it, and clearly exists in a world with other audio formats. It's also going to be encoded by normal people. You cannot expect broadcaster-competent levels of dynamic range management in the source.
In Opus the output gain may, or may not be, the Album Gain.
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. 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)?
If the output gain
is the Album Gain, but the player developer does understand the significance of this, they can try and improve the experience. This is hampered somewhat by the problem that a) they don't know if the output gain really is the Album Gain (think what happens when it isn't), and b) they don't have a peak level to check when (for example) increasing the loudness above -23LUFs to match other audio.
If the output gain is
not the Album Gain, then at least the Opus files will play at the same loudness as mp3s. Though if a user has some Opus files where it is, then those are going to sound very quiet in comparison. By default.
Dolby AC-3 can force loudness normalisation on everyone, partly because the files are professionally and consistently created, partly because their codec sits as the only codec in some situations, and partly because they write very careful rules of how to work with other codecs. Opus cannot tick any of these boxes. Hence Opus cannot force loudness normalisation on everyone.
This completely dwarfs your (1), (2) and (3)
It would if it did what you say, but as I've shown above, it doesn't.
I mentioned AC-3 as an example of how you design something in isolation from the ground up to support loudness normalisation. If you don't have that luxury - e.g. you are adding something onto an existing format, or designing a format that must co-exist with other formats, then you need to do more, not less. You either do something like Dolby technical bulletin 11, or you write some tags (e.g. loudness and peak tags to a certain reference) which players can use even if the calculation method or audio format changes.
The point of clipping is true, but that's a problem even IF you know the peak information. 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.
FWIW the current Opus libraries contain helper functions to do soft clipping, because clipping is an issue in DAP even if ReplayGain isn't in the picture at all.
True, but without peak information, you are only left with the compression/soft-/hard-clipping options, and can never have the "just play it a bit quieter but without damaging the audio" option.
I understand what you want. You want a perfect world.
I like things to improve. I like thing to be easy to use and difficult to break. I'm sure the Opus developers thought they were delivering the "easy to use" part, but I don't think they have, and they seem to have compromised the other two.
We can get some of that if we for example use Vorbis in foobar2000 or selected DAP, but go outside that much and it's a wasteland, and your Vorbis files turn into a pain to use. Opus' version of ReplayGain was designed so it would work everywhere, at the cost of dropping a feature whose benefit is very questionable (peak info).
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.
Cheers,
David.
Meanwhile, there is still no opusgain tool
Meanwhile, there is still no opusgain tool
One reason why I feel I have to offer support for REPLAYGAIN* tags in Opus files. Until there is a tool to set real Opus gains, and maybe even after, people are going to slap in whatever gain tags they have whenever they transcode a file.
Well, there's foobar2000.
Well, there's foobar2000.
If I admit I don't use it, do I get banned?
Well, there's foobar2000.
If I admit I don't use it, do I get banned?
(http://i.somethingawful.com/forumsystem/emoticons/emot-commissar.gif)
Meanwhile, there is still no opusgain tool
One reason why I feel I have to offer support for REPLAYGAIN* tags in Opus files. Until there is a tool to set real Opus gains, and maybe even after, people are going to slap in whatever gain tags they have whenever they transcode a file.
But are there tools that set REPLAYGAIN tags on Opus files? vorbisgain sure doesn't AFAIK. What idiot would write such a tool? It's almost intentionally malicious to do so. Users manually adding useless tags? Would be pretty strange as well.
So why on earth would you support this?
The only tool that supports ReplayGain scanning on Opus does it correct. So why would you intentionally add support for something the spec specifically says is forbidden? At worst you're now *encouraging* people to make broken files and you've just made your own problem worse.
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.
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Proposal to change the spec and include an R128_ALBUM_GAIN tag in Opus:
http://www.ietf.org/mail-archive/web/codec...t/msg03053.html (http://www.ietf.org/mail-archive/web/codec/current/msg03053.html)
Thanks for posting that link. It's a good step in the right direction.
Cheers,
David.
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.
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
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).
I realize this is an old post, but I feel compelled to respond to this quote:
The design rationale of the Opus design was clearly to make at least album gain just work even if the player developer had never heard of ReplayGain. This completely dwarfs your (1), (2) and (3) which are all based on the assumptions (s)he knows exactly how it's supposed to work, and even has the UI available to let the user make sane choices based on it. In the case of hardware players, that's obviously not true - how many do you know with full ReplayGain configuration?
Conversely, in the current specification, it will just work. If your player knows about ReplayGain, you get track gain too.
Have you seen how Opus is decoded on Android? It doesn't "just work" at all.
https://github.com/vanilla-music/vanilla/issues/952#issuecomment-528642366
https://github.com/google/ExoPlayer/issues/7046#issuecomment-605081648
Not gain, but more header problems:
https://github.com/google/ExoPlayer/issues/8396#issuecomment-760213244
Those appear to be issues with players that do their own decoding.
Those appear to be issues with players that do their own decoding.
ExoPlayer is a library/dependency, not a player, that Google pushes developers to use rather than the decoder inside the Android OS.
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.
Must say I am totally confused about Opus and loudness metadata. What I got out if it is this:
- Opus doesn't store Replaygain (track/album) peak values because standard forbids, for whatever good reasons
- Trackgain/Albumgain values can be saved
- There is also a Opus header gain value stored. ?!
- Foobar has a dedicated screen, "Manipulate Opus header gain" - Apply = Re-Encode? Just write a header? Or apply without re-encoding (as mp3directcut did). I guess the latter.
- That screen has "Lower adjustments according to peak levels" - But opus files hold no peak level metadata?! Or rather values it calculates on-the-fly?
Rocket science for mere mortals I think.
- Opus doesn't store Replaygain (track/album) peak values because standard forbids, for whatever good reasons
Incorrect - the standard doesn't
forbid, it merely
advises against the usage of ReplayGain tags (https://datatracker.ietf.org/doc/html/rfc7845#section-5.2.1):
To avoid confusion with multiple normalization schemes, an Opus
comment header SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN,
REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or
REPLAYGAIN_ALBUM_PEAK tags, unless they are only to be used in some
context where there is guaranteed to be no such confusion.
[EBU-R128] normalization is preferred to the earlier REPLAYGAIN
schemes because of its clear definition and adoption by industry.
Peak normalizations are difficult to calculate reliably for lossy
codecs because of variation in excursion heights due to decoder
differences. In the authors' investigations, they were not applied
consistently or broadly enough to merit inclusion here.
Note, specifically, that the standard states "
SHOULD NOT", not "
MUST NOT".
- There is also a Opus header gain value stored. ?!
Yes, Foobar uses the header gain for album gain purposes instead of the
R128_ALBUM_GAIN comment tag (which is why I stopped using it). I tried explaining to the devs that this is not how the header gain value should be used, but they didn't care. 🤷
- Opus doesn't store Replaygain (track/album) peak values because standard forbids, for whatever good reasons
Note, specifically, that the standard states "SHOULD NOT", not "MUST NOT".
We have been here from the beginning of Opus. In the discussions on the forum and IRC it was clear the authors don't want peaks included. So it should be respected.
- There is also a Opus header gain value stored. ?!
Yes, Foobar uses the header gain for album gain purposes instead of the R128_ALBUM_GAIN comment tag (which is why I stopped using it). I tried explaining to the devs that this is not how the header gain value should be used, but they didn't care. 🤷
The specs you quoted tells the reason "A muxer SHOULD place the gain it wants other tools to use by default into the 'output gain' field, and not the comment tag."
But foobar2000 has supported the R128_ALBUM_GAIN after it was added to the specs. And there is configuration option to even override the spec recommendation and force use of the tag over header value.
Could you please educate what the problem is?
We have been here from the beginning of Opus. In the discussions on the forum and IRC it was clear the authors don't want peaks included. So it should be respected.
That doesn't contradict literally anything I've said. From the standard itself it is clear that the authors "don't want peaks included", whence the use of "
SHOULD NOT". But the fact of the matter is that the standard doesn't
forbid the inclusion of peak values, it only
discourages it.
I haven't said anything incorrect and you haven't disagreed with me, yet you phrased what you said in a manner that indicates disagreement. Kinda confusing.
The specs you quoted tells the reason "A muxer SHOULD place the gain it wants other tools to use by default into the 'output gain' field, and not the comment tag."
(...)
Could you please educate what the problem is?
Sure!
First of all, a specific loudness normalisation gain should not be something the muxer "wants other tools to use
by default". Whether track- or album-based or even
no (this one is important - see next paragraph) loudness normalisation should be used should be up to the decoder's/player's settings.
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:
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").
In my experience, even a command-line tool like opusdec which actually does not do any volume control can not opt to not apply the header output gain.
Ergo, the header output gain is not "used
by default", but is just used and there's nothing a user can do about it.
In other words, this
And there is configuration option to even override the spec recommendation and force use of the tag over header value.
is only correct insofar as
forcing any player to apply the album gain aligns with the spec recommendation, which is really not specified
anywhere in the spec and is purely a developer judgment call.
Ergo, the header output gain is not "used by default", but is just used and there's nothing a user can do about it.
foobar2000 for example allows users to decide whether to use this info or not. It's tied to ReplayGain control.
In other words, this
And there is configuration option to even override the spec recommendation and force use of the tag over header value.
is only correct insofar as forcing any player to apply the album gain aligns with the spec recommendation, which is really not specified anywhere in the spec and is purely a developer judgment call.
The original specs made it clear that the header gain value is meant to be used for album gain: https://wiki.xiph.org/OggOpus#Comment_Header (https://wiki.xiph.org/OggOpus#Comment_Header).
There is no comment field corresponding to Replaygain's ALBUM_GAIN; that information should instead be stored in the OpusHead 'output gain' field.
But as was mentioned, foobar2000 has had configuration for this since 2016. By default it retains the old behavior that Opus was born with and uses header gain field for album gain. But you can configure header to remain as null and then gain gets only stored in the two R128 gain tags.
I think your problem with foobar2000 is based on some huge misunderstanding. It fully follows the specs and allows user full control of the gain behavior. Both for encoding and decoding.
Ergo, the header output gain is not "used by default", but is just used and there's nothing a user can do about it.
foobar2000 for example allows users to decide whether to use this info or not. It's tied to ReplayGain control.
Well it shouldn't, because that is
literally against the spec.
Foobar2000 has volume control, and - once again - straight from the spec:
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.
The original specs
are outdated and irrelevant. The OPUS spec is here (https://datatracker.ietf.org/doc/html/rfc7845).
I think your problem with foobar2000 is based on some huge misunderstanding.
On the contrary, my problem with foobar2000 is based on proper understanding.
It fully follows the specs
It actually literally does not, as I've clearly explained at the top of this post.
Honestly, this is my problem with foobar2000. I can literally copy-paste straight from the OPUS spec the part of the spec that foobar2000 is breaking, and - somehow - a literal copy-paste from the spec gets ignored and dismissed as "some huge misunderstanding", and foobar2000 gets proclaimed to "fully follow the specs".
I mean, if you just don't want to make it work by the specs, just say that. But this thing you're doing where you pretend that your disagreement with what I said isn't also in disagreement with the actual spec itself is honestly getting ridiculous and annoying.
I haven't said anything incorrect and you haven't disagreed with me, yet you phrased what you said in a manner that indicates disagreement. Kinda confusing.
Maybe language lawyering over which RFC2119 definition "forbids" corresponds to exactly wasn't the best way to get to a constructive discussion.
First of all, a specific loudness normalisation gain should not be something the muxer "wants other tools to use by default". Whether track- or album-based or even no (this one is important - see next paragraph) loudness normalisation should be used should be up to the decoder's/player's settings.
You're assuming here the decoder or player HAS these settings or even knows what ReplayGain is. When we discussed this 8 years ago there was no such assumption that all players would have this, and I suspect that's largely been borne out in practice too. So if, as a user, you want Album ReplayGain, then that's what you want your muxer (in this case foobar2000) to write out in the gain field, because that's the very minimal one the player will apply. (The discussion a few posts above points out that even that is gotten wrong by some libraries, but of course at that point all bets are off...)
If you want Track Gain instead, your muxer needs to be configurable to write that out to the gain field instead.
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). If you have a problem with that, that's on you, but don't be surprised that the developers continue to ignore you.
Going back through the past comments and how the spec evolved, you can actually see that R128_ALBUM_GAIN didn't exist initially, and was a reason for 2BDecided's frustration with not being able to interpret the default gain value. So arguing that the default gain shouldn't be album gain and that this is somehow wrong is weird, because it would mean that'd have been a backwards incompatible change and the format would've been Opus 2.0 (no such thing happened!). I'd still maintain that a player that writes out R128_ALBUM_GAIN with non-zero values and a neutral internal gain field is just being bad, because it will break loudness equalization in non-ReplayGain capable playback devices, for *no advantage whatsoever* in players that do actually support it.
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. 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.
We can now language lawyer a bit more whether the final output volume being different from what's in that tag (due to the user selecting another ReplayGain mode or there being additional album gain tags causing an additional scaling) means that the stated gain is "being applied" or not, but the spec makes it clear (and was always clear) that all the other gains are on top of that one, so there's no real misunderstanding possible in the implementation.
Arguing that a player having *an option* to ignore parts of the spec is "breaking the spec" is simply not interesting.
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.
Well it shouldn't, because that is literally against the spec.
Foobar2000 has volume control, and - once again - straight from the spec:
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/
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.
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.
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
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 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.
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:
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.)
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.
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 :) )
[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
[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.
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:
metaflac --list --block-type=VORBIS_COMMENT ...
In particular if it has REPLAYGAIN_REFERENCE_LOUDNESS tag.
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.
Can you show all the tags, e.g. with:
metaflac --list --block-type=VORBIS_COMMENT ...
In particular if it has REPLAYGAIN_REFERENCE_LOUDNESS tag.
[/quote]
[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
You can try opusenc with --discard-comments option.
It works, however it obviously throws away all metadata and tags which is an issue.
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 (https://gitlab.xiph.org/xiph/opus-tools/-/issues/2316). You probably have an older version. I think if you remove this tag it should be fine.
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!
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?
You can use metaflac in scripts to manipulate tag information, including passing that tag information to other programs for automation purposes.