Multiple Artists, ';' separator, etc. - discussion

[ZvezdanD]

The problem with a "multi-field" approach is that if I'm thinking of what you're thinking of, them it's even less ID3 compliant then some of the other things mentioned previously. Are you indeed talking about saving Artist 1 into an Artist frame, then saving Artist 2 into a separate Artist frame?

I think that you wrongly interpreted spacefish's suggestion. You should separate look at GUI from tags - those are two related but different things. Spacefish suggested GUI approach, not storing tags into a file. So-called multi-field GUI approach is most obvious on CATraxx example given before. This approach is good because MM don't need to artificialy guess which are separators between artists. Unfortunately, this approach has one drawback which is already mentioned - it is difficult to copy/paste full multi-artist name in one go. But, spacefish already gave you a suggestion about that (http://www.mediamonkey.com/forum/viewto ... 609#142609):

If the option for both single line and structured multi line editing were available everyone would be happy

Perhaps there could be an extra field below the area where one enters artists that shows what the parsed multiple values will look like.

I suggest a single-line field to be above of the multi-artists table:


Now, about tagging - jiri is right. There should be two different tags in each track with multi-artists. Please take a look on my suggestion about this:
http://www.mediamonkey.com/forum/viewto ... 810#143810

It is only questionable if we should use IPLS (Involved people list) for this extra tag as jiri suggested or maybe TXXX (User defined text information frame) suggested by me.

[chrisjj]

> The current MM default is ";" the current WMP default is ";"
> (one of the reasons it was chosen for MM) it should stay ";"

The current MP3 standards default is '/', note.

> I'm sorry that you migrated from an application in
> which ";" wasn't the default

You're mistaken - I didn't.

> but that is no reason to force current users to redo their
> libraries when this is introduced.

The proposal does no such thing - the users needs only set an Option.

> Explain this
>> The default is just "/", giving ID3V2.3 compliance

By that I mean the default be just "/", so that an ID3-compliant value e.g. Artist1/Artist2/Artist3 is interpretesed as such - regardless of the content of Artist1 etc., note.

> Are you now saying that the tag dosen't look like this: Artist1/Artist2/Artist3?

No.

> Jiri has already assured us that the "exception" list will be maintained
> automatically using this solution

Regardless exceptions will have to be specified by the user since MM is not a mind-reader.

> With "1/2 Pint" thats 4 exceptions I will have to enter manually (or none
> if they are included in an MM install) and thats all users should be
> expexted to do; not half their library that might have a "&" or "and" in it.

Agreed 100%. And by the same token - ';' .

[chrisjj]

> In practice, manually splitting artists that are pulled into a single field is
> a lot less of a hassle than upkeeping an additional list of exceptions.

Depends on the library e.g. I have many multiple artists and no '/' exceptions. Note also manual splitting Cannot obviate exceptions in a standard compliant solution. E.g. AC/DC.

> I can see the concern in how to transfer the existing data to the new
> methodology ... Everyone will have to adapt their data to it.

Sorry, that spells doom. MM's job here is to display standard tags in audio files, not to abuse that tags storage for it's own proprietary scheme and then require the user to "adapt". The current ';' messup is bad enough. Any more like that will be disasterous.

>> 3 In another enter Artist "Jam & Spoon" - 2 artists so far...
>> 4 Hit hotkey to add to exceptions - 1 artist
>> 5 In another enter Artist "Jam & Spoon" - 1 artist

> So now I have to enter the artist twice.

No. My example entered the artist again olny as required for another track.

> This is exactly what I was trying to prevent

Me too! :)

[chrisjj]

> ID3 standards specify that multiple values be saved with "/" ...
> WMP & now MM interpret this in their UI as ";".
> One could argue that both WMP & MM are wrong in this approach.

No - the spec doesn't specify the display. MM is spec-wrong only that it fails to SAVE with '/'.

> At this rate, it would probably just be easier for it to be left in
> "Artist 1; Artist 2" form and then simply let those who want to
> keep "feat." information

Agreed, except that the current ';' messup must be rectified.

[chrisjj]

> 5. That's a question - if it isn't stored in tag in any way, other applications (or even other
> instances of MM) won't be able to properly separate individual artists.

