Do you believe it's better to store the data in the actual Vorbis tags, where it's more practical, easier to implement, and more likely to gain widespread support?

Or do you believe that it's better to have each individual player handle replaygain itself because it's "The Right Thing", because having the data in the vorbis tags is too much of a kludge, and because it's not the responsibility or goal of Vorbis to deal with this?

I'd say vote for the Vorbis tag solution. If anything it offers another string to the bow of the Ogg (+Vorbis) feature set, if it is spread as a standard then it'll only help raise the quality and consistancy of archived music. That's what we're here for, right?

Not only could it assist with music, but also it could quite possibly assist in the future with the problem of quiet soundtracks on DVD backups.

Ruairi

[01:36] <Paradox> There is a fundamental difference between how MPC uses tags, and how Vorbis uses tags.
[01:36] <JohnV> what's the difference?
[01:37] <Paradox> We don't feel that tags are a proper location for playback data.
[01:37] <JohnV> but what's the fundamental difference??
[01:37] <JohnV> your feeling??
[01:37] <Paradox> I feel that tags are for identification, not playback data.
[01:37] <JohnV> but what's the fundamental difference??
[01:38] <JohnV> still your feeling??? :B
[01:38] <Paradox> That is a fundamental difference.

Paradox is the CEO of Xiph, Emmett Plant.

At least, now, we know the type of person we're dealing with.





Blah. Meff was probably right

Seems to me that this guy is a true 'anal retentive'! Doesn't really have a clue of what he is talking about.

Let me make a few things clear.

First off, I've read the replaygain spec, and I think it's a fantastically good idea. As someone who uses Ogg playback for some DJ work, I think that gain issues are an important obstacle to overcome. The kind of stuff I do makes it a royal pain to not be able to work in some semblance of a static, equalized environment. I can beatmatch as well as the next guy, but if I have to beatmatch and adjust volume at the same time, well, I only have so many hands.

I would gain an immediate benefit if the current push to embed replaygain data in Ogg tags were to succeed. I wouldn't have to monkey so hard to do volume equalization, as a matter of fact, I probably wouldn't even have to worry about it. It would be great.

On the other hand, Vorbis is strictly against using playback data in tags. After all, tags are for identification of a particular track, not a true metadata format in which to relay playback data to the player du jour.

When you order a pizza, you expect the delivery guy to bring you a pizza. While the delivery guy may have the strength and ability to bring you 30 orders of prime rib, that's not what the delivery boy is expected to do. He's expected to bring you pizza, and that's the entire idea. After all, you ordered pizza.

The problem with the current push for replaygain is that it is asking Vorbis to make a major fundamental change in how tags are to be used. Is this an incredibly difficult demand? No, of course not. Adding new tags to use replaygain is probably one of the easiest things to implement. It wouldn't be rocket science.

Here are my main problems with adopting replaygain tags in Vorbis.

There's no question that putting the tags in would be a quick-and-dirty solution. It's undoubtably a kludge, it's not exactly an elegant solution. I would prefer a solution that doesn't require a change in the way that Vorbis handles tags. Open Source alternatives are well-known for backwards, inelegant solutions that Work Really Well, but just because something is easy and has an immediate benefit doesn't mean it's the best solution.

There's also a massive barrier to entry in that players would need to understand the tags are there, what they're used for, and how to interpret them. This is a major issue, and people that make players are notorious for dragging their feet on adding even simple functionality. If there's going to be a lot of work done on getting the solution adopted by players, I want to make sure that the solution we offer them isn't a quick-and-dirty implementation, I want to make it something that kicks ass.

I also have a couple issues with not adopting the replaygain tags in Vorbis.

The people that are screaming for these tags are not uneducated monkeys who are merely interested in bitching. They are people who are unsatisfied with the current status quo, and they want a change that will help them. These people are Vorbis fans, they want what's best for Vorbis, and they view this as a great way to make Vorbis better than it already is. Where would Vorbis be if it weren't for the angry mob against patents?

I run a very real risk of alienating hardcore Vorbis fans if I don't make an educated decision. Hell, I'm one of them. I need replaygain for the limited DJ stuff I do.

So, that's where I am. I would like to say that there's an easy solution, but I don't think there is. I am extremely interested in hearing what people have to say as far as an alternative is concerned. There is a lot of room for compromise, and I'm primarily concerned with doing what's best for Vorbis in general. Maybe that means giving up the idea that tags aren't for playback data. Maybe that means compromise so that replaygain doesn't need four tags, but makes do with just one. No tags are better than one, but one tag may be better than four.

I could be wrong, I could be right. I look to the knowledge and experience of other Vorbis users and replaygain fans to help me understand the path to the best solution. I'll be following this thread, and I can be reached at should anyone want to drop an E-mail.

Thanks for your time!

Emmett Plant
CEO, Xiph.org Foundation

Well considering he is backing up the opinion of his developers then it's easy to understand his statements. I think:rolleyes:

Still though, for me the only "real" soltution I see is to implement the tags inside the container. Any other alternatives that were suggested? Player based is definitely not a good solution IMHO.

The values could be stored in header in similar way MPC does. That would keep the values in files where they belong and tags wouldn't be needed. But if Vorbis header isn't prepared for additional data this is probably out of the guestion.

Ok people, please give proper reasons why rg should be implemented in the tags or not. Not just "it's not a good solution in my opinion."
More defined reasons please.

The tags are not a technical problem at all. This is mainly a matter of principle. Vorbis devs don't want tags to have any playback information.

I'd also like to see other solutions that are realistic. It's not realistic IMO to expect wide player support for all the replaygain calculations and database for rg-values handled by player. This of course also means that you would have to redo replaygain calculations again everytime for different players.
I'd also like to know if there's a 3rd or 4th possible realistic solution.

The biggest problem I see here with this situation, and I've seen it happen in a few other Opensource projects I've been involved with, is that the stubbornness and principles of the developers end up hurting the users and end up not really solving anything.

In my opinion, if the users are asking for something and there is no valid reason not to support it other than some sort of principle, then in the end, that principle should give way to their demands.

