Skip to main content
Topic: ReplayGain album gain problem (Read 9946 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ReplayGain album gain problem

Is Hydrogenaudio the right forum for discussions about Replay Gain?  If not, apologies.

I perceive a problem with the way Replay Gain computes album gain.  The analysis requires a priori knowledge of the tracks comprising the album.  However, if the listener selects only a subset of the tracks for a listening session, then the album gain will (in general) be wrong.  The listener might even delete a subset of the tracks, in which case the album gain will be permanently wrong.  It is not feasible to recompute the album gain on the fly because the analysis takes too long.  Has there been any consideration of this problem?

ReplayGain album gain problem

Reply #1
The question is if it really matters at all.

Think about it:  Album gain applies the same gain to all the files of the same album, so that overall, the loudness of the album as a whole reaches the target defined by replaygain.

This doesn't make all songs sound the same. If the album had softer songs and stronger songs, they will continue to be some softer and some stronger.

Now, if i remove the softer songs, you say that this new set of songs should have a lower album gain. But the question is: Why? To do what?
If you listen only to those songs, they will play stronger compared to the new analysis. But why worry? track gain and album gain values will probably differ with either old or new analysis.

If you listen to more albums, it isn't important at all, since the change from one album to the other is completely random (the song change from one album to another will change the album gain to who knows what).


Sincerely, Album gain is just a way to apply a reasonable gain but keeping the songs without gain changes inbetween, which would defeat especifically gapless albums/mixes. When changing from one album to another, there will usually be a discrepancy of gain (but hopefully of just a few dBs)



ReplayGain album gain problem

Reply #2
[quote author=[JAZ] link=msg=735774 date=1292444596]
The question is if it really matters at all.

Think about it:  Album gain applies the same gain to all the files of the same album, so that overall, the loudness of the album as a whole reaches the target defined by replaygain.

...

Now, if i remove the softer songs, you say that this new set of songs should have a lower album gain. But the question is: Why? To do what?[/quote]

Didn't you provide the answer in your response?  The purpose of album gain is to adjust the loudness of each album to a target defined by Replay Gain (or so that all albums play at approximately the same volume overall).  If I redefine an album by deleting all of its softer tracks, then the gain must be lowered or the album no longer plays at a volume consistent with the target defined by Replay Gain.  If album gain has any purpose, then surely it must be recomputed whenever the definition of the album changes.

ReplayGain album gain problem

Reply #3
If album gain has any purpose, then surely it must be recomputed whenever the definition of the album changes.

Then recompute it.  What you want is surely not how RG was intended to be used.

As someone who uses shuffle mode a lot, I am very satisfied with using album gain as it currently is.  Tracks intended to be played softly in the context of their original album remain soft and tracks intended to be played loudly in the context of their original album remain loud.  Speaking only for myself, this is exactly what I want.

To me it sounds as if you should be using track gain.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

ReplayGain album gain problem

Reply #4
I prune any tracks I don't like from my files, and try not to waste my time ripping them in the first place. This does lead to inaccurate album gain calculations because I'm only using a subset of the original recording, but I've found that it usually doesn't matter. The difference is usually quite small. Usually.

If you're buying/acquiring loose tracks and can't be sure they're from the same mastering and haven't been normalized, then you have no choice but to only use track gain.

ReplayGain album gain problem

Reply #5
Let's try this: Suppose that the original album contained two pieces, a Haydn symphony (quiet) and a Mahler symphony (loud).  Replay Gain computes an album gain that adjusts the average loudness of these two pieces so that it matches the average loudness of other albums.  Now, suppose that I decide to separate these disparate works into two albums as they don't really belong together in the first place.  I would like to preserve the relative volumes of the movements of each work -- which is why track gain is inappropriate -- but the average volume of each work ought to be adjusted as if each work originally resided on separate media.  I fail to see why this result would be an unreasonable expectation.  Otherwise, when I listen to a bunch of Haydn symphonies, one of them will be quieter on average than the others simply because it came from an album with a companion work that was loud.

ReplayGain album gain problem

Reply #6
I would simply RG them as I plan on using them.  Separate the Mahler tracks from Haydn tracks and compute album gain for each set.

Like mjb2006, I also occasionally prune tracks from albums, though I typically do so after they've all been RG-ed.  If I have a track or two from a compilation then I just use track gain, but I do make exceptions if the result isn't what I want.  Beatles tracks tend to sound much louder than other stuff in my collection after RG, so I normally bump them downward.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

ReplayGain album gain problem

Reply #7
What is unreasonable is to want some program to somehow determine for you when you are finished pruning any particular album. I have not yet understood why you just do not recalculate when you feel it necessary.

terry

ReplayGain album gain problem

Reply #8
Quote
What is unreasonable is to want some program to somehow determine for you when you are finished pruning any particular album. I have not yet understood why you just do not recalculate when you feel it necessary.


Well, yes.  That does seem unreasonable.  Of course, I never suggested that the program should have to do that, you did.  Perhaps you did not consider that the existing implementation of Replay Gain is not the only possible solution to the problem of loudness equalization.  I did not ask in my original posting how to deal with these situations with Replay Gain, I asked whether they had ever gotten any consideration.  I'm going to guess that the answer to that question is "No".

I also anticipated your suggestion by pointing out that it takes too long to recompute the album gain, but you may be more patient than I am.  Clearly what you and greynol suggested would work, but the solution is not a model of usability.  In general, I would select the tracks that I want to play and then, instead of hitting the play button, hit the recompute album gain button, wait a while, and then finally listen.  At best, I would partition the tracks into works (e.g., Haydn/Mahler) and then recompute.  I could live with that solution, but I don't like it.  How do your players work?  Is there a button for Replay Gain that you have to actuate to initiate the analysis?  If so, are you apprised when you encounter a track for which you forgot to perform the analysis?  I've been thinking that the analysis should take place while ripping or importing so that it is transparent.

A better solution to the album gain problem would be to perform the time-consuming operation, the analysis, once and store something about that analysis in the header.  The player could access the information for all relevant tracks prior to play to compute an appropriate album gain.  This approach could encompass every use case described in this thread and more.  A simplistic example, just to clarify, would be to make the album gain the average of the track gains.  Accessing the track gains and computing an average would take negligible time, but would make it possible to adapt to changing definitions of the album (or not -- greynol's preferred way of using shuffle would still work as well).  An approach that would actually work would be to store the energy measures for every frame and then merge that data for the relevant tracks prior to play, but the tables would be excessively large.  Feasible solutions probably exist, I just wondered what possibilities might have been considered and rejected.

ReplayGain album gain problem

Reply #9
Guess I missed all the nuance in the OP. I'll leave you to come up with a new format.

regards.
terry

ReplayGain album gain problem

Reply #10
I always thought the simplest solution was for the album gain to be the same as the track gain for the loudest track, though it was pointed out to me why this could be a bad idea.  As an example, suppose you have an album that has bonus material that is significantly louder than the rest.

Anyway, the way RG currently works, album gain is just a scan of all the tracks together as if they were one.

Considering that I do not listen to classical music, my point of view is limited, though I am pretty certain that the developer of RG does listen to classical music, in addition to many other things.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

ReplayGain album gain problem

Reply #11
I think you just hit it on the head.  RG in its current form probably works fine for pop almost all the time.  It may even work fine for classical a lot of the time.  Maybe the cases I'm worrying about are sufficiently rare that I should ignore them.

ReplayGain album gain problem

Reply #12
RG in its current form probably works fine for pop almost all the time.

Track gain will probably work fine for pop almost all of the time.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

ReplayGain album gain problem

Reply #13
The RG tags along with other tags in the file already provide sufficient information to achieve what the OP would like. Implementing it would have to be the responsibility of the player.

1. The TRACK_GAIN RG tag in effect defines the track's "native loudness".
2. The other tags in the file (ALBUM, ARTIST, etc) define the album that a track belongs to.
3. If the gain applied is to be dynamically determined according to whatever tracks happen to be queued, then the player can use the "native loudness" of the tracks in the playlist to adjust gain accordingly.

Whether any media player author deems the effort worthwhile would be up to them.

ReplayGain album gain problem

Reply #14
I am pretty certain that the developer of RG does listen to classical music
Yes. And the biggest problem is that RG cannot know how loud something is supposed to be. A Harpsichord is not as loud as a symphony orchestra. Album gain is just one crude way of getting context for a track - one way of "learning" whether it should be a bit louder or quieter than average. It's hit and miss whether it achieves this goal, as it depends entirely on the combination of tracks on an album.

As far as I can see, proper solutions to this problem require human intervention*. So if you don't like the automated results, change the RG tags in your own files to give the loudness your ears think is correct.

Cheers,
David.

* - or at least some artificial intelligence - now that would be fun - an algorithm that determines how loud different arbitrary unknown sounds should be.

ReplayGain album gain problem

Reply #15
Let's try this: Suppose that the original album contained two pieces, a Haydn symphony (quiet) and a Mahler symphony (loud).  Replay Gain computes an album gain that adjusts the average loudness of these two pieces so that it matches the average loudness of other albums.  Now, suppose that I decide to separate these disparate works into two albums as they don't really belong together in the first place.  I would like to preserve the relative volumes of the movements of each work -- which is why track gain is inappropriate -- but the average volume of each work ought to be adjusted as if each work originally resided on separate media.  I fail to see why this result would be an unreasonable expectation.  Otherwise, when I listen to a bunch of Haydn symphonies, one of them will be quieter on average than the others simply because it came from an album with a companion work that was loud.



This example doesn't work, sorry.  If you want the soft one to be with other soft songs, and the strong song with other strong songs, you clearly don't need album gain. Album gain tries to keep the relative volume of tracks, so if two different albums get the same album gain any two random songs of each album may have a different enough replaygain. Anything different would imply changing the gains between tracks.


To be more precise, What you are looking for is a different target gain depending on the style of the music. Just like 2bDecided has said, the algorithm doesn't know if a sound should be softer or stronger. It just does an analysis to try to make all them to an appropiate loudness (and defining loudness as it is perceived by the ear, not as a result of the amplitude).


Conclusion: If a bunch of soft songs have to target 89dB as album gain, they will be boosted compared to a bunch of soft and strong songs which have to target 89dB as album gain too. Replaygain only works for similar genres since one would need a dynamic target otherwise. (Side note: the standard can still work because what would change is the relative gain, not the target itself).

ReplayGain album gain problem

Reply #16
At the end of the day you still have a volume control.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

ReplayGain album gain problem

Reply #17
[quote author=[JAZ] link=msg=735907 date=1292527447]To be more precise, What you are looking for is a different target gain depending on the style of the music. Just like 2bDecided has said, the algorithm doesn't know if a sound should be softer or stronger.[/quote]
According to the proposed RG standard (http://wiki.hydrogenaudio.org/index.php?ti...n_specification) the RG scanning algorithm has two important ad-hoc parameters:

Quote
The signal is chopped into 50ms long blocks.

In order to understand the trade-off of this parameter cf. e.g. the second chapter of "The Scientist and Engineer's Guide to Digital Signal Processing" (http://www.dspguide.com/ch2.htm):

Quote
How many bins should be used? This is a compromise between two problems. As shown in Fig. 2-7, too many bins makes it difficult to estimate the amplitude of the underlying pmf. This is because only a few samples fall into each bin, making the statistical noise very high. At the other extreme, too few of bins makes it difficult to estimate the underlying pmf in the horizontal direction. In other words, the number of bins controls a tradeoff between resolution along the y-axis, and resolution along the x-axis.

The second important ad-hoc parameter of the proposed RG standard is the picking at 95%:

Quote
A good method to determine the overall perceived loudness is to sort the RMS energy values into numerical order, and then pick a value near the top of the list. For highly compressed pop music (e.g. Figure 7, where there are many values near the top), the choice makes little difference. For speech and classical music, the choice makes a huge difference. The value which most accurately matches human perception of perceived loudness is around 95%, so this value is used by Replay Gain.

Maybe a way out is to allow (experienced) users to overwrite these two parameters at scan time. Maybe it is possible to provide casual users with presets of combinations of these two parameters corresponding to certain music or production styles (call it profiles, if you like).

ReplayGain album gain problem

Reply #18
Maybe a way out is to allow (experienced) users to overwrite these two parameters at scan time. Maybe it is possible to provide casual users with presets of combinations of these two parameters corresponding to certain music or production styles (call it profiles, if you like).
That's not going to solve the symphony orchestra vs harpsichord problem, or the all soft tracks on an album vs loud and soft tracks on an album problem.

I'm not sure what problem it would solve*, but it could certainly cause a few. IMO

That's not to say that better values overall, or a better algorithm overall, couldn't be found - nothing is more likely  but if found, they should be adopted as defaults - not added as one of several possible user settings to confuse people and potentially break the standard.

Cheers,
David.

* - a tens of milliseconds analysis window and high percentile choice - these are used because of how the human ear judges loudness. They have little to do with musical genre.

ReplayGain album gain problem

Reply #19
If I understand the OP correctly, then I think I've seen something similar suggested elsewhere.  I think of the OP's request as a "playlist RG", separate from track and album RG.  the "playlist RG" would be calculated on-the-fly and saved just in memory, not written as a third RG tag.  Or not.  I like the idea in general.  One of the major points in having an album and a track RG to begin with was to accommodate listener playback preferences, so a "playlist RG" would seem to be consistent with aligning with playback preferences.

ReplayGain album gain problem

Reply #20
That's assuming that the tracks in your playlist have comparable volume without RG.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

ReplayGain album gain problem

Reply #21
A PlaylistGain value, calculated in the same way as the Track and Album values, would maintain the (presumably unwanted) differences in loudness between different CDs. That can't be useful! Just disable RG if you want that functionality.

However, if you wanted to, you could figure out an algorithm which looked at the album gain of each CD included in the playlist - and for each CD, look at the track gains of those tracks included, look the track gains of those tracks not included, and use this data to make a semi-intelligent guess as to what a sensible "adjusted" album gain might be. Then use that for those tracks included in the playlist from that CD.

The calculation needs to be biassed - if the quieter tracks have been removed, it's unlikely the album gain needs to go down - but if the louder tracks have been removed, it's possible the album gain needs to go up.


I honestly can't figure out if this is useful or not. It sounds like an approach to make album gain less useful IMO, in a situation where ether the real album gain would be better (if you want intentionally quieter tracks to stay quieter), or track gain would be better (if you want all tracks to be about the same loudness)/

Cheers,
David.

ReplayGain album gain problem

Reply #22
Beatles tracks tend to sound much louder than other stuff in my collection after RG, so I normally bump them downward.
I don't really understand why this should be the case. Can you give from your collection a popular song and/or genre which sounds noticeably quieter than a Beatles tune when both are track-replayGained correctly?

Chris
If I don't reply to your reply, it means I agree with you.

ReplayGain album gain problem

Reply #23
Pretty much everything in my collection of Fusion, Rock and Metal.  The closest artist I have to the Beatles would be The Rolling Stones, I suppose.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

ReplayGain album gain problem

Reply #24
It sounds to me like the best solution for 3beezer is just to use Album Gain, but tag his music differently.

I did this myself with my classical music; I have a 5-CD collection of Beethoven's 9 symphonies, and instead of leaving them tagged as all part of the same multi-disc album (like I do with Pink Floyd's "The Wall", for instance), I tagged them as 9 distinct albums, each with their own distinct Album Gain value. I think 3beezer would be best off by doing something similar with his Hadyn/Mahler CD.

 
SimplePortal 1.0.0 RC1 © 2008-2019