Bugzilla – Bug 6890
Implement smarter RVA/track gain + SoundCheck logic
Last modified: 2009-09-08 09:21:54 UTC
After a recent change in the daily builds, the replay gains that I see in the mp3 tags are a lot different that what Squeezecenter reports. The files that have this issue are all ones with the iTunesNORM tag as well, so evidently Squeezecenter is getting the track gain from the iTunes tag and the album gain from the replay gain album tag.
Created attachment 2789 [details] Here is one of my mp3's that is affected by the replay gain issue
That's right, we're preferring the iTunesNORM tag now. Michael: What is the issue you are seeing? Are the levels wrong?
(In reply to comment #2) > That's right, we're preferring the iTunesNORM tag now. > Michael: What is the issue you are seeing? Are the levels wrong? Evidently Apple does iTunesNORM quite a bit differently than replay gain because the levels are a lot different and in a lot of cases, up to 10 dB difference. If iTunesNORM is the preferred one, I guess that I'll have to strip the tags out of +/- 75,000 files as the volume out of the Squeezebox is up and down.
The logic we use for this is: 1. Track gain and album gain read from tags. 2. If iTunesNORM is present, add the value from that to the track gain. Album gain is not changed. This mimics the way iTunes works. If you have an RVA track gain tag as well as move the SoundCheck slider, the two values are combined. See bug 3207 for reference, that's when this was changed. See comment 22 especially, Steven did some research on this.
(In reply to comment #4) > The logic we use for this is: > 1. Track gain and album gain read from tags. > 2. If iTunesNORM is present, add the value from that to the track gain. Album > gain is not changed. > This mimics the way iTunes works. If you have an RVA track gain tag as well as > move the SoundCheck slider, the two values are combined. > See bug 3207 for reference, that's when this was changed. See comment 22 > especially, Steven did some research on this. I think that I would rather mine not work that way and I'll just strip out all the iTunesNORM tags. I don't use iTunes anymore as it got to be way too slow once my music collection got to be so large, it doesn't do FLAC, and I use Rockbox on my iPod now so I would rather get rid of them than have playlists with combined mp3 and FLAC songs having the volume up and down.
I can't imagine that anyone with FLAC, APE, etc. files are going to like the way this is implemented, especially for playlist use. I can't follow the logic on why the iTunesNORM would be added to the replay gain. The majority of the tracks affected for me have a replay gain somewhere in the -7 to -10 range and then when the iTunesNORM value is added to that, it makes a lot of the tracks in the -14 to -20 range. Then when a FLAC track plays, it is somewhere from +7 to +10 louder because it doesn't have (thankfully) the iTunesNORM tag. I'm just not going to use anything proprietary like that when Apple couldn't stick with replay gain, which is better because of the separate track gain and album gain tags.
Sounds like this is fixed by adjust the tags.
(In reply to comment #7) > Sounds like this is fixed by adjust the tags. Could there possibly be added an option to choose between using iTunesNORM or replay gain?
We decided against it in bug 3207.
(In reply to comment #9) > We decided against it in bug 3207. Is replay gain going to be dropped completely? I rather not waste the time stripping all of the iTunesNORM tags if replay gain is just going to be dropped. Is there an archive of older builds so I can get rid of the current one?
No, replay gain is here to stay. What changed was the behavior when both iTunesNORM and Replay Gain tags appear together. I'm reopening this as an enhancement for the option you requested. We'll look again at this bug post-7.0. If you are the only person who's affected by this, though, it will be pretty low on the priority list.
(In reply to comment #11) > No, replay gain is here to stay. What changed was the behavior when both > iTunesNORM and Replay Gain tags appear together. > I'm reopening this as an enhancement for the option you requested. We'll look > again at this bug post-7.0. > If you are the only person who's affected by this, though, it will be pretty > low on the priority list. Not a problem...found MP3tag and it stripped out all the iTunes tags from 90,000 mp3's in under 2 hours.
(In reply to comment #4) > The logic we use for this is: > > 1. Track gain and album gain read from tags. > 2. If iTunesNORM is present, add the value from that to the track gain. Album > gain is not changed. > > This mimics the way iTunes works. If you have an RVA track gain tag as well as > move the SoundCheck slider, the two values are combined. Wait, this is incorrect. I think it should work as follows: 1. Track gain and album gain read from tags. 2. If iTunesNORM is present use that value for track gain otherwise use replay gain track gain. 3. If iTunesNORM and RAV is present combine the values and use for track gain. We should not be adding replay gain and iTunesNORM values together only iTunesNORM and RVA! This should mimic the way iTunes works. If this is not the case I need to reopen bug 3207.
OK I'm confused, RVA is the source for track gain info in an MP3 file.
RVA or Relative volume adjustment is indeed one type of tag for adjusting the volume of an mp3 file. iTunes uses this value for the manual Volume Adjustment slider under options on a per track basis. It can be set to none or any value between -100% to +100%. iTunes also creates the iTunesNORM tag for storing the Sound Check volume information. If a user in iTunes has Sound Check enabled and has modified the Volume Adjustment slider the values will be added together when played back in iTunes. The more popular tags I have seen in MP3s either as an id3 or ape tag would be the following: REPLAYGAIN_ALBUM_GAIN REPLAYGAIN_ALBUM_PEAK REPLAYGAIN_TRACK_GAIN REPLAYGAIN_TRACK_PEAK To be honest I don't know of any programs that actually use or create the RVA tag for replaygain.
More information can be found at: http://en.wikipedia.org/wiki/Replay_Gain
OK the situation with APE tags in MP3 files is one I hadn't considered. But ID3 doesn't use names like REPLAYGAIN_TRACK_GAIN, the value from the RVA tag used for this value. So, RVA is the same thing as REPLAYGAIN_TRACK_GAIN.
> So, RVA is the same thing as REPLAYGAIN_TRACK_GAIN. No, it should not be IMHO. All replaygain computing and tagging programs that I am aware of use id3 TXXX frames or ape tags for this information. The file attached to this bug for example is using the id3 TXXX method. However since the file was loaded in iTunes it also has a iTunesNORM tag. It does not even contain a RVA tag. Should this discussion continue in bug 3207?
OK I will try to describe exactly what SC does for replaygain in MP3 files. Note that this does NOT apply to any other file format. The SC database only stores 2 gain values: track gain (tracks.replay_gain) and album gain (albums.replay_gain). We also store peak values but we don't use them for anything. We are only concerned with track gain so I won't mention how the others work. 1. If there is a literal comment tag named REPLAYGAIN_TRACK_GAIN in ID3 or APE tags, that is picked up. 2. Then we see if there are any comment tags from broken taggers like J. River Media Center: "MEDIA JUKEBOX: REPLAY GAIN" becomes REPLAYGAIN_TRACK_GAIN 3. Then we look for RVA tags, this includes RVA, RVAD, and RVA2. 4. If we have RVA or RVAD, we get REPLAYGAIN_TRACK_GAIN value from RVAD -> RIGHT -> REPLAYGAIN_TRACK_GAIN. 5. If there is an RVA2 tag, REPLAYGAIN_TRACK_GAIN comes from RVA2 -> MASTER -> REPLAYGAIN_TRACK_GAIN or RVA2 -> FRONT_RIGHT -> REPLAYGAIN_TRACK_GAIN. 6. If there is an iTunNORM comment tag, this value is added to the value we found for REPLAYGAIN_TRACK_GAIN. Each of the above steps overrides the previous value for REPLAYGAIN_TRACK_GAIN, except for #6. So for example, if there is an RVA tag it will override whatever is in a literal REPLAYGAIN_TRACK_GAIN tag.
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?
Hmm, I guess that makes sense in that iTunes likely ignores TXXX comment tags but does not ignore RVA tags, is that right? Dean, what do you think?
Yes, iTunes does ignore the TXXX comment tags in question but does read and create the RVA tags. I don't recall what specific RVA tags that iTunes supports however.
Assigning to Dean for input.
We need to fix this for 7.1.
Is the change of replay gain logic I suggested in comment #20 non trivial?
It's unfortunate this bug got lost due to being marked 'future'... I will take a look at it soon. The issue is we store RVA in the same place as TXXX gain tags, but I think it shouldn't be too hard to fix. I'll be happy if we can avoid adding a new pref.
I could not agree more about adding a pref. The sheer number of replaygain tag implementations a single file can have boggles my mind and will most likely make this a difficult bug to solve completely with just logic however. Having said this I am confident that we can come up with a agreeable replaygain logic solution just the same.
Fixed in 7.1 change 20850.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC