Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Flaw in ReplayGain spec (Read 27177 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Flaw in ReplayGain spec

Reply #50
Great!

back to the issue in hand... what are the vorbis people saying at the moment about RG tags?

Flaw in ReplayGain spec

Reply #51
Quote
Originally posted by sam

Also, storing a +/- could confuse a few: Does -6 mean I need to decrease the volume of this file by 6 to get to the 83, or does it mean this file is 6dB quieter then the 83 standard.


Since the tag is called 'gain' and not 'level', it should be obvious...

--
GCP

Flaw in ReplayGain spec

Reply #52
Quote
Originally posted by 2Bdecided
Great!

back to the issue in hand... what are the vorbis people saying at the moment about RG tags?


Beats me. I'm no longer willing to discuss this issue on IRC. If there are arguments against the proposal, they are free to discuss them here. Paradox said he would keep following this thread earlier on, so if he keeps his promise, maybe now is a good time for him to comment as CEO of Xiph. (Edit:I've emailed him and asked him to read up on the thread)

Discussing on IRC is tiring, troublesome to time and has been totally nonconstructive. Sometimes fallacies are thrown against the porposal that I cannot refute instantly at 3am in the morning. (Not to mention the annoyance of people putting their finger in their ears and starting to cry 'neener neener' against your arguments). Contrary to email, this board is open for anyones opinion and I think it's an excellent place to discuss this.

I'm glad we've settled how things should look. If I got it correctly, this is the way the tags look now:

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

Lear, if updating the tool is finished and debugging and testing done, please give Peter P (WinAmp) and zinx at xmms.org a ring and ask them to update their player plugins as well (and explain the changes needed); awaiting a Vorbis reaction, we will want to update the players that already support the old proposal in any case.

--
GCP

Flaw in ReplayGain spec

Reply #53
Quoth Garf:

"Beats me. I'm no longer willing to discuss this issue on IRC. If there are arguments against the proposal, they are free to discuss them here. Paradox said he would keep following this thread earlier on, so if he keeps his promise, maybe now is a good time for him to comment as CEO of Xiph."

I've kind of been hanging back, looking at what's been going on here, seeing the best way to go about getting replaygain implemented.

Here's my current problem:

I have a very small staff, and they're very busy working on 1.0 of Vorbis and the Vorbis spec. I think it's clear to even the most casual observer that although replaygain support is important and useful, there are other, more pressing needs at the moment. That's number one, and that's outside the realm of even discussing replaygain.

Number two, I still am not convinced that adding replaygain tags is the best solution to implement replaygain. I am convinced that it would be the easiest solution, but I am not convinced that it would be the right one. Let me go back to my original point a little bit.

1.0 (and the spec) is due to be published very soon. Implementing a quick-and-dirty solution for replaygain is likely not a good idea, for a couple reasons. One, it's not a good idea to define temporary solutions in a 1.0 release. Two, if we do something we're going to change later, that means that you'll be bugging your player authors twice.

Unfortunately, there are pressing issues for Vorbis that are more important than replaygain support. I'm aware that it's important to a lot of people (including myself), but we don't have the time to implement it in the best possible way. When we have the time to implement replaygain data (which will likely be in a metadata stream), it will be done, I promise.

I'm very sorry if people are let down by this, but it's what we have to do. For every ten people that are screaming for replaygain support, there are a hundred people screaming for a specification. People shouldn't be screaming at all, but they do, at us, all the time.

Please remember that we are basically volunteers. We work on this stuff full-time when we could easily go out and find well-paying jobs elsewhere. We do this because we love it, and because we think it's important. People tend to lose sight of the fact that we do good work, and we give it away.

I understand that a lot of the people in the current discussion want replaygain implemented because they want what's best for the format, and I appreciate that immensely. I agree with them, and when they take the time to openly discuss their needs without resorting to insults, it behooves me to listen. Thanks to all the helpful posters in this thread.

That's about all for now. I'll keep reading.

Emmett Plant
CEO, Xiph.org Foundation

Flaw in ReplayGain spec

Reply #54
First, thanks for the speedy reply!

Quote
Originally posted by Emmettfish

I have a very small staff, and they're very busy working on 1.0 of Vorbis and the Vorbis spec. I think it's clear to even the most casual observer that although replaygain support is important and useful, there are other, more pressing needs at the moment. That's number one, and that's outside the realm of even discussing replaygain.


I realize this; a full devotion of the devteam towards RG support is not for today or even the near or forseeable future. This is why I started working on it in the first place.

Quote
Number two, I still am not convinced that adding replaygain tags is the best solution to implement replaygain. I am convinced that it would be the easiest solution, but I am not convinced that it would be the right one. Let me go back to my original point a little bit. 
[/b]

I agree the tags are likely not the best place to store it - I already
stated that in the thread above as well.

Quote
1.0 (and the spec) is due to be published very soon. Implementing a quick-and-dirty solution for replaygain is likely not a good idea, for a couple reasons. One, it's not a good idea to define temporary solutions in a 1.0 release. Two, if we do something we're going to change later, that means that you'll be bugging your player authors twice.


There is a lot of sense in not wanting to release a temporary solution, but it should not be generalized. If that is the case, we might not release 1.0 with the unavoidable preecho problems as well. Better wait till we finish 2.0 with wavelets so we won't have to bug the player authors twice.

That is not what we want, is it?

A temporary solution makes sense when there is no real solution in sight for the forseeable future. If you want to attach warning signs to it 'WARNING TEMPORARY HACK', feel free to do so. But don't just shoot it down without proposing a sensible alternative.

I don't feel it justified to call the current proposal quick-n-dirty. The vorbis implemenation predates your involvement with Xiph and it is based on the by now quite matured work of David Robinson. It's a complete solution with as only drawback that the data is not stored in the best place imaginable - forcedly so, since there is no other place for now and for the time to come.

The temporary solution is already out there. ReplayGain has been in use with Vorbis for half a year now. It was unofficial at first, but since there was interest from the Vorbis side as well, it got semi-official with talks of support in the libs. It wasn't clear to me there was a problem with the current method until things erupted on IRC (that was after several core Vorbis developers emailed me they were ok with the proposed change, even). Thing went from 'we're ok with this and like it' to 'it totally sucks and should die ASAP'.

I'm now in the unfortunate situation that the tools and player support are already out there, the proposal being ok with Vorbis developers or not. That's not my fault - the reason it got adopted by the players was because the player authors _wanted_ it. For the same reason, bugging them to change it is no problem at this point. (Moreso because the changes are minimal and we wrote most code ourselves anyway)

I proposed a change to the temporary hack because I saw a problem with it. I can leave it unchanged and not support it any longer, but it's not going to die. The feature is too important for some users. It will stay in use until Xiph comes with its own official implementation that is at least as good. If that's going to happen, I would at least like the hack to be as clean as possible, hence the proposed change.

The disagreement on what info (album/track/peak) should be stored is a non-issue because of this. It is clear at this point Xiph does not support the current proposal as something official at all, so no agreement is strictly needed - the proposal will be replaced at some unspecified point of time in the future anyway.

At the point Xiph does its own ReplayGain support it will quickly become obvious what is needed or not - if the official support is significantly more problematic (or misses essential features) than the temporary hack (which, IMHO, will happen unless Monty revises some of his opinions) then I will leave it up to you to draw the obvious conclusions.

Considering the choice right now is between doing nothing and leaving a somewhat broken proposal out there, or correcting it and having allmost-but-just-not-completely-perfect support out there right now, which can work until Vorbis finishes ReplayGain support itself (i.e. not for _quite_ a while), I will have to choose the latter.

The only real problem that will result from this is that player authors will not be inclined to support the temporary hack taking this into account. Considering the two most important players (WinAmp/XMMS), which are the ones I use, have already adapted the temporarly proposal, it's not a big problem. The others can do as if they feel like it, or might be inclined to if user pressure to do so exists.

