Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[m1abrams]

One thing I have noticed is that MC does not support multi-artist tracks.  Ideally the support should be able to handle it based on the tag structure (i.e. if using vorbis comments support it via multiple artist tags, or if using id3 then support it via delimited list), short of that maybe just support it via delimited list for all tag formats.

Edit: This would also be nice for Composer as well.

[MusicHawk]

Wonderful suggestion! In many music genres, a single song is performed by multiple "name" artists and could validly be organized by any one of them. Jazz does this routinely, as does classical.

For instance, is a recording by the Boston Pops conducted by John Williams best listed under the orchestra name, which would also include the Boston Pops conducted by Arthur Fiedler (and others), or by the conductor, which would exclude Fiedler but include Williams' movie theme recordings, etc. Both are desirable ways to organize the same recordings.

Treating the Artist field as multi-value (a la keywords) via delimiters would be a terrific tool to build views and playlists. The same applies for Composer, where multiple names and different combinations of the names is common.

However... if this is implemented, I hope the delimiter is NOT be a comma (probably ; is safe) because some users (like me) use commas in the Artist field for Lastname, Firstname to organize artists the same way most music catalogs and references do.

(The other choice for sorting/grouping could be Album Artist, but Artist is the only artist-related field that transfers to an iPod. I picked up the Last, First recommendation for Artist here a few years ago and it was terrific advice.)

[Matt]

You can add any number of list-type fields in Options > Library.

[hit_ny]

Yes, but the caveat is that its a nonstandard field.

So you can create an [Artists] field of list type and it will be a multi-artist field.

However MC is the only app able to read it, if you saved tags to files.

There is no std for multi-artist fields, so this is the only proprietary compromise available.

[m1abrams]

You can add any number of list-type fields in Options > Library.

Problem here is MC has hijacked the ARTIST and COMPOSER fields making that solution not practical.

[dcwebman]

So you can create an [Artists] field of list type and it will be a multi-artist field.

However MC is the only app able to read it, if you saved tags to files.

And you use something other than MC? 

I followed the lead of one of our experts here and created an Artists field just for this purpose. I base my file renaming of the songs off the Artists field and the directory off Artist. So in the one example, the Artist field would contain Boston Pops with the list in Artists. The nice thing is I can set up a view too and base it off Artists so that way I get every artist that has performed on a song. It's been working fine for me for the last year.

[MusicHawk]

>> There is no std for multi-artist fields

What happens if another tag-reader (library manager and especially iPod) encounters a field that has multiple values separate by semicolons? Does it read the entire string as one value (without messing it up), or read just the first value (which assumes the delimiter is recognized) and discard the rest?

If MC allowed multiple values for Artist and Composer (or, allowed a custom field definition that overrides the original field of the same name) and other software tolerated this, it could be the perfect solution.

If other programs/devices simply saw it as a normal field, and accepted the entire contents, delimiters and all, they wouldn't break the data. MC would use its multi-value logic while other programs would just see it as a single value that happens to include semicolons.

[m1abrams]

>> There is no std for multi-artist fields

Actually Vorbis comments do have a standard for multi-artist fields, it is by allowing more than one Artist comment to exist in the data block.  However for whatever reason many apps choose not to follow this standard.  My guess is because it does not "flow" well with other tag systems like ID3.

The only issue MC would have that I can think of is syncing with handhelds, in which case it could just take the easy way out and only use the first entry for such a field.

If they just stored the data as a delimited list other software should just see it as any other string.

[m1abrams]

There is no std for multi-artist fields, so this is the only proprietary compromise available.

There is a standard, check the Vorbis Comments definitions.

[hit_ny]

What happens if another tag-reader (library manager and especially iPod) encounters a field that has multiple values separate by semicolons? Does it read the entire string as one value (without messing it up), or read just the first value (which assumes the delimiter is recognized) and discard the rest?

Nothing, the pod won't read it.

If MC allowed multiple values for Artist and Composer (or, allowed a custom field definition that overrides the original field of the same name) and other software tolerated this, it could be the perfect solution.

Override isn't the accurate term here, its more like in-addition to.

The list fields are in addition to the standard Artist & Composer which remain as is.

If other programs/devices simply saw it as a normal field, and accepted the entire contents, delimiters and all, they wouldn't break the data. MC would use its multi-value logic while other programs would just see it as a single value that happens to include semicolons.

Again this is a propetary way they handle multi-value fields, WMP (amongst others) again has its own way to do the same.

There isn't a widely accepted standard (to my knowledge) as of yet, to handle multi-value fields.

[m1abrams]

There isn't a widely accepted standard (to my knowledge) as of yet, to handle multi-value fields.

Ok again at least with Vorbis Comments (FLAC, OGG, etc) there is an accepted standard for multi-value fields.  You just have multiple tags of the same name.

[MP101User]

I'd like to add my weight to this request.

I've also had to set up extra "Artists" and "Composers" fields which is a biy of a kludge. I think Composer shoulod definitely have been a multi-value list field from the start.

Bet it's a bit of a nightmare to unpick though. I'm not holding my breath on this one...

M.

[glynor]

I have some real concerns over this...

