Print

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

[fermenter]

Sorry to plagiarise your thread title m1abrams, but I started to post this in your thread then realised it was going way off tangent...

I'm wondering, if MC can get multiple artists sorted out, how about multiple genres too?!

I find it impossible to pigeonhole each track into a single genre, most tracks are equally at home in at least 2 or 3. As it is I tend not to use the genre field but instead create a playlist for each genre, that way tracks can easily be assigned (to) multiple genres, and it is quick and easy to select a couple of related genres to create a new playlist ad-hoc. It is also easy to add a currently-playing file to another genre or two while it is still playing.

The only trouble with this method is that there is no thorough way to ensure that all tracks are actually assigned to genres, so there are almost certainly hundreds of tracks on my computer that never get played unless they are cherry-picked deliberately, simply because I haven't yet assigned them to any genres.

One solution might be to create a column for 'assigned to playlists' - that would make it easy to spot tracks that have not yet been assigned to any playlists, as the field would be empty for those tracks.

Another option though, which might have some milage for the multiple artists situation too, is to allow MC to create multiple instances of the same file. The user could perhaps right-click on an entry, select 'create another instance', and a duplicate entry would appear that could then be edited with a new genre or artist. One would presumably have to be a master file whose tag info is correct, the other would simply be a 'ghost' that exists nowhere except within MC and points to the master file. Not especially elegant perhaps, but it would seem workable?

[gappie]

the answer is the same as in that thread. why not make a custom library field called genres, tools>options>library & folders>user library fields. pick as user data: list(semicolon delimited). i think it will do exactly what you want. when you also want to keep the data inside the files you can set that there also.

gab

[m1abrams]

The reason why we do NOT think creating a custom field to do this is because we already have a field.  Duplicating data becomes a nasty thing to maintain, which is what people are suggesting is the fix.

Why would it be so hard for an app to handle this properly?  Again the hardest part I see with this is when syncing with handsets that do not support it, the solution there is to make it clear that the "FIRST" entry will be used in that case.

[glynor]

I have some real concerns over this.  I posted over here though: http://yabb.jriver.com/interact/index.php?topic=44021.msg301356#msg301356

[)p(]

I personally would love to be able to change the datatype of the standard fields. All my audio files have a genre field delimited with ; for multiple-genres already setup for use with slimserver. I have work around this by making a custom pane entry for each string...but every time I add a different genre string to audio files I will have to manually update the pane to show it correctly.

Peter

[glynor]

I personally would love to be able to change the datatype of the standard fields.

That would be an acceptable "fix" for me, but I wouldn't use it so it wouldn't actually help me.  It would not, however, make the system unworkable, so I wouldn't yell if they decided on that as the solution.

[darichman]

so I wouldn't yell if they decided on that as the solution.

Me neither!

[gappie]

I personally would love to be able to change the datatype of the standard fields. All my audio files have a genre field delimited with ; for multiple-genres already setup for use with slimserver. I have work around this by making a custom pane entry for each string...but every time I add a different genre string to audio files I will have to manually update the pane to show it correctly.

Peter

you do know about

Code: [Select]

&DataType=[ list ]putting that in the pane changes (without the spaces)  the standard fields for some uses in list type fields.

so make a pane like [genre]&DateType=[ list ] and you it treats the ; fields like it would when it is a list. in most cases. 

[fermenter]

Darn, I should have just posted it in the original thread, it's essentially the same issue with probably the same solutions isn't it.

Probably best that any further comments go here: http://yabb.jriver.com/interact/index.php?topic=44021.0

[)p(]

you do know about

Code: [Select]

&DataType=[ list ]putting that in the pane changes (without the spaces)  the standard fields for some uses in list type fields.

so make a pane like [genre]&DateType=[ list ] and you it treats the ; fields like it would when it is a list. in most cases. 

Thanks gappie, I did not know that, I am a newbie and still learning everyday
Having it work in the panes is at the moment most important to me.

peter

[)p(]

I might be missing something obvious here. I tried making an expression pane like this:
[Genre] &DateType=

The result is the genrestring with "&DateType=
" appended to it as text, ie:
Classical &DateType=
etc.

What am I doing wrong here?

thanks,

peter

[gappie]

funny what happens when using list between []. but you should use DataType instead of DateType.

succes
gab

oh, im sorry for the confusion. i just saw that i used both in my previous post.

[MusicHawk]

I handle multiple genres via keywords, a compromise that mostly does the job. I set Genre to the best single value, then assign all the song's appropriate genres as keywords. This works pretty well with a large library. BUT it is not proper database design. It turns the Keyword field into essentially a flat table of values that of necessity are not of one semantic type. With this approach it's difficult (or impossible) to construct certain view/playlist formulas because there's no way to create relationships between different types of data when it all lives in just this one field/table.

It could be a bit better if I created custom multi-value fields in parallel to the single-value fields, such as Genres, Artists and Composers. But I didn't find the screen space to make this comfortable. With too many important fields to edit the Tag box requires scrolling because it doesn't resize (a pain), and adding columns to views also pushes other important stuff off the screen. Plus, it can require typing the same info twice into the two fields, or dealing with very long picklists. But this is a workable approach if the outcome is important enough.

