Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for iTunes ID3v2 tag 'GRP1' == 'grouping' #570

Open
rossgrady opened this issue Jul 28, 2020 · 6 comments
Open

Support for iTunes ID3v2 tag 'GRP1' == 'grouping' #570

rossgrady opened this issue Jul 28, 2020 · 6 comments

Comments

@rossgrady
Copy link

Feature Request

Due to some bad decisions, the iTunes team a few years ago repurposed TIT1 for Work Name and introduced a nonstandard tag GRP1 for grouping. (http://blog.jthink.net/2016/12/itunes-add-new-grouping-field-but.html)

This only seems to apply to mp3s encoded/edited in iTunes/Music, as their native m4a tag scheme uses @grp for grouping

I need to use grouping in a Smart Playlist use-case and I'm trying to validate that the metadata in a file is correct before pushing it to iTunes. I have to be able to handle both mp3s and m4a files.

The changes needed to support GRP1 are trivial -- an empty case: statement for it in id3v2/FrameParser, and something in ID3v24TagMapper to map it to something.

My understanding is that the common-metadata tag grouping isn't multi-value, which is why I assume you haven't added this support already.

Any thoughts about how one might go about supporting it? It is unfortunately all too possible to have both TIT1 and GRP1 set in a single file, so there is definitely the risk of a collision.

For my use-case, it would be sufficient to have music-metadata surface GRP1 and make it available somewhere on the metadata object, even if it wasn't pushed into the common object.

@Borewit
Copy link
Owner

Borewit commented Jul 28, 2020

The changes needed to support GRP1 are trivial -- an empty case: statement for it in id3v2/FrameParser

Sounds good. It needs to be added to the text cases I guess, this is slightly different then an empty case. From that point it would be accessible via metadata.native.

and something in ID3v24TagMapper to map it to something.

Sure

Any thoughts about how one might go about supporting it? It is unfortunately all too possible to have both TIT1 and GRP1 set in a single file, so there is definitely the risk of a collision.

Hmm it's sounds tricky. So we need to change the interpretation of TIT1 if there is a GRP1 is present?

I noticed the TIT1 / ©grp to Grouping for MP4 / Work name for MP3 in mp3tag tag mappings.

Do you have sample files?
Are you planning to submit a PR?

@rossgrady
Copy link
Author

Happy to submit a PR, and I can provide sample files.

Possible cases (all mp3, as the issue doesn't seem to exist for m4a and I haven't explored other encodings/containers):

  • Person populates the grouping field in iTunes/Music, which is stored in GRP1 ID3v24 field. TIT1 field is empty. The music-metadata output for grouping would currently be null.
  • Person populates the grouping field and the work name field in iTunes/Music. grouping is stored in GRP1 and work name is stored in TIT1. Their expectation is that these are two separate fields w/separate contents. Currently for MP3s, any other application, including music-metadata would surface TIT1 as grouping and would ignore GRP1. Thus the music-metadata output for grouping would currently be actively different from what they input.
  • Person populates the grouping field in another application, and it is stored in TIT1. When they open it in iTunes/Music, grouping is empty so they re-populate it, so now it is also stored in GRP1. Their expectation is that grouping is populated and should be the same anywhere they look at it (sigh).

I'm not sure that it's possible to successfully cover all of those cases with internal logic, which is why I had indicated that just having it available on metadata.native would be enough for me.

But the possible logic would be: if GRP1 and not TIT1 then GRP1 can be surfaced in common as grouping.

Beyond that, I don't think it's possible to deterministically conclude, if both GRP1 and TIT1 are populated, what the person's intention actually was.

@Borewit
Copy link
Owner

Borewit commented Jul 29, 2020

Why not like this?:

GRP1 set? TIT1 Set? Mapping scheme GRP1 to common TIT1 to common
yes no iTunes/Music grouping
yes yes iTunes/Music grouping work
no yes conventional grouping
mappingScheme = id3v2.GRP1 ? 'iTunes/Music'  : 'conventional'

Maybe exposing the GRP1 native as the first PR, which should be straightforward.

@Borewit
Copy link
Owner

Borewit commented Sep 20, 2020

Can we expect follow up on this issue @rossgrady?

@ffxsam
Copy link

ffxsam commented May 17, 2024

Hey @Borewit!

We recently ran across a need for this, as well. kid3/kid3-cli seems to recognize it:

$ kid3-cli -c get quiet.aiff
File: AIFF 24 bit 2304 kbps 48000 Hz 2 Channels 1:38
  Name: quiet.aiff
Tag 2: ID3v2.4.0
  Title                   Flow State
  Artist                  Sam Hulick
  Album                   School of Thought
  Date                    2023
  Track Number            1
  Genre                   Ambient
  Lyrics                  La la la
La la la la!
The end
  Picture: Cover (front)
  Grouping                100% me

On a related note, lyrics would be super handy too!

@ffxsam
Copy link

ffxsam commented May 17, 2024

Did some deeper digging into "Grouping" in music-metadata. I didn't notice it under the native object (lyrics is there though!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants