> > Players have already screwed this up, by assigning additional meaning to > > a field which wasn't intended, since there wasn't a field corresponding > > to the exact meaning desired. > > Now you have me confused. Did they *actually* screw this up or not? > > And how would making it even more complicated help them screw it up less? > > So far as I can see still, you're trying to find a use for an "album gain" > button that your application gave you, which isn't actually of any use at > all for this format, because the problem that album gain was invented to > solve doesn't actually exist with this format like it does for some others. > > You have two very simple knobs. Default gain, and normalised gain. > The latter being entirely optional for both users and players, and both > of which can be changed by the user losslessly if desired. > > If you say you want multiple levels of normalised, then where does this > stop? Should we also provide equalisation profiles for every room that > you listen in and every piece of audio equipment you use to play it? > > Aside from "making things an overcomplicated mess like ReplayGain", what > real problem cannot be solved with the degrees of freedom that the current > spec already gives you?
Let me state my goals simply:
1. I want my Ogg Opus albums to play back at the same loudness as
my existing albums in other formats (Vorbis, Flac, Mp3, etc.)
that are using ReplayGain.
2. I would like to be able to at playback time select track-based
normalization instead of my normal preferred loudness.
3. Ideally, I want to be able to give one of my files to a friend
who doesn't normally use ReplayGain, without them complaining
that "This is too quiet!"
#1 is pretty simple to do with header gain: I just store my album
ReplayGain values in the header gain field. Most of my players get this
right, but foobar2000 gets this wrong, and adds +5 dB to the value when
playing it because it assumes that the field contains R128 normalized
levels and it is compensating.
We probably still have time to get them to fix this before the rest of
the world decides to follow "what foobar2000 does" for compatibility :)
#2 is OK in theory using the R128_TRACK_GAIN tag, except that most of
the players I use don't know how to apply it yet. This is in general not
too bad, because they still apply the header gain, so the level is
close... but not correct.
#3 I can't do if the header gain field contains anything other than 0,
really. So I end up having an extra step of stripping out my personal
gain modification settings before giving away a file.
Or, alternatively, I can set the header gain field to any value (0 works
ok if I also remove the R128_TRACK_GAIN tag, since that tricks
foobar2000 into thinking that R128 gain isn't present), add ReplayGain
tags relative to the header gain value, and *everything works on all
players that I use*.
> > The reason for this is kind of a best effort fallback: You asked for
> > music to be normalized loudness. If it can't be normalized in the manner
> > you asked, a fallback would be to estimate a close level - Track gain is
> > usually within 1-2 dB of album gain on most releases.
> >
> > If this isn't done, you could (given modern pop mastering) suddenly get
> > a track that's 10 dB (add 5 dB if you're using R128 instead of
> > ReplayGain) or more louder than everything else, simply because e.g. it
> > was a single-track download and you didn't notice that your scanning
> > tool didn't add 'album' gain to it. It's to protect your ears and/or
> > speakers.
>
> If you're within 10dB of blowing your speakers, your ears are already lost.
> If you're relying on this to save either of them, then you'd better never
> change your player software, and hope nothing or nobody ever changes the
> current settings in it without you noticing.
>
> I'd certainly change my player if it applied track gain when I didn't ask
> for track gain to be applied.
Alright, I might be exaggerating a bit here, but still... a sudden 10 dB
jump in volume from one track to another while listening on headphones
can be very surprising and unwelcome. On speakers it's more "annoying
your roommates" than "blowing your speakers".
--
Calvin Walton <[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
