# Updating Itunes Soundcheck
**URL:** https://community.mp3tag.de/t/updating-itunes-soundcheck/47702
**Category:** Support
**Created:** [January 29, 2020, 2:49pm UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702 "2020-01-29T14:49:13Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@gsa999](https://community.mp3tag.de/u/gsa999)
#### Post date: [January 29, 2020, 2:49pm UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/1 "2020-01-29T14:49:13Z")
Hi,
I have just started had to update some ReplayGain values is a number of my older ripped albums/tracks using R128. I then ran an mp3tag action below that I have used for years
$rg2sc(%REPLAYGAIN\_TRACK\_GAIN%) which updates COMMENT ITUNNORM field.
All fine so far and the value changes (albeit all 10 blocks of 8 hex numbers are the same value, but I understand that is correct from reading elsewhere)
Then I go into iTunes and do Song Info which should reread all the tags, which it does for normal tags but it does not appear to be rereading the COMMENT ITUNNORM tag.
The volume value under the File tab in Song Info does not change.
Seems to be that iTunes only reads this tag when the track is first imported or maybe I am doing something wrong by rerunning the mp3tag action to generate a new soundcheck value.
Does anyone know how to refresh the soundcheck value in iTunes without having to delete and re-import the tracks since I'll lose playcounts/ratings etc
Thanks
---
### Author:  [@Flasshe](https://community.mp3tag.de/u/Flasshe)
#### Post date: [February 5, 2020, 6:14pm UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/3 "2020-02-05T18:14:59Z")
I have been noticing this issue since around Feb 2017. All my MP3s before that where I used $rg2sc() to set COMMENT ITUNNORM to ReplayAlbumGain for every track, imported into iTunes just fine. Song Info-\>Files-\>Volume shows the same value for every track in the album. However, anything I imported after Feb 2017 (using the same function/method) has "random" volume values for the track, which I assume are the ones that iTunes SoundCheck assigns if nothing in COMMENT ITUNNORM. I verified this by blanking out COMMENT ITUNNORM and ITUNNORM and re-importing the album after deleting it, and I still get those same random values instead of the consistent ones. (Note that supposedly COMMENT ITUNNORM is used by iTunes for MP3 files and ITUNNORM for AAC files.) For me, this issue is independent of whether importing an album for the first time or later.
This has been driving me crazy, I can never get it to use the values I set any more. Then I saw this recent post which seems to explain it:
[https://community.mp3tag.de/t/convert-replaygain-values/8069/45](https://community.mp3tag.de/t/convert-replaygain-values/8069/45)
So it appears to me that in 2017 there was either a change to MP3tag to encode the volume slightly differently, or there was a change in iTunes to interpret it differently (or a combination of the two). I can not find any way around this. It sounds like $rg2sc() needs to be changed.
[Edited to point to actual reply within thread that shows issue.]
---
### Author:  [@gsa999](https://community.mp3tag.de/u/gsa999)
#### Post date: [February 6, 2020, 8:56am UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/4 "2020-02-06T08:56:40Z")
Thanks for the information. This does seem to explain why iTunes is no longer picking up the correct Soundcheck values from value calculated in the mp3tag $rg2sc action.
I wonder if the $rg2sc action be changed to correct this
G
---
### Author:  [@gsa999](https://community.mp3tag.de/u/gsa999)
#### Post date: [February 8, 2020, 12:46pm UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/6 "2020-02-08T12:46:31Z")
HI - just tried a couple of things
Ripped with dBPoweramp v17 (Beta) with EBU R128 -18 LUFS and iTunes track normalisation. RG Trackgain was -0.54 dB
Soundcheck value using was:
0000046B 0000046B 00000B0C 00000B0C 00024CA8 00024CA8 00000000 00000000 00024CA8 00024CA8
Took copy of track, deleted comment itunnorm tag and used MP3TAG $rg2sc action to recreate and got a soundcheck value of:
0000046C 0000046C 0000046C 0000046C 0000046C 0000046C 0000046C 0000046C 0000046C 0000046C
Imported both tracks to iTunes
dBPa track registered as -0.5 db (dropping the 2nd decimal) - ie correct
MP3TAG track registered as +2.2 dB !!!!
Tried another track which was +4.02db trackgain
dBPa imported as +4.0dB - ie correct. Soundcheck value was:
0000018C 0000018C 000003DE 000003DE 00024CA8 00024CA8 00000000 00000000 00024CA8 00024CA8
MP3TAG version imported as +4.5dB !!! Soundcheck value was:
0000018C 0000018C 0000018C 0000018C 0000018C 0000018C 0000018C 0000018C 0000018C 0000018C
Seems to me as though the MP3TAG $rg2sc action is not working correctly
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 9, 2020, 11:59am UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/7 "2020-02-09T11:59:26Z")
It seems that there was some evolution w.r.t. what octets are actually interpreted by iTunes since the original implementation of the `$rg2sc` function.
I'll look into this. Thanks for pointing!
---
### Author:  [@Flasshe](https://community.mp3tag.de/u/Flasshe)
#### Post date: [February 9, 2020, 11:36pm UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/8 "2020-02-09T23:36:12Z")
Thanks for looking into it Florian! And thanks for the additional research gsa999. One thing I would like to point out (which is detailed more in the other thread, with the COMM "i" vs "h" value), is that I still believe the COMMENT ITUNNORM tag (as written by $rg2sc) is not getting read at all by iTunes these days, because of something other than the actual octet values. I think the reason gsa999 may be getting very different values is because in the MP3tag/$rg2sc case, the tag is not getting read properly by iTunes, so iTunes is ignoring it and putting in its own SoundCheck values. At least that is what my experience is showing. In other words, I think gsa999 would be getting the same values if he didn't have the tag in there at all.
---
### Author:  [@cleatus356](https://community.mp3tag.de/u/cleatus356)
#### Post date: [February 11, 2020, 7:01pm UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/9 "2020-02-11T19:01:27Z")
$rg2sc works on AAC files just not on MP3 files and the only reason is because "i" vs. the "h". I have no idea why it happens or how to fix it other than using a hex editor. I no longer really care since dBPowerAmp r17 Beta updated the software based on what I found...that is what I use simply because it works.
I gave all of the necessary information so that any software package can write these tags properly but to my knowledge only dBPA has acted on it...
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 15, 2020, 2:42pm UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/10 "2020-02-15T14:42:56Z")
This should be fixed with [Mp3tag v3.00a](https://community.mp3tag.de/t/455). Thanks for reporting!
---
### Author:  [@Flasshe](https://community.mp3tag.de/u/Flasshe)
#### Post date: [February 17, 2020, 6:15am UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/11 "2020-02-17T06:15:37Z")
It is fixed! Thanks so much!
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [March 18, 2020, 6:15am UTC](https://community.mp3tag.de/t/updating-itunes-soundcheck/47702/12 "2020-03-18T06:15:43Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.