The net result will be that for most users Vorbis will effectively have ReplayGain support _now_, even if it is nonofficial.

The nice side effect is that there will be less pressure on the Vorbis team to finish their own implementation.

The only bad thing is that work is going to be duplicated to some extend. Not a problem for me, nor do I suspect it will be for Lear. As long as it is made clear to player authors the solution is temporary, it is completely up to them to go for it or not.

Quote
Please remember that we are basically volunteers. We work on this stuff full-time when we could easily go out and find well-paying jobs elsewhere. We do this because we love it, and because we think it's important. People tend to lose sight of the fact that we do good work, and we give it away.


You don't have to tell us that - most of the people that have been involved in this are in exactly the same situation, with the difference that they receive zip for their efforts.

--
GCP

Flaw in ReplayGain spec

Reply #55
Quoth Garf:

"I don't feel it justified to call the current proposal quick-n-dirty. The vorbis implemenation predates your involvement with Xiph and it is based on the by now quite matured work of David Robinson. It's a complete solution with as only drawback that the data is not stored in the best place imaginable - forcedly so, since there is no other place for now and for the time to come."

I didn't mean to imply that RG was quick-and-dirty, only the proposed implementation. This is a common theme, I'm finding. People assume that I don't like RG, that I think it's useless, that I've never tried it, etc. Balderdash. My primary concern is that the current proposed implementation puts data where data don't belong.

Let me repeat this again. I don't have a problem with replaygain. I think it's useful. My problem is not with the methodology used to do what it does, my problem is that the proposed implementation does not jive with our standard.

And one more time, for those who missed it. I think that replaygain serves a powerful and useful purpose. My problem is not with what it does or what need it serves, my problem lies in the proposed implementation.

I hope that's clear now.

There is a tremendous amount of work that needs to be done, and this particular issue is driving me to distraction. At the end of the day, I have to look at our mission statement and see where things fit. It's my job to facilitate and manage the creation, production and maintenance of Open Multimedia. That's my primary concern.

I feel that a lot of people don't recognize this, and they bang on the 'I want my favorite feature implemented right now' door, with little concern that there may be other things that are simply more important. They're like the Comic Book Guy on the Simpsons. If we don't implement what they want right away, it's 'Worst Codec Ever.'

I feel fairly secure that at the end of the day, the people who really want this feature will implement it themselves, for themselves. After all, they've been doing it for a while now already. This is great, but there is a driving desire to see RG implemented on a much larger scale. That's okay, and definitely understandable (it's useful), but it's not my primary objective.

Emmett Plant
CEO, Xiph.org Foundation

Flaw in ReplayGain spec

Reply #56
I have no wish to get heavily involved in this discussion, but one thing is clear to me. The current and, for the near future, proposed solution holds the data in a place and in a way that lends itself very readily to conversion at some later date. Since it also, so far as I can see, causes no real problem where it currently resides, it is surely a fairly elegant ,if temporary, solution?

Maybe I am misunderstanding something here and, no doubt, someone will point that out if it is the case, but since no other immediate solution seems to be on the table, this one works and can later be amended if appropriate without too much pain.

Flaw in ReplayGain spec

Reply #57
Quote
You don't have to tell us that - most of the people that have been involved in this are in exactly the same situation, with the difference that they receive zip for their efforts.


This is true, but sometimes a lot of people rule that out or just forget about it quite often.

I don't have much to say about ReaplayGain spec, it works either way for me.
budding I.T professional

Flaw in ReplayGain spec

Reply #58
Quote
Originally posted by Garf
Lear, if updating the tool is finished and debugging and testing done, please give Peter P (WinAmp) and zinx at xmms.org a ring and ask them to update their player plugins as well (and explain the changes needed); awaiting a Vorbis reaction, we will want to update the players that already support the old proposal in any case.


Well, the code passes a basic test now, but I guess some more testing would be in order, even though there isn't much new code.  I'll email them (john33 included) this weekend at the latest.

Flaw in ReplayGain spec

Reply #59
Quote
Originally posted by Emmettfish
Quoth Garf:
I didn't mean to imply ...[snip]... I hope that's clear now.


I have said at least three times now in this thread I agree the data is not put where it belongs, so you don't have to try to convince me of that in every post you write.

Quote
I feel fairly secure that at the end of the day, the people who really want this feature will implement it themselves, for themselves. After all, they've been doing it for a while now already. 


...and we will continue doing it, thank you very much ;-)

