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

Flaw in ReplayGain spec

It occured to me today that there is a problem with the current ReplayGain spec, or rather, my proposal for doing it in Vorbis.

The issue is combining replaygain and clipping prevention.

If applying the replaygain would cause the track to clip, clipping prevention kicks in, and reduces the level. This will make the output loudness different from the ideal, 'equal' level.

When running in radio/track mode, there is no way around this, since you don't know in advance what you are going to encounter. The best you can do is set the default level low enough so you can hope it'll never happen. I believe this was the idea (among possibly other things) behind setting the default level to K-20 in the new MPC decoders? (Frank? )

If the implementation in the current Vorbis players is correct, a similar effect can be reached by setting the preamp in the plugin to -6dB or so.

In album gain, you could avoid this from happening for the entire album you're listening to, since you already ReplayGain-processed them in group and thus know what is coming up, however, my current proposal poses problems for doing this: You would need to read in all files that belong to the album, read in the peak values, and remember the largest, and use that as the peak value for the individual tracks.

This is what I originally envisioned, however, looking back, this is both ugly, cumbersome and it may not even be possible in some player/plugin architectures.

I think the correct solution would probably be to store an album-peak value.

It would be trivial to implement in the ReplayGain tools, and require only minimal changes in the players without all the uglyness the current method would require (which isn't done correctly by anyone anyway).

The disadvantage is that it requires another tag. However, since the Vorbis people seem to have gotten a bit more enthousiastic about ReplayGain lately, perhaps that isn't so much of a problem.

I believe it's valuable to do this, as it may post a real problem in practise. Moreover, the proposal as it is now is broken by design in this regard, and I'd prefer to fix it while it's still fixable.

Also, the ReplayGain proposal on David's site doesn't mention anything about this? Is there another way to address this problem?

There's two other issues with the current spec that I'd like to discuss about while it's still possible.

1) Change RG_* into REPLAYGAIN_*
This was proposed by Segher, with the idea that someone looking at the tags and that doesn't know what they are can at least google to find out, whereas you'd be left clueless with the current 'RG'. I think this idea is valuable and good.

2) Source/version tag
I didn't include one originally because I saw no way to keep it consistent if you allow the user to edit the tags (you can't require them to know the spec...), and because I didn't see the RG calculations being improved for quite a while. Unfortunately, Frank Klemm has already proven me wrong on the latter. I don't see a way to make such a tag actually _work_ though.

I'd like feedback from everyone about all of this. Is it worthwhile to change the current proposal and fix some of the above issues?

--
GCP

Flaw in ReplayGain spec

Reply #1
I think an album (peak) gain value would be good to have in Vorbis. It's already in Musepack, and I use it whenever I transcode MPC to MP3 for my portable player.

Of course, with Vorbis, one shouldn't have to transcode for portable listening purposes (eventually ), but as long as an album gain value is not hard to implement, it might as well be supported, right?

And I like the RG_* --> REPLAYGAIN_* change, since I remember reading from the MAC 2.90 thread that many people think the human-readability of Vorbis tags (or is that Ogg tags?) is a big deal. But since I don't have a single Vorbis file on my computer currently, it wouldn't affect my collection in any way, whereas it might be a pain for those who have already encoded and replaygained their music files with Vorbis. Is it possible to have both tags supported, or is that just a bad idea? If not, then how hard would it be to automatically convert all Vorbis files on a user's hard drive from RG_* to REPLAYGAIN_*?

EDIT: whoops, I meant album peak value, not album gain.

Flaw in ReplayGain spec

Reply #2
Quote
Originally posted by SometimesWarrior
I think an album gain value would be good to have in Vorbis.


It already is in Vorbis too. My proposal is about album peak tags. (Which MPC has, but the ReplayGain spec doesn't)

Quote
Is it possible to have both tags supported, or is that just a bad idea? If not, then how hard would it be to automatically convert all Vorbis files on a user's hard drive from RG_* to REPLAYGAIN_*?


Simple change in the ReplayGain tool to make it autoconvert all files.

--
GCP

Flaw in ReplayGain spec

Reply #3
Seems like Garf has valid points. I don't believe it's too late to fix the missing of album peak value, but Vorbis people are probably not too happy about changing names of tags. Actually, it's probably not necessary to change the RG_ to REPLAYGAIN_. I'd assume every decoder mentions replaygain somewhere, at least Winamp plugin has replaygain settings right in the first config screen so it takes quite a lot to miss the meaning.
About the version tag, I personally don't think it's necessary. If loudness is incorrect one can always re-apply replaygain to such files.

Flaw in ReplayGain spec

Reply #4
Quote
Originally posted by Garf
It already is in Vorbis too. My proposal is about album peak tags.
you might wanna know about a tag i have already defined. it stores the album maximal gain (1/peak), and it used in order to apply one-pass normalization (mainly, for LittleWing[/i]).

the tag is already supported by Peter's in_vorbis plugin, and should also be supported in the next version of OggDS.


technical details :
all ogg's created by BeSweet/LittleWing will have the following comment :
LWING_GAIN=xxxxx
examples :
LWING_GAIN=1.234, LWING_GAIN=12.34, LWING_GAIN=123.4.

as you can see, the comment's length is constant (16bytes), and the point is floating.


Shouldn't this suffice ?

Dg.

Flaw in ReplayGain spec

Reply #5
Quote
Originally posted by DSPguru

shouldn't this suffice ?


It's the same thing, I think, except that IMHO the fixed length requirement violates the Vorbis specs (tags are required to be human-readable and editable, which I dont think a fixed length tag complies with), and that it has a quite unfortunate name. (LWING says just as much as RG, and it's usable by a lot more than just your app)

