Print

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

[Matt]

I'll admit, I'm not totally up on the "album artist" discussion, but I know a lot of people aren't happy with our automatic stunt in MC 9.

So, here's my proposed solution: (maybe already suggested by others)

1) There will be an "album artist" field in the database which will be emtpy most of the time

2) "Album Artist (auto)" will work a little differently.  If "album artist" is filled in, that's what will be used.  However, if "album artist" isn't filled in, it will revert to the automatic [Artist] / "(Multiple Artists)" logic that is used now.

So, that gives us all the customization power of version 8 but also the cool automatic stuff of MC 9 if you don't want to customize.

Will that make everyone mostly happy?

Thanks for any feedback.

[dragyn]

works for me.

[zevele10]

will do with it ,sure.
Toda

[graham131]

Sounds like a good step / compromise to me Matt.

Thankyou.

Regards

GRaham

[nila]

Another idea Matt,

How about extending the Copy/Move Field tool so that it can also merge a bunch of fields into one so we could do this for instance:

Artist Album = [Artist] [Album]

Which would fill the field for them but then they could manually tweak it to what they wanted.

They could also do:

Custom 1=  [Album] - [Year] ([Bitrate])


Then we could do view schemes by these custom fields.

I know a lot of people have requested to be able to customise the data that shows in the trees before and this would be a good work around.

Programmatically it'd be pretty easy, to do it manually would take centuries.

What'd u think?

[MachineHead]

Next build? OK, so I'm a little anxious to see it back.  

[Tolga]

Another idea Matt,

How about extending the Copy/Move Field tool so that it can also merge a bunch of fields into one so we could do this for instance:

Artist Album = [Artist] [Album]

Which would fill the field for them but then they could manually tweak it to what they wanted.

They could also do:

Custom 1=  [Album] - [Year] ([Bitrate])


Then we could do view schemes by these custom fields.

I know a lot of people have requested to be able to customise the data that shows in the trees before and this would be a good work around.

Programmatically it'd be pretty easy, to do it manually would take centuries.

What'd u think?

I totally agree with this. In fact a more difficult to implement but a better solution is to have virtual fields, that are calculated from other fields on the fly. So, if you change [Album],
Custom 1=  [Album] - [Year] ([Bitrate]) above is updated automatically.

Although, this seems to be not very related what Matt has asked. I will comment on that in my next reply.

[Polonio]

So, here's my proposed solution: (maybe already suggested by others)

1) There will be an "album artist" field in the database which will be emtpy most of the time

2) "Album Artist (auto)" will work a little differently.  If "album artist" is filled in, that's what will be used.  However, if "album artist" isn't filled in, it will revert to the automatic [Artist] / "(Multiple Artists)" logic that is used now.

It looks great to me. Just some comments:

1) The important thing to me is that "Album Artist (auto)" has to be accesible just like any other library info. I wish to see it on the "renaiming from tag..." dialog, I wish to see it  when exporting, i wish to see it in the detailed list, and so on.

2) It would be nice also (but not so important) to customize the default value for "(Multiple Artists)" albums.

3) You also have to thing about "Album Type" tag. "Complete Album" or "Incomplete Album" info should be just like any other tag (autocalculated, of course).

4) I love Nila's idea. You could go even further by creating calculated fields. Calculated fields would add a lot of power to your product. I would define a field calculated as...

[Album2]=[Artist] - [Album]

I would use this fied in the scheme views.

But, well... I thing we'll have to wait to MC10 to see that.

[Cmagic]

looks good for me Matt,

Thanks

--
Listening to: 'Bloodsucker' from 'In Rock' by 'Deep Purple' on Media Center 9.0

[fex]

Sounds great!

Fex

[rocketsauce]

I've always been a little confused about how/why album artist works the way it does (even back in MJ 8), so I'll just ask my question.

For example, for a dj mix album I list each track artist in the artist field of the tag. These artists then show up in the artist view scheme.

Now, correct me if I'm wrong, if I put in the dj's name as album artist, then all of the track artists no longer are listed in the artist view scheme.

Is there a way to have both the track artist and album artist listed in the artist view scheme?

Rob

Listening to: 'Brutal-8-E' from 'Full On . . Mask Hysteria' by 'Altern 8' on Media Center

[phelt]

Matt:
I think your idea would be a good compromise solution.

I also agree with Polonio's comments about accessibility of the data.

[nila]

Tolgo - one down side of dynamically calculated fields is that the values cant be tweaked manually. The upside is they never have to be set.

If you could, when you create a new field, set a template value for it ie:

new field name =  my features
value = [album] - [year] ([bitrate])


Then it would be just as good as dynamic as all new songs would automatically be given the value, the upside would be though that you could then go in and manually edit the values after.

[PhatPhreddy]

I am just trying to get a handle on the proposed solution....

In trying to get a simple tree view (important with Glissando) I have not found a nice system and having multiple artists is no better really that assinging 'various' to the Album artist or or Artist field...

The system would become much more organized IMHO if you alowed the auto function to list either the artist or album artist depending on if the album is a single artsist (show artist) or multiple artists (show album artist)...

When I next update to the later builds I am simply going to copy my artist field to the album artists field for all my albums that do not have an album artist listed (all my normal albums) and this way by listing everything by albums artist I will have a solution...

If I am being unclear perhaps this thread make what I mean clearer http://www.musicex.com/cgi-bin/yabb/YaBB.cgi?board=beta;action=display;num=1045116994

Its pretty much your suggestion (I think, I may be confused) except instead of reverting to artist / multiple artists if no album artists is listed it should revert to artist (this is to create a tree view)...

[mcphzgig]

Matt, this looks like a good solution to my only remaining niggle with MC9.  Thanks for discussing it with us. Maybe I can have my cake and eat it too, after all.

Count me as strongly in favour. And just when I had started a major database edit to work around the issue.

Of course, us users always seem to want more, don't we?

Polonio has something in this

3) You also have to thing about "Album Type" tag. "Complete Album" or "Incomplete Album" info should be just like any other tag (autocalculated, of course).

Nila's and Tolga's ideas about calculated custom fields/tags are good as well, even if it waits for MC10.

For somewhere in the future I would like to see some content-conditional editing of fields/tags available in the Tools, maybe using the Unix grep string-editing model.

My avoidance strategy for Album Artist (Auto) on my multiple-artist albums was to edit the track names to "track artist - track name" ("Rename File from Properties" and back again), then manually entering my chosen Album Artist in the Artist field (and again renaming files from properties).

So, if your Artist Album proposal is implemented, I will have a bunch of albums where I would like to automatically remove everything in the track name up to and including the " - " string. This kind of thing (and ++more complex) would be easy meat for grep.

Here is a description of grep functionalility, as implemented in another package: http://www.funduc.com/regexp.htm. Public-domain code is available.

Thanks for the continuing responsiveness and current fantastic rate of evolution. Never seen anything like it elsewhere.