The first thing I notice is how the tag is written, or expected to be entered in the Monkey. According to the ID3 specs, it's a series of terminated strings in the raw tag, and that's fine as you can get MediaMonkey to write it in this manner. However, I'm not fond of how you're expected to achieve this, as you're expected to treat it as any other Multi-Value field. Thus, "Instrument; Person 1; Instrument; Person 2." There's nothing in the specs that specifies that this is improper, but based on what the field is, I find it to be a little strange.
The tag is a series of Key/Value pairs essentially. You list an involvement, such as an instrument someone played (Guitar) or other such information (such as "Executive Producer"), then follow it up by the name belonging to that involvement. Looks at the string which produces the correct writing of this tag, you could have trouble deciphering it if you have a few in there. Sure, "Drums" doesn't exactly look like the name of someone, but I believe the handling of this field could be made more cosmetically simple (if that even makes sense).
They are Key/Value type entries, so why couldn't the Monkey look at the tag and see there are four terminated strings written to the file in this frame, then present it in a manner that better represents the data. I'm thinking "Guitar:Slash; Drums:Travis Barker." That would be four terminated strings written to that frame, but MediaMonkey would be presenting it in a manner that easily represents that Travis Barker was the Drummer on this particular track, without having to manually look as think to yourself, "Okay, there's a key, and it's value, another key, that value belongs to that one, okay here we are, 'Drums', okay I see now, Travis was the drummer." Scanning and seeing "Drums:Travis Barker" I makes processing that information faster.
The main reason I pitch this example on how to read that frame is because I've noticed a couple other programs use the same method. "Key1:Value1;Key2:Value2," including MP3Tag which I use alongside MediaMonkey to do some bigger more automated jobs. Again, this frame is much like the other Multi-Value frames and even the Rating frame, how to write them to an ID3 Tag is documented, but there's no set standard how to present that data. Maybe you view these programs "interpretation" of this written data to be wrong, but I see it as a better way to visualize the data.
That said, MediaMonkey will also accept "invalid" data for this field. Reason I say that is because I've already covered that "The body simply contains a terminated string with the involvement directly followed by a terminated string with the involvee followed by a new involvement and so on." which I take to mean you should have pairs of two terminated strings. "Guitar:Slash" would be acceptable, but "Guitar" should not. However MediaMonkey will accept a single value such as "Guitar" without even a hiccup. I don't think MediaMonkey should accept these forms of values, as again, I read the information of this frame to mean you need an Involvement, and a name of that Involved Person. Perhaps a method to prevent entering a single or odd amount of information?
Maybe my own interpretation of how this field should be read, wrote, entered and used is wrong. However, it's with my view of it that brings me to my actual feature pitch. I think this field could be used for some good information, and some interesting things could be done with it too, as long as there is some standard form of entering the data.
If you go with my concept of "Key:Value;Key:Value", then there could be some new tables added to the database. The information to the left of the ":" would be entered into a table and treated like a Genre (a grouping, so you would have entries like "Drums", "Guitar", "Producer", "Engineer"). Then you would have the information on the right, which would be treated a lot like an Artist or Lyricist (as they would be people too). I don't know if they could be grouped in with the artists table or not, as I'm not 100% on how the database works. You would then need something like "ArtistAlbums" or "GenreSongs" that would match up the keys to the values... or however the information would need to be handled in the database, as this is only a guess.
This brings things to the fun part. What could be done with this information once it's in there? Why... add it to the tree of course! We've already got an Artist node, Album Artist, Composer, Conductor, etc. (though Lyricist is still missing...), so why not the Involved People? However you couldn't have just a single node that would list all the entries like the Artist node for instance, since this is a different kind of data. That's why I propose something like the following:
Code: Select all
| Involved People
| \_ By Involvement
| \_ Drums
| \_ Rob Bourdon
| \_ Mark "C-Bass" Causley
| \_ Travis Barker
| \_ Guitar
| \_ Brad Delson
| \_ Dave "Phoenix" Farrell
| \_ Michael Scott
| \_ Phil Thacker
| \_ Slash
| \_ Keyboard
| \_ Mike Shinoda
| \_ Turntables
| \_ Joe Hahn
| \_ Tom Sawyer
| \_ Vocals
| \_ Chester Bennington
| \_ Mike Shinoda
| \_ Powerdise
| \_ By Involvee
| \_ Brad Delson
| \_ Guitar
| \_ Chester Bennington
| \_ Vocals
| \_ Dave "Phoenix" Farrell
| \_ Guitar
| \_ Joe Hahn
| \_ Turntables
| \_ Mark "C-Bass" Causley
| \_ Drums
| \_ Michael Scott
| \_ Guitar
| \_ Mike Shinoda
| \_ Keyboard
| \_ Vocals
| \_ Phil Thacker
| \_ Guitar
| \_ Powerdise
| \_ Vocals
| \_ Rob Bourdon
| \_ Drums
| \_ Slash
| \_ Guitar
| \_ Tom Sawyer
| \_ Turntables
| \_ Travis Barker
| \_ DrumsYou can fit a lot of data esle where, such as the Artist, or the Lyricist, but I still feel the Involved People field has a lot to offer, and it's an already implemented ID3 Standard Field, so why not take advantage of it? Heck, one of the things I would probably use this for if it got some attention would be denoting which artists were involved in a group recording (using the Bone Thugs-N-Harmony as an example, Bizzy Bone isn't on all of them), as you could say I could enter this into the Artist field, but the "Artist" of the track is the group, thus "Bone Thugs-N-Harmony," not "Krazyie Bone; Layzie Bone; Wish Bone." I'm just saying.
I'm merely digging this topic back up (as like I mentioned, I recall it being discussed before, I just can't track down the threads it was done in), figuring maybe some time has changed the mind of people and this could be viewed as useful. If nothing else, maybe it'll offer a nice little discussion on why it would or wouldn't be.
PS -- I used "By Involvement" & "By Involvee" as I wasn't sure what to use there, however those are the two things the values were labeled as in the ID3 Docs, so I went with them, that doesn't mean there couldn't be better node names.