Vorbis is supposed to be a user oriented project, no? Looking at the results of the poll thus far, it seems fairly clear where most users stand on this issue, doesn't it?

As it stands, it almost looks as if many of the devs would rather having nothing at all (judging by some of the comments on #vorbis from people like segher and others who apparently think replaygain is useless and doesn't work) than a compromise that would actually provide something useful.

Most people will never see, understand, or even care about the implementation details of replaygain in vorbis as long as it works and is widely supported. When they switch from player to player (which supposedly support vorbis), they are going to wonder why some of them don't support replaygain at all while others do, and further, why they can't share this information between players because they all implement a different method for doing the exact same thing. This, all because it's more important to stick to principles on this regard and not to allow the data to be implemented in a universal and standard way in the vorbis tags. Guess who they are going to complain to about that?

Having said that, I'm all for an alternative solution. That is, if it is actually workable, practical, and is likely to be widely implemented. The current proposal for shifting the burden off onto the players is clearly unrealistic and far too much of an idealist goal to be practical. I have a hard time seeing another way of solving this situation without imbedding the replaygain data in the vorbis files themselves. Perhaps I'm missing something. At any rate, I'm still listening....

Btw, one last thing...

Can someone please explain to me the big problem between using 1 and 4 tags? How does using 4 tags instead of 1 somehow make this idea not worth implementing?

It seems to me that this is some other sort of other unrelated principle again because, clearly, if you make the compromise to allow tags in general to be used for playback data, that's entirely unrelated to the amount of tags used.

This seems to indicate to me that part of the problem behind replaygain in vorbis (which Monty seemed to express by saying that "Replaygain is still trying to expand it's fiefdom") isn't so much because of a technical or practical issue at all, but rather because some core people view this as an outside idea, not developled by them, that is somehow encroaching upon their territory and "tainting" the project. I certainly hope that's not the case, because of it is, that would be most unfortunate :/

Hummm... like their unwillingness to accept John33's OggDec sources in Vorbis CVS?

Btw, to everyone in this thread, lets try to keep personal attacks out of this debate please. Ok? If there's going to be some sort of discussion we need to try and keep it on topic, even if it may get a little heated

This is sort of going further off topic, but in the interest of potentially clearing up a misunderstanding, this is what Vakor had to say about the matter:



We talked some more and he had this to say:



I suggest maybe you or john33 contact him on irc in #project_mayhem or #vorbis, or you could email him at

OK, back on topic now

Just to clarify (Sorry for keeping OT)

I had offered OggDec code to Monty because it's the only person I know about Ogg Dev. :-P
Never heard of this Vakor guy.


(The discussion ended there)

I will contact Vakor now. Thanks for the info.

Regards;

Roberto.

Quoth Dibrom:

"The biggest problem I see here with this situation, and I've seen it happen in a few other Opensource projects I've been involved with, is that the stubbornness and principles of the developers end up hurting the users and end up not really solving anything."

Well, remember that I'm here in an effort to ascertain if there's something we can do about it. I'm really not interested in debating the reasons why the principles are necessary or not important, I'm interested in learning about alternative solutions. I'm interested in a way to make this work out for the best. Imagine if we just did exactly what people wanted, when they wanted it, every single time they wanted it, damn the consequences? Maybe we'd solve more problems, but we'd likely create a lot more than we started with.

"In my opinion, if the users are asking for something and there is no valid reason not to support it other than some sort of principle, then in the end, that principle should give way to their demands."

I agree with you, but only when the demands of the well-meaning users are discussed and all the alternatives are on the table. Remember, I'm on your side. I like replaygain, and I think it's useful. If you're a big replaygain fan, don't you want to see it implemented in the best possible way? I do. That's why I'm taking the time to see what's possible.

"Vorbis is supposed to be a user oriented project, no? Looking at the results of the poll thus far, it seems fairly clear where most users stand on this issue, doesn't it?"

No, it doesn't. A poll on Hydrogen Audio is not a representative sampling of everyone who uses Vorbis. Imagine if the poll weren't about embedding replaygain tags into Vorbis. If it were to ask if I should wear a suit made of bananas in an effort to make Vorbis more attractive, and everyone voted for the banana suit, would I then be forced to wear a banana suit by mob rule?

Just because a million people think it's a good idea, doesn't mean it couldn't do with more discussion and the presentation of alternatives. Contrary to popular opinion, mob rule does not make for good design.

"Having said that, I'm all for an alternative solution. That is, if it is actually workable, practical, and is likely to be widely implemented. The current proposal for shifting the burden off onto the players is clearly unrealistic and far too much of an idealist goal to be practical. I have a hard time seeing another way of solving this situation without imbedding the replaygain data in the vorbis files themselves. Perhaps I'm missing something. At any rate, I'm still listening..."

Many moons ago, the idea of a patent and license-free alternative to mp3 was considered 'clearly unrealistic' and 'far too much of an idealist goal to be practical.' Please remember that at the player level, the current proposition remains the same; You still need to convince people that make players that they need to add this functionality. Nearly everything else pales in comparison to this fact.

"This seems to indicate to me that part of the problem behind replaygain in vorbis (which Monty seemed to express by saying that "Replaygain is still trying to expand it's fiefdom") isn't so much because of a technical or practical issue at all, but rather because some core people view this as an outside idea, not developled by them, that is somehow encroaching upon their territory and "tainting" the project. I certainly hope that's not the case, because of it is, that would be most unfortunate :/"

I think that if there is any of that kind of thought process going on, it's likely because Monty doesn't take well to 'do this right now without thinking of the consequences' ultimata. Do you? See above for the dangers of implementing features without discussing them first. I can't say as I blame him. Monty is just as interested in the gain issue as I am, but he feels that the current proposition is not the best implementation.

So, all that being said, I'm still very much listening, and I'm here in good faith to support all the people that support us and want to see us succeed. Let's put an end to the finger-pointing and name-calling, and work something out - And I mean that as much for my own people as everyone else.

Still listening...

Emmett Plant
CEO, Xiph.org Foundation

The reason that this doesn't really apply is that Replaygain is that has been thought out. It's not just some random idea that fell out of the sky. Yes, it may not be perfect, but we aren't asking for something totally rediculous here. To assume that by somehow implementing this feature in this method could possibly lead to the breakdown of all principles and that resultingly, all consequences would no longer be considered, is simply absurd.

QUOTE

[b]I agree with you, but only when the demands of the well-meaning users are discussed and all the alternatives are on the table. Remember, I'm on your side. I like replaygain, and I think it's useful. If you're a big replaygain fan, don't you want to see it implemented in the best possible way? I do. That's why I'm taking the time to see what's possible.

Fair enough. However, if the alternatives are truly to be discussed, shouldn't you get the originator behind the Replaygain design involved in this as well? Shouldn't you be contacting a wider variety of people in order to get this taken care of? It kind of seems that you are posting here now on HA only because this issue had gotten out of hand on irc and because there was such an outcry (if only from a few vocal users) about this issue. I wasn't even aware of this shift in policy towards Replaygain until I overheard some conversation about it the other day and Garf apparently being fed up with trying to argue with you guys.

QUOTE

[b]
No, it doesn't. A poll on Hydrogen Audio is not a representative sampling of everyone who uses Vorbis. Imagine if the poll weren't about embedding replaygain tags into Vorbis. If it were to ask if I should wear a suit made of bananas in an effort to make Vorbis more attractive, and everyone voted for the banana suit, would I then be forced to wear a banana suit by mob rule?

Perhaps it doesn't represent the majority of [b]all users, but I can almost assure you that the majority of the hardcore Vorbis users read and take part in discussion on this site quite regularly. To ignore them would be a very poor judgement call. After all, it's the hardcore users that usually help drive interest and development. Quite a few users on this site, including myself, have contributed to the Vorbis project either by providing quality tuning information for Monty, or helping to develop some sort of Vorbis related audio tools.

I don't understand the relevance behind the bit about the banana suit either, sorry. It's quite a poor analogy to the current situation I think. I also don't really think it's fair to try and trivialize the matter by continuing to make such absurd comparisons (recalling the comparison of replaygain tags to a "pet" tag in #vorbis earlier).



First of all, replaygain and it's implementation was not designed by a mob. It was designed by David Robinson who happens to be quite versed in audio compression, psychoacoustics, and related technologies. Secondly, yes, it's always better to get an even greater sample of people to discuss and give their opinion on a matter, but where does that end? When do you decide that it's important to finally just implement something which is practical and usable?



That's quite a different thing. What I am referring to as being "impractical" here, has to do with the fact that you are going to have to rely on others to get the support implemented. The easier you make it for them to do this, the more likely it is that it will be done. Designing a patent-free codec only relies on one party having to do so. In comparison to what we are talking about now, that is a much more practical goal. You already said that it's difficult to get people to implement new functionality in their players, don't you think they will be even less likely to do so if it requires more work?



Replaygain is not a brand new thing. It has been around for awhile now, and Monty has known about it for awhile now. People have been discussing it in regards to Vorbis for awhile now also. How come there has never been any discussion about a more proper way to do this until now? If you guys like the idea so much, but want a different implementation, then why is it only that we find out about this now, *after* there has already been some fallout on the matter? Why don't you guys contact David Robinson and try to work something out with him. Have you guys even tried that yet? I'm curious. I already know for a fact that many of the devs and people arguing against this have not even read the replaygain website, and also that many haven't even tried using it. Those who have didn't really seem to give it much of a chance either, like segher.



I very much want to see Vorbis succeed. I want to see it become the best that it possibly can. I just hope some sort of politics and principles don't get in the way of that. It happens to much these days.



I agree with this 100%. I'm sorry if I may have offended anyone (I've tried to stay cool on this matter), and I apologize if anyone from here has offended anyone else also. I want to try and work this out in a rational manner.

Ok, before I start in, please understand that I am a complete idiot, and I am a terrible programmer, so I may in fact not know a damn thing about which I speak.

That having been said, as an avid Ogg Vorbis user, I've been following this thread with great interest. I use ReplayGain extensively, it works very well for me, and I've had no problems with it thus far, even if the data is stored within a tag.

From what I can gather, Emmitt's main concern with storing ReplayGain data in a tag, is that the Ogg tagging mechanism was not designed to store playback metadata, but only normal static tagging information, such as song title, artist, &c. Ok, a little anal, yes, but that's good. We want Ogg Vorbis to be a well planned, well constructed, well though-out, logically-consistent format, and not some kludge like MP3 with all of it's various tagging implementations. Anal is good. Anal means - "Do it right the FIRST TIME".

So, what to do? Ok, so if I gleaned correctly that the current tagging system should only store normal tagging info, why not (and this might be really STOOPID) implement *TWO* separate tagging areas / mechanisms, one right after the other? (Again, I'm an idiot...) One specifically for static song-related information, and the other specifically for dynamic playback-related metadata (ReplayGain, EQ stuff, CUE stuff, light-show control instructions, &c.). That'a'way, the song-related tag information could be freely displayed in places like the Winamp tag info dialog, whereas the metadata tags could be well-hidden from view, except by specialized metadata-manipulatin' tools.

Also, it would give users the freedom to:

a) Disable ALL METADATA RELATED PLAYBACK CUSTOMIZATIONS with one click of a checkbox (say, like in the Ogg plugin prefs in Winamp).

b) Clean out / replace ALL METADATA TAGS with one simple tagging tool without disturbing normal static tags (option: wipe metadata)

