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: Flaw in ReplayGain spec (Read 27179 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Flaw in ReplayGain spec

Reply #25
The ReplayGain values are the 'property' of a particular track, or tracks in the case of Album settings. The notion of storing them anywhere other than as part of the track to which they belong is complete and utter nonsense.

I repeat, what is the big deal? The overhead of carrying the values within the tag structure is so small as to be inconsequential. What is all the fuss about? It must be better to carry the values within the encoded file than to attempt to replicate the values everywhere that they may be used.

john33

Flaw in ReplayGain spec

Reply #26
Also, even if there's going to be replaygain calculation support in many players (very unlikely), you probably have to do the calculations with each player separately.. and each player probably uses different format for storing the replygain data..

I can't understand what's the real reason behind this? Why on earth replaygain data can't be saved to the tag?
Juha Laaksonheimo

Flaw in ReplayGain spec

Reply #27
Couple of thoughts..

I use replaygain; I use ogg; I like them both.
Cool.

On tags in general, what if all 'special' tags were prefixed with something to mark them as 'not designed for human digestion'? That doesn't necessarily mean they're not human readable, just that it would be kind of silly to human-edit them.

Also, I like the 4 fields. I can understand your frustration, Garf, (as much as someone who is not trying to do the same thing can)  but is it truly necessary to get Xiph endorsement of replaygain in order to use it? I mean, it is preferable no doubt, but is it essential? Or would things just get less happy-friendly if you just went ahead and did it separately?

I mean, I can understand the idea of using an external database, I don't even mind it, but it is not much help for things like burning individual files to a CD if you want to burn 50 tracks, but not the database for all 5000 tracks you may have. From this perspective, I think tags on the individual files are better.
Of course, in this case, Album gain may be unimportant; but that said, if you don't want it then you can always ignore it. That dozen or so bytes is not going to fill the hard drive notably quicker (or at least, one would hope not).

Just a few thoughts on the table, sorry for any ranting; caffine levels are a tad high this morning.

gnoshi

btw. garf: In case I didn't get the message across, I really like your work on replaygain. WD+THNX.
happiness comes in brown paper bags.

Flaw in ReplayGain spec

Reply #28
Quote
Originally posted by gnoshi
On tags in general, what if all 'special' tags were prefixed with something to mark them as 'not designed for human digestion'? That doesn't necessarily mean they're not human readable, just that it would be kind of silly to human-edit them.


The tags are human-readable (though you'll have problems understaing what exactly they do if you are not familiar with RG), and it makes sense for a human to edit them.

Quote
Also, I like the 4 fields. I can understand your frustration, Garf, (as much as someone who is not trying to do the same thing can)  but is it truly necessary to get Xiph endorsement of replaygain in order to use it? I mean, it is preferable no doubt, but is it essential? Or would things just get less happy-friendly if you just went ahead and did it separately?


It would be a possibility, but it's obviously hardly ideal, especially since at least monty really wants RG support for vorbis too, so it will get added to Vorbis eventually. I want to avoid a split over this.


Quote
I mean, I can understand the idea of using an external database, I don't even mind it, but it is not much help for things like burning individual files to a CD if you want to burn 50 tracks, but not the database for all 5000 tracks you may have. From this perspective, I think tags on the individual files are better.
Of course, in this case, Album gain may be unimportant; but that said, if you don't want it then you can always ignore it. That dozen or so bytes is not going to fill the hard drive notably quicker (or at least, one would hope not).


The database problem does not work, and that is my problem with it. Way too much added complexity to the player side. Imagine what it would be on a _portable_, for example.

--
GCP

Flaw in ReplayGain spec

Reply #29
Quote
Originally posted by Garf
So, if anyone has an interest in keeping using the current Vorbis ReplayGain, the current suggested format looks like:

REPLAYGAIN_ALBUM_GAIN=-6.43 dB 
REPLAYGAIN_TRACK_GAIN=+1.20 dB 
REPLAYGAIN_ALBUM_PEAK=1.12443 
REPLAYGAIN_TRACK_PEAK=1.04343 


OK, I've mostly changed VorbisGain now, including a way to convert the old format to the new (haven't tested it yet though, so it isn't ready for release). But there's one thing I've been thinking about (and that has been mentioned in this discussion): Change the "gain" to "level" or something. I.e., don't store the relative gain, but the absolute volume level.

The reason is that you may want different "target levels" in different situations (e.g., use the "standard" 83 dB when playing on your home computer with a 24-bit soundcard, but 89 dB when using a portable player). And it wasn't without a reason that Snelg decided for 89 dB as the default for MP3Gain...

Besides, the peaks describe a property of the file. Level would do the same.  (And do you really need the "REPLAYGAIN_" prefix then? )

Anyway, after thinking a bit about it, it seems like the right thing to do. The --target-level option doesn't really belong in VorbisGain IMHO; the player is a better place (the fact that the Vorbis Winamp plugin already has a pre-amp option speaks in favour of that, I'd say).

Comments please.

Flaw in ReplayGain spec

Reply #30
Is almost the same discussion happening in two threads here?


Lear,

First, please read www.replaygain.org especially the bit about reference level.

You see, the "level" as you want to define it is not intrinsically the level of the track. Why not? Because you'll get a (completely) different value depending on how you measure it! So, to be meaningful, you have to say "the level, measured <this way> is x dB". But even this isn't a great idea!

The Replay Gain Proposal suggests a way of measuring the level, AND defines a reference level. Already Frank Klemm has improved the way of measuring the tracks "level". However, because there's a reference level for him to tie this to, he can do this without breaking compatibility. BUT if you only say "this is the level of this track when calculated by this method" then using any other (better?) method would break the whole system.

So, you can't say "the track is x dB loud", because you haven't said how you measured it, or what you're measuring it relative to.

You can say "the track needs to be x dB louder to match an agreed reference", because the measurement method doesn't matter when you're talking about relative (rather than absolute) levels (so long as it works quite well!), and you have a defined reference.


In short: you have to specify a reference level or a method of calculation. That's why you need to say "this is a replay gain tag".

It's not just my ego ;-)

Cheers,
David.

Flaw in ReplayGain spec

Reply #31
Quote
Originally posted by 2Bdecided
Is almost the same discussion happening in two threads here?


Yep, Garf started this, then Dibrom started that vote thing...

Quote
You see, the "level" as you want to define it is not intrinsically the level of the track. Why not? Because you'll get a (completely) different value depending on how you measure it! So, to be meaningful, you have to say "the level, measured <this way> is x dB". But even this isn't a great idea!

The Replay Gain Proposal suggests a way of measuring the level, AND defines a reference level. Already Frank Klemm has improved the way of measuring the tracks "level". However, because there's a reference level for him to tie this to, he can do this without breaking compatibility. BUT if you only say "this is the level of this track when calculated by this method" then using any other (better?) method would break the whole system.


Why? What's the difference in storing e.g., +6.5 or 76.5? In the first case you increase the volume by 6.5 dB, in the second you increase the volume by 83 - 76.5 = 6.5 dB (assuming 83 was set as the "reference level" in the player)...

That's what I'm suggesting: the calculation of e.g. 83 - 76.5 should be done in the player. That's all.

As you say on www.replaygain.org: "So, we send the pink noise signal through the ReplayGain program, and store the result (let's call it ref_Vrms)." Which means the reference level isn't an absolute. It depends on the method used to measure the reference signal (the only absolute). So, regardless of method used to calculate the level, it would have to be calibrated against the pink noise signal. I'm not suggesting to change that. My suggestion is simply that the output (when using the reference signal) should be 83 (as an absolute value) rather than 0 (as a relative value).

Quote
So, you can't say "the track is x dB loud", because you haven't said how you measured it, or what you're measuring it relative to.


OK, so the "REPLAYGAIN_" prefix is useful. But then that wasn't the important part of my suggestion anyway... It was just an idea to make the tag names a little shorter.

Flaw in ReplayGain spec

Reply #32
All other things being equal, assuming a complete understanding of replaygain in the player, both are equivalent.

So we can store either. ..


"relative": the player does this:

a) read in replay gain value
b) apply replay gain value


