I agree wholeheartedly.  I'd love to be able to do volume normalization on My iTunes/Apple Lossless collection.

Are you guys using iTunes importing to get your music into your library or do you have itunes turned off and are only specifying a music folder?  I see the soundcheck imported when using itunes but not when just using a music folder.

The itunes soundcheck data is stored in the file like this.  This is the $tags has returned by get_MP4::Info::get_mp4tag($file):

$VAR1 = {
          'SIZE' => 9547478,
          'YEAR' => 2002,
          'MS' => 907,
          'TMPO' => 0,
          'ARTIST' => 'They Might Be Giants',
          'SECS' => 90,
          'CPIL' => 0,
          'MM' => 1,
          'GENRE' => 'Children\'s Music',
          'NAM' => 'No!',
          'TRKN' => [
                      4,
                      17
                    ],
          'TRACKNUM' => 4,
          'DAY' => 2002,
          'SS' => 29,
          'GNRE' => 'Children\'s Music',
          'TOO' => 'iTunes v6.0.4',
          'TIME' => '01:30',
          'ALB' => 'No!',
          'META' => [
                      {
                        'MEAN' => 'com.apple.iTunes',
                        'NAME' => 'iTunNORM',
                        'DATA' => ' 00001020 00000EF1 0000613B 00006100 000090D4 000090D4 00007FDD 00007FDD 000020E2 000020E2'
                      },
                      {
                        'MEAN' => 'com.apple.iTunes',
                        'NAME' => 'iTunes_CDDB_IDs',
                        'DATA' => '17+D03F93A8C52FE41B97CD73B02C7C1D3A+2057750'
                      }
                    ],
          'ENCRYPTED' => 0,
          'TITLE' => 'No!',
          'ALBUM' => 'No!',
          'BITRATE' => 830,
          'ART' => 'They Might Be Giants',
          'VERSION' => 4
        };

Need to add support for that iTunNORM tag.

I've got the 'use iTunes' option turned off in Slimserver, and I just specify a music folder.

Ah, ok.  The syntax in the apple lossless files themselves is something that our scanner doesn't understand yet.  the information above is what we need to fix it.

but I did confirm that if you use itunes importing it does work, so most folks won't be affected.

dan, can you take a look at this after 6.2.2?

Just spoke with a customer that had quite a few apple lossless files that were playing back with lots of static and noise.  I had him disable replaygain, stop the server, remove slimserversql.db, and things started playing fine after that.  This was with 6.2.2-release.

See TMID 5716. We have another customer that has observed this bug. 

Dean - any idea how to decode that data?

As said above, I have also observed this bug

However, according to the above there should not be a problem if itunes is used to import the files and/or itunes is used to manage the music library.  I am doing both of these but still have the bug.

I am running SB3,  Slimserver 6.3.0 on  Mac OS X 10.4.7

I am happy to assist by trying out any suggestions you have.

Mike

Ok, so there are two problems:  

1. Mike is seeing the itunes xml volume adustment information ignored.  that we should fix that for 6.5, if possible.
2. In the absence of an xml file, we should also interpret the meta information in the file.  That can wait post 6.5

The Volume Adjustment flag is found and used properly when importing from iTunes for Apple Lossless files in 6.5

Fixed in change 8467

SlimServer now looks for the iTunes Sound Check iTunNORM tag, and decodes it.

If you set a manual Volume Adjustment in iTunes, that will be used instead of the Sound Check value.

A customer thinks this bug has appeared again in our latest build.  His e-mail is below.

(reference tmid 15524)

I have conducted a test plan in order to resolve some issues I was having with normalizing track volumes.  I would be
grateful if you could confirm my conclusions and comment upon what I believe to be a bug.

My configuration
1.  All tracks were ripped into MP3 files using iTunes 7.0.2.
2.  I have SlimServer 6.5.1 (to be precise: "6.5.1 - 10638 - Windows XP - EN - cp1252")
3.  My Server settings include: "Use iTunes".
4.  My Player settings include: "Use Track gain".
5.  I am using Softsqueeze version 3.2.1 (until Santa brings me my Squeezebox).