I picture the right solution to this problem as allowing multiple values in the standard Genre and Artist and Composer fields, IF there's a way to handle them as single-value fields when that's necessary (other software/devices) but also as lists in MC. This might require MC automatically parsing for delimiters and populating a parallel true multi-value read-only field for use in views/playlists. (The field auto-populate idea is similar to how Album Artist (auto) is populated; I don't find this field helpful but it demonstrates part of the concept.) These associated fields would need to be saved as tags (I assume any data not saved in tags is at great risk of being lost, so it's the only kind of data I put in MC, and I only use media file types with MC that can store data as tags.)

The key question is not whether this could be made to work in MC, it's whether putting multiple values into the standard fields would break any other important software/devices.

[)p(]

funny what happens when using list between []. but you should use DataType instead of DateType.

succes
gab

oh, im sorry for the confusion. i just saw that i used both in my previous post.

oops... hehe I should have seen that myself, thanks again Gappy 

peter

[fermenter]

MusicHawk,

An interesting workaround, I might give that a try.

As regards the additional functionality that might 'break' other apps, I don't see why this is such an issue? What is wrong with having these solutions, and the extra data, reside purely within MC's own library data?

Surely the main purpose of MC is to do whatever it can to manage standard file types with standard fields, but then to provide additional coolness that its users can take advantage of?

I suppose the question is, are we looking for extra MC functionality, or are we trying to redefine the various standards?

Why can't MC support artist1, artist2, artist3 and so on, in a drop-down list for example? Artist1 could then exist in the file's 'artist' tag, the other artists listed for the track would simply exist within MC library data. The only problem as I see it, from a 'conceptual' point of view, is that users may get a little confused as to what data is going to be edited directly within the file and which is MC-specific data. But surely this has been the case since Media Jukebox days, where you could add data to file type that did not support it? The data worked fine within MJ, but when you used that file away from MJ the additional data simply didn't exist. Why can't different coloured field backgrounds, or a different font colour, convey the difference between tag and non-tag data?

If we allow drop-down lists for multiple artists, then couldn't an alphabetical ordering by artist even display an instance of the file for each artist listed? And couldn't the same work for genres?

To use my previous example, let's take U2 and Pavarotti performing Miss Sarajevo. I might make the decision that Artist1 is U2 and Artist2 is Pavarotti. When I order my library by artist, why can't an instance of the file appear under both U and P? If I go to edit the 'clone' entry it shouldn't be too hard to alert me to the fact that this is simply a clone entry, and ask me whether I want to continue or edit the original file instead.

I think the answer to a lot of these things might lie in divorcing ourselves from the idea of one track = one library entry, and embracing the library as a tool to access the files we want in the way we want.

I'd also imagine it wouldn't be too hard to force one track = one entry for those who are particularly wedded to the concept, but they would then not be able to use the additional functionality.

[)p(]

Ok that almost works 100%. The only issue in the panes I can see is duplicates when there are genre entries with both one and more items, ie:

classical
classical;classical - quartet string

expected result:
classical
classical - quartet string

actual result:
classical
classical
classical - quartet string


I am not sure if this is a bug or just how it works. If I end the first genre string with ; then it works as expected. But then it show up in slimserver as classical;

peter

[gappie]

hi peter,

i do think DataType= [ list ] does not work as it should. and i seem to remember that it worked. but i tried to roll back to 308 to test. is not allowed anymore.

but i just tested a bit and this should do the trick

Code: [Select]

clean([genre]&DataType=[List])gab

[)p(]

Thanks again gab, it now works 100% correct 

peter

[MusicHawk]

Fermenter,

>> U2 and Pavarotti performing Miss Sarajevo. I might make the decision that Artist1 is U2 and Artist2 is Pavarotti. When I order my library by artist, why can't an instance of the file appear under both U and P?

This is exactly what happens using a view that groups on the Keywords field. A song with 5 keywords appears in 5 places in the view, once under each keyword.

>> If I go to edit the 'clone' entry it shouldn't be too hard to alert me to the fact that this is simply a clone entry, and ask me whether I want to continue or edit the original file instead.

The 5 instances in the view of the one song are not clones, they are simply view items. They ALL point to the same ONE physical file, so any of the 5 can be selected as a way to access the one file and edit its database record/tags.

It's this Keywords multi-value automatic behavior that is wished-for with Genre, Artist and Composer fields (rather than creating and manually managing separate custom fields). The two problems are that these are built-in fields, and they are "standard" across different media software/devices. That's why I suggested MC-managed associated fields that handle these standard fields as multi-value lists. Easy to suggest , but some issues about whether it would create other problems.

I've had to reload MC from files/tags several times over the years (including last week), with no easy way to reconnect the files to the database. So, I just populated an empty library database by pulling field data from the files' tags. So I don't care for data that exists only in MC rather than in the physical files via tags and/or a firm naming convention.

[fermenter]

I've had to reload MC from files/tags several times over the years (including last week), with no easy way to reconnect the files to the database. So, I just populated an empty library database by pulling field data from the files' tags. So I don't care for data that exists only in MC rather than in the physical files via tags and/or a firm naming convention.

But surely there are better ways to solve that particular issue (like avoiding the situation in the first place, or perhaps MC could develop a better way to reconnect the files with the database after a major operation) without having to sacrifice a whole heap of potential functionality? To limit MC to only do what can be supported with standard fields, without upsetting other applications, seems like an unfair imposition.

I couldn't really give two hoots whether the data is stored in the file's tag or not - MC is pretty much the only way I access them, and as long as it maintains what tags it can, I can wear the loss of any additional data. Especially if it was clear to me which data was 'MC only', so I could make a personal decision how much of that data I wanted to enter in the first place.