"absolute": the player does this:

a) read in replay gain value
b) subtract 83 from this value
c) apply the resulting value



I originally thought about storing the "absolute" value (rather than the "relative" adjustment) but several people pointed out that storing the adjustment is easier - and I agreed. So that's the way it is. You've got to pick one of the other, so I picked the option that made player implementation easier.


Quote
My suggestion is simply that the output (when using the reference signal) should be 83 (as an absolute value) rather than 0 (as a relative value). 


But they're both relative, aren't they? Decibels (dB) are, by definition, a relative measurement. The 83 isn't just "83", like you could say the length of a piece of string is "83cm" and that's that. It's equivalent to the perceived loudness of a -20dB FS (relative to a full scale sinewave) RMS pink noise signal replayed via an SMPTE RP 200 calibrated audio system.


My way, you don't put an 83 in the replay gain calculation, and you don't put an 83 in the player calculation either. Your way, you could well add it at one end, and then subtract it at the other! why?!


and finally...

Quote
Besides, the peaks describe a property of the file. Level would do the same. 


If you store what you suggest (e.g. 80dB instead of -3dB, for example) then you're NOT storing a property of the file. You're storing the gain required to make the file average 83dB perceived loudness in a calibrated system. Rather than storing a property, you're still storing an adjustement. A loud file will have a lower value, whether you add 83 to it or not! So, you'd have to take the "-3dB", switch the sine (+3dB), add it to 83dB, and store this (86dB) as the perceived loudness of the file. Then, to play it back, you take this value (86dB), and subtract it from the required level (e.g. 83dB-86dB=-3dB), and then apply this gain change to the file. BUT LOOK! We're just where we started - with the number -3dB! so why bother?!


