aha. so you weren't actually creating itunnorm values due to the typo. Glad its fixed. This is my action info. I have both of these combined in one single action.
for mp3. (replace _ALBUM_ with _TRACK_ to use RG Track value)
Just sharing my experience with RG convertion to Sound Check.
I'm using Mp3Tag v2.54 and for me by default there is already the Replaygain 2 Itunes action.
I'm using itunes 11 latest version.
I used the rg 2 sc in my ~10k size library consisting of 90% .mp3 and 10% .aac and .m4a (apple lossless), and through mp3tag I can see that the RG values has been properly written.
Itunes does recognizes all the converted values properly, and that's great news!
I tested both with adding new files, and also editing the tag of existing files on the itunes library and forcing itunes to "reload" the tag infos by writing dummy data to any field like groupings or bpm to all the files. Either way it works, once i turn on Sound Check, iTunes does not calculates the values and displays the correct values in the info dialog.
Buuuut, it does not recognizes the SC values for the .aac and .m4a files! =/
The values are there as mp3tag has written correctly, but apparently iTunes is not seeing the ITUNNORM field anymore?
I have found some topics (/t/14419/1 asking about wheter iTunes has stopped using the ITUNNORM field or not.
I am not sure, but on my setup it seems to not be using for .aac and .m4a files.
If anyone has any answer to that, I would greatly appreciate if you share your findings.
I think the topic you linked says it all !!
The only thing what you can do now is goto Apple iTunes Discussions and complain there, as Mp3tag can't change things that Apple iTunes doesn't support or reads. Apple likes to break things that worked like a charm before.
Link for Apple iTunes Discussions: https://discussions.apple.com/community/itu...nes_for_windows
This is a pretty old thread but I am trying to convert replay gain to sound check using the information in this thread. It is working for aac/m4a files but not for MP3. Everytime I import an MP3 file, itunes rescans it and changes the volume to the track gain that soundcheck uses. Is anyone else having this problem.
I am using the COMMENT ITUNNORM field for MP3 and the ITUNNORM field for aac and writing the field in the same way for both. Again, ITUNNORM works for AAC but COMMENT ITUNNORM not working for MP3.
create a single ACTION containing two commands. Note, I use ALBUM RG values. If you want TRACK RG values, replace "ALBUM" with "TRACK" in the two format strings below.
format value, field:
format value, field:
I already did what you said but it doesn't work for mp3 files...iTunes rescans the file every time. Not sure why it would work one way and not the other...in fact I'm tired of screwing around with it so I'm converting everything possible to AAC. I may even convert some things I only have in mp3 (I know I should not transcode) just so that I can normalize them to the album gain.
Odd. Not sure what's happening on your end. As a test, I just made copies of an mp3 file and an AAC file and deleted the Soundcheck tag field on both (either COMMENT iTunNorm or iTunNorm). I then ran the ACTION above to add SOUNDCHECK values with mp3tag and then imported both files into itunes. Afterwards, I compared the SOUNDCHECK value of the newly imported files with my old copies that had not been imported yet, and found the contents of both "COMMENT iTunNorm" and "iTunNom" identical. That is, itunes did not rewrite/recalculate the SOUNDCHECK value.
I'm using ver. 2.99a of mp3tag and iTunes ver. 220.127.116.11 (windows)
I used the code as you listed it exactly in MP3Tag. I am only having trouble with MP3 files...AAC/m4a files work just fine. I have further been comparing it with Foobar2000 and dBPoweramp. I can't get any of them to do it correctly for an MP3. I will give you an example based on a file that I used in each of the programs. Note that this file gets a calculated album replay/gain value of +2.44
COMMENT ITUNNORM = 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A
When imported into iTunes, the volume shows as +2.0
COMMENT ITUNNORM = 0000023A 0000023A 00000590 00000590 00024CA8 00024CA8 00005A8D 00005A8D 00024CA8 00024CA8
When imported into iTunes, the volume shows as +2.0
COMMENT ITUNNORM = 0000023A 0000023A 00000591 00000591 00024CA8 00024CA8 00007C24 00007C24 00024CA8 00024CA8
When imported into iTunes, the volume shows as -0.7
I am using MP3Tag v2.98 and iTunes 18.104.22.168 (windows 10)
looks like both mp3tag and foobar2000 are doing it correctly in this example. SOUNDCHECK volume adjustments will be similar to the replaygain value (e.g., +2 vs +2.44), but not identical as I understand that the itunes algorithm is a bit different. Not sure of the technical details.
I would agree with you that those programs are doing correctly EXCEPT for the fact that other tracks on this album have different values. This particular album is one I only have in MP3. Here is a snippet of the different values when technically they should all be the same since the COMMENT ITUNNORM value is the same for every track:
Track 1 = +2.0
Track 2 = -0.7
Track 3 = -0.2
Track 4 = -0.5
Track 5 = +1.5
Track 6 = +2.4
Track 7 = +2.4
Track 8 = +2.4
Track 9 = +2.4
Track 10 = +2.4
Track 11 = +1.6
There are more tracks but you get the point.
Note that if I convert these same tracks from MP3 to AAC/m4a and then run the code to write the souncheck value into the ITUNNORM field, every track imports into iTunes at +2.4 which is the correct value. This is very confusing as I would think the COMMENT ITUNNORM and ITUNNORM fields would give the same results with the same hex numbers but they clearly don't. I do have a select few mp3 albums where using foobar2000 has worked for the entire album but I honestly have not been able to figure out a rhyme or reason as to why it works sometimes but not others. Very frustrating...
definitely something odd going on. But I don't have any solution ideas. I've moved away from using itunes in any case and all my players now use the ReplayGain tags instead. I use foobar2000 mobile on my iphone/ipad.
I thought about trying to switch to foobar2000 mobile but was a bit intimidated with having to ftp transfer tracks to my phone. Since m4a works I think I'm just going to convert the mp3 tracks...not an ideal solution but then I don't have to mess around with it anymore. Thanks for trying to help!
I transfer the files to my iphone using itunes on windows and connecting my phone, just as if I was going to use the apple music app. But once the files are on the phone, I can play them with foobar2000 mobile.
Just to follow up on the foobar2000 mobile side issue, I recalled that I had recently purchased TuneFusion (from the maker or dbpoweramp). It turns out that TuneFusion can automatically transfer songs/albums etc. to an iphone/ipad and other portable devices (including over WIFI). I played with it a bit last night. It has several interesting functions. The two best I've found for me are that (1) it can automatically convert lossless files to a lossy format upon transfer to my iphone, retaining all tag and art info, and (2) it has a "smart" sync function which will transfer only certain items based on user customization.
With this functionality, I can truly drop the use of itunes for any music related purpose.
I downloaded foobar2000 mobile again last night. I see that I can play my music thru that app but it does not add my playlists in as well. If it would grab my playlists too then using this app would be a no brainer. I know the Cesium music app can grab everything from itunes but it does not support replay/gain. I wish foobar2000 could just learn how to grab everything from itunes like the Cesium app does...it would greatly simplify things
I started experimenting again and comparing how MP3Tag writes the COMMENT ITUNNORM field as compared to iVolume for one of the troublesome MP3 files I have that is not showing the correct SoundCheck value in iTunes and here is how they were written. Note that the album replay/gain value calculated in Foobar2000 and dBPowerAmp using the EBU R128 at -18 LUFS was +2.44:
MP3Tag: 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A (imports as +2.0 dB for SoundCheck because iTunes analyzes the track)
iVolume: 0000023D 0000023D 00000599 00000599 0000BD60 0000BD60 00000000 00000000 0000D0C8 00009138 (imports as +2.4 dB for SoundCheck)
I then took this a step further and looked at the files in a hex editor to see how the COMMENT ITUNNORM field has actually been written. The only reason that MP3Tag is not working to write the values to an MP3 file is because of one tiny little thing:
MP3Tag: COMM...i...0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A 0000023A
iVolume: COMM...h...0000023D 0000023D 00000599 00000599 0000BD60 0000BD60 00000000 00000000 0000D0C8 00009138
If I change the "i" to an "h" in the hex editor, then the COMMENT ITUNNORM value that MP3Tag writes imports into iTunes correctly. I don't know what the "i" or the "h" means but hopefully someone else can take it from here and make the necessary changes so that writing these SoundCheck values works for MP3 files.
I can verify your research - replacing the "i" with an "h" makes it work like it used to. (Unfortunately, at least with the editor I was using, it made some of the other metadata get blown away, but at least the track volumes were now properly set from ReplyAlbumGain.) As I stated in another thread, something must've changed around Feb 2017. All my files from before then preprocessed with MP3tag and the $rg2sc() function have the "h" and the volumes are correct. All after that have the "i" and iTunes is not using the tag for the volumes. Could have something to do with the ID3 version (though all mine are ID3v2.3) or the way the frames are implemented or something. Someone who knows more about this stuff than me would need to look at it, but something changed and it's not right.
The Hex Edition I use is HxD and it seems to work pretty well but if obviously a tedious way to make this work in iTunes...
This should be fixed with Mp3tag v3.00a. Thanks for reporting!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.