I have a lot of metadata in my files, since iOS 10 or iOS 11, and/or iTunes 12, that metadata is now causing some incredibly undesired behavior, purely visual, thankfully, but I'm completely lost in how to rectify this sort of situation. As far as I can tell, tags in my files, either the 'Grouping', or Conductor, Composer, or some such, is being rendered on iOS (see attached image) in a really nightmare way.
These albums are all self-ripped, typically using either XLD or Max (I've used both for various phases over the years.
And then again, the files are either encoded using XLD or Max.
I tend to tag files initially via MusicBrainz Picard and then throw them into the 'Automatically Add to iTunes' directory, and then use Yate to get updates as metadata changes in MusicBrainz.
iTunes Match/iCloud Music (pre-Apple Music) may or may not be playing a role in all this sheer madness, however metadata ultimately works with those services.
And then I have DJ-specific metadata being added to files via some combination of rekordbox, Serato DJ, and Mixed In Key. Mixed In Key is perhaps specifically interesting because it writes files to multiple commonly used fields:
* comments (prepends initial key and BPM)
* Also sets an initial key field which I doubt iTunes or most other non-DJ specific software cares about
* grouping gets a numeric value
It will do this for MP3 (ID3 tags) and MP4s. Probably others, but those two formats are all I keep in my library.
I am fairly positive the mixture of rich metadata plus this grouping field is what's creating the mess but I can't for the life of me figure out how / unset it properly in Yate. Looking at the raw data of the songs (MP4s) in that screenshot tracks 1 and 4 have mostly common data so I don't understand why the grouping starts where it does.
I want to know why this grouping starts where it does, but I'm also interested in some kind of Yate resource to strip this data. As far as I can tell, Mixed In Key writing to GRP (for mp4 files) was a huge mistake, and pretty much is the cause of all of my woes. It also writes the value to an 'ENERGYLEVEL' which I think my DJ software honors.
So, why is the grouping starting at track 3? Tracks 1 and 3 both have the same producer field data, grouping value (4), track/disc numbers are consistent (trkn 1/23 vs trkn 3/23, disk 1/3 in both cases), etc.
'PRODUCER' => [
"\x{5149}\x{7530}\x{5eb7}\x{5178}",
"\x{4e2d}\x{6751}\x{5149}\x{5ba3}"
],
Perhaps why isn't as important. Is the issue primarily the GRP field? Note 'Maximum iTunes Grouping-Work Name compatibility' is disabled for me. Is there a field I can clear manually, or, a resource I can implement so that saving automatically cleans up this legacy mess in my library?
(I have seen at least 6 albums that have this issue, it's madness.)
p.s. Screenshot was taken on iOS 12 public beta, but it's existed for a long time but I just now started my annual 'metadata update' process and it came to mind that I should look into fixing this.
p.p.s. I mentioned that this bug is purely visual. Despite the track names missing in these work/grouped titles, they play without issue and all the metadata underneath still exists in iTunes, etc.
p.p.p.s. I'm happy to entertain workflow optimization suggestions AFTER solving this madness.

|