Volume Adjustment in iTunes
iTunes has two different methods of volume adjustment:
a)  Its "SoundCheck" feature.  This results in a tag frame with the name ITUNNORM.  (This
automatically-generated data is stored in the mp3 file whether or not you have chosen to make use of the SoundCheck
feature upon iTunes Playback.)
b)  You may use a Volume Adjustment slider (-100% to +100%) which results in data being stored in the iTunes Music
Library XML file.

Review of available information
I have reviewed both Forum threads and Bugzilla in relation to this matter.  There is a recent thread #28524 which
discusses this issue.  It concludes that the manually entered Volume Adjustments take precedence over the SoundCheck
data, based upon the closing comments in Bug
3207.

Conclusions from my Testing
1. SlimServer converts the SoundCheck (ITUNNORM) data into a dB "volume adjustment" value which is displayed
on the Song Info page.
2. Adding manual volume adjustments has no effect upon playback volume from SlimServer as long as the SoundCheck data
remains in the mp3 file.
3. If I delete the ITUNNORM data from the file (using the MP3tag utility) then iTune's volume adjustment slider values
are used to generate a dB "volume adjustment" in SlimServer.	(Furthermore, adjustments in iTunes are
immediately available in SlimServer without needing a rescan.)

This final conclusion would seem to be in conflict with the fix generated as a result of Bug 3207.  I wonder whether my current version of SlimServer has regressed this fix?

I wish to make use of the volume adjustment slider method, but am loathed to remove the ITUNNORM from thousands of
tracks in case it proves to have some future value.

There have not been any regressions. We prefer the iTunNORM tag over any manual volume adjustment.

(In reply to comment #14)
> There have not been any regressions. We prefer the iTunNORM tag over any manual
> volume adjustment.

Dan,

In Comment #12 you said that: "If you set a manual Volume Adjustment in iTunes, that will be used instead of
the Sound Check value".  This no longer seems to be the case, as per my testing above.  The manual adjustments are being ignored as long as the ITUNNORM frame exists in the MP3 file.

Geoff

Steven, after the 6.5.2 release (or earlier if you need a break :) would you have a look and see if this is fully working in 7.0?  It looks like Dan implemented scanning for this iTunNORM flag and adjusting the volume, but some users are reporting that it doesn't work for some reason.

I am seeing the same behavior as described in Comment #13.

I agree that SlimServer should ignore the iTunNORM value if a RVA/RVAD/RVA2 value is present as described in Comment #12. It is very difficult to change or remove the iTunNORM value even in iTunes, however the RVA/RVAD/RVA2 value is easily changed in iTunes with the volume slider control.

SlimServer currently does the opposite as described in Comment #14. Why the change?

Perhaps there should be a user selectable priority option for this.

Steven,

NB: I am the customer whose email was the subject of comment #13, and so am taking a particular interest in this bug.

I just wanted to clarify one point in your last update.  You mention RVA/RVAD/RVA2 - are these frames in the mp3 tags?  If so, I have to report that I do not see these in the iTunes-generated mp3 files.  As mentioned in comment #13, the slider volume adjustments made in iTunes are stored in the xml libraray file.

(Apologies if I have got the wrong end of the stick here.)

Geoff, the RVA/RVAD/RVA2 frame, also known as relative volume adjustment, is saved in the tag by iTunes, at least in version 7, by adjusting the volume slider. Since this frame is part of the ID3 spec I feel it should take president over the non standard iTunNORM comment tag, at least with MP3 files. I have not investigated if this tag is saved in other iTunes supported file formats. I believe you are correct that this information is also stored in the iTunes xml file.

Note to self: How does the volume slider in iTunes interact with sound check?

The manual adjustment should win over the automatic soundcheck normalization. 

Steven to look after Andy's recent changes.

We still use the ITUNNORM value over the RVA value for calculating the Volume Adjustment in SqueezeCenter.  The thing is just switching to preferring one value over the other is not really a complete solution.  These values work together in iTunes for example.

So if I have Sound Check turned on in iTunes and the file has an ITUNNORM value of say -10 db and a Relative Volume Adjustment of +10 db, I end up effectively playing back the file with 0 db of adjustment.  However if I turn sound check off in iTunes the file will playback with a volume adjustment of +10 db even though the file still has a ITUNNORM tag.

So if the user is making Volume Adjustments to their files in iTunes with Sound Check on will expect a different result then a user that has Sound Check turned off.

So I see a total of three combinations here.  SqueezeCenter uses the Sound Check value, SqueezeCenter uses the Voulme Adjustment value or SqueezeCenter combines both values together to get a result.  Any other solution I can think of would be more complex.

Another thing I noticed is that the Voulme Adjustment value is in the iTunes Library.xml while the Sound Check value does not appear to be.  Possibly we can use this to our advantage?

Dean, your thoughts?

We should emulate the behavior of iTunes so that when somebody listens with iTunes and then with Squeezebox they hear the same relative volume.

Guys,

These are the results of my own empirical testing with iTunes:
a) “SoundCheck” is intended to normalise track volumes upon replay in iTunes.  It is set in Preferences>Playback.  
b) iTunes places SoundCheck data into the ITUNNORM frame that it stores in the ID3 tag.  
c) This Soundcheck data is stored whether or not SoundCheck is enabled.

