PDA

View Full Version : Positive ReplayGain and Clipping



cliveb
2006-12-05, 02:55
This is a question about those cases where a file has a positive ReplayGain requirement (typically only found on classical music). Suppose a file has these tags:

replaygain_track_gain = +2.00dB
replaygain_track_peak = 0.95

The peak level of 0.95 represents a level of about -0.45dB, so the maximum volume adjustment that can be applied without clipping is about +0.45dB. If the full +2dB adjustment were applied, severe clipping would result. Does the Squeezebox firmware take note of this and set the volume adjustment accordingly, or would it just apply the full +2dB and cause clipping?

marsboer
2008-12-08, 00:31
I have the same question for Squeezecenter v 7.2.1.

Does it take the REPLAYGAIN_TRACK_PEAK and REPLAYGAIN_ALBUM_PEAK values into consideration when applying replaygain to avoid clipping (that's what they are there for)

If not why not, the logic should be quite simple. Maybe something like this (logically wise, not the code of course):

IF ( (-20*LOG(REPLAYGAIN_*_PEAK) < REPLAYGAIN_*_GAIN )

THEN
REPLAYGAIN_*_GAIN = -20*LOG(REPLAYGAIN_*_PEAK)

ELSE
REPLAYGAIN_*_GAIN = REPLAYGAIN_*_GAIN

cliveb
2008-12-08, 02:03
I have the same question for Squeezecenter v 7.2.1.

Does it take the REPLAYGAIN_TRACK_PEAK and REPLAYGAIN_ALBUM_PEAK values into consideration when applying replaygain to avoid clipping (that's what they are there for)

No, it doesn't take these values into account (even though they are in the Squeezecenter database). Positive replaygain tags can cause clipping. I reported this over a year ago. See http://bugs.slimdevices.com/show_bug.cgi?id=5119.

I am a little disturbed by some of the comments made in response to that bug report - it seems that until Sean added his note on 08/07/24, nobody at Slim Devices seemed to understand why it was a fundamental flaw that ought to be put right. But even now it's targeted for "future" rather than any particular release. My guess is that it needs to be fixed in the firmware.

In the meantime, you can amend the values stored in the database to prevent clipping - the necessary SQL to run is in one of my followup comments.

Nonreality
2008-12-08, 02:27
No, it doesn't take these values into account (even though they are in the Squeezecenter database). Positive replaygain tags can cause clipping. I reported this over a year ago. See http://bugs.slimdevices.com/show_bug.cgi?id=5119.

I am a little disturbed by some of the comments made in response to that bug report - it seems that until Sean added his note on 08/07/24, nobody at Slim Devices seemed to understand why it was a fundamental flaw that ought to be put right. But even now it's targeted for "future" rather than any particular release. My guess is that it needs to be fixed in the firmware.

In the meantime, you can amend the values stored in the database to prevent clipping - the necessary SQL to run is in one of my followup comments.
For some reason they have had problems understanding replay gain. If you have the Itunes version soundcheck, they just add it to the replay gain, this doubles the replay gain, not right. It has been put off forever. Just like not using the peak value figure for avoiding clipping. I'm hoping they fix both these issues soon as they are important. Other than that they have done a fine job as far as I'm concerned with the program.

Moonbase
2008-12-08, 05:53
If you have the Itunes version soundcheck, they just add it to the replay gain, this doubles the replay gain, not right. […] I'm hoping they fix both these issues soon as they are important.
I second that. Important. I’d wish for
Not double-applying RG if both SoundCheck & RG tags exist. (Some people have both tags, RG for »normal use« and SoundCheck for using the same files on iTunes/iPod!) If both exist, use RG.
Correctly applying (non-clipping) RG (even if positive).
Probably an option to switch clipping prevention on/off (like other players have).
I’d also suggest having an adjustable »default gain« setting for files that don’t contain RG/SoundCheck tags (i.e., -6 dB default, adjustable). Winamp has that and I liked it a lot (before all my files were correctly RelayGained).

marsboer
2008-12-08, 09:37
Bad news. This basically means that the replay gain feature is useless when used with Squeezecenter.

Example:

One of my lossless FLAC files has a REPLAYGAIN_TRACK_GAIN at +8,52 and REPLAYGAIN_TRACK_PEAK at 1. This peak value means that there is no more room for digitally increasing the volume without clipping.

cliveb
2008-12-08, 10:15
Bad news. This basically means that the replay gain feature is useless when used with Squeezecenter.

Example:

One of my lossless FLAC files has a REPLAYGAIN_TRACK_GAIN at +8,52 and REPLAYGAIN_TRACK_PEAK at 1. This peak value means that there is no more room for digitally increasing the volume without clipping.
It's a bug for sure, and some people would classify it as serious.

But to conclude that it's *useless* with Squeezecenter is perhaps going a bit over the top. The vast majority of non-classical albums aren't affected. What's more, there's a simple workaround (described in the bug report) to adjust the gain values in Squeezecenter so as to avoid clipping. IMHO it's still a useful facility.

marsboer
2008-12-08, 10:25
It's a bug for sure, and some people would classify it as serious.

But to conclude that it's *useless* with Squeezecenter is perhaps going a bit over the top. The vast majority of non-classical albums aren't affected. What's more, there's a simple workaround (described in the bug report) to adjust the gain values in Squeezecenter so as to avoid clipping. IMHO it's still a useful facility.

Maybe a bit. But this means that I can't trust that the track will be played back without clipping, which in my case means that it can't be used (I am a high-end hi-fi nerd :) )
Even though there is only some rather small percantage of my collection that will be affected I still think it's a rather stupid (and serious) problem when it seems to be so easy to fix it.

And the "temporary" fix could have been nice if it had been executed automatically, but since I must do this after EVERY rescan it's not a working solution for me.
Maybe the best solution would be to manually edit the RG values in the tags to avoid that ANY software/hardware plays it back with clipping without wondering if they care about the PEAK tags or not.
But this would of course mean a lot of unnecessary work.

Mnyb
2008-12-08, 11:28
If you don't have a bugzilla log in get one and vote for the bug.
More voters more attention.

This is an important bug that involves core functionality of the product.
It's ability to playback files (correctly without introducing errors).

There are some other disturbing bugs regarding that, that needs more attention to some OGG bugs i voted for to and possible others.

So voting is a way to have influence.

Can someone log a bug on nonrealitys issue with soundcheck combined with RG ?
I have not yet (for obvious reasons) any files with neither RG or Soundcheck.
Therefore I can not provide any examples or faultracing, but i will vote if the bug is filed.

Moonbase
2008-12-08, 16:37
Maybe the best solution would be to manually edit the RG values in the tags to avoid that ANY software/hardware plays it back with clipping without wondering if they care about the PEAK tags or not.
I wouldn’t go for a »workaround« that affects correct data (i.e., your RG tag values). Instead, I’d try to influence the party that »does it wrong« to correct it. And *maybe* try to live with either some clipping or the DB correction stuff for a short while.

The Good Thing: RG isn’t hard to understand and both problems (avoid clipping and don’t apply RG twice) should be *really* easy to fix, so it can’t be long until it’s fixed if they hear us. Fortunately, most of it is software (and good design) anyway, so things can quite easily be fixed. Also, turnaround time for fixes and improvements seems quite fast here ;-)

Let’s go vote for the bugs. (And I also promise to get an account now.)

marsboer
2008-12-09, 01:28
I have now voted for the bug. I also wrote a comment as it seems to me that they have some troubles grasping the replaygain peak vs gain concept.

cliveb
2008-12-09, 02:20
And the "temporary" fix could have been nice if it had been executed automatically, but since I must do this after EVERY rescan it's not a working solution for me.
I agree that if you tend to do lots of rescans it is a pain to remember to do it manually.

In theory it should be possible to add the updates to SqueezeCenter's SCHEMA_OPTIMIZE.SQL file and have it executed automatically. But I've tried that (on a Windows 2000 machine) and couldn't get it to work. (If anyone reading this knows how to get statements added to that file to be executed, I'm all ears).