Keeping all these tags separate within their respective tagging constructs seems logical to me, if your concern is organization, cleanliness, ease of manipulation, and keeping things of a differing functionality separate.

Anyway, just my $0.02. Shoot me down, but not too hard. Afterall, y'all're the experts here. I'm just a user.

I don't know what the Ogg format entails from a technical perspective, but something like this maybe illustrates the point (a painfully simplistic model):

Ogg header

Actually, this metadata type stuff was discussed very briefly in the #vorbis channel. I believe it was Monty or someone else who said that this is where the replaygain data could go (note they didn't say that's where it would go though). Of course, the problem is that this new system won't be ready until "sometime in the future". Who knows what that could mean.....

So, right now, it isn't really a solution it seems. :/

True, but if it easy to implement it is much more likely to actually be implemented. The current "proposal" is easy. Read some fields (tags at the moment, as that's the only place available) from the file and make a few small changes to the decoder loop (see this thread for a good example). If only the track gain is included (as mentioned in this thread), quite a bit more is needed.

I think that ReplayGain data should be implemented in tag. Then in the player you can chose if use this data, don't use and recalculate on the fly or simply don't use....

My question. Wouldn't it (like MPC) be a viable solution to store RG values in the header? If no second metadata-system is made, this seems like the best solution to me. Unless headers definately aren't meant for "such" metadata.

Leaving it up to every player to implement their own set of storing RG-tags seems invalid to me. For compability the "global" values ought to follow the file, instead of relying on which player you use.

And, replaygain is a very well founded concept that carries a lot of validity for being implemented. It isn't just a fancy idea, but has a great potential for use.

So to cut my argumentation short, I say my preferred view is:
1) Either use a new metadata-system for "real" metadata
2) Use header if possible (unless this clearly conflicts with intentions behind the Ogg headers and/or specs)
3) Use tags (Also has the advantage that users easily can edit and remove them)
4) Leave it to the individual players