Given (c) above I am unable to see how you will be able to determine whether the iTunes user has Soundcheck turned on or not.

FYI:  The approach I have adopted is to remove the ITUNNORM data from my mp3 files (using the MP2Tag utility). Manual volume adjustments made in iTunes (and registered in its XML file) are then immediately picked up by SlimServer; no rescan required.


Geoff Johnson

Dean, the only way I can think that we would be able to emulate iTunes in regards to volume would be to have a Sound Check toggle in SqueezeCenter.  I was hoping we could avoid that.

The other issue that may come up is when a file has Replay Gain tags in addition to iTunNORM and RVA/RVAD/RVA2 tags.  I'm not sure what we do currently but I can check.

We already have a Volume Adjustment/Replay Gain setting.  This should be used to toggle the SoundCheck behavior.

Dean, I suppose we could do it that way but in order to emulate the way iTunes handles this we would need to apply the RVA/RVAD/RVA2 volume adjustment to the audio when volume adjustment is off and add the iTunNORM volume adjustment when volume adjustment is on.

I see two problems with this solution.  First we do not currently store both the iTunNORM value and the RVA/RVAD/RVA2 value in the database and second there would not be a way for the user to disable the RVA/RVAD/RVA2 adjustment without adding an additional toggle.

I think that this setting should either be:

OFF - Don't use any volume adjustment.  Play back the audio as it is in the file.
ON - Combine the iTunes tags together. 

Would this fix the reported bug?  I realize that this doesn't allow for independent control, but I'm not sure that anybody would want the other two settings (SoundCheck:off RVA/RVAD/RVA2:on vs Soundcheck:on RVA/RVAD/RVA2:off).

Dean, I agree with you and think we should just combine the two values for Volume Adjustment and close the bug, but you did say "We should emulate the behavior of iTunes" :0)

However Geoff in comment #24 wanted "SoundCheck:off RVA/RVAD/RVA2:on" but has a workaround.

Dean, have we made a decision about this?  Who should this be assigned to?  Thanks!

Is there a description anywhere of how the volume adjustment function is supposed to work, other than the thread of this bug?  In particular, what is the "Smart" gain setting meant to do (I assume Track and Album gains work in the standard Replay Gain fashion)?  I am using iTunes to create the library, but not to manage it - I just point SqueezeCenter to a library folder.  I do not enable SoundCheck in iTunes.  All song files are MP3s.  If I enable Track Gain in SqueezeCenter, moving the sliders in iTunes doesn't seem to have any effect.  Do I actually need to change the Replay Gain parameters in all the files (with Foobar2000, for example)?

Steve,