didbox
2008-12-10, 04:51
Just to inform you that I voted for the bug

marsboer
2008-12-12, 01:29
It seems that someone at Slimdevices finally noticed!
Bug has been updated with targetet milestone for a fix in 7.3.1.

Nice!

cliveb
2008-12-12, 06:55
It seems that someone at Slimdevices finally noticed!
Bug has been updated with targetet milestone for a fix in 7.3.1.
Yes, but...

The affected component has been changed from hardware players to SqueezeCenter. That implies they plan to fix it at the server end. Assuming that SqueezeCenter tells the player how much volume adjustment to apply (based on the values stored in the database), then it is probably a very simple fix.

However, there are additional subtleties. Sean's comment (made in July) shows that he understands that if there is also some digital attenuation at the player, then this should be factored into how the replaygain may be adjusted. I mentioned this as a possible "nice to have" in my original bug report. I'm not convinced the other Slim Devices folks have taken this on board.

What follows is speculation on my part, and it may be completely wrong. But from the evidence available to me, it makes sense:

Firstly, it's my understanding that the digital volume control is done in the player firmware. It must be, because we know there are different loudness envelopes in different firmwares. Since the web interface also responds to changes in the volume, presumably the player reports back to SqueezeCenter when the volume is changed. Or perhaps the server tells the player what setting (in terms of 0-100) it should set its volume. But it seems clear that only the player's firmware is in a position to know what actual dB attenuation a given setting represents.