But there is no metadata format yet. It's not even being developed yet, and, to the best of my knowledge, it also isn't exactly high on Monty's priority list right now.



There is no change in the way Vorbis handles tags - it changes how they are used.



Whoot? You mean you are on my side? The current proposal is easy to understand, braindead to implement (see the example code linked elsewhere in this thread) and will pose no problems when the player doesn't support them - you won't have ReplayGain functionality, of course. The proposal also completely handles all ReplayGain aspects if the player does support it.

On the other hand, all proposal that have come from the Vorbis side massively increase the complexity of implementing the support in the players, have a lot of potential for mistakes, and it's not even clear that some of them actually handle everything correctly.

The proposal I have made is by no means quick-and-dirty, and I cannot understand how you denounce it citing reasons that actually support it.



Changing it from four to one tag is a trivial change I have no problems making with, hell, in the other thread I already proposed an alternate version that works with one tag. I like it less because it adds complexity, IMHO, for no reason. Why are more tags automatically so bad, if they ease working with them?

--
GCP

I believe this is the case - you can't just add header fields.

--
GCP

Just an idea, wich I realize might take some time to implement:

Why not implement a second sound control stream that could control the sound volume in different parts of the track? This could be very useful when archiving mix-sets of audio or backing up dvd:s, where the audio volume can differ a lot between different parts. Using this method you are not limited to one rg value, but an unlimited numbers.

Personally, I'd prefer sound modification information being done this way. An other idea might also be to add eq information, sound effect information and so on, in the sound control stream.

Cheers.

Edit: Sorry, noticed that the idea was discussed just above.

If the only issue is where to store the info (tags or metadata), then there is no problem. See my post below

--
GCP

I see three problem areas right now:

a) Store data in files vs store data in players

A lot of reasons why storing data in the players hardly looks like the right solution were already given:

1) players need to add a database system (not likely for plugins, or stuff like ogg123)
2) ...and include all replaygain calculation code
3) all data gets duplicated between each player
4) if the user overrides a value, he has to do so in each player
5) for some players, the added complications may simple make it impossible to support (think portables! it's one area where having ReplayGain support would be _really_ useful)
6) why seperate essential information about the song from the song itself?

b) Store RG-data in tags vs store RG-data in metadata

I think this is a non-issue. I agree the RG-data belongs in the metadata, if it is possible to do so. There is no metadata standard for vorbis yet, and none is coming up for the near future.

I simply propose to store the data in the tags for now, and when the metadata actually becomes something else than vaporware, and you start adding support to the players and libs, you can switch over the RG tools to put the RG-data in the metadata.

When metadata gets added, all players, libs and tools will need to be updated to be able to make use of it anyway! At that point, it is no problem to change them to get their RG info from the metadata instead of the tags.

c) What tags should be stored

Monty had problems with the amount of data the RG proposal needs to store. He thinks it is possible to make everything work with storing just one value (radio gain).

(gets a bit technical here)

I think this is false. Firstly, not storing the peak tags, but instead taking clipping into account in the radio gain tag itself, makes it impossible to get the RG to work correctly. If the user decreases the preamp (=increasing the headroom) in the player, the song would no longer clip and we would be able to apply the correct gain. This is not possible in Monty's proposal - the loudness of the song cannot be corrected any more, because you don't know the exact gain that needs to be applied. You've thrown away this information already.

Inferring the album gain values from the individual file in an album is problematic in the players. Peter P indicated to me that WinAmp 2.x can't handle it, and that it would pose problems in WinAmp 3 as well. The same is true for XMMS and most players - they were never designed to handle something like this. If you're proposing something that can't be handled by the players, you've got a problem. You can't realistically expect them all to seriously modify their design just to handle this single issue. For playing a single file, you'd suddenly need to magically infer from the playlist which files belong to the same album, read them all in and parse all their tags, and then do the math to get the right album values. This is assuming correct album gain can be inferred from the seperate track gain values in the first place!

BTW. I would like David Robinson to comment on the latter.

If you look back at the original thread that started this debate, you'll see that this is exactly the reason why I felt the need to modify my proposal. Having to read in all tags of all files of the album you are playing is not possible in some players, and a needless complication in the others.

--
GCP

Really I'm not clear on what Emmett's definition of 'playback data' is - I don't think that it is an accurate characterization of RG data. The RG data describes the peak value contained in the file, the average loudness of the track, and the average loudness of the album containing the track. This is a gross simplification of course, but it is true that these values are static data directly associated with, and descriptive of, the contents of the file. Now the users' preference as to which of these values to use (radio vs album), how to use them (amount of extra headroom etc) are clearly 'playback data' and should not be stored with the file any more so than should (for example) a user's preferred EQ preset for playing back the file. Average and peak values, however, are intrinsic properties of the file contents, no less so than tile/artist/album etc, so I don't see how, even from a purist standpoint, they are inappropriate for inclusion.

Quoth Randum:

