player settings->audio, volume adjustment.  this can be set to disable volume adjustment and playback should not get adjusted for replaygain/souncheck

Thanks KD f- I can see that setting on my SB2 but not on my SB1. Is it firmware/hardware related?

SB1 firmware doesn't support replaygain. the hardware is not able to support it.

Seems that SlimServer should give the user a bit more control over which replay gain methods are imported since (it seems to me) it only supports storing one such value in the database.

We have a meeting planned in the next couple of weeks to target enhancement requests more specifically.

i would like to see a switch in SS that lets the user decide which volume adjustment tags to use (e.g., iTunNorm from iTunes or ReplayGain from MP3Gain and Foobar2000).

iTunes automatically generates the iTunNorm tags whether you want it to or not.  Most users don't like the quality of the result.  if you also use MP3Gain to adjust the file, your values are ignored because SB uses the iTunNorm tag first.

I definitely think it's time for a (minor?) upgrade to the volume options. I use iTunes Sound Check within iTunes because it doesn't recognize replaygain. That's fine for my portable or (now rare) burning discs. But I have all my files tagged for replaygain. Unfortunately, the Squeezebox favors the iTunes tags.

Sadly, despite assurances to the contrary, iTunes' Sound Check is not nearly as good as replaygain. I very much want it to be and try hard to believe it is, but it's not nearly as consistent in its results.

Various workarounds really aren't options for me because I've got 90,000+ tracks to contend with and am still adding tracks pretty regularly. Plus, it doesn't seem a workaround should be necessary when all the tags are in place.

I know this issue has been discussed before, but is a drag-down selection of which tags to favor a major change, especially considering options already are available (track vs. album gain)?

Is there any time table on fixing the replay gain / Soundcheck problem? I thought that I had a bug report on it but now I can't find it.  I've deleted all my soundcheck tags but it's really a hassle not being able to have both replay gain tags and soundcheck tags in the same file.  I should be able to have both without Squeezecenter adding them together.  Right now I can't use soundcheck on my Ipods because of this problem.  I prefer replay gain which works much better but Ipods can't use it so now I have to choose either replaygain for the Squeezebox or soundcheck for the Ipods but not both because of the way the Squeezebox adds the two together.  Why this was ever done is beyond me because they do the same purpose.  By adding them together you are dropping the volume on most modern music 14-20 db's.  If someone happened to have a rare song with a large positive gain you could have a potential situation for blown speakers by adding them together.  