To make the stored value a property of the file (i.e. truly absolute, not relative) you have to remove the calibration step (stage 4, if you refer to the explanation on the website). It's the calibration step that causes different calculations (e.g. mine and Franks) to fall on the same scale - take this away, and you've got a big disadvantage: no prospect of improving the calculation.


I hope this clarifies the situation. Yes, you could equally well store the value with 83 added to it or not, just so long as everyone understood which you were doing. But since NOT adding it means you then DON'T have to subtract it again, that makes most sense. It's also what has been happening for a year, so there seems no reason to change now. Also, it's still a relative value: an instruction to turn up or turn down the file to match a reference level. If you remove this reference level, then you can state something explicitly about the file, but you loose the calibration, so making it harder to change the calculation while retaining a compatible scale.

In short: adding 83 makes little difference (but is no use, and a small amount of trouble); changing to a true representation of "what's in the file" will cause many problems for little gain (pardon the pun).


Cheers,
David.
http://www.David.Robinson.org/

 

Flaw in ReplayGain spec

Reply #33
I'll try to keep this short, since we seem to agree on most things now.

Quote
Originally posted by 2Bdecided
All other things being equal, assuming a complete understanding of replaygain in the player, both are equivalent.


Then we agree on that part at least. Now's the question: why doing it the "absolute" way?

Quote
Originally posted by 2Bdecided
"absolute": the player does this:

a) read in replay gain value
b) subtract 83 from this value
c) apply the resulting value


b) should rather read something like this: "subtract a user-configurable value, which defaults to 83, from this value". If that value isn't configurable, then there's indeed not much use in doing it like this.

Quote
Originally posted by 2Bdecided
In short: adding 83 makes little difference (but is no use, and a small amount of trouble); changing to a true representation of "what's in the file" will cause many problems for little gain (pardon the pun).


But there's another problem now. MP3Gain defaults to a "target level" of 89 dB, not 83. To be "compatible" with this, VorbisGain does the same, but also allows that to be changed (--target-level option). Then you can have different files where the gain is based on different target levels, and you can't tell what the level is just by looking at the tags. To avoid that, store the "absolute" level rather than the change needed to get to a certain target level. I.e., move the "--target-level" option from VorbisGain to the player (which is a better place, IMO).

Flaw in ReplayGain spec

Reply #34
Quote
Originally posted by Lear

OK, I've mostly changed VorbisGain now, including a way to convert the old format to the new (haven't tested it yet though, so it isn't ready for release).


A little note: Vakor (Michael Smith), the vorbis-tools maintainer, has started work on adapting the tool to fit into the vorbis-tools set. He had some issues with the portability of the tool and found some bugs as well. You might want to give him a ring and sync up your improvements. (Dunno the email by hearth but should be easy to find)

