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.

[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.

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.

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 :/

Originally posted by Dibrom 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?

--------------------

Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:http://www.rarewares.org

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

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

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:

QUOTE

[b]<Vakor> Dibrom: To set facts straight: we didn't have oggdec offered to us for inclusion in vorbis-tools, and we didn't reject it. I haven't seen the code, but as a general statement, an oggdec tool would be welcome.

We talked some more and he had this to say:

QUOTE

[b]<Dibrom> I don't really know the situation, but I'd find it kind of hard to believe that john33 didn't contact you guys <Vakor> Feel free to post something quoting me - I don't have the time or patience to use web boards.
<Vakor> Dibrom: well, he may have contacted someone else, but currently I seem to be the main vorbis-tools active maintainer, and I've not even heard it _mentioned_

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

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.

QUOTE

<xiphmont> A completely new tool might not be the right way to do it though.... :-(
<rjamorim> Humm...
<xiphmont> maintianing two seperate trees with identical features sharing most code, just for two different OSes, is a headache.
<xiphmont> Occasionally necessary, but eh.
<rjamorim> Well, the code at my page only sports the changes John made.
<rjamorim> I think the decoding engine is 100% standard ogg/vorbis libraries

(The discussion ended there)

I will contact Vakor now. Thanks for the info.

Regards;

Roberto.

--------------------

Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:http://www.rarewares.org

"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.

Originally posted by Emmettfish 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.

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).

QUOTE

[b]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.

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?

QUOTE

[b]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.

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?

QUOTE

[b]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.

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.

QUOTE

[b]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.

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.

QUOTE

[b]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.

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).

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):

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.....

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.

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.

Originally posted by Dibrom 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. :/

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

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.

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.

QUOTE

I would prefer a solution that doesn't require a change in the way that Vorbis handles tags.

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

QUOTE

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.

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.

QUOTE

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.

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?

Originally posted by Case 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.

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.

Originally posted by Dibrom 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. :/

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