Involved People Improvements/Suggestions

Any ideas about how to improve MediaMonkey? Let us know!

Moderator: Gurus

Mizery_Made
Posts: 2283
Joined: Tue Aug 29, 2006 1:09 pm
Location: Kansas City, Missouri, United States

Involved People Improvements/Suggestions

Post by Mizery_Made » Wed Dec 31, 2008 2:34 pm

I've yet to actually start using it myself, but I have been "testing" it here recently. It's like when you go to a swimming pool, most people don't just dive right in, instead they walk over and dip their toe in to see what the temperature is like. Anyway, it's during my experimenting with this field that I've come to the conclusion that it's being under utilized. I seem to recall a discussion or two in the past about this field, ones I might have even voiced an opinion in, but I've spent a short time trying to rediscover these topics and wasn't having much luck so I figured I would make a fresh pitch.

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
|       \_ Drums
It's similar to the Classifications node, since you have that node as a grouping node of the sub nodes for each Classification type, except this one would go deeper as you go into the Involvement or Involvee. This would allow your to look up the data by role, so you could find all your Guitarist, or look up a single person such as Mike Shinoda and see which tracks he played Keyboards on and which he had vocals on. This field wouldn't be restricted to instruments either, as you could add information for the producer of the track, who engineered it, who mastered it, etc.

You 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.

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Re: Involved People Improvements/Suggestions

Post by MoDementia » Wed Dec 31, 2008 3:32 pm

This got introduced to this thread at some point
http://www.mediamonkey.com/forum/viewto ... 20#p147120
Image
You can see the paired entry screen.
Blank or feat, etc = Artist field
Drummer or Guitar etc = Involved People field

The choice of separator in the new builds is the first step in the process, so hopefully it will be built upon in future versions.

ZvezdanD
Posts: 3106
Joined: Thu Jun 08, 2006 7:40 pm

Re: Involved People Improvements/Suggestions

Post by ZvezdanD » Thu Jan 01, 2009 4:20 am

MoDementia wrote:This got introduced to this thread at some point
Yeah, that was my proposal and rendering of Properties dialog box, how I would like to see it. However, I didn't mean to have just one list, but two - one list for Artists (main and featuring/presenting/versus) and another for Involved people (musicians, producers, ...). You should take a look on a screenshot of competitive products which I mentioned here: http://www.mediamonkey.com/forum/viewto ... 505#p95505

By the way, what is a reason why you edited/deleted all your posts in a thread that you are referenced?
Mizery_Made wrote:If you go with my concept of "Key:Value;Key:Value", then there could be some new tables added to the database.
Well, this is nothing new - I already suggested exactly same thing for database representation several times before. However, we should distinguish three different things: a tag representation (internal to the audio files), a database representation (how values are stored in Songs table) and visible representation (how we see it and how we enter values in Properties dialog). It is not necessary for these three representations to be same.

Here is a description for IPLS frame (Involved people tag) from http://www.id3.org/id3v2.3.0: "The 'Involved people list' is a frame containing the names of those involved, and how they were involved. 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." Here is a description about terminated string: "Terminated strings are terminated with $00 if encoded with ISO-8859-1 and $00 00 if encoded as unicode." So, a form "Key:Value; Key:Value" could be used only with Involved people field/column of the Songs table in a database, not in tags.

Well, I also think that there should be additional table in a database for the role of involvement, something similar as existing tables ArtistSongs and GenreSongs. Here is what I sent to MM developers more than one year and a half ago:
Please, could you tell me your opinion about screenshot which I posted earlier? What do you think about CATraxx approach for involved persons? As you could see from its screenshot, in CATraxx you can define almost unlimited number of definition about some person's participation on some song. So, you don't need to create separate fields for every possible involvement: Musician (Vocal, Guitarist... ), Producer, Composer, Director...

Let me tell you about this concept. I think that you should have only one IDPerson field inside of the Songs table, with a link to the IDSong field in new Involvements table. In this table you should have 4 columns: ID, IDName, IDSong, and IDRole. Field IDName should be in connection with ID field in new Persons table, which should contain ID and Name fields. Field IDRole from Involvements table should be in connection with ID field in third new table, Roles, which should contain ID and Role_Name fields.