I can understand your frustration.  I too at one time tried to set up a Multi-Artist field, but I abandoned it because it was too difficult to make sure the regular [Artist] field, and the [Artists] field always matched.  The problem is that I use my files in a wide variety of different Handhelds and with a number of different media player applications (I have Macs and Linux computers).  So, I need the "standard" ID3 Artist tag to be filled properly.  I don't want any ";" or other weird stuff in the [Artist] (or [Genre] tag) at all.  In most cases where I want multiple artists, one artist is the "primary" and the rest are more "backup" or "supporting".  I'd want the [Artist] tag filled with the primary and the [Artists] tag filled with them all.  But, like I said, this was far too complicated to maintain manually.

However, I do NOT want the [Genre] and the [Artist] field to change to list-type fields, as some have suggested here!!  That solution would be much worse than the problem.

There are a number of reasons for this.  First of all, I'm anal and when I view my files on my Mac in iTunes or on my Sansa or on my Linux boxes, I don't want a bunch of list type fields showing up in the panes like "so and so 1;so and so 2;so and so 3".  I spend time and make sure my files are tagged nicely so that all files by a particular artist show up in the panes together and I want it to stay that way!  If there was some way to make all other applications and devices somehow recognize the non-standard ID3 tag in the file to only show the first artist added, then this'd be fine.  I sincerely doubt this would be possible.  How would you prioritize which Artist was primary? MC simply shows them alphabetically for list-type fields, so that wouldn't work.  And besides, there is another (bigger) problem...

Another huge reason is that it would horribly hamper my ability to quickly tag large numbers of files.  For example, one of the fastest ways to tag huge numbers of files is using Drag-Drop in the tree.  With list-type fields, this adds the tag, rather than replaces it, which would completely ruin my tagging method.  For example, I prefer all my files to be tagged in this format for [Artist]: Last Name, First Name (or Beatles, the).  When I get a bunch of new files of a particular artist from the Amazon MP3 store or something, they're never tagged this way, and they're never in the right Genre.  To fix it, all I have to do is grab all of the new files, and drill down and find the artist in my Genre/Artist/Album view scheme and drop the new files onto the Artist's name in the Tree.  This fixes both the [Artist] and the [Genre] tag in one fell swoop.  If these were list-type fields, I wouldn't be able to use this method AT ALL because dropping "The Beatles" onto "Beatles, the" would tag it with BOTH options rather than replace the incorrect tag. This would increase my tagging time significantly for almost every single file I import.

List type fields also make tagging using the Tag AW much slower because it opens a separate dialog for those items, and generally makes changing or removing an already set tag much more difficult no matter what method you use.  List-type fields can be useful, but they are much slower.  Changing [Artist] and [Genre] (probably the two most commonly used fields in any library) to these "slower to work with" types, would be horrible from a work-flow point of view and completely unacceptable to me (and I'm sure many other users who haven't commented).