(In reply to comment #7)
> Unfortunately, the Squeezebox favors the iTunes tags.

Rather that options, how about just favoring the ReplayGain tags over the iTunes tags?  It would be safe to assume that anyone who has gone to the added trouble of running Mp3Gain on their Mp3s would prefer to use ReplayGain rather than the poor iTunes normalization.

Agree with Jim 100%.  To my mind logic should be if replaygain and soundcheck tags both present then use replaygain and ignore soundcheck.

imo, a user should be able to tell SC to exclusively use RG tags, or itunes tags, or FIRST RG tags and if not present, then itunes tags, or use none at all.

SC should never aggregate all tags tho.  i'm surprised how old this bug is, seems like something important that should have been dealt with by now.

Since we can select between "None", "RG Track", "RG Album" and "Smart RG" already, I'd suggest either changing the logic to prefer RG over SoundCheck, or, BETTER, have a "selection switch" in the WebUI that lets the user select between "If both exist ..." — "Prefer ReplayGain over iTunes SoundCheck" and "Prefer iTunes SoundCheck over ReplayGain".

This could apply to the whole system or any player and should be quite an easy change (I think).

Oops. I guess we read them in scanner, so it [i]has[/i] to be a system-wide setting.

Brandon: your comments? would this fall under new schema?

Agree on the options of either (1) default to use replaygain tags if both these and soundcheck are available, or (2) Add option to a switch for user choice.

Seeing the problems users have with SoundCheck only supplying "track gain" (and different loudness values!), we should think about simply changing the "preference" to "prefer ReplayGain over SoundCheck if both tags exist" real soon now.

See forums post
http://forums.slimdevices.com/showthread.php?p=412917#post412917

This would be a rather simple change and surely make a lot of users much more happy. There ARE a lot of them who use iTunes/iPods AND SqueezeCenter and would like to have a "perfect" ReplayGain for "both worlds". We could rather easily make this true, by letting them have BOTH types of tags in their files and preferring ReplayGain tags if we see them.

It only makes sense to use a proven standard.  Replay gain having both track and album is much better with SC's Smart gain.

I was reading http://svn.slimdevices.com/slim/7.4/trunk/server/Slim/Utils/SoundCheck.pm?view=markup to see if there is an easy patch to ignore iTunNORM when ReplayGain is already found (the answer is yes), and stumbled upon bug 3207 mentioned on line 40. The (very interesting) discussion for bug 3207 ended a year ago with the following remark from Andy: "Yeah, a pref is the only real solution.  Steven: can you come up with some text and options for the pref that you think would make sense to everyone?"

+1 for ReplayGain to take a higher preference than Soundcheck. I use both (because I use iTunes and I can not disable Soundcheck) but prefer ReplayGain.

CW

(In reply to comment #19)
> +1 for ReplayGain to take a higher preference than Soundcheck. I use both
> (because I use iTunes and I can not disable Soundcheck) but prefer ReplayGain.
> 
> CW

The forum discussions lately seem to assume that RG does take preference over Soundcheck when both exist in latest software (SbS 7.4.x). Can anyone confirm that this is true?

I did not experiment with actual mp3 files, but the code at http://svn.slimdevices.com/slim/7.5/trunk/server/Slim/Utils/SoundCheck.pm?view=markup says:

43 if ($comment && ref $comment eq 'ARRAY' && $comment->[2] eq 'iTunNORM') {
44 	
45 	if ( my $gain = normStringTodB($comment->[3]) ) {
46 	# Bug 3207, if we already have a known gain value,
47 	# combine it with the iTunNORM value
48 	$tags->{'REPLAYGAIN_TRACK_GAIN'} ||= 0;
49 	$tags->{'REPLAYGAIN_TRACK_GAIN'} =~ s/\s*dB//gi;
50 	$tags->{'REPLAYGAIN_TRACK_GAIN'} =~ s/[^-\d\.]//g;
51 	$tags->{'REPLAYGAIN_TRACK_GAIN'} += $gain;
52 	} 

There has been no change in this code for a long time. It still combines iTunNORM with ReplayGain.

I just found that the current logic (ReplayGain is combined with iTunNORM) is a result of implementing bug 6890. Step 6 in comment 19 of bug 6890 to be precise.

(In reply to comment #22)
> I just found that the current logic (ReplayGain is combined with iTunNORM) is a
> result of implementing bug 6890. Step 6 in comment 19 of bug 6890 to be
> precise.

The rest of that bug discussion seems to state that this problem (the logic of Step 6 above) was fixed in 7.1 versions and later.  Is this not actually true? Thanks.

(In reply to comment #23)
> The rest of that bug discussion seems to state that this problem (the logic of
> Step 6 above) was fixed in 7.1 versions and later.  Is this not actually true?
> Thanks.

Yes it is, but step 6 of bug 6890 is why SoundCheck en ReplayGain are aggregated. This is the second part of this bug 4362. This is also noted by Spies Steven in comment 20 of bug 6890 and confirmed by Andy in comment 21 of bug 6890. I think he just forgot about this when he implemented it.

Andy just corrected me in the forum. The code in http://svn.slimdevices.com/slim/7.5/trunk/server/Slim/Formats/MP3.pm?view=markup says:

328 	 # Look for iTunes SoundCheck data, unless we have a TXXX track gain tag
329 	if ( !$tags->{REPLAYGAIN_TRACK_GAIN} ) { 

So in fact Slim::Utils::SoundCheck::commentTagTodB() is only called when a TXXX (or APE) ReplayGain tag is not present. This means this bug is now only about adding user configuration options, and not the Volume Adjustment tags behaviour.

Sorry for the confusion.

bug 2431

is there any reason this bug should not be closed?

as far as i know, "smartgain" works, RG and soundcheck are no longer "added" together db-wise, and RG will be used by SBS over soundcheck if both are available.

i think this bug should be closed.  any objections?

I think the lack of a configuration option to choose between ReplayGain and SoundCheck is the reason this bug is still open. Personally I do not need such an option. Everything works the way I expect it to at the moment.

if thats the case, i think a new bug should be filed for that, and this one should be closed.  but i also think thats kind of an unnecessary option, for several reasons.  1. RG is better than soundcheck.  2. RG almost always has to be deliberately added by the user, and if they do so, presumably they want it used.  (soundcheck is done most times by itunes without the user knowing)  since RG is preferred over soundcheck already, i just can't envision a scenario where a user would "want" soundcheck over RG, or where its worth dev time to implement such an superfluous option.

does anyone following this bug see if differently or object to closing it?

(In reply to comment #29)
> if thats the case, i think a new bug should be filed for that, and this one
> should be closed.  but i also think thats kind of an unnecessary option, for
> several reasons.  1. RG is better than soundcheck.  2. RG almost always has to
> be deliberately added by the user, and if they do so, presumably they want it
> used.  (soundcheck is done most times by itunes without the user knowing) 
> since RG is preferred over soundcheck already, i just can't envision a scenario
> where a user would "want" soundcheck over RG, or where its worth dev time to
> implement such an superfluous option.
> 
> does anyone following this bug see if differently or object to closing it?

I agree with this 100%. 99% of the time, a RG user specifically chose RG. A soundcheck user may or may not know what they have.