--
GCP

Flaw in ReplayGain spec

Reply #60
Quote
Originally posted by john33
I have no wish to get heavily involved in this discussion, but one thing is clear to me. The current and, for the near future, proposed solution holds the data in a place and in a way that lends itself very readily to conversion at some later date. Since it also, so far as I can see, causes no real problem where it currently resides, it is surely a fairly elegant ,if temporary, solution?

Maybe I am misunderstanding something here and, no doubt, someone will point that out if it is the case, but since no other immediate solution seems to be on the table, this one works and can later be amended if appropriate without too much pain.


Thank you for restoring my faith in mankind.

--
GCP

Flaw in ReplayGain spec

Reply #61
To Lear - Thanks.

And, to Garf - You're welcome!

Flaw in ReplayGain spec

Reply #62
Although my technical audio knowlege and programming abilities are not up to the level of most posting in this thread, I have read it with great interest. I would just like to ask why the following replay gain tag format is not preferrable to the four seperate tags format:

eg. REPLAYGAIN=trackpeak;trackgain;albumpeak;albumgain
eg. REPLAYGAIN=0.00000000;000.00;0.00000000;000.00

eg. REPLAYGAIN=1.23456789;-12.34;1.23000000;+02.00

It is still human readable, with the keyword REPLAYGAIN being enough for users new to replay gain to get more info on what the tag does. I don't see why the four values have to be labeled (or 'sub labeled'), most users will never edit them manually as text in the tag editor, and audiophiles would have no problem figuring it out. Whether you make the field size fixed (pos/neg sign required, zero padding, etc.) is really not that big of an issue, but if it were fixed it would IMO help to standardize the replay gain tag even further, just by setting some sort of template.

Thanks!

Flaw in ReplayGain spec

Reply #63
Quote
Originally posted by lijil

It is still human readable, with the keyword REPLAYGAIN being enough for users new to replay gain to get more info on what the tag does. I don't see why the four values have to be labeled (or 'sub labeled'), most users will never edit them manually as text in the tag editor, and audiophiles would have no problem figuring it out. Whether you make the field size fixed (pos/neg sign required, zero padding, etc.) is really not that big of an issue, but if it were fixed it would IMO help to standardize the replay gain tag even further, just by setting some sort of template.


1) easier to parse
2) field _must_ be editable in a tag editor that does not know about ReplayGain
3) field _cannot_ be fixed-size
4) field _cannot_ be dependent on exact formatting

--
GCP

Flaw in ReplayGain spec

Reply #64
This discussion on VorbisGain suggests there may be a lot more utility to the tags than just carrying bits of user information.

Has there been any thought of there being more than one type of tag?

I.e. 
- Variable tags
(such as the ones that exist now - act as labels attached to the music - casually editable by the average person and only for human consumption)
+
- Constant tags
(information of specialised interest to some users, and intimately related to the way the music is machine interpreted - could there be other tags (apart from gain) which could control the way the information is interpreted by a decoder here? - the information is only adjustable after software has opened a lock - thus it can't be casually changed by a novice (such as myself messing with the gain tags because I was fresh and innocent and thought they couldn't be important because they were amongst all those other editable tags that were purely cosmetic)

Flaw in ReplayGain spec

Reply #65
Quote
Originally posted by mijj
This discussion on VorbisGain suggests there may be a lot more utility to the tags than just carrying bits of user information.

Has there been any thought of there being more than one type of tag?


