Print

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

[GreggP]

When I tag a track with the style, the source of this information I use is from Allmusic.com. Frequently, a track will contain multiple styles. When I enter them, I separate each style with a semicolon.

Why does jrmc treat the style tag as a string and not a list? Can it be changed to a list?

I've noticed that the genre tag is a list and that makes sense. As it should for the style tag.

[ferday]

What allmusic calls style is what most of us here call sub genre, which can be dealt with numerous ways

Im not honestly sure what JRiver intended the style tag to mean, so I'm sure there were reasons to make it a string...?

[mwillems]

I would also be a fan of treating it as a list instead of a string for the same reason.  I have tons of music with semi-colon delimited "lists" in the style field from AMG, and the string treatment makes those hard to use as a view sorting mechanism.

[Arindelle]

I just make a custom field called "styles" notices the plural and use the AMG tags often.

If you want to try what I do

Create first as data field then save. Modify to be a calculated field using this as an expression

Code: [Select]

[style]&datatype=[list]
of course replace the style field with whatever other field your are basing the list field on ... sub-genre etc. Works well with artist and most data fields mapped in VOrbis comment for info

use that to tag and for your views. Handles the separators perfectly and will auto-populate from your existing tags info. Will not write to the file,

[GreggP]

Creating a new tag isn't as useful as just modifying the existing style tag. I use dBpoweramp to rip my CDs and it automatically grabs that info from AMG and applies it to the default tags, including style.

[Arindelle]

Creating a new tag isn't as useful as just modifying the existing style tag. I use dBpoweramp to rip my CDs and it automatically grabs that info from AMG and applies it to the default tags, including style.

I understand that it applies the tags to the fields; but creating the other one will give you a list field like you want; and will not mess up imports which should be a data field. Its easy, and in your case there is nothing to do. If you want to edit or display choose the new field. The separator ";" will be added to the style data field; in other words it autosyncs in both ways. So your importing/mapping of tags won't change, just gives you a lot of extra options.

If you modify the style tag, converting it to a list field it will be a calculated field and you would not be able to import the AMG details. So yes, it is very useful.

[GreggP]

I disagree. They are all data fields. A list is another data type. What I am talking about is changing from a string, which is a single combination of alpha/numeric characters to a list, which can be several distinct strings. AMG already handles the 'Style' tag as a list. When I use dBpoweramp to rip my CDs, it grabs the data from AMG and displays the 'Style' tag as a list. So, if MC changed the data type to list instead of string, it should handle the list from dBpoweramp/AMG.

I could be a little confused, but I think this should work just like it currently does with the 'genre' tag. MC handles 'genre' as a list. When I use dBpoweramp to rip a CD with more than one genre (Pop/Rock; Folk), MC imports both of the genres. After they changed 'genre' to a list, they did not turn it into an uneditable calculated tag.

The key thing for me is exactly what mwillems wrote in this thread regarding sorting the library. When I try to create a view based on the style, it is very difficult.

Here's an example:

I have a tree view of my audio library customized for 'Style/Album Artist/Album', so the left most column is set to 'style'. the middle column to 'album artist' and the right column to 'album'. Let's say I'd like to view a list of all my Blues-Rock albums. It doesn't work very well, because the Blues-Rock style is in multiple strings. The first time it appears in my library, it is part of this string -

"Adult Alternative Pop/Rock; Album Rock; Alternative/Indie Rock; Blues-Rock; Hard Rock; Latin Rock; Contemporary Pop/Rock".

It's also included in dozens of other strings, like these other examples:

"Album Rock; Blues-Rock; British Blues; Fusion; Hard Rock; Regional Blues; Rock & Roll; British Psychedelia; Contemporary Pop/Rock; Guitar Virtuoso; Psychedelic/Garage"
"Album Rock; Blues-Rock; British Blues; Guitar Virtuoso; Hard Rock; Regional Blues; Contemporary Pop/Rock; Rock & Roll"
"Album Rock; Blues-Rock; Fusion; Hard Rock; Latin Rock; Rock & Roll; Contemporary Pop/Rock"
"Album Rock; Blues-Rock; Hard Rock; Latin Rock; Contemporary Pop/Rock"
"Album Rock; Blues-Rock; Hard Rock; Latin Rock; Rock & Roll; Contemporary Pop/Rock"
"Album Rock; Blues-Rock; Psychedelic/Garage; Acid Rock; Psychedelic Soul; Soul"

If I select the first string that includes Blues-Rock, my library shows only one album: Santana - Supernatural. Using a smartlist, it shows I have about 160 Blues-Rock albums. There a so many different styles and I don't want to create that many smartlists.

I shouldn't have to create a custom tag named 'Styles' and then move the tags generated in dBpoweramp from "Style' to "Styles' to handle the list properly.

[Arindelle]

I disagree. They are all data fields ...

Nothing to disagree about, of course they are all data fields. I was referring to the two choices "User Data Fields" and "Calculated Data Fields".  I understand about strings, and lists and also use dbpoweramp to import style fields. Now I might have confused you, with the "if you modify the style tag" I admit, my bad for lack of clarity? ...

Anyway, yes, I think you are confused, in that some fields like genre, artist, if I remember soloist off the top of my head, these fields give you a list type box for editing and behave differently in Panes view (they are out-of-the box developer fields). Try them in category views ...won't work the same.

I shouldn't have to create a custom tag named 'Styles' and then move the tags generated in dBpoweramp from "Style' to "Styles' to handle the list properly.

Just a sec, I'm trying to help you, you don't want to use my suggestion that's cool. You don't have to do anything except creat a field and paste an expression into it., As I said they auto-populate in both directions. If you import them from the dbpoweramp style tag it will fill out the other automatically =[Fieldname], in this case Style, if its not empty it will "autopopulate" by track (or database record if you prefer).

If you are interested, I will post a screenshot which might make it clearer (I have over 500 styles 24 using combinations with "blues-rock" tagged, each are parsed separately). MWillems way of doing things also has its merits too.

[GreggP]

Sorry, I appreciate your advice. I guess I always lean toward simplicity. I was once the PM of an earlier music jukebox application when I worked for Sonic Foundry. It was called Siren Jukebox. I tend to have strong opinions about usability and would have just changed the data type instead of creating an extra tag, even if it does auto populate.

I guess I'm not familiar with what you are referring to as category views...

Yes, please post a screenshot.

[Arindelle]

ok this might help explain what I mean

in panes view using both the standard field and calculated list field



category type view without new field



with new field



field created in options here