"Really I'm not clear on what Emmett's definition of 'playback data' is - I don't think that it is an accurate characterization of RG data. The RG data describes the peak value contained in the file, the average loudness of the track, and the average loudness of the album containing the track."

By playback data, I mean 'values that are passed to the player in order to give direction on how to play the audio contained therein.'

A tag like 'ARTIST: David Byrne' doesn't tell a player to play this particular track a particular way. It's a tag that identifies the artist of the audio contained in the file, and it's not a direction on where to set parameters in terms of playing that file. That's the difference.

Emmett Plant
CEO, Xiph.org Foundation

Its a fine distinction I know, but I dont think that by this definition RG data is playback data. Yes, interpreted literally the RG data is saying "attenuate by Xdb", which would seem to be a 'direction on how to play the audio contained therein'... however when you realize that this 'direction' is simply a measurement of the difference between a property of the waveform itself, and a fixed value, really this is a measurement, i.e. description, not a direction. You COULD store the RG data as simply the average loudnesses, and leave it up to the player to do the calculation, based on this measurement, of how much attenuation to apply for a given RG or clipprotect mode. This data would be exactly equivalent to the RG data proposed to be stored, the only difference being that it has been reformatted to appear intuitively as a description of the waveform rather than a direction on its playback.

I'm glad Radium picked up on this fine point!

The title field says what the title of the track is.

The replay gain field says how loud the track is (well, kind of!).


The title field doesn't tell the player to display the title.

The replay gain field doesn't tell the player to change the volume.


However, this is being picky, but proves an interesting point: the RG data both is and is not playback data! It's not playback data, in the sense that it gives some information about the audio track that is true for that track, and (unless it's not actually correct) will never need updating. In this way, it's just like the title field. BUT whereas the information in the title field is useful on playback in that it can be sent to a display, the information in the RG field is useful on playback in that it can be used to change the audio data.


It's clear to me that the RG info should travel with the file, be it meta data or tag data. That was one of my main aims when I set up replaygain.org - to get this important (yet neglected) metadata into all audio formats. Audio Engineers spend a lot of time worrying about small improvements that most people will never notice - but most people will notice if one album is much louder than another, and it's about time we fixed it. It's also good to tie the data to a real world reference level, allowing the possibility of playing things at realistic volumes - but only 1 in a million people are going to care about this, so I don't push this point!


I've got a lecture - back soon.....

David Robinson.
http://www.replaygain.org/

I know it's been kindly said several times in the thread that the vorbis team should ask me what I think, but I'm probably the last person to ask (I'm probably about to prove this point with a long rambling post!).

I am very happy with the way others are taking the replay gain idea forward, and Garf has already said all the things that I would have added to the general discussion!


I'll make the following points, to add to the discussion about metadata vs tags. I realise that in practice the choice will come down to "whatever works", so this is probably pointless, but maybe it'll help... I appologise that I'm just repeating what others have said - but I'd like to back them up and say "I think you're right!"

0. tags ARE metadata. but I'll follow the convention that seems to have built up in this discussion that "metadata" means "some other area of data inside the file that's not a vorbis comment tag" when discussing this.

1. Store the four values. Just 1 value is (as Garf has explained) much less use - you need at least the "peak" value to go with it. Having track and album makes sense too. An intelligent player could infer the album peak from the playlist by checking each tracks "track peak" - but why not have that fourth value? It makes the players job easier.

So, if there's no space for four values in a vorbis header or metadata space, it'll have to go in the tags.

And have you thought of this point: If the format is released (which is kind is!), and then a meta data format is figured out later, people will NEVER use that new meta data part - they'll just stick everything in the tags as they always have done!


2. I think the RG values should be tied to the audio data as closely as possible. You need to be able to adjust them (in case they're wrong - the calculation isn't perfect!), but generally they should sit in the file along side the audio data, travel with the audio data (i.e. individual player-side storage solutions are a very bad idea), and not change.


3. Have you looked that the meta data provision in Meridian Lossless Packing (the DVD-audio format)? It includes the specification of an SPL reference (like the RG value) and Dynamic Range control information, information about what each of the 63 possible audio channels correspond to, and other stuff which is tied to the audio data (because it's packed with it in the same data stream). It's mainly information related to the playback of the audio, rather than stuff like title/artist etc. The Meta Data specification is open ended, and they thought about including it from day 1.

I can't find a great web reference for the meta data (I've read it somewhere, but now I can only find a small summary doccument with meta data at the end - http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF ) but it seems to be a well thought-out solution to the playback metadata needs of a 21st centurary audio format. You really should have the provision for something similar in vorbis! I appologise if it's already there.


I guess I'm coming down on the side of embeded meta data rather than tags for RG - but in truth, I don't think it matters either way! What does matter is that you should include human readable and editable type data, and machine readable type data, both in an open ended manner. The former you would propbably call "tags" and the latter you would probably call a "header" or "metadata".

To define the header (metadata) now, close the discussion, and (most importantly) not leave provision to add more is probably not wise. This, by necesity, would force any machine readable audio related information into the tags, which (I seem to recall) are supposed to be human readable. But there is obviously some data which should not be in the general human readable/editable tag area (e.g. number of audio channels!), and there may be more in the future which you haven't thought of yet! I think replay gain should probably go with this data.

Hope this helps. Sorry if it doesn't.

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

web site not updated since last October - proving what a replaygain zealot I am! :-)

I'm late to this discussion, for I need to study first what ReplayGain is all about. I've never used it before, and now I know why--I listen mostly to classical music, and I've no use of RG.