That third table is needed because some person can have two or more involvements. As with example from screenshot: The Edge are playing guitars, vocals...

With this concept you would have unlimited number of involved persons with unlimited number of different custom defined roles.
Here is an answer which I got:
yes, I’m planning something like this and it will probably appear in the next release after alpha 6 – which will hopefully be the last DB change for MM 3.0.
Now, take a look on Jiri description from mentioned thread (http://www.mediamonkey.com/forum/viewto ... 70#p142870):
Just to clarify UI:

Artist: Artist1 & Artist2 feat. Artist3

Involved People: (Not implemented this way in MM 3.0, but is planned)
Person1 Guitar
Person2 Bass
...

And it would be in tag:

Artist (TPE1): Artist1 & Artist2 feat. Artist3
Inv.People(TIPL or other): Person1/Guitar/Person2/Bass/Artist1/Artist/Artist2/Artist/Artist3/Artist
To be a honest, I don't care for all of that things already implemented in 3.1.xxx. I just really want to see a better support for main/featuring artists and Involved people like he promised. I think this is a must for the next version.

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

Re: Involved People Improvements/Suggestions

Post by MusicBringer » Thu Jan 01, 2009 5:57 am

ZvezdanD wrote:
MoDementia wrote: I just really want to see a better support for main/featuring artists and Involved people...I think this is a must for the next version.
I have read this thread carefully, and to be honest it goes right over my head. I am not sufficiently techy to understand all the jargon.
However, I too am keen to have better support for "main/featuring artists and Involved people", for example band members who actually played on the recording.
I have tried using the field Involved people but I find the small space far too fiddly for me.
MM3 should address this issue soon, please :D
MediaMonkey user since 2006

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

Re: Involved People Improvements/Suggestions

Post by MusicBringer » Wed May 13, 2009 11:10 am

As this topic has cropped up again today I am wondering what progress has been made with this issue.
Have changes been made without my knowledge - after all, it is 5 months since my previous post.
Have I missed any improvements.
If not, can I expect something in the short term, please. :)
MediaMonkey user since 2006

Lowlander
Posts: 47299
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: Involved People Improvements/Suggestions

Post by Lowlander » Wed May 13, 2009 11:14 am

No changes were made or are expected soon as MediaMonkey 3.1 is in RC phase (No new features will be added).
Lowlander (MediaMonkey user since 2003)

Mizery_Made
Posts: 2283
Joined: Tue Aug 29, 2006 1:09 pm
Location: Kansas City, Missouri, United States

Re: Involved People Improvements/Suggestions

Post by Mizery_Made » Wed May 13, 2009 11:22 am

Improvements in this area aren't really make-or-break for me when it comes to using MediaMonkey, but I'm still holding out hope that MM3.2/MM3.5/MM4.0 (whatever the next landmark will be) will see some improvements made on this subject.

BlissDisrupted

Re: Involved People Improvements/Suggestions

Post by BlissDisrupted » Tue Jun 14, 2011 9:48 am

What's the latest on this? In today's world where artists move freely from band to band, it would be great to see this in the Monkey. If you could define the members in a band once, and then see in the outline all the music made by a person across all the bands they have played in, that would be a thrill.

Dreadlau
Posts: 1967
Joined: Sun Nov 25, 2007 6:49 am

Re: Involved People Improvements/Suggestions

Post by Dreadlau » Tue Jun 14, 2011 4:09 pm

BlissDisrupted wrote:What's the latest on this? In today's world where artists move freely from band to band, it would be great to see this in the Monkey. If you could define the members in a band once, and then see in the outline all the music made by a person across all the bands they have played in, that would be a thrill.
That would be great indeed.
Seven Ultimate X64 SP1 / Sansa Clip 2go (with RockBox)

dtsig
Posts: 3217
Joined: Mon Jan 24, 2011 6:34 pm

Re: Involved People Improvements/Suggestions

Post by dtsig » Tue Feb 18, 2014 8:56 pm

and here we are 3 years on and the question will exists. I really would like to see better representation in properties/details as I use this a lot for videos films and tv.
Where's the db and ini stored
Reporting Bugs
Where tags are stored

Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig

Post Reply