Sort of. There has been discussions about adding a metadata stream to Ogg Vorbis files, for storing data more suitable for machine interpretation, or that is otherwise unsuitable to store as a tag (such as lyrics, I guess). That would be a bit like the constant tags you suggest.

Flaw in ReplayGain spec

Reply #66
Quote
Sort of. There has been discussions about adding a metadata stream to Ogg Vorbis files, for storing data more suitable for machine interpretation, or that is otherwise unsuitable to store as a tag (such as lyrics, I guess). That would be a bit like the constant tags you suggest.

Yep, and it's more general than that.
People have wanted a general metadata stream for ages, but there have been no serious discussions about where it should go, what it should look like, and what it should contain. You can expect these discussions to be long, vitriolic, tedious, and almost completely pointless .
There is a need to define some information stream, particularly with ogg being used as an AVI replacement (including multiple audio streams, multi-language subtitles, etc.). Either something is hashed out quickly, or the people that are actually *using* the format (via the closed-source directshow filters) will just establish a de-facto standard, and we'll just have to live with it.

Flaw in ReplayGain spec

Reply #67
< ... mijj contributes with a confidence and confusion borne of innocence and ignorance ...>

... erm ... how about if you were able to include Java code as a hidden tag (and ignorable) - so you could enable a sort of user definable pre-processing facility.  E.g. use it to allow for scrambling and unscrambling voice messages.  ... allow calls to internet pages so you could be bugged by advertising while you play that particular Vorbis file. (.. erk!).  ... Use the Java code to generate event triggers based on the coded sound for synchronisation with external processes... etc.

Flaw in ReplayGain spec

Reply #68
Quote
Originally posted by mijj
< ... mijj contributes with a confidence and confusion borne of innocence and ignorance ...>

... erm ... how about if you were able to include Java code as a hidden tag (and ignorable) - so you could enable a sort of user definable pre-processing facility.   E.g. use it to allow for scrambling and unscrambling voice messages.  ... allow calls to internet pages so you could be bugged by advertising while you play that particular Vorbis file. (.. erk!).  ... Use the Java code to generate event triggers based on the coded sound for synchronisation with external processes... etc.


That would be very unsecure. People could start adding malicious Java code to their oggs and uploading them to FTPs. (Or sharing)

Flaw in ReplayGain spec

Reply #69
a question:

when turning on RG in mpc winamp decoder, it will turn down the volume even for the songs which doesnt have the RG tags (probably to some reference level?) which seems like a corect action, not the same for vorbis decoder which will play files without tags at the original 'loudness', why is that so?

p.s. in_vorbis.dll is v1.2 b22 and VorbisGain v0.30.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Flaw in ReplayGain spec

Reply #70
... and speaking of tags ...

... how come whoever-it-was decided not to include track and album rms value tags?  They could have been useful on playback too. (I think)

Flaw in ReplayGain spec

Reply #71
Quote
Originally posted by smok3
when turning on RG in mpc winamp decoder, it will turn down the volume even for the songs which doesnt have the RG tags (probably to some reference level?)

This is only true if you have over 14 dB headroom. At K-14 the volume will be identical with original.

Flaw in ReplayGain spec

Reply #72
I don't quite understand what the deal with the tags are:

Vorbis (and Xiph) do not wish to have the REPLAYGAIN_* tags be official tags, but why does this really matter? Are you suggesting calculating replaygain immediately after encoding (essentially putting calculation into oggenc)?

I would think that IF you were calculating right after encoding that wouldn't be needed. The encoder should simply encode the files, and once encoded a seperate program could calculate the replygain stuff. The seperate program could add the tags, and as long the player and plugin developers agreed to a standard, all would be well.

The original suggestiosn about changes to the tags were nice though, make it easier to read, and if someone were to download a file and notice the REPLAYGAIN tags they could easily get more information (except if you notice what people are sharing, most people don't even bother with doing ID3 properly)

Flaw in ReplayGain spec

Reply #73
I love how this thread keeps getting resurrected from the dead 

Where's rjamorim's Batman image when you need it?