So... While I acknowledge that the desire for using multiple artists in a field (and Genres too I suppose, though I wouldn't use that feature at all) is a good one, and I acknowledge that the current method of using a separate list-type field has it's drawbacks, the solution proposed is much worse than the problem in my opinion.

[m1abrams]

Well personally I would not want the multi-artist to be supported via delimited list myself, that would just be the easiest method for MC to impelment.  Ideally atleast for file formats that support Vorbis Comments it would just have multiple ARTIST tags, in which case your fear would not happen.  Apps that do not support multiple tags will just grab the first tag.

Another solution would be to allow support for MC list fields ARTIST, COMPOSER, etc.  However by default make it a standard string and allow users to edit the type to list if they choose to.  However multi-tag support for formats that support would the the best solution.  Obviously this would not work with MP3 formats however that particular format does not have a good standard for multi-artist.

[glynor]

However multi-tag support for formats that support would the the best solution.  Obviously this would not work with MP3 formats however that particular format does not have a good standard for multi-artist.

Unfortunately that would violate one of the "rules" that makes MC so useful and powerful.  In that media files of one format would work one way and files of another type would work another.  The way MC works is that ALL media files of a particular [Media Type] work (as far as the tagging functionality is concerned) identically.  This is a big deal because you can be sure that your tagging operation will work no matter what without concern over what kind of files you are applying the tags to... In other words, It Just Works.

Not only that, but how precisely would you implement this in the UI without causing all of the workflow problems I mentioned in the above post, and without requiring you to have a special [Artists] tag?  I'm not seeing it.  Sure... You can store multiple [Artist] tags in some file formats, but MC can store whatever it wants in the file tags, by simply using it's own proprietary tags.  The capabilities of the file formats aren't the issue... The issue is how do you implement it seamlessly without breaking usability in other ways?

[m1abrams]

Unfortunately that would violate one of the "rules" that makes MC so useful and powerful.  In that media files of one format would work one way and files of another type would work another.  The way MC works is that ALL media files of a particular [Media Type] work (as far as the tagging functionality is concerned) identically.  This is a big deal because you can be sure that your tagging operation will work no matter what without concern over what kind of files you are applying the tags to... In other words, It Just Works.

Not only that, but how precisely would you implement this in the UI without causing all of the workflow problems I mentioned in the above post, and without requiring you to have a special [Artists] tag?  I'm not seeing it.  Sure... You can store multiple [Artist] tags in some file formats, but MC can store whatever it wants in the file tags, by simply using it's own proprietary tags.  The capabilities of the file formats aren't the issue... The issue is how do you implement it seamlessly without breaking usability in other ways?

Actually you are wrong in the MC does have to treat different file formats differently.  The tag types and structures of say ID3 are very different than Vorbis Comments.  However MC does this behind the scenes so the end user does not have to worry wether the tag is  TALB or just ALBUM.

To handle multipe tags under MC should not be any issue, other tools can do it fine.  Your issue is that when you open the file with another program you do not want the tags to be messed with.  By following the standard defined by the format then any app that also follows the standard should not have a problem with it.  Keep in mind I am not talking about MC doing any non-standard, actually the opposite.  Now for handle different formats (mp3, flac, etc) MC needs to of course do this in such a way that it is not apparent to the user.  This is not a simple task of course but it is far from impossible.

[glynor]

Actually you are wrong in the MC does have to treat different file formats differently.  The tag types and structures of say ID3 are very different than Vorbis Comments.  However MC does this behind the scenes so the end user does not have to worry wether the tag is  TALB or just ALBUM.

No.  I'm well aware of that.  I'm saying that the non-behind the scenes part of MC would have to be inconsistent.  My point was that you can't support multi-artist on OGG, FLAC, and the others, but not support it on MP3.  That would be terrible!  The reason MC's UI is as nice as it is because it treats all "audio" files the same, even if the underlying file format doesn't support something.

To handle multipe tags under MC should not be any issue, other tools can do it fine.  Your issue is that when you open the file with another program you do not want the tags to be messed with.

That is NOT my only issue, not even my primary one.  Read my previous post in its entirety before responding.  My point was... HOW do you propose that MC's UI actually accomplish this without making the [Artist] tag more difficult to work with?  If you can make a proposal, I'm sure that people here will be happy to support it.  My issue was that the proposals made thus far are not workable, for the reasons I outlined, and I think the JRiver folks know it.

[m1abrams]

No.  I'm well aware of that.  I'm saying that the non-behind the scenes part of MC would have to be inconsistent.  My point was that you can't support multi-artist on OGG, FLAC, and the others, but not support it on MP3.  That would be terrible!  The reason MC's UI is as nice as it is because it treats all "audio" files the same, even if the underlying file format doesn't support something.

I agree with you that the UI needs to handle them as if they are the same.  For mp3s that can be accomplished by storing the "extra" data in a library only field and the "primary" artist in the tag, downside to this approach is that the data is not available to other apps, course mp3 does not support multi-artist anyhow that should not be an issue.

That is NOT my only issue, not even my primary one.  Read my previous post in its entirety before responding.  My point was... HOW do you propose that MC's UI actually accomplish this without making the [Artist] tag more difficult to work with?  If you can make a proposal, I'm sure that people here will be happy to support it.  My issue was that the proposals made thus far are not workable, for the reasons I outlined, and I think the JRiver folks know it.

Not sure I understand the issue, why can the interface not work much the same way lists work currently?  Only issue is the current lists do not have a way to define the order, which would be needed to say which tag is the primary.  This could be done in a similar fashion as the sort fields handle order but the order in the clicks and placing a small number indicating the order.  However I am sure with a few others inputs better solutions could be made.  One thing I would want and I am sure you would, is that the interface should work just as simple as it does now if you only have a single value and only get more complex when you want to add multiple values.

[glynor]

Not sure I understand the issue, why can the interface not work much the same way lists work currently?  Only issue is the current lists do not have a way to define the order, which would be needed to say which tag is the primary.

Did you read my entire post before?  The way list-type fields work is slow and unweildy for mass-tagging!  They're fine for [Keywords] and other similar tags, but to change the most common tags [Artist] and [Genre] would make most of my (and others I'm sure) most common tagging operations take significantly longer.

And besides, there is another (bigger) problem...

Another huge reason is that it would horribly hamper my ability to quickly tag large numbers of files.  For example, one of the fastest ways to tag huge numbers of files is using Drag-Drop in the tree.  With list-type fields, this adds the tag, rather than replaces it, which would completely ruin my tagging method.  For example, I prefer all my files to be tagged in this format for [Artist]: Last Name, First Name (or Beatles, the).  When I get a bunch of new files of a particular artist from the Amazon MP3 store or something, they're never tagged this way, and they're never in the right Genre.  To fix it, all I have to do is grab all of the new files, and drill down and find the artist in my Genre/Artist/Album view scheme and drop the new files onto the Artist's name in the Tree.  This fixes both the [Artist] and the [Genre] tag in one fell swoop.  If these were list-type fields, I wouldn't be able to use this method AT ALL because dropping "The Beatles" onto "Beatles, the" would tag it with BOTH options rather than replace the incorrect tag. This would increase my tagging time significantly for almost every single file I import.

List type fields also make tagging using the Tag AW much slower because it opens a separate dialog for those items, and generally makes changing or removing an already set tag much more difficult no matter what method you use.  List-type fields can be useful, but they are much slower.  Changing [Artist] and [Genre] (probably the two most commonly used fields in any library) to these "slower to work with" types, would be horrible from a work-flow point of view and completely unacceptable to me (and I'm sure many other users who haven't commented).

[m1abrams]

Did you read my entire post before?  The way list-type fields work is slow and unweildy for mass-tagging!  They're fine for [Keywords] and other similar tags, but to change the most common tags [Artist] and [Genre] would make most of my (and others I'm sure) most common tagging operations take significantly longer.

I did read your post, however I do not find list fields slow at all for mass tagging.  However I may do my mass tags differently.  I select all the tracks I want to edit, then click Alt-Enter to bring up the edit tag window, then change the fields I want changed.  Wether the fields are multi select lists or just the artist is takes all about the same amount of time.  Which is why I do not see the issue, maybe if you tagging process is different than mine.

