Add support for new iTunes Grouping Tag (ID3v2)

[Uwe Klotz]

Apple has (silently?) changed the mapping for the Grouping field to ID3v2 tags in iTunes 12.5.4.42:

https://community.mp3tag.de/t/work-name-name-and-movement/18175
https://community.mp3tag.de/t/work-grouping-fields-itunes-12-5/18659
https://community.mp3tag.de/t/support-for-new-itunes-grouping-id3-frame-grp1/18523

http://mutagen.readthedocs.io/en/latest/api/id3_frames.html#mutagen.id3.GRP1
https://github.com/quodlibet/mutagen/issues/304
https://github.com/quodlibet/mutagen/commit/d7f7ef008eed860c0e4909e32cc6a353cb9a0669

This conflicts with the mapping to "Content group description" as proposed by MusicBrainz Picard:
https://picard.musicbrainz.org/docs/mappings/

We need a concept how to deal with those differences.

Import ID3v2 tags: Prioritize MusicBrainz over Apple
- Read Grouping from TIT1 frame first.
- Read Grouping from GRP1/GP1 frame if TIT1 frame does not exists or content is empty.

Export ID3v2 tags: Try to avoid redundant information in multiple frames
- Write Grouping into GRP1 if the frame already exists, otherwise skip it.
- Write Grouping into TIT1 frame if the frame already exists. Add it only if no GRP1 frame has been written (see above).

[Uwe Klotz (uklotzde-deactivatedaccount)]

http://www.jthink.net/jaikozforum/posts/list/19698.page

"So actually for ID3 formats the old grouping field is actually TIT1, and this was used by users to store things like genres. However when iTunes added support for classical music work and movements they decided to use TIT1 to store the work, and created a new field called GRP1 that mapped to their Grouping field.

So we now have the situation that most tools use TIT1 (also known as Content Group Description) for grouping, but iTunes uses it for Classical works and uses GRP1 for grouping, this affects Mp3 and Aif, there is not a problem with other formats."

Also here:
http://blog.jthink.net/2016/12/itunes-add-new-grouping-field-but.html

[Daniel Schürmann (daschuer)]

Since we cannot know if it is a track from ITunes or an other player, we can either ignore the issue, shiw both fields or add an iTunes compatibility mode, right?

Can we distinguish ITunes tracks from others somehow?

Is this bug a real user request, or just a finding? I tend to ignore this until we have a user suffering this. Maybe there is a chance to solve his specific problem then.

What do you think?

[Uwe Klotz (uklotzde-deactivatedaccount)]

Already fixed on master.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9315