Flaw in ReplayGain spec Options

[Garf]

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

The issue is combining replaygain and clipping prevention.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--
GCP

[Emmett_v2]

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