Quote
Besides, the peaks describe a property of the file. Level would do the same.  (And do you really need the "REPLAYGAIN_" prefix then? )


I changed RG into REPLAYGAIN to (almost literally) make it possible for someone who has never heard of it to enter the term in google and get to the right place. You need to at least have heard of ReplayGain to make sense of most of the tags, so it must be clear what the tags belong to. The length (if reasonable) is less of an issue than making clear what the tags are about.

My preference for storing a relative gain instead of an "absolute" level follows similar reasoning. It's more clear from looking at the kind of tag what it is about.

REPLAYGAIN_ALBUM_GAIN=-6.00dB

vs

REPLAYGAIN_ALBUM_LEVEL=83.00dB

IMHO, it's more clear from the first tag that somehow the volume has to be changed by -6dB.

There is no real technical reason to prefer one over another. I prefer whatever is more clearer.

I agree the level adjustment doesn't belong in the tool but in the players. But (*chimes*) it already _is_ there. That is what the preamp (or headroom) slider is for.

--
GCP

Flaw in ReplayGain spec

Reply #35
Quote
Originally posted by Lear
But there's another problem now. MP3Gain defaults to a "target level" of 89 dB, not 83. To be "compatible" with this, VorbisGain does the same, but also allows that to be changed (--target-level option). Then you can have different files where the gain is based on different target levels, and you can't tell what the level is just by looking at the tags. To avoid that, store the "absolute" level rather than the change needed to get to a certain target level. I.e., move the "--target-level" option from VorbisGain to the player (which is a better place, IMO).


I'd choose the "absolute" method, zero is a more natural origin for me so there's no need to all agree on an 83 origin. Also, storing a +/- could confuse a few: Does -6 mean I need to decrease the volume of this file by 6 to get to the 83, or does it mean this file is 6dB quieter then the 83 standard. At least by storing 89 I'd know 'how loud it is' right away.

Flaw in ReplayGain spec

Reply #36
Quote
Originally posted by Garf

A little note: Vakor (Michael Smith), the vorbis-tools maintainer, has started work on adapting the tool to fit into the vorbis-tools set. He had some issues with the portability of the tool and found some bugs as well. You might want to give him a ring and sync up your improvements. (Dunno the email by hearth but should be easy to find)


Michael Smith? I thought Stan Seibert was going to do it; after all, he's the one I've been in contact with regarding VorbisGain... Oh well, I've e-mailed both now.

Quote
There is no real technical reason to prefer one over another. I prefer whatever is more clearer.


True, but it isn't very clear what the result of the change is...

Quote
I agree the level adjustment doesn't belong in the tool but in the players. But (*chimes*) it already _is_ there. That is what the preamp (or headroom) slider is for.


Yep. So if *_GAIN is to remain (and not be changed to *_LEVEL), I'll remove --target-level and mention in the manual that pre-amp can be used to change the "result level". Considering the amount of support here of my suggestion (i.e., none at all ), I guess that's what I'll do. I'll stick with 89 as a "target level" though.

Flaw in ReplayGain spec

Reply #37
Quote
Originally posted by Lear
Considering the amount of support here of my suggestion (i.e., none at all ), I guess that's what I'll do. I'll stick with 89 as a "target level" though.


I support ya! I'm ok with the arguments on the other side, but for Joe public this track is 89dB loud is probably more easily understood then this file needs to be adjusted by this much.

I used MP3Gain and I like the feel of the "absolute" value. I'm just a user tho.

Flaw in ReplayGain spec

Reply #38
sam,

that's just the point. the track isn't 89dB loud. If you store REPLAYGAIN_TRACK_LEVEL = 89dB as Lear suggests, what you actually mean is "this track needs to be played at 89dB to make it 83dB loud."*

Whereas REPLAYGAIN_TRACK_GAIN = +6dB means "increase this track by 6dB (to match the reference level)"

In either case, if you want it louder or quiter still, you'll just adjust the pre-amp and that value will be added to it.

David.

P.S. If you really wanted to store something that represents the "level", you have to store something else (see previous post) And that something else makes it even more complicated than * above!

Flaw in ReplayGain spec

Reply #39
Quote
Originally posted by 2Bdecided
It's the calibration step that causes different calculations (e.g. mine and Franks) to fall on the same scale - take this away, and you've got a big disadvantage: no prospect of improving the calculation.


