Thanks for the suggestion. This implies that I will have to "promote" these frames to "unified frames" and map them to all other tag types because only "unified frames" can be used as "quick access frames".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have checked the situation for these three frames:
ID3 TIT3 is displayed in iTunes as "Description". ID3 TIT3 is mapped to the unified frame type "Subtitle" ("Subtitle/Description refinement" in id3v2.4.0-frames.txt, thus both "Description" and "Subtitle" make sense). Therefore for the ID3 case, the issue is solved with using "Subtitle". For the M4A case, it is a bit more difficult. I had seen M4A desc only as "Video Description" in iTunes 10 and as "Description" in AtomicParsley, for the unified "Subtitle" frame I had taken the unofficial free form atom "SUBTITLE", because this is what is used by Mp3Tag and TagScanner. Now I have verified with iTunes 12.8.2 that desc is really used as "Description" in audio files. So I suggest that I change the mapping of Subtitle from "SUBTITLE" to "desc" in order to be consistent while still keeping compatibility with the old ID3 behavior, OK?
I agree that iTunes is an important application and that not all name mappings are best for iTunes users. When choosing the mappings, I always look at how such frames are used in other applications and try to make a tradeoff. As can be seen in your table, only a few mappings are hard to guess.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Description/Subtitle
Yes I think changing the M4A mapping to 'desc' makes the most sense. But if you want to maintain compatibility with Mp3Tag and Tagscanner, maybe you could write both 'desc' and 'SUBTITLE'? I don't know how feasible that would be.
Movement
Sorry, I did not check if it was official. It is in fact, not part of ID3 v2.4 spec. I want to avoid anything not in spec because the implementation will be unpredictable. I retract my request for this one.
Thanks for the suggestion. This implies that I will have to "promote" these frames to "unified frames" and map them to all other tag types because only "unified frames" can be used as "quick access frames".
I have checked the situation for these three frames:
I agree that iTunes is an important application and that not all name mappings are best for iTunes users. When choosing the mappings, I always look at how such frames are used in other applications and try to make a tradeoff. As can be seen in your table, only a few mappings are hard to guess.
Such an unstandardized mess, isn't it.
Description/Subtitle
Yes I think changing the M4A mapping to 'desc' makes the most sense. But if you want to maintain compatibility with Mp3Tag and Tagscanner, maybe you could write both 'desc' and 'SUBTITLE'? I don't know how feasible that would be.
Movement
Sorry, I did not check if it was official. It is in fact, not part of ID3 v2.4 spec. I want to avoid anything not in spec because the implementation will be unpredictable. I retract my request for this one.
Work/Grouping
Actually, I just tried it, and the '©wrk' frame shows up as "Work" in Kid3, which is what I would expect.
"Grouping" in Kid3 maps to '©grp' for M4A files, which is nothing in iTunes
"Grouping" and "Work" are separate fields in iTunes.
I think the best solution here is to unify 'TIT1' and '©wrk' as 'Work' in Kid3. The ID3 spec gives piano concerto as an example, which is indeed a classical work.
https://www.khanacademy.org/humanities/music/music-basics2/notes-rhythm/a/glossary-of-musical-terms
I would argue that tagging applications should conform to media playing applications.
Last edit: Joe 2019-04-29
What about changing some mappings like shown below to improve compatibility with iTunes?
now:
new:
The GRP1 ID3 tag is Apple-specific (instead of TXXX:GROUPING), maybe I could bring this into TagLib, but maintenance there has slowed down.
Perfect! That's exactly how I would do it.
I am indifferent towards use of the GRP1 frame since it's not standard. But if you want to display it in Kid3 I'm OK with it.
I have now put a development snapshot git20190505 on https://sourceforge.net/projects/kid3/files/kid3/development/, which has the new type mappings. Please have a look at it to see if it meets your expectations.
It's perfect.
I don't have a lot of money right now, but I sent you enough for a coffee I hope. :)
Is now implemented in version 3.8.0.