Edit:

Also, the precision of your tag is not enough, see this thread:

http://www.hydrogenaudio.org/forums/showth...25&pagenumber=2

--
GCP

Flaw in ReplayGain spec

Reply #6
unfortunate name ? come-on..
hehe..

btw, the fixed length isn't a MUST. the reason i set a fixed length was to ease a little bit the decoding implementation (it can be easily parsed without libvorbis).
if you feel like extending the definition into a variable length, it's okay by me .

as for "human-readable" tags,
this information is technical.  techical users can read it, non-technical users won't care about it. therefore, i don't think it matters.


anyway, you don't have to adopt it. just wanted to let you know .


Dg.

Flaw in ReplayGain spec

Reply #7
Quote
Originally posted by DSPguru

as for "human-readable" tags,
this information is technical.  techical users can read it, non-technical users won't care about it. therefore, i don't think it matters.


The issue is that for something that looks like text, it's not a very good idea to have it behave like binary data....like breaking if a space gets added or some decimals deleted.

--
GCP

Flaw in ReplayGain spec

Reply #8
Another thing would be renaming AUDIOPHILE to DISK or ALBUM and renaming RADIO to TRACK.

Its much clearer what they actually do, whereas now you at least need to have read the replaygain specs to understand what they are about.

I dislike the fact that it's different from the original replaygain proposal, but the added clearness may very well make up for that.

--
GCP

Flaw in ReplayGain spec

Reply #9
You know my thoughts on most of this, but my opinion is...


1) Change RG_* into REPLAYGAIN_*

good idea - do it ASAP. If you find the tag and don't know what it is, a websearch for RG won't help - but a websearch for REPLAYGAIN will.


2) Source/version tag

Yes - useful to include - and I won't say "I told you so" ;-)


3) include album peak value

yes again - great idea


4) renaming AUDIOPHILE to DISK or ALBUM and renaming RADIO to TRACK

You probably know my reservations about this (or at least Frank does!) but in the face of common understanding, it does seem sensible to do as you propose. rename radio to track, and rename audiophile > album.

btw, it's compact disc, not disk - I believe it's because of English v American spellings, and european vs american dominance of CD vs PC development that we have compact disc, and hard disk drive. Whatever the reason, the confusion over spelling is a good enough reason to use "album" instead of disc/disk. Anyway, if you take something off a tape, it's still an album, but not a disc!

I think the word album goes back to the start of the last century, when collections of 78rpm discs were bound into cardboard albums to hold entire classical works, which required many discs at 3-5 minutes per side.

Cheers,
David.

http://www.replaygain.org/

P.S. I appologise for that website being very out of date. The more websites I write, the less time I have to spend keeping each one up-to-date!

Flaw in ReplayGain spec

Reply #10
Interesting how things run full circle!!

I proposed this some time ago to be used in oggdec and was told that the vorbis dev team was very much against the addition of another tag!!!

Ah well, nothing new in life I guess!

john33

Flaw in ReplayGain spec

Reply #11
Quote
Originally posted by 2Bdecided

2) Source/version tag 

Yes - useful to include - and I won't say "I told you so" ;-)


I hate to bust your enthousiasm, but as long as I see no way to make this work correctly, I'm not going to include it :naughty:

The problem remains that it will be possible to change these values in a non-replaygain capable tag editor. When that happens, the value in the field is worse than useless, it'll be wrong!

If I don't include the tag, the worst that can happen is that when a new version comes out the people that really want to re-replaygain their entire collection will have to have a bit more patience. 

IMHO, that's no comparison to the current problem (the miss of album peak can totally break replaygain on a silenty recorded album with great dynamics) I'm not proposing adding a tag because I think it's cool to have another one, I'm proposing it because without this tag replaygain simply won't work!

In a theoretical ideal world the album peak value is not needed: it can be determined easily by reading in the peak tags of the rest of the album. In practise, it simply won't work because of the way most players are designed. (Not to mention added complexity).

Quote
3) include album peak value

yes again - great idea


Might want to mention it on replaygain.org somewhere.

Quote
4) renaming AUDIOPHILE to DISK or ALBUM and renaming RADIO to TRACK

You probably know my reservations about this (or at least Frank does!) but in the face of common understanding, it does seem sensible to do as you propose. rename radio to track, and rename audiophile > album. 


I don't know what your reservations are...all I remember is Frank saying ' I don't listen to the radio and I'm not an audiophile '

Thanks for the 'album' clarification.

--
GCP

Flaw in ReplayGain spec

Reply #12
Quote
Originally posted by john33
Interesting how things run full circle!! 

I proposed this some time ago to be used in oggdec and was told that the vorbis dev team was very much against the addition of another tag!!!

Ah well, nothing new in life I guess! 

john33


Amazing isn't it? All feedback from the vorbis side so far has been ' we think your ideas are fine '.

Big difference from the first time it was proposed: ' Three tags?!?!?! Are you nuts ?!?!?!'

--
GCP

Flaw in ReplayGain spec

Reply #13
On the pratical side, I'm considering

REPLAYGAIN_ALBUM_GAIN=-6.00 dB
REPLAYGAIN_TRACK_GAIN=-7.00 dB
REPLAYGAIN_ALBUM_PEAK=1.12443
REPLAYGAIN_TRACK_PEAK=1.04343

vs

REPLAYGAIN=ALBUM:-6.00dB; TRACK:-7.00dB; ALBUM_PEAK:1.12443; TRACK_PEAK:1.04343

Advantage: only one tag
Disadvantage: harder to parse

--
GCP

Flaw in ReplayGain spec

Reply #14
Quote
Originally posted by Garf
On the pratical side, I'm considering 

REPLAYGAIN_ALBUM_GAIN=-6.00 dB
REPLAYGAIN_TRACK_GAIN=-7.00 dB
REPLAYGAIN_ALBUM_PEAK=1.12443
REPLAYGAIN_TRACK_PEAK=1.04343

REPLAYGAIN=ALBUM:-6.00dB; TRACK:-7.00dB; ALBUM_PEAK:1.12443; TRACK_PEAK:1.04343

Advantage: only one tag
Disadvantage: harder to parse


4 == sscanf ( buffer, "REPLAYGAIN=ALBUM:%lfdB; TRACK:%lfdB; ALBUM_PEAK:%lf; TRACK_PEAK:%lf %c, &ga, &gt, &pa, &pt, &trash)

Useful if exact this form is forced.
--  Frank Klemm

Flaw in ReplayGain spec

Reply #15
Quote
Originally posted by Frank Klemm


4 == sscanf ( buffer, "REPLAYGAIN=ALBUM:%lfdB; TRACK:%lfdB; ALBUM_PEAK:%lf; TRACK_PEAK:%lf %c, &ga, &gt, &pa, &pt, &trash)

Useful if exact this form is forced.


Reordering of the field names breaking all parsers? Bad idea.

--
GCP

Flaw in ReplayGain spec

Reply #16
KISS rules, I think!

john33

Flaw in ReplayGain spec

Reply #17
There has been a huge discussion about this on #vorbis, and it wasn't nice.

Basically, the vorbis people seem to want to throw out this system altogether.

Monty basically thinks everything but the radio gain value should be thrown out. His arguments were that you can 'clip' this value to take the peak into account, and that the audiophile settings are redundant because they can be inferred from combining the tags of the individual tracks.

If you look at my post that started the thread, you'll see the reason I proposed a change was exactly that that is impossible in most players, and adds a lot of unnecessary complexity in those where it could be done.

Losing the radio peaks means losing ReplayGain functionality when you manually reduce preamp (i.e. increase headroom). Losing the album peaks causes problems with _all_ of the above. Moreover, it seems that this tag is wanted for purposes outside of ReplayGain.

When Monty was done, the Xiph.org CEO went as far as to say that Vorbis should drop ReplayGain support completely, as 'it's really a player issue', going on to explain it can be done by letting the players do all calculations and storing the results in a database etc etc...

Needless to say, I'm not happy with this. The entire goal of my proposal was to make ReplayGain a) work b) easy to support in players. The above nukes both of these goals, and without them, I don't see ReplayGain for Vorbis gaining a lot of support, if any.

I don't really know what to do with my proposal either. It doesn't seem a good idea to continue it if the Vorbis people are so heavily opposed to it, but on the other hand, a lot of people, (including me) want this feature, and it just plain _works_ right now. Updating it to the changes I proposed here would be trivial in both the players and tools.

The players only need to change their reading of RG_* into REPLAYGAIN_*, AUDIOPHILE/RADIO into ALBUM/TRACK and use the REPLAYGAIN_ALBUM_PEAK tag when it's present and we're in album gain mode instead of the REPLAYGAIN_TRACK_PEAK one.

The tools need to change RG_* into REPLAYGAIN_, AUDIOPHILE/RADIO into ALBUM/TRACK, write out the new tag, and include an autoconvert option which converts files from the old format.

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

But beware! Because this needs the obviously unacceptable amount of four tags, the Vorbis people will come and haunt you at night for such blashphemy.

Peter, Magnus and zinx, I'll leave it up to you whether you want to update your stuff to the new proposal, or wait for the Vorbis people to come up with a working proposal of their own.

Personally, I've had enough of this for the next two months. I have to fight with David over each tag I leave out, and I have to fight with the Vorbis people over each tag that gets in. This is no situation to be in and I see no reason to keep wasting my time with it.

--
GCP

Flaw in ReplayGain spec

Reply #18
This is really rather sad!

I thought that part of the idea of the vorbis tags was flexibility,etc. I also thought that the relative lack of rigidity compared to ID3 was to allow people to 'create' tags for their own use. With the currently expounded philosophy it makes you wonder why they bothered! Might just as well have stayed with ID3!!!

I don't really understand why it should be such a big deal.

john33

Flaw in ReplayGain spec

Reply #19
I think your idea's Garf are great - clear, simple and easy to use. The database idea is a strange one, not very object orientated! If the gain feauture was supported as a standard in ogg as you state Garf, it would seriously increase the chance of me choosing ogg.

Flaw in ReplayGain spec

Reply #20
Only incuding radio gain does indeed seem to be a step backwards. In a way I can see Monty's point that the radio gain is the only required value (which is true; perhaps peak is good too). But having each and every player calculate the rest (and perhaps store it somewhere) isn't very good, and won't promote adoption in a lot of players.

You might then just as well say that each and every player should calculate the gain as well! Possibly differently (just compare ReplayGain for Vorbis and MPC, which does differ slightly).

And lets not forget that 2Bdecided (that's the ReplayGain "author", isn't it?) thinks that the album value *should* be possible to change by the user.

So it would be better to make it easy for the players (and users), IMHO. Having four tags is a bit much perhaps, but there is no other place but tags at the moment, so that will have to do. However, putting all in one tag (as Garf suggested) would be kind of nice. Code to parse that could be included and isn't very complicated anyway. But it doesn't make the player code "as simple as possible"...

Anyway, I'm fully prepared to update VorbisGain, once it is decided how to do it. At least if Winamp and XMMS will supports the "new" standard.

Monty might not like it (or support it in Vorbis, via libs or included tools), but he can hardly stop us from doing it.

(Gotta run...)

Flaw in ReplayGain spec

Reply #21
I have even better idea. Let's store all the tags in player databases, that way also they can be handled by players where they really belong, after all, those are responsible for showing them. Actually players are responsible also for playing sound, maybe players could store the vorbis data in local databases. That would keep Ogg files really small, they would only need to store some hash numbers to access database.

Flaw in ReplayGain spec

Reply #22
Quote
it seems that this tag is wanted for purposes outside of ReplayGain.


What exactly had they been planning on using it for?

I definitly think replaygain is a good idea, but if the tag is going to be needed for something more important than it, than I would think otherwise.
budding I.T professional

Flaw in ReplayGain spec

Reply #23
Quote
Originally posted by HotshotGG


What exactly had they been planning on using it for?

I definitly think replaygain is a good idea, but if the tag is going to be needed for something more important than it, than I would think otherwise. 


Read the thread from the start. I explain in the first message why it is needed for ReplayGain. In DSPguru's message you can see that this tag is useful for other tools.

--
GCP

Flaw in ReplayGain spec

Reply #24
Quote
Originally posted by Lear

You might then just as well say that each and every player should calculate the gain as well! Possibly differently (just compare ReplayGain for Vorbis and MPC, which does differ slightly).


This is in fact what Paradox (Xiph CEO) said should be done.

Quote
And lets not forget that 2Bdecided (that's the ReplayGain "author", isn't it?) thinks that the album value *should* be possible to change by the user.


This is still possible if the tag is stored in the database. But it becomes a problem when you switch players.

Quote
However, putting all in one tag (as Garf suggested) would be kind of nice. Code to parse that could be included and isn't very complicated anyway. But it doesn't make the player code "as simple as possible"...


My basic question is: why is it bad to have four tags? Adding complication to reduce the number of tags only makes sense to me if there is a good reason to have as few tags as possible.

--
GCP