"COMMENT ITUNENORM" tag and iTunes... ignores tag if keeping leading space in tag???

[Xlr8]

Using the RG Utility codec to calculate and write RG tags + ITUNENORM tags... works great, have been playing around with different levels. I notice iTunes seems to ignore the tag as written and overwrites/calculates its on "soundcheck" value if you leave the leading space in the COMMENT ITUNNORM tag as written by DB RG Utility...

Test Scenarios *1
- Convert 1 album using RG utility codec with -30 LUFS setting (to clearly make it really low) and write tags...
- read tags with MP3tag and all tracks show approx -20dB (due to me setting low level), COMMENT ITUNNORM tag has leading "space"
- create new iTunes DB, soundcheck on, import album, it DOES analyze volumes of all tracks, and when done DOES NOT SHOW any sign of following the +20dB I was expecting it to see, it shows -5dB (iTunes own calculation) for all tracks
Conclusion, iTunes seems to completely ignore COMMENT ITUNNORM tag with the leading space and creates its own to write to iTunes .itl file

Test Scenarios *2
- Convert 1 album using RG utility codec with -30 LUFS setting (to clearly make it really low) and write tags...
- read tags with MP3tag and all tracks show approx +20dB (due to me setting high level), COMMENT ITUNNORM tag has leading "space"
- in MP3tag manually remove leading space in COMMENT ITUNNORM tag of all tracks in this album
- create new iTunes DB, soundcheck on, import album, it DOES NOT analyze volumes of all tracks, and when done DOES SHOW the +20dB I was expecting it to see
Conclusion, iTunes seems to accept COMMENT ITUNNORM tag without the leading space and uses it to write to iTunes .itl file

Anybody else test this or experienced this strange iTunes behaviour...?

Using DB15.1, DSP effects 11, and iTunes 11.4.0.18

[garym]

Re: "COMMENT ITUNENORM" tag and iTunes... ignores tag if keeping leading space in tag

I suspect this is not strange itunes behavior, but an incorrect tag created by dbpa. I've used mp3tag for many years to convert RG values to a COMMENT ITUNNORM (so itunes sees this and uses as the SOUNDCHECK value automatically). When dbpa initially allowed for creation of ITUNNORM tags for soundcheck, there was something wrong as well (can't recall), but later I recall that Spoon fixed this. What you've discovered in likely another small issue with getting the dbpa COMMENT ITUNNORM tag corrrect so that itunes uses it.

edit: also see this:

http://forum.dbpoweramp.com/showthread.php?34322-iTunes-Sound-Check-not-recognizing-the-Comment-iTunNORM-Tag

[Spoon]

Re: "COMMENT ITUNENORM" tag and iTunes... ignores tag if keeping leading space in tag

For mp3, you need R15.2 which is in beta testing (testing section of this forum), we were writing unicode ITUNNORM tags, which iTunes could not handle.

[imeric]

Re: "COMMENT ITUNENORM" tag and iTunes... ignores tag if keeping leading space in tag

After banging my head on this for quite some time here is how I resolved my issue with MP3TAG for Itunes to not scan mp3 files fro volume leveling and use the one in the tag. (As dbpoweramp 15.1 was not working):

I created the following action and ran it on my MP3 files (Alac and AAC files were ok):

$cutLeft($rg2sc(%REPLAYGAIN_TRACK_GAIN%),1) This is an MP3 tag feature (I guess....) converting track gain info to sound check and eliminating the leading space which seem to cause the issue. I guess I could have just run the trim action in MP3 tag on the dBpoweramp 15.1 Comment itunnorm calculations to get the same result...