But I've read through David's web site (to the best of my ability -- I'm a social science guy), and I've read the two recent threads about RG, which I ignored initially.

Still, I have some questions, and hopefully some of don't mind teaching a newbie a thing or two.

Question 1:

If the issue is about putting 4 tags in the user-definable Vorbis tags area, what exactly are you trying to get the Vorbis team to agree to?

Because classical music is my thing, I need quite a few extra tags on my ogg files. I need composers, opus no., original source (from piano rolls to 78 rpm to LP to CD), performers, orchestra, conductor... etc. I don't think I need any permission to create those tags, so if those RG tags are so important to you, why don't you just do it?

What does "official support" exactly mean in this context? You want the vorbis encoder (oggenc) to also do RG caculation and store the tags? Or you want the the libraries to provide functions to read/write the tags? Or you want the reference decoder to be RG-enabled? Or...?

Q2:

IIRC, the decoder has been freezed since RC1, right? The promise was a properly-implemented decoder/player now will be able to decode all future v 1.x files without problem, even if they're encoded with newer version of encoders. If we want the vorbis team to change the requirement so that only a RG-enabled decoder is a compliant decoder, they would have to break the promise, don't they?

This doesn't entail that they should never do it. But I think if this is really the case, their reluctance is at least understandable. Because it's they who have to go explain to everybody why they have broken their promise.

Q3:

Monty and Emmett never said this, so it could be just my imagination. But is it possible that there's a concern of loss of control? RG's development isn't under their control, and they might fear (legitimately, I think) that they'll have modify their specs again if something is changed on the RG front.

Q4:

About the number of tags. I don't really get why tags other than the track gain tag are necessary. Yeah, I understand the concept of maintaining the relative loudness between tracks within an album. But if you're really listening through an album, isn't adjusting the volume knob once enough for the whole album?

I guess I probably misunderstood something there, but my impression is that with those album gains, album peak, etc. you can listen through several albums without having to adjust the volume? Assuming that's correct, it's cool. But is it that important? To have three tags per file just to avoid tuning the volume once per album?

I guess some ideas are just hard for a non-RG fan to comprehend. I adjust volume depending on more factors than the loudness of the recording itself. It has to depend on the environment, time of day, what I'm doing, whether I'm wearing a headset or not...etc. I certainly can't program all these into the tags.

I do see the benefit of the track gain setting (radio mode), when playing mixed songs. But very little beyond that.

I guess all my questions circle back to the first one: if there's really nothing for the vorbis team to do except giving you their blessing, then there should be no problem at all. You write your own tools to write the tags, and ask player plugins or decoders to use them. You don't really need the permission of the vorbis team.

If some things need to be done on their part for this to be useful, then could someone explain Q2 to Q4 to me, please?

Frankly, I quite sympathize Monty and his team (how many people are there?). They've been swamped by demands. Some people want written specs, NOW! Some people want v 1.0, NOW! Some peole want very low bitrate encoding, NOW. Some people want even better audio quality, at even lower bitrate. Some peole wonder why they don't send an army of promoters to hardware player developers and give them their fix point encoder for free. And now this.

I don't know Monty, or Emmett, and I don't know how exactly they feel, but I certainly don't envy their jobs.

Monty has said that he wanted ReplayGain support for Vorbis. I do not want a ReplayGain proposal that is not ok with the Vorbis people, because otherwhise work will be duplicated eventually and two implementations will exist. I want to avoid that.

ReplayGain does not really need support for the Vorbis side, but any given (officially standardize tags, support in libs) is very handy as it helps adoption.



There is no need whatsover for a decoder to support ReplayGain in order to be compliant. It is a completely optional feature.



What do you mean, outside of their control? They control exactly what Vorbis wants to support and what not. If they don't like a part of it, they don't have to use it. That's exactly why were having this discussion.

Q4 has already been answered in this thread. Moreover, if you have no use for RG, any of its features will seem useless to you. (sounds logical, doesn't it?)



Paradox has done just that.

--
GCP

That's what we've been doing. ReplayGain for Vorbis has been available for a couple of months now.

QUOTE

About the number of tags. I don't really get why tags other than the track gain tag are necessary. Yeah, I understand the concept of maintaining the relative loudness between tracks within an album. But if you're really listening through an album, isn't adjusting the volume knob once enough for the whole album? 

I guess I probably misunderstood something there, but my impression is that with those album gains, album peak, etc. you can listen through several albums without having to adjust the volume? Assuming that's correct, it's cool. But is it that important? To have three tags per file just to avoid tuning the volume once per album?

Not quite. In an album, the percieved volume of some tracks can intentionally be lower than that of others. When listening to a random playlist, one may wish to preserve that volume difference (I do).

The peak values aren't strictly required to get the "normalized playback" thing working. However, some tracks will have their playback volume raised. Since this is done by scaling the actual decoded sample values, there's the possibility that clipping is introduced (or increased), which can lead to audible artifacts. The peak values can be used to prevent this (by limiting the amount of volume increase).

QUOTE

I guess some ideas are just hard for a non-RG fan to comprehend. I adjust volume depending on more factors than the loudness of the recording itself. It has to depend on the environment, time of day, what I'm doing, whether I'm wearing a headset or not...etc. I certainly can't program all these into the tags.

True, but this limits the need to that only. E.g., you don't need to rush to the volume control when quiet song (or album) is followed by a compressed song.

QUOTE

I guess all my questions circle back to the first one: if there's really nothing for the vorbis team to do except giving you their blessing, then there should be no problem at all. You write your own tools to write the tags, and ask player plugins or decoders to use them. You don't really need the permission of the vorbis team.

For increased player support it is nice if this (optional) feature is supported by the core libs and tools, to make it even simpler to implement. And as has been said, the right place for this information isn't really the vorbis tags, but that's the best place that works [b]now - and can be used as a stop-gap measure until a better solution is available (e.g., a metadata stream or special header fields).



But in this case [b]we (2Bdecided, Snelg, Garf and me) have been doing most of the work, not them.

(Edit: Fixed two typos.)

I knew that. Sorry if I didn't make myself clear.

What puzzled me was what you guys were up to by starting a poll here as if to put pressure on the Vorbis team to accept "something." Not that there's anything wrong with starting a petition, but I just had trouble understanding what the "something" really is. What do you want them to accept?

Now, from you and Garf's explanation, I gather it comes down to this:



You want RG functions to be part of the official library. But I wonder how much effort on their part has to go into this to make it happen. I understand you guys have been doing most of the jobs, up till now. But wouldn't it require quite some effort on their part if RG is to be supported by the official set of libraries and tools?

My biggest concern is, will this delay ogg vorbis's progress toward v 1.0 noticeably? There have been lots of talks that many big players in related fields (hardware manufactureres, CD mastering software companies like Ahead and Roxio, and other software vendors) won't even consider vorbis support until it hits 1.0. And there's been a lot of complaints for not seeing the specs, which Monty has promised to be delivered when vorbis hits 1.0. From my POV, it's more important to get there, and it might be a little too late to add RG without causing significant disruption.

Well. Just an opinion from an outsider. I certainly don't know how disruptive this will be, or how much effort is needed to incorporate RG into vorbis's libraries. Sorry if I didn't sound like too enthusiastic.

I did not start the poll, nor do I want to pressure the Vorbis team.

I want to know the reasons why they think the current proposal is no good. And I want arguments for it, so I can refute them one by one, or if that's not possible, alter my proposal.

I do not want them to 'accept' anything, just find out why they think the current proposal is good or not good.



No, I will repeat again, if they don't want to, there is no need whatsoever to have library support for ReplayGain. ReplayGain works just as well without library support and is still trivial to implement without it.

The initiative of getting support in the libs has come from the Vorbis side, _not_ us.

The tools are already written.



No. The limiting factor to getting 1.0 out is Monty finishing the encoder software. He is the only one with the needed knowledge. This is seperate from ReplayGain support, whose implementation can (and has been) done by others.

--
GCP

Ok, but how much different it is from the status quo then if it's optional. I mean, if you've got the tools and tags standardized, isn't it also up to the player/decoder developers to use it or not?

I guess I've some logical barrier to understand your position clearly. If it's as easy as adding an additional library to the vorbis library set, and its use is completely optional, then what's the difference from what you've got now?

If what you want is a greater degree of integration into the libraries and tools, then I would guess the integration needs quite some effort on their part, too. No? (My concern has been stated in my reply to Lear.)



I mean further down the road. If they adopt your proposal and integrate RG into their tools and libraries. What if someday you (I mean you and other RG core developers) decide to make changes, what do they do? Yes, theoretically, they can keep what they have and refuse to implement your changes. But that isn't very realistic, isn't it? Once you've taken something in, it's hard not to follow its development.



Well, I personally have no use for any of it, yes. But I can relate to the need of the radio gain (track gain) tag, while I have difficulty following what others are really good for. I mean, I do understand they'll be useful, but I doubt whether it's worth using 3 tags for that extra benefit.

If it's implemented in tags, I've no problem, for they don't bother me if I don't use them. But I'll be a little concerned if it's put into metadata (header) as some people suggested. Because that means it would bloat the header even if I don't use the feature at all. That's not to say I'll necessarily vote against it, though. Just concerned. But this is moot now since it seems you've abandoned the metadat route.



To one or a select few companies only, isn't it? There're still some hot air over on vorbis-dev mailing list, where people argue whether an independently developed free fix-point decoder would hurt Xiph's (potential) revenue. And some people are accusing Monty of trying to discredit the free deocodor in order to protect their own commercial interest, even though all Monty did was to clarify that a decoder capable of decoding RC3 files isn't necessarily compliant. Then he's further accused of withholding the specs (so no one know how to be fully compliant) in order to protect their own interest.

I understand the frustration of vorbis supporters of not being able to see the specs, but the discussion attests to Monty's pressure to get the thing out of the door asap.

Well, once again, please excuse the rambling of an outsider, who obviously knows much less than you guys.

I repeat, again:

There is no need to add an additional library to the vorbis set. The implementation works completely with the existing libs.

The initiative to get ReplayGain support into the Vorbis libs does _not _ come from us, but from the Vorbis side itself.

The Vorbis people _want_ ReplayGain support. There is a disagreement how it has to be implemented, and it must be ironed out so we do not end up with two competing implementations.

[b]This is the only thing there is discussion about. All the rest are side issues. The discussion is not about ReplayGain support or not. It's about _how_ to implement it.



No, it does not. The support in the libraries is not necessary to work and the software has already been written.



Nonsense. I repeat again: They control exactly what they support. If a certain feature would break backwards compatibility once the software gets spread out, they do not have to support it (and hence break their promise). Not to mention nobody on RG side is going to be inclined to introduce such a feature in the first side - it would break all work done to getting RG adopted up to that point.



All of what you say here is completely senseless, since we do not even have an idea how the metadata will look or work in the first place. It does not exist yet. It is not even in development. There is nothing that says the metadata implementation won't be as flexible as the tag system is. (And hence won't waste space on things that aren't saved)

I haven't abandoned anything - there isn't anything to abandon yet in the first place.



This is a complete lie. Monty has explained _exactly_ what is wrong with the alternate fixed point decoders, and why they will break. The problem is that fixing the cause of that is a non-trivial programming exercise, and the author of the decoder is only interested in fixing it when it breaks.

The current fixed point decoders won't hurt Xiph's income - they're GPL, and hence unusable for most commercial companies. It has been explicitly stated it was GPL just for those reasons.

--
GCP

<backing away> Sorry if I misunderstood you, and sorry if I somehow offended you (for you seem quite irratated). I've never meant to impede anything.

My concern, from the POV of a user and vorbis supporter, is to see it reach the v1.0 finish line asap. And I raised some questions only because the issue was polled on the board, and I thought a wider range of input was solicitated. I didn't know the question was so narrowly defined. My apology. Ok? Please don't be offended.



I'm not sure what "lie" you're referring to. From your explanation, you mean those accusations that I relayed in my previous message, right? Well, I was only relaying the sentiment on the mailing lists and some other boards where some people aren't happy with what Monty or other Xiph's people are doing.

I certainly didn't (don't) agree with them, and I believe I made clear that those accusations were false. I was using those accusations as an evidence of the pressure vorbis team is under. Nothing more. I meant no offense, and if I somehow managed to offend you, I'm sorry. Ok?

Hew!

p.s. I didn't vote in this poll, since the question is so technical. Don't count me as one of those who vote "no".

I didn't think my opinion would interest anyone... :-)

David.

P.S. when did adding 16 bytes (or whatever it is) to a 5MB file become "bloating"? ;-)