What you have just described reiterates my own testing which gave rise to my original email (reproduced in Comment #13 above).  From the conclusions presented in that email you may see that alerting the volume sliders in iTunes has no effect as long as the ITUNNORM tag remains in the mp3 file.  It was for that reason that I devised my workaround of removing the ITUNNORM data (see comment #24).

Geoff

I have a Beta version of SqueezeCenter 7.0 - 14001, and I have verified Geoff's observed behavior with some more details.  I use iTunes to manage my music library, but I do not use iTunes in SqueezeCenter, and in fact the iTunes XML Library file is on a different computer from the song file database and SqueezeCenter.  My MP3 files normally have ID3v2.2 tags with the iTUNNORM frame included, even though I have never had SoundCheck enabled in iTunes.  When I display a Song in SqueezeCenter, there is a "Volume Adjustment" parameter displayed.  Changing the iTunes volume slider adds or changes an "RVA" (Relative Volume Adjustment) frame in the MP3 file, but does not affect the Volume Adjustment parameter in SqueezeCenter nor the actual volume (where does the value of this parameter come from in this case?).  If I then delete the iTUNNORM field using MP3Tag, the Volume Adjustment parameter still doesn't change even if the RVA frame existed.  However, deleting iTUNNORM in MP3Tag causes the tags to be changed to ID3v2.3.  If I THEN change the iTunes volume slider, an "RVAD" frame is added to the tag and at that point the SqueezeCenter Volume Adjustment parameter does change, as does the actual volume from the SqueezeBox.

This would allow manual changing of the iTunes slider to affect the volume.  However, I have 27,000 song files so this isn't the ideal solution.  I will continue to experiment with Replay Gain unless someone has a better idea.

Like you said steven: "we should just combine the two values for
Volume Adjustment and close the bug"

Andy, can you take a look for 7.0?

Fixed in change 15991, at least for MP3 files.  You will need to do a full wipe and rescan.

RVA* tags don't appear to be used if they are found in AIFF files.  Not sure if that's a bug or intentional.

Please reopen if you still have an issue with this.

Please see bug 6890 starting with comment #19.

Would it be possible to back out change 15991 for the 7.0 release and then revisit the issue for 7.0.1?

Although possibly imperfect, the 15991 solution seems much better than the previous implementation.  One problem is caused by the minimal adjustment (+/-6dB) of the iTunes volume slider.  If, for example, the Soundcheck parameter produces a value of -9dB (and in my library this is a typical number) and this is too loud, there is no way to adjust it.  Removing iTUNNORM and using the slider produces a minimum volume of -6dB, which is even louder.  Combining the two values is the only real way to make this work (as iTunes does).

Steve, I totally agree with you when it comes to iTunes.  The problem right now however is the current code change will also combine completely different gain tagging methods as described in bug 6890.  IMHO SqueezeCenter needs better logic when it encounters different gain tagging methods in one file.  Andy described some of the current gain logic in that bug and is an excellent starting point to discuss the gain logic further, perhaps on the forums.

My bigger concern is if change 15991 affects more users in a negative way then a positive one when 7.0 is released.  I'm feeling that it may cause more harm then good currently.

We need a decision on how this should work for 7.0.1.

I'm confused as to the choices.  Can you summarize?

Dean, I summarized what change I feel needs to be implemented in bug 6890 and have pasted it below.  I think this change would cover both this bug and bug 6890 for now.  I assigned both bugs to you for input. 

From bug 6890:
Andy, thank you so much for breaking it down!  I now understand what the
problem is with our current implementation.

This:
6. If there is an iTunNORM comment tag, this value is added to the value we
found for REPLAYGAIN_TRACK_GAIN.

Should be changed to this:
6. If there is an iTunNORM comment tag, this value is added to the value we
found for RVA.

Using the file attached as an example, the current implementation would result
in a track gain of -18.6 since the iTunNORM=-8.9 and REPLAYGAIN_TRACK_GAIN=-9.7
and no RVA tag present.

The new implementation would result in a track gain of -8.9 since iTunNORM=-8.9
and no RVA tag present and REPLAYGAIN_TRACK_GAIN=-9.7 would be ignored.

This was the method I thought was implemented in bug 3207, would this be an
trivial change and can it make 7.0?

*** Bug 7748 has been marked as a duplicate of this bug. ***

PING DEAN

Note that the only option that will make everyone happy is a preference for selecting which way it works...

I'm ok with a preference here, where the current behavior is the default.

Andy, would this be yours?

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?

I am going to close this bug since it was originally about not reading soundcheck tags in apple lossless files which has been fixed.

Please see bug 6890 for additional comments on how SqueezeCenter handles soundcheck, replaygain and relative volume adjustment tags.