NOTE: I already have the ComposerS field and I find that a poor solution, which is why I started this thread.

[glynor]

Yeah... We do things differently.  I try to avoid using the Tag AW altogether if at all possible.  I generally only ever pull it up if I need to tag only one file, or to change [Name] tags manually.

You should try drag-drop tagging sometime!  It's amazing how much faster it is.  With properly constructed View Schemes, you can sometimes set 5-6 different tags on hundreds of files in one simple drag-drop move in less time than it takes to <tab> from one field to another in the Action Window.  I quite often will set [Artist], [Album], [Disc #], [Year], [Genre], and [SubGenre] all in one fell swoop (with one "move").  It also allows you to be very consistent with your tags, because it eliminates typos (when I manually type it, I constantly accidentally type Greatful Dead instead of Grateful Dead).

In fact, I really like how it works for the list-type fields like [Keywords].  When I'm sitting there keywording my pictures or movies, I usually have a View Scheme open showing all my existing Keywords in the tree.  And I just go through the files drag-dropping them onto keywords left and right.  I don't have to worry about what is already there, I don't have to worry about checking and unchecking boxes in a little display area (I have effectively my whole screen height to work with).  It's fantastic.  I just wouldn't like it for [Artist]!

[glynor]

I should just reiterate.... I agree with the premise, just not the proposed solution.  I too would love some way to be able to seamlessly tag multiple artists, while still have the [Artist] tag stay the way it is.

What I'm thinking is maybe a way to link different fields... So that you could have this:

[Artist] == the same regular stock, string-type field we're all used to.
[Artists] == list-type field, which always contains [Artist] automatically, but would allow you to add to it.  So, effectively, the first "item" contained in the list-type field would be =[Artist] (a pointer to the regular artist field).

You could do the same with many of the different fields.  [Genre] could have a "companion" [Genres].  The problem with the existing system isn't so much that [Artist] is limited, but that maintaining both [Artist] and [Artists] is unwieldy.  The biggest thing is that the maintenance would be automatic.  So that if you then change the [Artist] tag, it would automatically make the relevant item in the [Artists] tag match (and vice-versa).