If it (inc. alternative seperators) IS stored in a tag in any way, STILL other applications won't properly separate because they don't share an interop standard. I agree such a standard would be good, but I suggest MM should first get its own house in order.

> it misses one feature... To be able to assign some artist to a track
> (e.g. 'Iron Maiden'), but show it also under other artists (like 'Bruce Dickinson').

Sorry, I overlooked that, because it is not actually an issue of multiple artist, but multiple artist name i.e. alias. Hence that the appropriate place (think "normal form") for an alias table is app Options, not tags.

[Mizery_Made]

Actually jiri isn't talking about "Alias'," Bruce Dickinson is the lead singer of Iron Maiden, not an alias he goes by. His suggestion is giving the capability to link for instance, Travis Barker to a song by Blink-182, but also credit him for his work for +44. Both are bands he belongs to, not alias' he goes by.

You could say that this is what the IPLS frame is for, linking Travis Barker as the Drummer on each, however he wouldn't show up as an 'Artist' for these tracks which technically he is an artist of the song, even though he did the work under the flag of +44 or Blink-182.

[chrisjj]

Actually jiri isn't talking about "Alias',"

I should have checked Jiri's original... but couldn't find it and still cannot. But I did find

from UI point of view, there wouldn't be any connection between artists and involved people

so perhaps we can simplify this discussion about artists by leaving out involved people, (not-)aliases etc.

[spacefish]

No. My example entered the artist again olny as required for another track.

Okay, that wasn't clear at all.

chrissjj, you have completely missed every point I made. I never once suggested that MM "abuse that tags storage for it's own proprietary scheme and then require the user to "adapt". " Do you seriously think that users will not have to adapt to any change that the devs make to this system? Given your example, and the fact that you ask a user to enter an artist in two places, I can't seriously see how you believe no "adapting" will be required. Your method is extremely different than anything we have now. What? I don't have to adapt my existing data using your method? Is MM simply going to read my mind to know which artists I want in the exception list?

Also, you didn't address how your method would handle multiple exceptions. I'd be interested to hear how you'd resolve that.

ZvezdanD pointed out that yes, indeed, I'm making a separation between the GUI and tag storage. Hence why I stressed that tag parsing must also be considered in the design process. If it's not then all we've got is a new way to enter multiple artist data but no good way to report it.

I've given several suggestions for my own vision and also adapted other suggestions to something that I think would work given MM's current basis with as little pain as possible to the average user, including yours. That's what good design comes from. Collaboration and recognition that other people might actually have better ideas than you do.

People tend to resist change, especially big ones, so I think it's important that this be done right -ONCE- rather than finding out later how much it doesn't really work at all. Constantly changing a program without regard to its affect on the user is irresponsible, even if that change does something really perfect and necessary. Applications that don't consider the user in the design process tend not to have any users once it's done.

If jiri wants to add a relationship table, more power to the monkey! I certainly won't object.

[Owyn]

I watch this thread and I have to admit it keeps my head spinning.

When the dust settles I hope someone will recap this in the Wiki, hopefully without edit wars.

[chrisjj]

> Do you seriously think that users will not have to adapt to any change that the devs make to this system?

Except for the change that backs out of the current ';' messup, then yes I do.

> Given your example, and the fact that you ask a user to enter an artist in two places,
> I can't seriously see how you believe no "adapting" will be required.

I don't ask a user to enter an artist in two places. The user has a choice - for pre-existing requirements, he does not change his usage.

> What? I don't have to adapt my existing data using your method?

Correct - once the ';' messup is fixed, your original data will work fine as it did. If you want to use a new multi-artist scheme, then you add the absent multi-artist info to your data.

> Also, you didn't address how your method would handle multiple exceptions.

What makes you think "Options has also a list of exceptions e.g. "AC/DC"" and "4 Hit hotkey to add to exceptions" doesn't do that?

> changing a program without regard to its affect on the user is irresponsible

Yup, that's why the current version is unacceptable for production release.

[spacefish]

How you fathom that no one will need to adapt to your method is beyond me. Anything different will require adaptation. It's just plain common sense.