Therefore, if we want to take into account the digital volume setting when deciding what to do with replaygain, it can only be done in SqueezeCenter if it knows the dB attenuation in the player. But unless SqueezeCenter knows the volume envelopes of all firmwares for all player types, it's in no position to do this.

My conclusion is that in order to do a "full" fix of this issue, it needs to be done in the firmware. I would very much like to be wrong about this.

marsboer
2008-12-12, 10:07
For my use that is no problem as I use a separate pre-amp with the volume locked at full volume.

I do however fail to see how the signal may clip as you can only lower the volume on the player side after the signal has bin lowered to a level where it's non-clipping on the server-side. Could you please explain the possible problems that may occur in more detail?

andyg
2008-12-12, 10:22
Yeah I'm interested in this bug now after running into a really bad case of clipping yesterday due to a combination of this bug and wrong gain tags.

I think we'll start by implementing the gain+peak calculation. I'm not sure worrying about the player volume is that important.

Moonbase
2008-12-13, 17:52
Player volume (hopefully) shouldn’t play a big role here. It must be taken into account that we might want to stream synced to more than one player, so the base stuff should be done before, as lightweight as possible, and preferably only once. (Allowing to generate one »corrected« signal and distribute that to all players involved, thereby reducing computing overhead in the server. Don’t know if this is feasible with the current architecture.)

A digital signal has only so many bits of resolution, so one question might be where to apply a loudness change: At the start of the chain (thereby reducing the number of usable bits in the »signal«), or at the end of the chain (thereby being able to transport the full dynamics of the signal and somehow tell the destination DAC to »reduce/increase by x«).

Probably a decision that needs to be based on the current hardware/firmware possibilities.

Added some further comments to the bug.

cliveb
2008-12-14, 07:42
Player volume (hopefully) shouldn’t play a big role here. It must be taken into account that we might want to stream synced to more than one player, so the base stuff should be done before, as lightweight as possible, and preferably only once. (Allowing to generate one »corrected« signal and distribute that to all players involved, thereby reducing computing overhead in the server. Don’t know if this is feasible with the current architecture.)
Hang on a minute. My reading of what you've said here suggests to me that you're proposing that the server should apply ReplayGain to the audio samples prior to sending it to the players. If I've misunderstaood what you're saying, my apologies. If however that is what you're saying, then this is absolutely, unequivocally the wrong way to do it. The audio samples *must* be sent to each player unmolested, for a variety of reasons:

1. Some players might have ReplayGain enabled, others not. Some may want to use track gain, others album gain. You can't apply the ReplayGain at the server end once for all clients.
2. The ReplayGain adjustment (which is done in the digital domain) should be applied after the signal has been widened to 24 bits within the player (in order to preserve resolution). If it's done in the server, you'd have to widen it to 24 bits, which might involve on-the-fly decoding to WAV, widening and either re-encoding back to FLAC or acceptance of increased network bandwidth requirements.
3. Some of us run SqueezeCenter on low-power servers, which may not have the CPU available to perform all this stuff at the server.
4. There may be some more reasons I've not thought of.

Mnyb
2008-12-14, 07:56
Hang on a minute. My reading of what you've said here suggests to me that you're proposing that the server should apply ReplayGain to the audio samples prior to sending it to the players. If I've misunderstaood what you're saying, my apologies. If however that is what you're saying, then this is absolutely, unequivocally the wrong way to do it. The audio samples *must* be sent to each player unmolested, for a variety of reasons:

1. Some players might have ReplayGain enabled, others not. Some may want to use track gain, others album gain. You can't apply the ReplayGain at the server end once for all clients.
2. The ReplayGain adjustment (which is done in the digital domain) should be applied after the signal has been widened to 24 bits within the player (in order to preserve resolution). If it's done in the server, you'd have to widen it to 24 bits, which might involve on-the-fly decoding to WAV, widening and either re-encoding back to FLAC or acceptance of increased network bandwidth requirements.
3. Some of us run SqueezeCenter on low-power servers, which may not have the CPU available to perform all this stuff at the server.
4. There may be some more reasons I've not thought of.

Clive is correct (i think) when this works i plan to maybe put it into use on my kitchen player but not my hifi player.

jeffmeh
2008-12-14, 11:46
Perhaps I am confused here, but I would think that a server-side fix could be implemented as follows:

If the file has no replaygain tags, do nothing.

Else, if the file has replaygain tags, calculate from the track peak and track replaygain whether the adjustment will make the track clip. If it will, replace the replaygain with the maximum possible value that will not cause clipping. Perform the same function for the album replaygain.

Send the file along and let the player apply album, track, or no replaygain based upon its settings.

I believe that this will not be particularly resource-intensive on the server, because it really only has to perform the calculation when the replaygain value is positive.

Are there other ways to apply positive gain in the digital domain other than through a replaygain adjustment? Unless we are applying positive digital gain we cannot cause digital clipping (bit overflow), correct? Digital clipping may have occurred earlier in the recording chain, and we may have "flat" peaks, but that damage is done, and whatever information we have left by definition fits within the 16 bits we have (or 24, or 48, or whatever the file contains). Am I missing something here?

marsboer
2008-12-14, 13:14
I don't really se the problem unless it's a problem today already.

Everything should still work as before, the only thing is that the replay gain processing engine should see gain tags adjusted to be non-clipping instead of the real gain tags.

How is this done today is the real question!

If the file is sendt to the receiver before replay gain processing is applyed this is a good thing. The only different thing should then be that the Squeezecenter server is adjusting the gain tags before it is sent to the receiver, so that the receiver sees the non-clipping gain tags not caring if it's adjusted or not and applyes the replaygain logic as usual.

As I can see, this is a server operation to do, and everything will still function as they always have if my logic is correct, even though the receiver is doing the real work applying the gain.

If however the operation is already done at the server today, i still don't see the problem as no one has complained yet, the only difference will still be that the replay gain is adjusted before processing.

If they however change the whole process and location of the process as it is today then it seems a bit strange and unnecessary.

cliveb
2008-12-14, 13:51
Send the file along and let the player apply album, track, or no replaygain based upon its settings.

I believe that this will not be particularly resource-intensive on the server, because it really only has to perform the calculation when the replaygain value is positive.
Yes, quite so. The server can do a trivial calculation to limit positive RG value so as to prevent clipping, and then send that adjusted RG value to the player instead of blindly sending the original RG value. There is no argument about this.

What I think Moonbase was proposing was that the server should actually apply the RG value and alter the audio samples before they are sent to the player - that's what I was objecting to (in the strongest possible terms).

