Add support for new iTunes GRP1 field
For ID3 only ITunes now uses this new GRP1 field for storing groupings rather than TIT1 which it now uses for Works
Comments (13)
-
reporter -
Yep. Looks like iTunes now maps grouping to
GRP1
and work toTIT1
. Fun.IMO, it would be nice, if there was simple support for
GRP1
, perhaps underID3v24FieldKey
(and other v2 fieldkeys) asITUNES_GROUPING
? -
reporter Yes, it is very ID3v2 specific and I don't want to redefine the existing Grouping mapping so I think yes this may just be a change for ID3, but the trouble is then code has to specifically use the ID3 api I would like them to to be able to use the generic api, even if they have to do if(file.isMP3()) first
-
I guess that means, adding
ITUNES_GROUPING
toFieldKey
as well (along with the required mappings)? -
reporter Yes but all other formats do not have a separate GROUPING and ITUNES_GROUPING are our logic does not support mapping two FieldKey to the same format specific key
-
GROUPING
could still be mapped toTIT1
(just like before).ITUNES_GROUPING
could be mapped toGRP1
for mp3 and nowhere for other formats.So if a user wants to set this field, s/he needs to know, whether she wants to write to
GRP1
orTIT1
.Other than this solution, we could think about an iTunes 12.6 mode and a regular mode.
In iTunes 12.6 mode,
GROUPING
is always mapped toGRP1
andWORK
is always mapped toTIT1
. In regular mode,GROUPING
is mapped toTIT1
andWORK
is mapped to aTXXX
field.Isn't there this class
TagOptionSingleton
that could handle this? -
I'm very interested in getting this done in the next couple of days, but would rather coordinate with you before implementing stuff blindly. Please let me know, what you think!
Thank you.
-
reporter HI, okay I think adding something to TagOptionSingleton is a good way to go, whether it needs to map both Work and Grouping Im not sure since in my code I always write Work to TXXX:WORK and then additionally allow to write to TIT1 if iTunes option enabled, have a go and we can review it.
-
Just sent you a pull request.
The changes basically mean:
- You can switch between two modes (iTunes 12.6 or regular)
- You can so so via a method in
TagOptionSingleton
- Switching only makes sense before you do anything else.
- All it does is change the mapping of
FieldKey.GROUP
andWORK
toGRP1
andTIT1
. - So when in iTunes mode, things work seamlessly with iTunes 12.6, because the behavior is identical.
Sounds good?
-
reporter Support iTunes 12.6's way of mapping GROUPING and WORK to GRP1 and TIT1, instead of TIT1 and TXXX:WORK. See issue #180 (https://bitbucket.org/ijabz/jaudiotagger/issues/180). This patch allows swapping the FieldKey mappings for ID3v2 via the TagOptionsSingleton.
→ <<cset a58fa8da0f92>>
-
Ive merged it in. I also added a test for AIF and WAV files so I can confirm it also has an effect on AIF which is right, but it also effects WAV fiels which I think is wrong (although not sure) since iTunes doesnt understand WAV metadata
I guess there are two use-cases:
- You want to be compatible with iTunes 12.6
- You don't care about iTunes and want things to stay the way they were
In case 1 you always want to write data in a way that iTunes understands. It really does not matter how you write to
WAV
, because iTunes does not know how to read or write ID3 metadata fromWAVs
.In case 2 you always want to write the same way. What iTunes makes of this does not matter. Here you get neat "old-style" tags in all the formats. I.e. ID3 in its various containers and whatever else you have.
So in essence you have to choose which path you want to go down. PR50 lets you do that.
-
In PR 50 I wrote:
For AIFF, iTunes 12.6 seems to write GROUPING to GP1. Work and movement don't not seem to be written at all.
I checked this again and it is true: As far as I can see, iTunes does not embed work or movement info into the AIFF ID3 tag. I checked this with iTunes 12.6.1.25 on OS X 10.10.5 using a hex editor (i.e. actually looking into the binary file).
I have filed a bug with Apple (radar 32461134).
-
- Log in to comment
This is very much iTunes specific currently so should be labellled as such. Not sure how/if to deal with at generic level since only applies to ID3 formats, but we dont want users to have to use ID3 specific frames if at all possible,may have to do something with isSupported()