BTW, does Frank's calculation method supersede the original one?

I'm going to update my Winamp plugin this week, so should I use Frank's one, the orignal, or give an option to choose between both?

Matthijs

Flaw in ReplayGain spec

Reply #40
Quote
Originally posted by matthijsln
I'm going to update my Winamp plugin this week, so should I use Frank's one, the orignal, or give an option to choose between both?

Only Frank's plugin have replaygain support.

Flaw in ReplayGain spec

Reply #41
Case,

I think you missunderstood his question. or else I did.


Matt,

Frank emailed me about one of his improvements, and then said it didn't work and rejected/changed it. He's made at least one more improvement which he has kept. But the only way to see the changes are to look at his source code in the latest mppdec bundle. (I can't program so it means nothing to me!). I think I'd use his latest version, if I were you - but check with him first!

Cheers,
David.

Flaw in ReplayGain spec

Reply #42
Quote
Originally posted by 2Bdecided
I think you missunderstood his question.

Very possible. But Winamp plugin doesn't know about method used for replaygain calculation so it has no effect here. If one wishes to use official replaygain spec instead of Frank's enhanced version one has to undefine KLEMM in sources and compile ReplayGain.exe again.

Flaw in ReplayGain spec

Reply #43
Quote
Originally posted by 2Bdecided
that's just the point. the track isn't 89dB loud. If you store REPLAYGAIN_TRACK_LEVEL = 89dB as Lear suggests, what you actually mean is "this track needs to be played at 89dB to make it 83dB loud."*

Whereas REPLAYGAIN_TRACK_GAIN = +6dB means "increase this track by 6dB (to match the reference level)"


The way I was thinking is due to my experiance with MP3Gain. When it says Radio Gain is 99 it sounds loud, and when it says Radio Gain is 80 it sounds quiet. Are we measuring from the other end of the scale here - Like my 89 (which I take as loud) is really -89dB, and add on the 83 to gve the -6, the final adjustment to make it play at 83.

My main point tho was that for me, the average user, a "TRACK_LOUDNESS=x" where 0<=x<=~100 is a lot simpler. I take two tracks, one with x=90 and another with x=80, I can see right away that the first is 'louder'. May be an abstract scale is better?

Flaw in ReplayGain spec

Reply #44
OT: That's really bizarre - we both live in Essex, and your girlfriend and my wife both do cross stitch! Anyway...


Yes, I see it makes sense from a user's point of view to see a louder file having a bigger number. But hopefully the user will never have to look at the value - the whole process should just happen "in the background".

And yet, ignoring Lear's actual proposal (which is back to front, but in fairness I don't think he realised this when he suggested it), both methods are conceptually sound. You either:

(1) store "this file will sound x dB loud in a calibrated system", and the player says "hey - I want it y dB loud, so I'll scale it y-x dB".

or

(2) store "this file should be x dB louder", and the player says "hey - I want it y dB louder still, so I'll scale it y+x dB".

Of course, in the second, "y" is optional, though recommended to be +6dB.


Is anyone who is coding this proposing that it should be changed? I've heard Lear - what about Frank and Garf?


My worry against changing it is (a) confusion, and (b) in some file formats, the values are stored as binary data (not ASCII comment tags!), and it's more compact to store values between +/- 30, rather than values between 60 and 110 (approx). Unless, of course, you subtract a pre-set number from those second set of values before storing them - but then you're back to where we are now!

I do not think it's an option to (for example) store (1) "level" in Vorbis and (2) "gain" in mpc. That would just be asking for trouble and confusion. So unless BOTH the mpc and vorbis implementations agree to change, they should BOTH DEFINITELY stay as they are!

Another reason against (1) is that almost no one will have a calibrated system - to them 83 dB or 89 dB is just a (meaningless) number. Whereas "6dB louder than suggested" is still just a number, at least it gives you some idea of what you're doing. To know what 89dB means, you have to know it's 6dB louder than what's suggested. but still OK. In contrast, 100dB (which sounds nice and loud) just won't work (user thinks: "why not - my system can output that power"), whereas "+18dB above what's recomended" does sound like you're going to overload it!


btw, the SMPTE RP 200 spec was changed from 85 to 83. I doubt they'll change it again (and actually the two specs are equivalent) - but if it were changed, (1) would be wrong, whereas (2) would be right.

work to do...

Cheers,
David.

Flaw in ReplayGain spec

Reply #45
Quote
Originally posted by 2Bdecided
OT: That's really bizarre - we both live in Essex, and your girlfriend and my wife both do cross stitch! Anyway...


Oh dear, I've been rumbled! ...more bizarre, I'm Imperial College doing a Mathematics PhD in Dynamical Systems (not that you'd tell from my posts...) and from what I can figure you're at Essex Uni.

Quote
Yes, I see it makes sense from a user's point of view to see a louder file having a bigger number. But hopefully the user will never have to look at the value - the whole process should just happen "in the background".


Yeah that's my only real point. Either way the two methods are the 'same' in the end.

Quote

it's more compact to store values between +/- 30, rather than values between 60 and 110 (approx). 


Fair point.

Quote

I do not think it's an option to (for example) store (1) "level" in Vorbis and (2) "gain" in mpc. That would just be asking for trouble and confusion. So unless BOTH the mpc and vorbis implementations agree to change, they should BOTH DEFINITELY stay as they are!


Yeah, 100% with you on this. Although the +/- means everyone would have to stick to 83 I guess.

Quote

Another reason against (1) is that almost no one will have a calibrated system - to them 83 dB or 89 dB is just a (meaningless) number. Whereas "6dB louder than suggested" is still just a number, at least it gives you some idea of what you're doing. To know what 89dB means, you have to know it's 6dB louder than what's suggested. but still OK. In contrast, 100dB (which sounds nice and loud) just won't work (user thinks: "why not - my system can output that power"), whereas "+18dB above what's recomended" does sound like you're going to overload it!


Now that you have raised that ~100dB, which sort of looks like a good value to pick for someone who doesn't realise quite what is goin on, I think my idea should be dropped totally on this point alone!

Anyway, I hope I've added something to the Gain argument by bringing up a few points.

Flaw in ReplayGain spec

Reply #46
Quote
Originally posted by 2Bdecided
sam,

that's just the point. the track isn't 89dB loud. If you store REPLAYGAIN_TRACK_LEVEL = 89dB as Lear suggests, what you actually mean is "this track needs to be played at 89dB to make it 83dB loud."*


No, I mean it like this: "this track is 89 dB loud when measured by a method that says the reference pink noise is 83 dB loud". I.e., 6 dB louder than the reference (and the gain value would then be -6 dB with a 83 dB reference).

Quote
Whereas REPLAYGAIN_TRACK_GAIN = +6dB means "increase this track by 6dB (to match the reference level)"


But from this information you can't tell for sure what the reference level is. Which only is a problem if the target level can be specified in the program calculating the difference.  (Which is the case at the moment.)

Quote
In either case, if you want it louder or quiter still, you'll just adjust the pre-amp and that value will be added to it.


Really, my suggestion was simply that I thought it would be clearer - for the user - to specify a value like "89" rather than "+6". I.e., the reference level would be explicit rather than implicit.

Flaw in ReplayGain spec

Reply #47
Quote
Originally posted by Lear
Really, my suggestion was simply that I thought it would be clearer - for the user - to specify a value like "89" rather than "+6". I.e., the reference level would be explicit rather than implicit.

Actually I don't see this would work with your proposal. If someone raised the number behind LEVEL tag he would only get quieter file when played back. That's because player thinks the file is louder and needs to be attenuated to sound like reference 83dB signal. If someone wishes to change target level it should be done in the player.

Flaw in ReplayGain spec

Reply #48
I appologise if I've sounded harsh to anyone in this discussion. I didn't have all the answers at the start. It's nearly a year since I thought all this through, and I've had to keep going back to replaygain.org to check what I originally came up with! So I've been re-learing as this thread has grown.

Apart from the few sensible (and many trivial) reasons I've thought of to stay with what I originally proposed, I think the confusion we've managed to generate is reason enough to leave it as it is! :-)

Cheers,
David.

Flaw in ReplayGain spec

Reply #49
And Case saw a quite good reason to keep it the way it is (and that's what I've based my latest changes to VorbisGain on).