P.P.S. Thanks for all your work on this Garf. I'm sure millions of users will thank you one day! (soon, I hope).

Hehhh? Sorry, I really don't get this. Do you have anything to say, or not? (English isn't my first langauge. It's hard enough to get the literal meaning right, and to read into implied meanings, sarcasm, emotion, ...etc. is usually beyond me. Sorry.)



Hmmm, many of my ogg files are far smaller than that. They don't use very high bitrate, and the tracks are short. (In classical music, some tracks are as short as less than 20 sec.)

And I didn't know how many bytes were needed. Looked to me the tag names alone took a lot of bytes. (Probably not necessary should they be implemented at the header leve, instead of tag. But I wasn't sure.) And frankly, I'm not sure how the header would look like if we all put things we think important there. If you ask me, there're more things that should go in there than RG. (But that's just me. ok? I certainly know classical music listeners are in the minority.)

That being said. You're right, in general. 16 bytes (if that's all it takes) don't sound like many, and I take the word "bloat" back. Is that enough for peace?



That I've no doubt. And I believe you and some others deserve credit, too.

tw101,

Don't worry - my sarcastic comment wasn't directed at you (or Garf)



That's a good point. I still doubt you'd notice it. AND (this being very important) no one will force you to include Replay Gain tags.

You're right - the ASCII tags take up more than 16 bytes - it would be more like 100. That's still only 0.1kB. Even if you have on average 1MB audio data per file, only 0.01% is going on RG info. Or to look at it another way, if you had 10000 very short audio tracks, the RG data in all of them put together would take up the space of 1 very short audio track.

But no one is forcing you to include them, unless I'm very mistaken. Adding the replay gain tags is a separate optional process.

Cheers,
David.

Not your fault - I'm just extremely easy to get annoyed, and this debate has already gotten the better of me, so at this point I'm just barfing my annoyance at anyone who comes along, including you Arf! Arf! [1]

It's your full right to comment on our doings - though I would prefer it if people commenting on this matter would carefully read what has already been written (replaygain.org/previous debates first), as it would clear up a lot. I'm specifically *cough* thinking of some Vorbis people here *cough*.

QUOTE

I'm not sure what \"lie\" you're referring to. From your explanation, you mean those accusations that I relayed in my previous message, right? Well, I was only relaying the sentiment on the mailing lists and some other boards where some people aren't happy with what Monty or other Xiph's people are doing.

I certainly didn't (don't) agree with them, and I believe I made clear that those accusations were false. I was using those accusations as an evidence of the pressure vorbis team is under. Nothing more. I meant no offense, and if I somehow managed to offend you, I'm sorry. Ok?

If the accusations are false, the Vorbis team should not feel pressurized by them. The pressure for a spec _is_ grounded, and that's why it is high on their priority list. ReplayGain support is not critical. Which is why I'm not pressurizing for any official support. I am (or more, was) pressurizing for an agreement or at least sensible discussion, because that is important now. Competing specs would be no good.



You are right - while Dibroms intentions where no doubt good, a technical decision like this shouldn't be based on a vote of which most voters will not understand all issues involved.

--
GCP

[1] Now you know where the handle comes from as well.

Correct. There is no overhead if it is not used, and if it is, it is very small.

--
GCP

To clarify, of course I agree with you. The point isn't to bring about a decision based upon the poll itself. Rather, I created to poll to exemplify the fact that there are a good number of people interested in this issue. Both Paradox and segher had stated they had not received any emails on the topic at all and that this somehow implied there was very little interest in seeing this matter through, so it wasn't very important. While it is true that in relation to many of the other items on the TODO list, replaygain isn't so critical, the notion that people are not particularly interested is not. I wanted to show this and also drum up some more discussion and awareness of matters at hand here. I think so far it has been a successful endeavor.

As for most people not understanding the matter properly, that may be true to an extent. Certainly most people won't understand it in quite the detail (including *ahem* some of the people in #vorbis) that some like yourself would, but the issue as to whether the support should be on the player side or in the files themselves (via tags or metadata), is a pretty easy concept to grasp IMO.

ReplayGain support is something that should no be underestimated. When I started working on it, I did more so because some people indicated that they wanted that feature before switching over to Vorbis, and because it was something I had the knowledge to program. At that time I had never used it myself (for MP3 or MPC). I was aware of the problem, but it had never occured to me it could be (and had been) solved.

The amount of feedback after publishing the first version quite surprised me. Looks like there are a _lot_ of people out there that use this crazy idea.

After starting to use it myself, I would not want to go back.

ReplayGain just needs to get better known to get more popular. Most people that don't use it do so because they don't know it yet, not because they don't like it or have no use for it. They've all encoutered the problem, but some live with it just because they don't know there is a solution.

Some weeks ago, I took a peek some weeks ago into a Belgian MP3 newsgroup too see what kind of stuff was being discussed there. Aside from the usual 37337 s(3N3 crap there was a complaint from someone that all those MP3's had a different volume and asked if there was a way to change the volume of an MP3.

One of the anwsers given to him was a pointer to MP3Gain, which, of course, immediately solved the problem completely and made for one more happy MP3 user.

At that point, I became completely convinced ReplayGain solves a [b]real problem.

--
GCP

Well Garf, to tell you the truth I'd be very surprised if you can pull this Vorbis RG off someway in order to have Xiph's blessing.
I was discussing at #vorbis about this, and it just seems that the discussion there always gets heated, or someone always gets upset for whatever reasons.

Anyway. What I gathered is that there's even conflict inside Xiph how RG should be implemented. Emmett would go for metadata, while Jack doesn't want RG even into metadata.
Emmett cares about RG but said that he doesn't care about it in large scale. Jack says he cares about RG, but I have no idea how much.

All in all, the situation even inside Xiph is not clear regarding RG. One thing they agree though is "not right now, maybe later".

My opinion is that your current suggestion won't get support from Xiph.

Yes. It is time to lay this discussion to rest. There will be no official support for ReplayGain for the time to come, both because of disagreement on all fronts about the how and because of a lack of complete infrastructure and time and willingness.

The unofficial support will get improved via the revised proposal.

At the time the Vorbis team works out their own official support, we can drop the unofficial support. At least there will be incentive to make the official support work at least as good as the current unofficial one.

--
GCP