And, behind the scenes, I agree wholeheartedly that MC should properly in-file tag those file types that do support multiple-tags (like OGG and FLAC) with the proper method (while using MC-only tags for those that don't, like MP3).

[m1abrams]

Hey I was never arguing my solution was the way to do it.

I like the solution you propose above, trying to think of issue that may happen.  One issue I can see is if they use the FLAC method of multiple tags how do you know which one is the first one?  Cause not knowing the first one would be very problematic, course my solution I had above suffered the same issue.  Not sure how much you can rely on order of entry in the metablock.  Maybe order in metablock is reliable, however I suspect if you edit outside of MC things could fall apart.

[glynor]

I would say that the "real" [Artist] tag should always be written out as the first one.  Any subsequent contents of [Artists] would get written out as "secondary" occurrences of the artist tag (for file types that support it).

One other thing that would be essential, if they implemented this solution, would be for the linkage to work both ways.  In other words..  Say I have this file: M:\Music\bright eyes\the album leaf & bright eyes collaboration volume 1\01 - hungry for a holiday.mp3

This file is part of a collaboration between "bright eyes" and "the album leaf".  For my own reasons, I want these all filed under "bright eyes" as the primary (so they show up under Bright Eyes on my Sansa, on my iPod, on my Macs and Linux boxes, etc).  So, I'd set the tags like this:

[Artist] = Bright Eyes
[Artists] = =[Artist], the album leaf

When you look at it in a column or in a pane though, [Artists] would just look like: Bright Eyes, the album leaf

This would result in the file being sorted under both Bright Eyes and the album leaf when I use the [Artists] pane in a View Scheme, but when I use the [Artist] pane (or view the file on a non-multi-artist supporting player) it would just show up in Bright Eyes.  What I'd need is for that =[Artist] to be linked "in both directions"... In other words:

Say I've tagged the file as described above, and a couple of days later I realize that I spelled "Bright Eyes" like "Birght Eyes" (I do this a lot -- fat fingers).  I should be able to change the [Artist] tag, and have the changes automatically reflected in the display of the [Artists] tag.  That's simple and obvious.  However, for it to be useful, I would also want to be able to correct it in the display of the [Artists] tag (if I happened to be using a View Scheme that wasn't showing both columns) and have the change automatically fix the real [Artist] tag.

What I'm afraid of is that this system, if not truely "bi-directional" would lead to the same problem.  That [Artists] would become disconnected from [Artist]. 

Another small "niggle" is that if I wanted to change the primary artist (continuing the above example)... If I change [Artist] to "the album leaf" then the [Artists] tag would contain effectively "the album leaf, the album leaf".  This isn't ideal, but is acceptable in my mind.  If you need to change the primary, you'll be expected to manually update the list-type field (because if there were 3 or more items in the list, MC wouldn't know which one to remove necessarily).

[m1abrams]

This issue I know is non-trivial.  It gets pretty hairy quickly.   If you can make the assumption that only MC touches the tags not so bad, however the day MC makes that assumption will be my last day using it.  That is my main problem with iTunes, that self-centered egotistically POS.  (I do own a mac).

The above solution as you can see requires many rules, and then what happens if the user edits the tags outside of MC.  I guess part of the rescan (update library from tags) could be coded to correct problems in the tags. But not sure how much editing I would want MC doing during that type of process.

Great now you are talking me out of the idea

I do like your idea of using a meta field to populate the list, but as you pointed out it is very important that it is bi-directional and also able to heal itself from outside tag modifications.

[glynor]

Update Library (from Tags) doesn't usually happen automatically.  When it does get initiated (manually or via Auto-Import), I'd say it should just follow two very simple rules...

(1) Fill [Artist] with whatever artist it first encounters in the file tags.  If there is only one, then all is good and right with the world.

(2) If it is reading the file tags (of a FLAC or OGG or APE or whatever) and it encounters a second instance of the [Artist] tag, then it should fill the [Artists] tag (which would probably be a library-only field) with:

[Artists]: =[Artist]; "second encountered artist here"; "third encountered artist here", "fourth encountered artist here"; etc.

That should also be how it writes them to file for the files that support it (if they implement in-file tag writing for this).  That would also allow you to use external programs to mess with the files, and it should work, at least for the file types that support it properly.

[m1abrams]

You know I like your idea, however the more I think about it I feel it might be too fragile and so far from standard.  I think maintaining a multiple artist within the Artist field, either via multiple tags for formats that support it or via delimited list for those that do not would be the least fragile solution.  Using just the artist tag would be supported the most if not all apps with the exception of mp3 that have to have delimited list.

Now I know you are concerned about the UI, and personally not using the tagging in the manner you do I can not comment on how to solve that.  But I think solving that UI issue would be easier than making the other system more robust.

Now I also think this should be an opt-in option since it can cause issues with mp3 tags and other formats that do not support multiple tag values, course it wont break anything or destroy the data, just would not be pretty in other apps.

[darichman]

What if MC were able to parse ", " and " & " internally for

This should allow it to separate Artist A, Artist B & Artist C into a list of each of the a artists...
it wouldn't be saving the tag in a non-standard format (great for handhelds) just changing the way it reads the tags in the library

[MusicHawk]

>> What if MC were able to parse ", " and " & " internally

Might be an idea, but keep in mind that artists and composers can be listed in various ways, including comma, ampersand, and even slash.

Also (PLEASE) keep in mind that some of us use Lastname, Firstname in the Artist field (lacking another "universal" way to do this) so we don't want comma treated as a multivalue delimiter.

To avoid the comma conflict, which would require an official way to create the list, gets back to the lack of universal support for a list in the Artist and Composer fields. So, the solution might need to be MC-specific, but open in case another tagging system wants to use it.

For instance, perhaps give MC optional associated field behavior. In Artist, accept a list (with semicolons) as simple text, to not break anything. But if related library field Artist-List (or Artists or whatever) exists (or an option is set to use it) automatically populate it with the same text, but treated as a list. The only field that is editable is Artist, which always updates Artist-List. Artist-List can be used in views just like Keyword is.

Do the same for Composer field, and maybe Genre.

[glynor]

What if MC were able to parse ", " and " & " internally for

This should allow it to separate Artist A, Artist B & Artist C into a list of each of the a artists...
it wouldn't be saving the tag in a non-standard format (great for handhelds) just changing the way it reads the tags in the library

Yeah... That wouldn't work at all.  What about Medeski, Martin, & Wood?  Or Crosby, Stills, Nash, & (sometimes) Young?  Or Maggie, Peirce, and E.J.?  Or Simon & Garfunkel?

You know I like your idea, however the more I think about it I feel it might be too fragile and so far from standard.  I think maintaining a multiple artist within the Artist field, either via multiple tags for formats that support it or via delimited list for those that do not would be the least fragile solution.

I really like my proposed solution, and I'm not sure why it'd be unworkable.  It's certainly possible (even likely maybe) that it wouldn't be able to fully support interchangable in-file multi-artist (or multi-genre or whatever) tags, but that's no different than our current situation.  And, it would allow those files to work fully in other applications, with a usable [Artist] tag.  And, frankly, the idea of changing [Artist] to a list-type field is quite "out of standard" if you look at the ID3 standards.  Keep in mind, while FLAC is certainly on the rise, it has nothing near the market penetration of MP3 (or even MP4 wrapped AAC).  OGG and other similar file containers are little more than niche containers currently.  First and foremost, it has to be a good MP3 tagger.  Everything else is secondary.

Could you explain what you see as the problems in detail?  I'm not sure what you're seeing as "fragile"...

The other "simpler" solution would be to simply allow the user to change the data type on Standard Fields.  Then you could change [Artist] to list type if you prefer (or leave it alone if you don't).  However, this would be much worse from a "interchangable file tag" point of view because if you did change it, then all those list type fields would show as semicolon delimited lists to other applications and players that don't understand this method (and I wouldn't use it for that reason).

I don't think changing so many fields en masse to list-type would go over well, so I don't know that it is a realistic option at all.  I remember "discussions" from when the Tagging AW was changed heavily back when MC12 was still brand new, and a lot of the complaints centered over the handling of list-type fields.  Some fixes were made, but some people are still tenuous in their support of it as is... I can guarantee you that I would not be the only one complaining (and I suspect that JimH would be with me, which is pretty much game-set-match).

[Alex B]

Naturally the default Artist, Album, Date (year) and Genre fields must be kept compatible with various programs, devices, tagging standards and CD & other online databases (e.g. LastFM). In MC the Artist field has also the automatic linking with the "Album Artist (auto)" field.

In my opinion the current system works fine in MC. Users can create as many custom list type fields as they wish.

Here is a tagging example from my library:


Click to enlarge.


Click to enlarge.


Click to enlarge.

It is a compilation album that has various artists, genres and composers. The album artist is included as an artist in some of the tracks, but not in all. With my custom genres I can easily handle each individual artist, composer and genre separately.

[glynor]

For instance, perhaps give MC optional associated field behavior. In Artist, accept a list (with semicolons) as simple text, to not break anything. But if related library field Artist-List (or Artists or whatever) exists (or an option is set to use it) automatically populate it with the same text, but treated as a list. The only field that is editable is Artist, which always updates Artist-List. Artist-List can be used in views just like Keyword is.

This is exactly what I proposed above.  That's what I meant by all that =[Artist] stuff.  Basically, in ANY list type field, allow you to insert a special "expression" instead of a string that would represent an item in the list.  If the item entered is prefixed with an "=" then whenever that list-type field is "displayed" (in a column, pane, tree, or in Rename Files from Properties or whatever) then that item gets "expanded" to point back to the referenced tag.

About the only UI change I can see that it would require would be to add a new "Default Data" box to the Configure Library Field dialog.  That would be needed so that you wouldn't have to manually tag every single file's [Artists] tag to start off with "=[Artist]" as the "default data".

I think it's a great solution.  The way I envisioned it would not be limited to [Artists] or [Genres] or whatever... You could use it on ANY list-type field, so you wouldn't be limited to just the fields that they decided it would work well with.  Anytime you wanted to have a single string-type field with an associated list-type field, you could set it up.  They wouldn't even need to be list-type fields, in fact.  Say you just wanted [Artist] to always match [Composer].  You could set =[Artist] as the default data for the [Composer] tag.  If you have a couple of songs that don't follow those rules, just open it in the Tag AW and delete the =[Artist] and put in your composer!  (I was thinking that the Tag AW could be "different" and allow you to see and edit the =[Field] type rules instead of expanding to the actual value.)

[glynor]

Alex ... I agree mostly.  It is close to fine.  (Isn't that a song?)

The problem is that if you want to be able to use both the [Artist] string-type tag (so that it works with those files on your iPod or your Mac or whatever) AND you want to be able to use a list-type [Artists] tag, it is up to you to make sure they stay in sync.  For those of us who are exceedingly anal, this isn't a problem, but for most mere mortals it becomes nightmarish quickly.

For example, when I was using it, I had a bunch of files that I tagged with my "multi-artist" tag, that ended up with no associated [Artist] tag.  That's fine as long as I use nothing else but MC, but when I transferred them over to my Sansa, they showed up with a lot of blank (or whatever was in the file originally).  That's no good, and that's why I abandoned using the list-type [Artists] field.  It was too hard to remember to essentially tag the artist twice for every single file for every single change!

[Alex B]

For those of us who are exceedingly anal, this isn't a problem, but for most mere mortals it becomes nightmarish quickly.

I have old files, which have only a fraction of the tags that I would like to have, but I tag every new album properly from the beginning. I don't usually need to change them unless there's a typo.

In addition, most of my music has only one artist for each track. Multi-artist tracks are rare in my library so usually I don't need to fill the Artists tag.

Though, I just added 47011 Artists tags from the Artist field in one step by writing =[Artist] in the Artists column. So I don't have empty "Artists" values anymore. I can change the "vs." "and", "with" etc words to list separators in small batches later.

For casual browsing I usually use an Album Artist (auto) > Album view in the "thumbnails on top -- files on bottom" mode. I have the Artists field included only in a couple special view schemes. It is useful for quickly accessing all tracks in which a particular artist is included, but I don't use the field often.

[fermenter]

I wonder if there is a simpler solution?

Perhaps the MC interface could just distinguish which fields will be stored in the file's tags, and which are MC-specific? Say, a colour tint to the field box?!

That way MC could unleash a whole new bunch of functionality, and those that only use MC wouldn't especially care whether their data was stored in tags or MC library files, and those that need to work with multiple apps can ignore the 'MC enhanced' fields or use them in a way that suits them?

[m1abrams]

What I mean by fragile, unless your plan is to actually store the expression and not the value in the ARTISTS field then I am not sure how MC can reliable detect that the tag is to be an evaluated expression.  The problem with storing the expression in the tag is now it will not work outside of MC at all.  Not talking about just being a little ugly as in the case of a delimited string for id3, but no usable data.

My solution requires the least amount of work to keep the data integrity, anytime you have to have complex rules to maintain data integrity you create a fragile system.  In fact no work because their is no bi-directional linking, the data is what it is.

I am not sure what is so wrong with my solution?  Changing Artist to a list type field is only out of standard for mp3, and I fully understand that mp3 is the norm.  However people that are anal about how their data is tagged, those are the only people who would really use this feature most likely do not store their music in mp3 format.  I use mp3 as only a means to get it to my ipod and only care that my ipod have the primary artist.  ID3 is one of the worst conceived ideas for storing metadata I have ever come across and it is a shame it has been made so ingrain into the system.  Look at the available genres you had to choose from in the id3v1 days.

Will be giving Alex method a try by the way.

[m1abrams]

Note: I really hope my comments are not taken offensively, really just trying to work out ideas.  I personally have found 3 new things to try with MC from this thread so thanks.

[JimH]

Note: I really hope my comments are not taken offensively, really just trying to work out ideas. 

You're good.  Thanks.

[glynor]

Note: I really hope my comments are not taken offensively, really just trying to work out ideas.  I personally have found 3 new things to try with MC from this thread so thanks.

You're good.  Thanks.

Absolutely.  (And same here.)

[glynor]

What I mean by fragile, unless your plan is to actually store the expression and not the value in the ARTISTS field then I am not sure how MC can reliable detect that the tag is to be an evaluated expression.  The problem with storing the expression in the tag is now it will not work outside of MC at all.  Not talking about just being a little ugly as in the case of a delimited string for id3, but no usable data.

That's exactly what I meant.  [Artists] would be a MC-only tag anyway, so what is stored in it would be irrelevant.  That is no different from what we already have (which is single-artist only and no multi-artist support unless you build it yourself -- which is MC only).  Behind the scenes, if they were nice enough to implement it, when MC was saving tags out to the file, if the file type supported it, it could automatically parse the [Artists] tag and actually translate that into multiple [Artist] tags.  For MP3s and other similar "stupid" metadata formats, it would just save the [Artists] tag in the normal JRiver format (like it does for any other user-created or MC-only field).

[glynor]

Alex... My issue with your method (which is exactly what I tried before) is that it didn't end up solving the problem for me.

First off, I don't ever use the Album Artist (auto) tag.  That is useless for me (from the way I use and listen to media).  To me, if I get a "compilation" album, and I'm browsing by Artist, I don't EVER want to see "Various" or anything similar.  I want to find the Bright Eyes song from that compilation filed under Bright Eyes, and the Album Leaf song filed under Album Leaf.  If I happen to want to listen to the Soundtrack or whatever as "produced", I'll use my Albums View Scheme (but that never happens... I've long since stopped "consuming" music in that way).

What my "problem" is that I want to solve is this... Using the above example of a song that is by both Bright Eyes and the Album Leaf, I want to have a view scheme (my normal, everyday Genre/Artist/Album view scheme, not something special) where if I don't remember if the song I'm looking for is filed under "Bright Eyes" or "Album Leaf, the" that the song I'm looking for will show up under both artists (when browsing via the tree or panes).  This works, if I use your method, but then I have to essentially abandon using the "real" [Artist] tag in all of my View Schemes.  Of course, then that brings up the portability issue and I have to make sure that [Artist] always matches whatever I've (somewhat arbitrarily) chosen as the primary artist (so that the file shows up with an appropriate artist on my Sansa or on my Mac or whatever).

[m1abrams]

That's exactly what I meant.  [Artists] would be a MC-only tag anyway, so what is stored in it would be irrelevant.  That is no different from what we already have (which is single-artist only and no multi-artist support unless you build it yourself -- which is MC only).  Behind the scenes, if they were nice enough to implement it, when MC was saving tags out to the file, if the file type supported it, it could automatically parse the [Artists] tag and actually translate that into multiple [Artist] tags.  For MP3s and other similar "stupid" metadata formats, it would just save the [Artists] tag in the normal JRiver format (like it does for any other user-created or MC-only field).

Ok I gotcha now, I kept looking at the problem of keeping the tags with the file.  I try to keep as much with the file that way if I just need to do backups of my music to have all the tags and music.  Also I do not like feeling tied to any one piece of software.  However your method if they implemented it so save out multiple [Artist] tags to supporting formats would be a very nice solution.  Not saving it out to the file tags (for supporting formats) would bother me a bit because their are apps that handle that format just fine.

[hit_ny]

For example, I prefer all my files to be tagged in this format for [Artist]: Last Name, First Name (or Beatles, the). 

Why do ppl put 'the' at the end as you did with Beatles or last name before the first name ?

MC can ignore articles and isn't it easier to read the other way round.

First off, I don't ever use the Album Artist (auto) tag.  That is useless for me (from the way I use and listen to media).  To me, if I get a "compilation" album, and I'm browsing by Artist, I don't EVER want to see "Various" or anything similar.  I want to find the Bright Eyes song from that compilation filed under Bright Eyes, and the Album Leaf song filed under Album Leaf.  If I happen to want to listen to the Soundtrack or whatever as "produced", I'll use my Albums View Scheme (but that never happens... I've long since stopped "consuming" music in that way).

find all Bright Eyes tracks by doing a Locate->Artist or all tracks by any artist for that matter.

If you don't use AA (auto), what is the quickest way to find all albums by a featured artist then ?

What do you do when you get a new album ?

i find listening to it in track sequence is the best way unless its a collection of mixes. Afterwards however sure, i'm done rating the tracks so i can pick & mix as desired.

[darichman]

Might be an idea, but keep in mind that artists and composers can be listed in various ways, including comma, ampersand, and even slash.

Yeah... That wouldn't work at all.  What about Medeski, Martin, & Wood?  Or Crosby, Stills, Nash, & (sometimes) Young?  Or Maggie, Peirce, and E.J.?  Or Simon & Garfunkel?

Point taken

I would also like to voice my support for editing the field type of default fields... at least this way MC can still save to the tabs in a standard format, just read them differently?

[fermenter]

What my "problem" is that I want to solve is this... Using the above example of a song that is by both Bright Eyes and the Album Leaf, I want to have a view scheme (my normal, everyday Genre/Artist/Album view scheme, not something special) where if I don't remember if the song I'm looking for is filed under "Bright Eyes" or "Album Leaf, the" that the song I'm looking for will show up under both artists (when browsing via the tree or panes).

That's exactly how I would want it to work too, so you certainly aren't on your own! I don't use MC as some kind of record-keeping database, I use it to select music, and if U2 and Pavarotti do a song together then I would like to select it whether I'm in a U2 mood or a Pavarotti mood.

I would say the same is even more true for genres, there aren't many tracks that sit squarely within a single genre and nothing else, and again I like to use the genre field to quickly select a whole bunch of music to suit whatever mood I happen to be in. To do that with every track in a single genre list is virtually impossible.

[dcwebman]

In my opinion the current system works fine in MC. Users can create as many custom list type fields as they wish.

Nice Alex. Since you are very detailed with your tagging, just wanted to let you know that Henri Rene and His Orchestra should be added next to Eartha Kitt.

[glynor]

Why do ppl put 'the' at the end as you did with Beatles or last name before the first name ?

MC can ignore articles and isn't it easier to read the other way round.

Again....  I use more than just MC.  There are plenty of applications and players that can't, including Windows Explorer (when I want to look at my files using it).

find all Bright Eyes tracks by doing a Locate->Artist or all tracks by any artist for that matter.

I'm not sure what you mean by using the locate artist.  My point is that I want my normal View Scheme, that I can browse using the panes, where that track (and other similar tracks) show up under both artists.  Maybe I want to select a bunch of different bands using the panes "on the fly" and make a little playlist (and play it on random).  I do this often (multiple select items in the panes).  If the song is by both Bright Eyes and the Album Leaf, I want it to show up under both.

And, by the way, Locate --> Artist wouldn't work, since the track might be listed as [Artist] = Album Leaf, the (or might not -- the point is that I can't remember 3 months after I did the tagging).

If you don't use AA (auto), what is the quickest way to find all albums by a featured artist then ?

What do you do when you get a new album ?

i find listening to it in track sequence is the best way unless its a collection of mixes. Afterwards however sure, i'm done rating the tracks so i can pick & mix as desired.

I'm not sure what you mean.... I've removed [Album Artist (Auto)] from all of my View Schemes.  It doesn't sort by it, doesn't show in the columns, and none of the View Schemes use it as a pane.  I use the regular old [Artist] tag in it's place.  I don't like the idea of an Album Artist.  If a particular album has some songs by one artist, and some more by another, I want those songs to show up separately if I'm browsing by Artist.  If I filter the list to show only Bright Eyes, in my opinion, it should show ONLY songs by bright eyes (and not include some random B-Side by another band that they put on one of their Singles or EPs in the list).  That random song off of the EP should show up when I filter the list to show that other artist.  I realize not everyone likes it this way, but that's how I see it.

The problem with this is that if a song is actually by both artists (not just a song by another artist stuck onto someone else's album, but an actual collaboration), then I want it to show up under both.  There is no easy way to accomplish this goal currently.  You can hack it on, but it involves a lot of housekeeping work be done manually if you also want to support the standard, string-type, ID3 [Artist] tag (to support other players).

When I get a new album I tag it with the proper Artist, Album, Genre, and other info.  I'm not sure what you were asking there.  If I happen to get a "mix" CD (like a Soundtrack) I go through and tag each song with it's own individual artist.  When I'm browsing by [Artist] they show up separately (with tracks scattered all around throughout different artists).  If I have [Artist] set to All and I'm browsing by [Album] (which for me is rare, but does happen occasionally) then they show up together and in the right order.  That's fine with me.  I DJ myself, thanks, and don't need some record company exec deciding what order I listen to things in.

When I get a new album by a certain artist, or albums by an artist that puts a lot of work into building a cohesive work (like Radiohead or Pink Floyd for example), sure... I'll listen to them in order.  My system allows for that ([Artist] = All, filter by [Album]).  I'm not talking about anything complex... Just a Genre/Artist/Album View Scheme (I also have others, but that's the "main" one).  Nearly 100% of the time these albums are only by one artist, so I can simply choose the Artist from the Artist pane (which filters the list of albums) and then choose the album I want in the Album pane.  Any album that has other artists mixed in (like a Soundtrack CD) would likely not fall into that type of listening scenario for me...  I generally don't listen to the whole thing in order, ever!  Of course, I generally don't buy Soundtrack CDs either so (except for an occasional exceptional one)...

[Alex B]

Nice Alex. Since you are very detailed with your tagging, just wanted to let you know that Henri Rene and His Orchestra should be added next to Eartha Kitt.

Thanks. I'll fix it...   

Luckily, most of my albums have much simpler tag info.

[CrazieCabbie]

I've been struggling with this for a while, and I finally found a solution that works, at least for me. I thought that some of you might find this useful.

First I added a custom list-type field to my library called "Artists - All", where I can enter all the artists for a given track. Then, I added a pane in the audio view scheme with the following expression:

Code: [Select]

clean([Artist];if(IsEmpty([Artists - All]),,[Artists - All])&DataType=[List])
And what I get is a listing of all the artists in my library, along with any artists that I've entered in my custom tag. I've tested it with a few tracks, and everything seems to group together as it should. Each track show up both in the listing from the "Artist" tag and in each listing from the "Artists - All" tag. Hope this helps some of you who are looking, as was I, for official support for multiple artists.

[CrazieCabbie]

I just realized that I could make that expression a lot simpler:

Code: [Select]

clean([Artist];[Artists - All]&DataType=[List])