Hello, I came across an issue with the ITUNESADVISORY tag and the Apple Music App for Windows 11 and iOS 26 where the E no longer shows in either app.
For example, if I put a 1 in that tag like I normally do for explicit content, Apple Music does not show the E.
I tried to troubleshoot and here is what I found:
If I use MP3TAG v3.31a, ITUNESADVISORY works as expected. Once I import the file in Apple Music, the E shows up fine.
If I use MP3TAG v3.33, ITUNESADVISORY does not work as expected and the E does not initially show up unless I do this process…
Put a 0 in that field & save it
replace the 0 with a 1 & save it
Finally, import the .m4a file in Apple Music and the E will show up.
I thought this was a fluke, so I tried it with another .m4a file and I had to go through the same process in order for the E to show up in Apple Music when I use MP3TAG v3.33. If I use MP3TAG v3.31a, everything works fine and I do not have to do that process.
I do not know what examples or other information you need from me, but I am more than happy to provide more information if needed.
I am editing the tags before I import the .m4a in Apple Music. I made sure to delete the .m4a out of Apple Music before each step during troubleshooting.
Hmm, I wonder what’s causing it then. Only 2 things changed, I upgraded to the newest version of MP3TAG and the newest version of dbpoweramp. All I am doing is going from FLAC to ALAC, updating some tags and then importing it in Apple Music.
I wonder if it’s an issue with the conversion process. But, why would MP3TAG v3.31a work and not 3.33 on the same file. It’s not a huge deal I guess since I can just write an action to do the process I mentioned. Hmm. I am puzzled lol
Are you doing the conversion in DBPA after the edits in mp3tag? Or copying and pasting the tags from FLAC to ALAC after the conversion?
I use both programs myself. And have found DBPA drops some fields when converting from FLAC to ALAC and the other way as well. There has been some discussion about this on their forum. Maybe a solution is coming. But this is not an issue from mp3tag I believe.
I am using mp3tag after the conversion from FLAC to ALAC. Initially when I purchase music, I use mp3tag to properly tag the FLAC files. So, when I do the conversion, DBPA already tags the ALAC file, at this point I use mp3tag to clean up the ALAC file because not every tag survives the conversion process.
I've received an example file via PM and was able to track down the reason for the field not being recognised by Apple Music.
Here comes the lengthy explanation (which I already shared via PM, but want to also describe publicly for transparency):
I made some fairly big internal changes to the MP4 code end of August (v3.31b) and one of which was reusing internal fields (MP4 atoms) upon rewriting the tag if the content hasn't changed.
It now happens that the ITUNESADVISORY field in this file is not stored as rtng atom as required by Apple Music, but as a user-defined field with the name ITUNESADVISORY (caused by adding this field already to the FLAC file and the conversion process not being aware of the semantics of this field).
Previously, on v3.31, Mp3tag always rewrote the entire tag and would have translated this user-defined field named ITUNESADVISORY to the rtng atom. Not so in v3.33, which only does this if the field content is changed (e.g., from 1 to 0 and back again) or when the tag is rewritten completely (as with cutting and pasting).
I've just released Mp3tag v3.34-beta.1 which reverts back to the previous v3.31 behaviour and doesn't try to reuse MP4 atoms and instead writes the tags according to Mp3tag's mappings.
If someone needs minimal changes applied to the tag, there is now an option Reuse unmodified MP4 atoms at Options → Tags → Advanced, which also has the implications described above.
A big thank you to @Florian for this change! I had an issue with tag transfer using the Actions command, which has been fixed in this version Mp3tag v3.34-beta.1 .
See my screenshot for the two commands Florian added:
