Well, I'm not going to argue with you. I never suggested that MM should use a "non-standard" style. I only said that a better interface is needed in addition to supporting the standard. I used CATraxx as a reference because it has more flexibility with multiple values than MM has. MM is a tagger/media player with some database functionality while CATraxx is a database with some media player/tagging functionality. Merging the two programs would make one sweet app. Indeed, the two developers could learn a lot from each other, if only the programs weren't written in different languages.

I want standards-compliance /and/ usability, and see no good reason why MM cannot deliver, and better than lesser programs.

And that was my point.

I started a new thread with some related info here.

Jiri

I have no idea ... whether or not it's compliant

ITYF it is not.

I'd much rather have a program that parses (exports) multiple values in a meaningful way, which CATraxx does and MM (currently) does not.

AFAICS, CATraxx doesn't export (or indeed support otherwise) ID3-standard multiple artists any better than MM.

It's all well and good to have MM conform to the standard, but it's useless to me if all I see and all it passes are slashes in my artist names.

Agreed. Except I a CATraxx-style non-standard solution is useless to me. I want standards-compliance /and/ usability, and see no good reason why MM cannot deliver, and better than lesser programs.

As I said, I don't know about how individual frames are written but that's in any software. CATraxx does show multiple artists. I have no idea how the metadata gets written or whether or not it's compliant though I'm sure it could be easily determined. I've been using the program since long before it had tagging functionality.

I do know that for organizational/sorting/data retrieval purposes CATraxx is far more robust and flexible than MM. I really wish the two apps could be merged. Since I have little faith that last.fm will ever become "ID3 compliant", I'd much rather have a program that parses (exports) multiple values in a meaningful way, which CATraxx does and MM (currently) does not. It's all well and good to have MM conform to the standard, but it's useless to me if all I see and all it passes are slashes in my artist names.

As an end user, I don't care what the separator is. If the standard says it's a slash, fine (though I have to wonder what would happen to artists like AC/DC). I have no problem with that and agree that MM should try to meet any standard as best it can. I just want the program to accept, organize, and display that data in a friendly and meaningful way. If services like last.fm could also read that metadata properly and parse it correctly on their end, well all the better but I sure won't be turning blue over it.

spacefish wrote:

chrisjj wrote:I cannot see it being practical for the tracklist to have multiple Artist columns and the Property dialog have multiple Artist fields.

CATraxx has been doing this successfully for years.

CATraxx can show columns for different role artists but surely not for different multiple artists in Artist as per the ID3 spec.

I certainly don't want my tracks to read Joe Blow/John Doe - A Song for You. They'll be next to useless when I submit them to last.fm.

That's an issue of export not storage. If last.fm import was ID3-compliant, there'd be no problem.

I can also use things like 'vs.' and 'feat.' so that multiple artists appear with those separators instead

Indeed cool, but I think those are role designators and not (just) separators. The separator issue is just about representing multiple /indistinguished/ artists in a single property.

chrisjj wrote:> What we really need is multi-FIELD functionality where there is one
> value per field per tag item.

Field... as in display/edit field? I cannot see it being practical for the tracklist to have multiple Artist columns and the Property dialog have multiple Artist fields.

CATraxx has been doing this successfully for years. Granted, it would mean quite a bit of change for MM's environment but it can certainly be done.

As far as tagging is concerned, only the parsing of the multi-value separator is a concern (I honestly don't know how tag "frames" are written in any of the software I use). While it may be nice for the ID3 standard to say that '/' is a multi-value separator, I certainly don't want my tracks to read Joe Blow/John Doe - A Song for You. They'll be next to useless when I submit them to last.fm. CATraxx uses '&' as the default parsed separator but this is configurable. I can also use things like 'vs.' and 'feat.' so that multiple artists appear with those separators instead AND I can use multiple separators in a string.

chrisjj wrote:Why they went to the bother of excluding the subsequent values, GOK

Thanks.

SDK consistency? WMA containers, which have "true" support for multiple names in metadata, doesn't use text delimiters... and it only shows the first one, too.

> The XP shell, however, only shows the first name "by design."

Ah!

> So, for MP3, it does still parse the name via "/" as defined in ID3v2.3,
> but it ignores the other names. They didn't bother with a UI to deal
> with it.

Why they went to the bother of excluding the subsequent values, GOK ;)

Thanks.

chrisjj wrote:> all associated Microsoft media applications -- including the Explorer shell -- do.

Explorer XP shell does??? That could be useful. Could you give details?

Vista shell does 100%, including editing the multiple names in metadata fields that allow it. The column views even say "Artists" and "Composers" instead of the singular versions.

The XP shell, however, only shows the first name "by design." So, for MP3, it does still parse the name via "/" as defined in ID3v2.3, but it ignores the other names. They didn't bother with a UI to deal with it.

> Requiring the user to use separators, know what they're for, where
> and when they can use them is just not very friendly.

Agreed, but worse is that MM messed up my standard use of those characters, e.g. http://www.mediamonkey.com/forum/viewto ... 092#141092

> What we really need is multi-FIELD functionality where there is one
> value per field per tag item.

Field... as in display/edit field? I cannot see it being practical for the tracklist to have multiple Artist columns and the Property dialog have multiple Artist fields.

And what about mask variables such as <Artist>???

> all associated Microsoft media applications -- including the Explorer shell -- do.

Explorer XP shell does??? That could be useful. Could you give details?

What we really need is multi-FIELD functionality where there is one value per field per tag item. MM can then do whatever it wants with those values in the background when it writes the tag. Requiring the user to use separators, know what they're for, where and when they can use them is just not very friendly. Following the ID3 standard would certainly be a plus but a more intuitive interface is no less important.

chrisjj wrote:It does not. With "artist a/artist b" in an MP3 Arist field, MediaMonkey (V3.0.3.1148) fails to enter album a on the Artists node and fails to enter artist b on the Artists node. This is a major failure to follow ID3V2.3.

Correct. The current MediaMonkey release does not handle it. Windows Media Player 10/11, and all associated Microsoft media applications -- including the Explorer shell -- do.

If you follow the ID3v2.3 informal standard, which is the de facto tagging standard for MP3, you should obey the "/" as a delimiter if your application supports the concept of multiple discrete names per tag. Remember to put in an explicit workaround for AC/DC, like Microsoft.

As a bonus, for applications that don't support the concept... the user will still see/edit the multiple names with the real "/" between them so you get some interoperability.

As I mentioned in another thread, there are very few people that have implemented this or even bothered with the concept of multiple names. But since MediaMonkey does now handle multiple artists, etc... it should go for full compatibility as an option.

Anyway, ID3v2 is a poor design, but it's what we're stuck with for MP3.

ID3V2.3 says mulitple strings in text fields are to be separated by "/". Id3V2.4 says multiple strings in text fields are to be spearated by a NULL. If multiple values are implemented, please implement them based on the standard.

MediaMonkey follows the standards.

It does not. With "artist a/artist b" in an MP3 Arist field, MediaMonkey (V3.0.3.1148) fails to enter album a on the Artists node and fails to enter artist b on the Artists node. This is a major failure to follow ID3V2.3.

> ID3V2.3 says mulitple strings in text fields are to be separated by "/".

Note: it says "/" is a multiple value separator in some specific text fields, but not text fields in general. And it says in some other specific fields, "/" has a different special meaning e.g. separating track number from track quantity.

> If multiple values are implemented, please implement them based on the standard.

Absolutely!!