However, as I said in an earlier post (http://forums.slimdevices.com/showpost.php?p=369178&postcount=15), the presence of attenuation via the player's digital volume control adds additional subtleties. If we want to take that into account and end up with a "gold standard" solution, then as far as I can make out it can only be solved in the player's firmware.

I'm fairly relaxed on this issue. I certainly wouldn't want to insist that the "gold standard" be implemented if it were to seriously delay getting the basic problem fixed. I'd be happy with a simple server side fix that just reins back a positive RG value on the assumption that the player will be at 100% volume.

CatBus
2008-12-14, 16:28
Not to throw a monkeywrench into this whole discussion, but couldn't SqueezeCenter quickly scan its entire database for the maximum amount it will need to scale back positive ReplayGain values, and then apply the same adjustment to *ALL* tracks?

Upside: all tracks/albums would again have the same volume, and you wouldn't have to worry about one album seeming quieter than the rest because of clipping-avoidance.

Downside: everything could get very quiet, perhaps so quiet that some small powered speakers wouldn't be able to compensate and achieve the same volume.

Sounds like a desirable user option to me, though.

marsboer
2008-12-14, 16:43
CatBus:
You have misunderstood the whole concept of replaygain.
Adjusting all tracks with the same gain will result inn the exact same volume differences between tracks as you would get with no replaygain.

Replaygain is not the same as real playback volume. It's a value that says how much the volume should be adjusted on each track to give the impression of the same volume between tracks relative to a given reference RMS level (89db)

In other words, replay gain is only relative to each tracks own RMS volume and therefore it must be different from track to track with different overall volume to have any function.

CatBus
2008-12-14, 16:46
Oops I guess I wasn't clear.

Let's say you have three albums. One with -2 album gain, one with -4 album gain, and one with +2 album gain. The +2 album gain needs to be trimmed back to +1 to avoid clipping.

Why can't we also trim back the other albums to -3 and -5 respectively?

i.e. we're changing the reference level to below 89dB...

jeffmeh
2008-12-14, 17:46
Yes, quite so. The server can do a trivial calculation to limit positive RG value so as to prevent clipping, and then send that adjusted RG value to the player instead of blindly sending the original RG value. There is no argument about this.

What I think Moonbase was proposing was that the server should actually apply the RG value and alter the audio samples before they are sent to the player - that's what I was objecting to (in the strongest possible terms).

However, as I said in an earlier post (http://forums.slimdevices.com/showpost.php?p=369178&postcount=15), the presence of attenuation via the player's digital volume control adds additional subtleties. If we want to take that into account and end up with a "gold standard" solution, then as far as I can make out it can only be solved in the player's firmware.

I'm fairly relaxed on this issue. I certainly wouldn't want to insist that the "gold standard" be implemented if it were to seriously delay getting the basic problem fixed. I'd be happy with a simple server side fix that just reins back a positive RG value on the assumption that the player will be at 100% volume.

I absolutely concur with your objection.

I'm not really clear on the problem with the attenuation via the player's digital volume control. I would expect this to be additional attenuation, after replaygain is applied. Is that not how it works today?

Moonbase
2008-12-15, 01:05
@ cliveb, jeffmeh, marsboer:
Sorry if I was too ambigous regarding where RG should be applied. If we know that we have something »at the receiving end« that can do it, we should do it there, since the receiver might well have some 24-, 48- or 96-bit DAC that of course could apply changes much more »lossless«. And without hogging all server resources.

I also very much agree with the possibility of a decision on a per-player basis. (Missing it on remote streams though—I often listen to my music while working and use Winamp or xmms for that.)

I found that this actually pretty much is how SC/SB combos work already.

The reason for maybe elaborating too much on general principles was maybe that
I tend to see all standpoints, try not to forget a real-world possibility. (Over 30 years in the business affect the brain ;-)
I also tried using a »remote stream«, i.e. hooking Winamp to SC. Which will apparently not allow RG adjustment. (That’s why I thought about doing something on the server end for these cases. Almost every cheap software player can do that nowadays, so I expected it not be too much overhead for these cases.)
I have been working a lot in the broadcasting area during the past years, this might have influenced my writing a little. (Need to do all processing before signal gets »on air«.)
Frankly, I’m quite new to this product, so I haven’t had the time to study each and every aspect of it. (Actually missed how much RG stuff was already implemented.)

Anyway, sometimes a good thing to »re-invent the wheel« again without being influenced, and then compare the results.

So, my apologies if I offended anyone by stating the obvious again. I guess we pretty much agree, after all.

cliveb
2008-12-15, 01:31
I'm not really clear on the problem with the attenuation via the player's digital volume control. I would expect this to be additional attenuation, after replaygain is applied. Is that not how it works today?
The simplest way to explain is probably with an example. Suppose you have a file that peaks at -3dB and has a replaygain value of +6dB. This would clip if the RG value is blindly applied (as at present). So the simple solution is back off the RG to +3dB. And this could easily be done at the server end.

But suppose the player's digital volume control is set to -4dB. That would put the file's peak at -7dB. So there is now enough headroom to apply the full +6dB of replaygain. If the player's volume was set to -2dB, there's room to apply +5dB of the RG. I hope you get the picture.

So, you may ask, why can't *this* calculation be done at the server end? I don't know for sure, but I believe it can't because although the server knows what volume setting the player has in terms of the 1-100 scale, I don't think the server knows how that setting maps to a specific dB attenuation. We know that the characteristics of the volume control varies between different firmware releases (and possibly between different player models).

The question is: does SqueezeCenter have a way of discovering the dB attenuation for attached players? If it can, then what I previously described as the "gold standard" implementation for replaygain can be done entirely inside SqueezeCenter. If not, then it would need firmware modifications.

marsboer
2008-12-15, 05:27
The simplest way to explain is probably with an example. Suppose you have a file that peaks at -3dB and has a replaygain value of +6dB. This would clip if the RG value is blindly applied (as at present). So the simple solution is back off the RG to +3dB. And this could easily be done at the server end.

But suppose the player's digital volume control is set to -4dB. That would put the file's peak at -7dB. So there is now enough headroom to apply the full +6dB of replaygain. If the player's volume was set to -2dB, there's room to apply +5dB of the RG. I hope you get the picture.

So, you may ask, why can't *this* calculation be done at the server end? I don't know for sure, but I believe it can't because although the server knows what volume setting the player has in terms of the 1-100 scale, I don't think the server knows how that setting maps to a specific dB attenuation. We know that the characteristics of the volume control varies between different firmware releases (and possibly between different player models).

The question is: does SqueezeCenter have a way of discovering the dB attenuation for attached players? If it can, then what I previously described as the "gold standard" implementation for replaygain can be done entirely inside SqueezeCenter. If not, then it would need firmware modifications.

Wouldn't this lead to some unwanted behaviour. It would at least annoy me when I lower the volume on my Transporter and the volume is not reduced because all it does is to fill inn the non-clipping headroom. So I practically have to reduce the amount of volume more than the difference between REAL replay_gain and CALCULATED replay_gain to really get lower volume. This will of course only be a problem in the upper volume levels, and the persons who are using the volume control are most likely to be well below maximum volume when listening so they won't notice it in a big way.

cliveb
2008-12-15, 05:47
Wouldn't this lead to some unwanted behaviour. It would at least annoy me when I lower the volume on my Transporter and the volume is not reduced because all it does is to fill inn the non-clipping headroom.
That's a fair point, and certainly it is a downside. Maybe whether digital volume control is incorporated in the adjustment calculations should be a user option. But now we're getting dangerously into creeping elegance territory - which is the enemy of getting things done.

Here's my position. There's currently a bug that can cause clipping. It needs to be fixed. If taking account of the digital volume control when making the fix is easy, then it makes sense to include it, perhaps with a user option to switch it off. On the other hand if it makes the fix complex (eg. lots of firmware changes), then I'm happy to see that aspect ignored or deferred to a later release.

jeffmeh
2008-12-15, 07:34
Clive, thanks for the example. I understand.

If the player's digital attenuation were incorporated into the replaygain adjustment, I would expect that if the user were to increase the volume mid-track, then he could cause clipping.

To continue with your example:
- File peaks at -3dB, replaygain is 6dB, player volume -2db.
- The basic "no-clip" replaygain is 3dB. The player-specific "no-clip" replaygain is 5dB.
- User queues the track, SC sends replaygain of 5dB. While track is playing, user increases player volume to -1dB. Track clips.

I do not think it desirable to allow the user to introduce clipping with the player volume control, so I would not really be in favor of this.

That being said, if it is simple to implement, optional, and defaults to off, I would have no problem with it, lol.

cliveb
2008-12-15, 09:32
Clive, thanks for the example. I understand.

If the player's digital attenuation were incorporated into the replaygain adjustment, I would expect that if the user were to increase the volume mid-track, then he could cause clipping.

To continue with your example:
- File peaks at -3dB, replaygain is 6dB, player volume -2db.
- The basic "no-clip" replaygain is 3dB. The player-specific "no-clip" replaygain is 5dB.
- User queues the track, SC sends replaygain of 5dB. While track is playing, user increases player volume to -1dB. Track clips.
Indeed. That's another reason why to incorporate the digital volume control into the calculations, it probably needs to be done in the firmware - which could re-calculate while playing the track when the volume is changed.

The more this gets analysed, the trickier it seems that incorprating the digital volume control would be. Probably the safe option is to just forget about it - in which case the fix can be done purely in SqueezeCenter, which ought to be much easier than fiddling with the firmware.

CatBus
2008-12-15, 21:26
For those not tracking this bug closely, it looks like a server-side solution has been implemented, which is certainly a big improvement.

marsboer
2008-12-16, 01:22
I looked at the code and it seems to me that they have just added this no-clip check at the end of their original replaygain engine before replaygain is executed. This is the correct way to handle this in my opinion as everything should stay the same as before functionality wise.

andyg
2008-12-16, 07:10
Yep it was a very simple fix. The gain value sent to the player with each track is just reduced if it would clip.

cliveb
2008-12-17, 05:30
Yep it was a very simple fix. The gain value sent to the player with each track is just reduced if it would clip.
I saw your comment in the bug report that it's fixed in "change 24314". Is this fix included in the latest nightlies, or would I have to download some Perl source and manually replace the files in SqueezeCenter? If the latter, are there any special considerations needed for Windows?

(I'm approaching this update with some trepidation, as I'm still running SC7.0 at present - not had a reason to upgrade it until now).

schiegl
2008-12-17, 05:47
It should be included in the current nightlies - although you may wait for a possible "regression" to be handled first (see bug 10355 (http://bugs.slimdevices.com/show_bug.cgi?id=10355))

kind regards,
Markus

Moonbase
2008-12-17, 18:29
Just in case someone wants to verify or play around with test cases, I have attached the Excel table which I use to see if I’ve programmed stuff correctly. (Uses calculation as of SC 7.3-24330, 2008-12-17.)

Zipped, this forum doesn’t allow .xls.

Change looks great, by the way. Kudos for getting and fixing this!

---

Two more things to ponder about a little:

1. If a file has no RG but a peak above 1.0, what can/should be done to prevent clipping—if anything?

2. Since we are mainly fighting against artifacts from (lossy) psychoacoustic compression here (lossless and CD won’t have peak above 1), what could or should be done against »loudness jumps«?

Basic RG was once »invented« to prevent unwanted loudness jumps in music, as was (and is) done in the broadcasting industry with the intent to let all listeners to TV or Radio Stations keep their loudness setting the same all the time. Which is nowadays sadly misused by TV ads, but that’s another story. RG originally used a »reference level« of 83 dB SPL (Sound Pressure Level), which is a comfortable loudness for radio and TV. Nowadays, 89 dB SPL is mostly used for RG.

WAV and FLAC, being lossless, won’t show a peak above 1.0, because 1 is »full scale«, i.e. 0 dB FS. (Using 16-bit CD audio data, the smallest possible sample would be around -96.3 dB FS.)

MP3s can well have peaks above 1, since unfortunately, psychoacoustic coding of heavily limited audio data (as is usual in Pop/Rock music) can lead to sample values larger than digital full scale upon decoding. I’ve seen peak values of 1.7 and above!

When applying a »brute-force no-clipping approach« (like we now do), it will of course never clip but probably do very audible loudness jumps when playing mixed music (i.e., not from one album and not using RG/Album). This has probably to be checked and listened to some sample files. RG was mainly invented to overcome the problem of audio sources (CDs) not having an agreed-upon standard loudness, not to repair whatever lossy compression leaves us with.

Depending on the psycho-acoustic model (and filters) used when compressing, the actual peak value we get is very dependent on the audio content. For example, one cymbal can force a high, but short »peak« when decoding the audio, so we would drastically reduce the overall loudness! (Which, again, would not happen with a lossless file; another reason towards using FLAC or TAK or the like.)

On his old ReplayGain page (http://replaygain.hydrogenaudio.org/player_clipping.html), David Robinson says:

»The audiophile user will not want any compression or limiting on the signal. In this case the only option is to reduce the pre-amp gain (so that the scaling of the digital signal is lower than that suggested by the replay level). In order to maintain the consistency of level between tracks, the pre-amp gain should remain at this reduced level for subsequent tracks.«

How does the community here feel about this being an issue or not?

What do the developers think?

And what should be done if it turns out to become an issue? — Leave the volume »bumped down« as David suggests? Build some kind of »average« over the last x songs? Do nothing?

MrSinatra
2008-12-18, 12:48
to answer your question 1:

thats why i posted the winamp datapoints to that bug. it has a feature that lets you apply whatever gain you like to sources without RG tags. i'd guess it is to address the clipping issue you mention.

question 2:

i'm not sure i fully understand what you are saying. if the peak is way out of line with the avg loudness of the track, thats unfortunate but i think SC can only deal with the info RG gives it. i don't know how you would address this issue via SC without RGs help, and i certainly never want to see compression used in SC ever.

Moonbase
2008-12-18, 15:12
1: Yes, I have also suggested it somewhere (having a basic Gain for files w/o RG)

2: Basically, that in spite of RG there might be loudness jumps (on lossy files), and how to handle them. And I’m also pretty much against »falsifying« anything by applying compression. The question is basically »How severe are actual loudness jumps?« and »Should we leave the volume turned down after handling one that needed to played at low volume due to the peak?«

marsboer
2008-12-19, 06:34
1. ADD REPLAYGAIN TAGS! That is what they are there for. It is not and should not be Squeezecenters job to do some "magic" in the background as long as we have the tags for this exact reason for the people that really care about this.

2. This volume differences because of non-clipping logic will not be a big problem, it is probably only noticeable with some lossy tracks with peaks well above 1 and very low average RMS levels. In other words - rather few songs. It is still way better than not having replaygain.

MrSinatra
2008-12-19, 10:41
1. sure, add RG tags, if u can. not always possible. the winamp gain adjust feature is for any files that don't have them for whatever reason. i wouldn't call it magic, but more like "just in case." it defaults to -6db, (but also "off" i think).

2. it would be interesting to figure out how many files i have, (mp3s btw) that have high peaks and otherwise low avg volumes... i wonder if any apps out there ID such tracks? i am hoping it is a small amount of tracks too.

Moonbase
2008-12-19, 11:42
And anyway, there's still internet radio. Most use high compression to "stand out" (like many newer CDs, unfortunately), so expect a huge "loudness shock" if switching from RG'ed music library to some internet radios. Show me how to add RG tags to radio stations please :-)

There could of course be some setting per station, thinking of it. (Which would add other complications and is totally off-topic anyway.)

Ben Sandee
2008-12-19, 12:04
On Fri, Dec 19, 2008 at 12:42 PM, Moonbase
<Moonbase.3koigz1229712301 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> And anyway, there's still internet radio. Most use high compression to
> "stand out" (like many newer CDs, unfortunately), so expect a huge
> "loudness shock" if switching from RG'ed music library to some internet
> radios. Show me how to add RG tags to radio stations please :-)
>
> There could of course be some setting per station, thinking of it.
> (Which would add other complications and is totally off-topic anyway.)

That's a long-standing feature request that is being taken seriously
as far as I can tell.

http://bugs.slimdevices.com/show_bug.cgi?id=2431

Ben

marsboer
2008-12-20, 04:01
And anyway, there's still internet radio. Most use high compression to "stand out" (like many newer CDs, unfortunately), so expect a huge "loudness shock" if switching from RG'ed music library to some internet radios. Show me how to add RG tags to radio stations please :-)

There could of course be some setting per station, thinking of it. (Which would add other complications and is totally off-topic anyway.)

I agree that this is a real problem as there is no possibility for the user to add tags here.

marsboer
2008-12-20, 04:07
1. sure, add RG tags, if u can. not always possible. the winamp gain adjust feature is for any files that don't have them for whatever reason. i wouldn't call it magic, but more like "just in case." it defaults to -6db, (but also "off" i think).

2. it would be interesting to figure out how many files i have, (mp3s btw) that have high peaks and otherwise low avg volumes... i wonder if any apps out there ID such tracks? i am hoping it is a small amount of tracks too.

1. What do you mean, not always possible? It is always possible to add replaygain tags if you really care about it, except maybe if your collection is in .WAV format (and why should anyone just juse the plain WAV format without some kind of container for tags if they care about replaygain?).
I can't see one positive argument for adding a default replaygain value as this value is plain wrong compared to the real content, and there is no guarantee that this value is any more correct than no replay gain value. Either use the correct one (as in adding the RG tags) or nothing is my opinion.

2. Just use mp3tag and add a custom tab for the RG tags. This way you can easily sort your whole collection by individual RG tags and see which files have high peaks and in addition low RMS values (by gain value)

Moonbase
2008-12-20, 08:32
@ Ben: Thanks for pointing at the bug so I could vote.

@ marsboer: (Custom tab for RG in Mp3tag) - That's how I do it. Recommended.

I've actually even written an Mp3tag "export" to have it calculate RG for FLAC, OGG, and MP3 type files. Unfortunately, this has many dependencies and involves batch files, so probably not (yet) for everyone and not really fit for publishing. I intend to put a nice little installer around it one day, but I just gotta finish too many other things first ...

marsboer
2008-12-20, 16:07
@ Ben: Thanks for pointing at the bug so I could vote.

@ marsboer: (Custom tab for RG in Mp3tag) - That's how I do it. Recommended.

I've actually even written an Mp3tag "export" to have it calculate RG for FLAC, OGG, and MP3 type files. Unfortunately, this has many dependencies and involves batch files, so probably not (yet) for everyone and not really fit for publishing. I intend to put a nice little installer around it one day, but I just gotta finish too many other things first ...

Sounds nice, but I just meant customizing the sort columns to add the RG tags.
I use foobar2000 to add RG tags, but it would sure be nice to add those with mp3tag instead.

didbox
2008-12-25, 03:58
Hello,

I installed SC 7.3.1 in order to take advantage of the new Replay Gain functionality allowing to avoid clipping in case of positive Replay Gain. For a long time (since SC version 6.X), all my files are already tagged with all needed RG tags (RG and RG peak tags).
I have 2 questions:
1: Do I have to rescan my library?
2: When playing a track (I use the "Smart" volume gain control option), is there a way to see the real calculated replay gain that is applied?

Thank you!!!

andyg
2008-12-25, 07:17
Hello,

I installed SC 7.3.1 in order to take advantage of the new Replay Gain functionality allowing to avoid clipping in case of positive Replay Gain. For a long time (since SC version 6.X), all my files are already tagged with all needed RG tags (RG and RG peak tags).
I have 2 questions:
1: Do I have to rescan my library?
2: When playing a track (I use the "Smart" volume gain control option), is there a way to see the real calculated replay gain that is applied?

Thank you!!!

No rescan is necessary, the peak value has always been stored in the database, just never used before now.

To see the real gain value used, and the original value from the tag, go to the track info menu. (Click on the track title in the web UI, or press right from Now Playing with the remote, then select More Info and look for the Volume Adjustment items).