Multi-item fields request

[Teknojnky]

artists, genre's, etc...

Please let us choose which delimiter we want to use.

Semi-colon's look ugly.

Personally I would prefer to use the pipe char "|" especially since that is rarely, if ever, used by any normal artist name or genre.

Some other folks may prefer to use the slash or backslash.

In any case, the user should be able to control what delimits multiple items per field.

[judas]

I back this request! I think I would use a slash, or even a coma.

[emalvick]

I definitely don't want to see the comma become the only delimiter (if that were to happen) because I rely on having my artists in the way of "last, first". I actually think the pipe is a good idea as it is a rarer character and does look better than a semi-colon (although I thought the semicolon would be ok until I saw an earlier post by Teknojnky regarding a group that the semicolon was part of the name.

[Macarena]

Ath moving on this topic, or is this close and the delimiter was agreed to be a semicolon ";"? IMHO,
comma , -- very, very not wise
pipe | semicolon ; slash / and backslash \ -- great (well, we have to solve the AC/DC feature)
"let us choose which delimiter we want to use" -- absolute gorgeous option, but I guess it's about the .mdb definition.

Regs,

[REIKA]

I think that the display form on MM3 is not important. I do not care about the semicolon either.
However, the delimitation written in the ID3V2 tag is embarrassed in the semicolon.
In ID3V2, it is sure to be provided to use slash.
It is necessary to refrain from the way to make the generality of the user data lost by the convenience of specific software.
At least, I think that the form based on the specification should be made available by the option.

[rusty]

keep this discussion going...we want to change this post 3.0.

Note though: although the ; is used in the MM ui, this has little to do with how the data is saved to a tag (i.e. the visual representation is distinct from the tagging format, and the tagging format is done as per the tag format's standard).

-Rusty

[Teknojnky]

Thanks Rusty, Ideally, the user would be able to choose exactly which delimiter is used for both _displayed_ and what tag formatting is used (ie v2.3 or v2.4 or even CUSTOM delimiter).

The 2nd is important for people with oddball devices or other programs... instead of trying to restrict MM to only certain things, the user should have alot more control over tagging aspects so that they can easily configure MM to fit in well with other applications/devices that are not as flexible and powerful as MM.

[Guest]

Thanks Rusty, Ideally, the user would be able to choose exactly which delimiter is used for both _displayed_ and what tag formatting is used (ie v2.3 or v2.4 or even CUSTOM delimiter).

The 2nd is important for people with oddball devices or other programs... instead of trying to restrict MM to only certain things, the user should have alot more control over tagging aspects so that they can easily configure MM to fit in well with other applications/devices that are not as flexible and powerful as MM.

I agree strongly. I'd never though about it before. I just checked out the ZVM forum on creative.com, and there is no discussion growing on the multiple genre/artist topic. All of them end with "unfortunately, not supported on ZVM." But what if later they start to support it - either on ZVM or on some new device, but they will use sth else then semicolon? Or, what if any main producer (Apple, Creative, MS,...) will support a different delimiter than MM would now agree on and also different from id3v2. IMO, they should go towards id3v2.3 (v2.4) format (so should MM, that was already mentioned above by REIKA - thanks for this). But finally, there is only a market agreement and a market decision. I hope I'm too scared, only.

I wish MM would belong to tools with such a flexibility -- to choose a delimiter on user's own.

BTW, there is already a function while synchronizing -- to synchronize only the first genre/artist. Does it mean MM actually cuts the tags inside the tracks? I believe there is only a step forward to create another line with: "Choose delimiter for the synchronized files: <space>".... In this sense, nobody has to implement a variable delimiter into MM, just to make him learn a new way of export (and then checking on the device)

Regs,
Macarena

[mattisse]

Instead of a delimeter between 2 artists, I'd suggest a delimiter around one artist (sort of an opening and closing tag).
This delimiter would only be saved in the tag, but not visually represented.

The main advantage is that users can put whatever they want between two artists: commas, semikolons, feat., with, and, &, vs., ...

Example with the pipe sign as delimiter:
Stored in tag: |The Beatles|, |Earth, Wind & Fire| feat. |The Rolling Stones|
Visual representation: The Beatles, Earth,Wind & Fire feat. The Rolling Stones

You could also use 2 different delimiters to distinguish between main artists and supporting artists.

[ZvezdanD]

This delimiter would only be saved in the tag, but not visually represented.

I already said long time ago that users don't want to know anything about some separators (http://www.mediamonkey.com/forum/viewto ... 5505#95505). MM developers should re-design the Track Properties dialog where user could enter multiple values without thinking about some separator.

Please, take a look on another musical cataloger - in the second column of the Artist table you could enter Vs, Feat, Pres. or whatever you want. It had multi-item support several years before MM and it is a way better.

[spacefish]

Please, take a look on another musical cataloger - in the second column of the Artist table you could enter Vs, Feat, Pres. or whatever you want. It had multi-item support several years before MM and it is a way better.

Hah! CATraxx ftw! This is clearly the way it should be done. I talk about it here and I've added it to the wishlist discussion.

[Bex]

Yes, I support a change here too. I don't want to lose my feat./pres./vs./and/& etc but I still want the separate artists to be individual in the nodes.