> Also, you didn't address how your method would handle multiple exceptions.

What makes you think "Options has also a list of exceptions e.g. "AC/DC"" and "4 Hit hotkey to add to exceptions" doesn't do that?

Tell me then, if I enter into the artist field

Jam & Spoon, Crosby, Stills, Nash & Young, Rod Stewart, Bryan Adams & Sting, Dan Turèll + Halfdan E

how will I get everyone except Rod Stewart, Bryan Adams & Sting into the exceptions list separately by pressing a hotkey?

[chrisjj]

How you fathom that no one will need to adapt to your method is beyond me.

Sorry SF, clearly I was unclear ;). What I mean is: going from the current MM production release to my proposal, no user who wants the existing (combined artists) interpretation needs adapt, because the new is compatible with previous data and usage (though not identical in the case of MP3 '/', so perhaps an Options checkbox is needed). No user who wants standard (i.e. /-separated) multi-artist interpretation has to adapt either. The user who wants custom multi-artist interpretation necessarily adapts - declares any custom separators (e.g. ", "," feat. ") and any artist exceptions (but just once per artist) e.g. "AC/DC".

Tell me then, if I enter into the artist field

Jam & Spoon, Crosby, Stills, Nash & Young, Rod Stewart, Bryan Adams & Sting, Dan Turèll + Halfdan E

how will I get everyone except Rod Stewart, Bryan Adams & Sting into the exceptions list separately by pressing a hotkey?

Ah, multiple /new/ exceptions in a /single/ new artist property value. I get you - thanks. Well I suggest if the Devs thought it was worth it, make that hotkey (or menu/button command - let's call it Mark As Single Artist) let you enter:

Code: Select all

Jam & Spoon[MASA], Crosby, Stills, Nash & Young[MASA], Rod Stewart, Bryan Adams & Sting, [select>]Dan Turèll + Halfdan E[<select][MASA]

i.e. MASA enters onto the exception list the selected text if any, else the leftward text less any existing exceptions and terminal separators.

I think this would be really easy to use.

[spacefish]

How you fathom that no one will need to adapt to your method is beyond me.

Sorry SF, clearly I was unclear . What I mean is: going from the current MM production release to my proposal, no user who wants the existing (combined artists) interpretation needs adapt, because the new is compatible with previous data and usage (though not identical in the case of MP3 '/', so perhaps an Options checkbox is needed). No user who wants standard (i.e. /-separated) multi-artist interpretation has to adapt either. The user who wants custom multi-artist interpretation necessarily adapts - declares any custom separators (e.g. ", "," feat. ") and any artist exceptions (but just once per artist) e.g. "AC/DC".

Okay. So basically you're saying that this method will work for everyone but only folks who want multiple artists parsed in a logical and friendly manner (i.e. Queen & David Bowie, not Queen/David Bowie), will need to adapt. Please correct me if I'm wrong.

Still, I think that a majority of users will want to see their artists, as well as report them via plugins, etc., in a friendly way and not with a straight slash (the reason I've been pushing for parsing methods at the same time during this discussion). Is it worth the extra work (because there will be a lot more with your method than there is currently) to update exception tables and separator options manually? I don't think it is. I believe the program should do as much of the work as possible. Yes, some values for separators will need to be entered initially by the user but designed into the work flow of adding/editing properties, rather than a separate options table, makes it virtually invisible to the user.

Multi-field method: I don't have that multi-artist separator defined? Add + here next to the artist (tandem to the artist field in the properties window; available in a pull-down menu next time I need to use it as a multi-artist separator). Since this method only assigns one artist per artist field, I don't have to worry about the + in the next band's name. MM knows it's only one artist because it's in an artist field.

Your method: I don't have that multi-artist separator defined? Cancel out of properties, go to options, remember where I need to add this + symbol, add it there, (do I need a separator between my separators?), click OK. Click properties again, edit track as usual. Next time I have an artist with + in their name though, I have to decide whether or not to add them to the exception table too otherwise the program will think it's a multi-artist separator.

Lot more steps in your method and I have to worry about the next artist that has in their name a symbol I might have added to the separator list. Too much thinking for me!

Tell me then, if I enter into the artist field

Jam & Spoon, Crosby, Stills, Nash & Young, Rod Stewart, Bryan Adams & Sting, Dan Turèll + Halfdan E

how will I get everyone except Rod Stewart, Bryan Adams & Sting into the exceptions list separately by pressing a hotkey?

Ah, multiple /new/ exceptions in a /single/ new artist property value. I get you - thanks. Well I suggest if the Devs thought it was worth it, make that hotkey (or menu/button command - let's call it Mark As Single Artist) let you enter:

Code: Select all

Jam & Spoon[MASA], Crosby, Stills, Nash & Young[MASA], Rod Stewart, Bryan Adams & Sting, [select>]Dan Turèll + Halfdan E[<select][MASA]

i.e. MASA enters onto the exception list the selected text if any, else the leftward text less any existing exceptions and terminal separators.

I think this would be really easy to use.

So type in first artist name, press hotkey, type in second artist, press hotkey, or... ? Or if there's a requirement to go back and select things afterwards and press hotkeys at each selection and go OOPS I selected too many letters now how do I fix it? there's going to be a lot of confusion. I'm not saying it couldn't work. I just think it's a cumbersome method and perhaps needs a more streamlined mechanic. Lots of steps needing to be retraced which could just as easily be avoided with a multi-field interface.

[Mizery_Made]

I had to read over your "Multi-Field" proposal again, Spacefish, before I got an idea of what you were on about. So you're proposing that there be a text area where you would enter an artists name (Artist & Some Band) and then if there are other contributing artists, you would select next to this box an option of "featuring" for instance which would open up a second text area where you could enter a second artist (Lead Singer from Other Band). Then in the main window, this would show up as "Artist & Some Band featuring Lead Singer from Other Band" yet correctly parse into two seperate artists in the tree?

If that's indeed what you're proposing, I think a few things are lost with this approach. The ease of Copy & Pasting a string of artists into a single box is lost as you now have several boxes for the various artists participating.

How would this be saved to the MP3 tags? How would MediaMonkey handle importing MP3s with these kinds of values when the MP3 is first scanned into the database? Just a couple questions that pop into my head.

[spacefish]

I had to read over your "Multi-Field" proposal again, Spacefish, before I got an idea of what you were on about. So you're proposing that there be a text area where you would enter an artists name (Artist & Some Band) and then if there are other contributing artists, you would select next to this box an option of "featuring" for instance which would open up a second text area where you could enter a second artist (Lead Singer from Other Band). Then in the main window, this would show up as "Artist & Some Band featuring Lead Singer from Other Band" yet correctly parse into two seperate artists in the tree?

Actually, nothing new would open. It would be just that, a multi-field area where each name is entered separately. More below.

If that's indeed what you're proposing, I think a few things are lost with this approach. The ease of Copy & Pasting a string of artists into a single box is lost as you now have several boxes for the various artists participating.

I already addressed this earlier in the thread and ZvezdanD illustrated it in a post at the top of this page:

Perhaps there could be an extra field below the area where one enters artists that shows what the parsed multiple values will look like.

I suggest a single-line field to be above of the multi-artists table:

How would this be saved to the MP3 tags?

The extra, "combined" field would show the completely parsed values. This is the value that would get displayed or reported to plugins. If we're looking for the tag to be truly standards compliant, I suppose it has to store multiple artists separated by slashes. MM would have to translate these internally. If each artist isn't stored in a separate frame, and the tag must end up being ArtistA/ArtistB in it's raw format, then there must be some other mechanism in place to report the values in a friendly way for views and plugins. I know I don't want ArtistA/ArtistB in main views or in my last.fm profile just as I don't want ArtistA;ArtistB now.

How would MediaMonkey handle importing MP3s with these kinds of values when the MP3 is first scanned into the database?

Scanned into the combined artist field, MM could attempt to separate artists based on information it already has. Alternatively, it could simply populate the first artist field (leaving the combined field for parsing alone), and then the user can make any separations required, if any. Since the majority of track artists won't require further handling, I'd vote for the latter since it makes the combined field a true representation of the values in the multi-artist fields.