Print

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

[AndrewFG]

All my tracks are tagged with full composer names (like Wolfgang Amadeus Mozart or Ludwig van Beethoven) and until now I have let my Composer View sort simply alphabetically on the full string. But I would like to change it to sort on Surname.

What is the easiest approach to do this? I think as a general rule the sort on Surname would be a sort on the last name in the string. But I am sure there will be many exceptions to that. Ideally I don’t want to retag a lot of files. So I am looking for advice about moving to a simple, reversible, sort algorithm, that can handle the general rule, and also the exceptions too.

Any thoughts?

[DJLegba]

Looking through my collection, your "last word" sort would handle almost everything. I did edit all the composer tags to the format "Bach, Johann Sebastian (1685-1750)" because it works in every view, and Musici Music Tagger made it easy, but it does mean I have to edit the composer field every time I import a new album. I still haven't figured out a good way to enter composer collaborations.

[dtc]

You can create a new field and store the sort name in that. You then sort on that field. There is a SWAP function that will switch the first and last name, but there are situations where that does not work, like The Beatles or Emerson, Lake and Palmer. So, you sometimes need to be able to override the swap function. That is usually done with 2 fields, one which does the swap and one that you can fill in by hand. So, something like Artist Sort and Artist Sort Manual. In the library field definition, use Calculated Data  with an expression that if the manual field is populated, [Artist Sort] is set to that, otherwise it uses swap.  Then just use [Artist Sort] in your sort. With that logic, most of the Artist Sort values are filled in automatically, and you just have to manually add values the anomalies.

Artist Sort calculated data  - If(isempty([Artist Sort Manual], swap([Artist],[Artist Sort Manua])

For composer, just change Artist to Composer.

See Expressions if the Wiki if you need help with the expressions.

[wer]

Within the limits of the expression language, I'm not sure this can be done completely programmatically if you are strict about surnames and what you consider them to be.

dtc's example of Emerson, Lake and Palmer is good.  But do you consider Ludwig's surname to be Beethoven, or von Beethoven.  And when you have decided Beethoven, then you have to think about a name like "de Sermisy".

You may also have tracks where the composer is listed as "John Lennon and Paul McCartney" or various permutations of that.

I think what I would do is programmatically populate a new field with an expression just taking the last element of the name, and then overwrite that with the correct value for all the cases I didn't like.  Simple, but if you have thousands of artists, unappealing.

It would certainly be possible to construct a complicated IF statement that handled all the le, de, von etc prefixes, but even that would not work for Emerson Lake and Palmer, or Bachman Turner Overdrive.

I think you could make such a calculated field work IF you added a third field, which indicated if the name was a band or not. If band, use full field name, if not band, use computed surname.  Follow?

[glynor]

This is definitely possible to do now, and I've discussed strategies for doing so a few times (though mine are often centered around Artist, Actors, and other similar auto-filled fields).

If you already have the field filled in Firstname Lastname format, you can build a sort-field you can use in various places with one simple "checkbox" Field and an expression. There are issues with it, if you want to be able to tag or view them in name-swapped order, but if you only want to sort-by the swapped order (and continue to view and edit everything in "normal order") then you're fine to use this.

Make an Override Field
First thing you need is a simple boolean field you can set to allow you to override your normal sort-behavior (for edge case names that don't get "swapped" properly). So, you can name it as you see fit, of course, but you want basically this:
Field Name: Composer Sort Override
Field Type: User data
Data Type: Integer
Relational: Store one value for each composer
Edit Type: Check
Acceptable Values: 0;1
Save in File Tags (when possible): Up to you, I'd do on so you don't have to re-do it for re-imports, but 🤷‍♂️.
Show a Link Checkbox: Off

Make a Field to Use for Sorting
Now, make a second new field. This one is going to be a Calculated Data type Field:
Field Name: Composer (Sort)
Field Type: Calculated Field
Edit Type: Cannot Be Edited
Show a link checkbox: Probably not.
Expression:

Code: [Select]

If([Composer Sort Override],[Composer],Swap([Composer]))
Then, you use [Composer (Sort)] to sort anywhere you'd have previously sorted the Composer field. You continue to display the Composer field everywhere in your views (you never look at the [Composer (Sort)] field columns or anything, except when testing), but you sort your stuff using it. You can sort the Categories too. Simply save a Sorting Preset with your [Composer (Sort)] field, and then any time you add [Composer] as a field, sort it by this preset instead of "Ascending" or "Descending".

The built-in Swap() and Unswap() function does know about some name suffixes (like Jr. and III) and it might even handle common prefixes like "von" as mentioned by wer above. Or, I suppose you could include them as articles in the articles list and attack it that way. If you have a lot of edge cases for which Swap() doesn't work of a particular type, you can just special case them with IfCase() or additional nested If() statements in the [Composer (Sort)] expression to "fix" those particular cases.

However, the [Composer Sort Override] checkbox is your release valve. If you check that box, it "overrides" the normal expression behavior and passes through the original text of the [Composer] field. The nice thing is, since you can make [Composer Sort Override] a relational field on [Composer] then you only need to check one instance of the particular composer's name to override. So, if you have any particular composer for whom the Swap() behavior doesn't work, tag the [Composer] field on just those files however needed to get them to sort correctly, and then check the box. You only have to check the box once, on one file, and then any file with that [Composer] value will be treated properly automatically (even future files).

Alternative Composer Sort Override Method
That's the simplest mode. If you don't like that you have to see those "specially tagged" files in the [Composer] field with possibly ugly-looking text (which won't "match" the rest of the data stored in [Composer]) for those Overriden composers, then you change the [Composer Sort Override] from a boolean field to a string field:
Field Name: Composer Sort Override
Field Type: User data
Data Type: String
Relational: Store one value for each composer
Edit Type: Standard
Acceptable Values: <empty>
Save in File Tags (when possible): Up to you, I'd do on so you don't have to re-do it for re-imports, but 🤷‍♂️.
Show a Link Checkbox: Up to you.

That's effectively what dtc suggested above. Then, you use it just like the checkbox version above, but instead, you type in what you'd like to override it with in this field (instead of just checking a checkbox). Then you just tweak the expression in [Composer (Sort)] to do If(IsEmpty([Composer Sort Override]) instead. That way, you don't have to look at the "ugly". The only downside is that you give up the simplicity of checking a box to pass-through names which are "already right" in [Composer] as they are now. I'd think that might be the more common failure case for Swap(), single-named people and whatnot, but you'd have to see how it worked out in your Library, and how willing you'd be to fix other special cases in the Expression. There's also the further downside that you have to remember to change the text in two places if you change a [Composer] value in the future (in the real field, and then in the corresponding [Composer Sort Override] field for at least one of those files afterwards). The Checkbox method doesn't have that downfall.

And, if you're perhaps a bit too clever, you could do it with three fields and combine both approaches. But that's likely more trouble than it is worth in ease-of-use and setup effort.

All of that should work just fine. The only issue is if you want to use that [Composer (Sort)] field as a Category and Column in your Views directly (so they look like they should sort in the order they do). That is difficult or impossible currently if you want to use those Columns or Categories to tag files, effectively replacing the "underlying" [Composer] tag. You can't do that, which is why I asked for the Writable Calculated Fields feature, but none of the versions of that idea we came up with in the other thread have been implemented.

So, for now, if you do it, you're stuck viewing [Composer] as it is, but if that is okay with you, you can sort it however you'd like.

[glynor]

I left out: I can't remember if [Composer] is a list-type field, like [Artist] and [Actors]. But if so, and you need to handle that, this is possible too with a few modifications to the Expression in [Composer (Sort)]. Swap() does properly handle list-type data, so it is primarily adding the data type to the expression, but there might be other things to consider.

[wer]

What glynor described, in excellent detail, is exactly what I was talking about. His [Composer Sort Override] provides exactly the function of the third field I mentioned (band/not-band).

The approach will work, if you're careful enough about your surname prefixes, if you have any and if you care about them.

I was not aware that Swap could accommodate von and other such prefixes. It it can, that will make things a lot easier on you.

That need for the third field, which Glynor aptly describes as a "release valve" is why I originally hedged about "completely programmatically".  The use of this field, which I cannot see a way to avoid, is in my view a manual entry type of override that allows you an out for all the cases where the algorithm cannot work on its own.  If you have to manually tweak the output for all the cases where the program logic breaks, one can't truthfully call it "completely programmatic".  But you may well think it's good enough.

[glynor]

I was not aware that Swap could accommodate von and other such prefixes. It it can, that will make things a lot easier on you.

Not sure it can (I said "might"), but it should be relatively simple to special case in the expression if not.

And I'm not sure what special casing it really needs. For Sorting purposes only, having it treated as a "middle name" is probably the best choice anyway (Ludwig van Beethoven under B and not V), and it'll do that anyway without anything special. People with less-common or multiple suffixes are probably going to be the larger issue, but you have lots of choices there.

[wer]

For Sorting purposes only, having it treated as a "middle name" for is probably the best choice anyway

That's why I gave the caveat about how strict he was in his views on surnames. Putting von Beethoven under B seems clear to you and me, but some people might take great umbrage if names like de Sermisy or van Sloan were placed under S.

I mention this because (although I couldn't think of any French composers with a single-syllable surname) traditionally, French surnames with a prefixed single syllable  are sorted by the prefix. Think Charles de Gaulle. He would be expected to be found under d, never g. With multi syllable surnames, it can happen either way depending.

Although I'm less sure, same may be true of other languages. I have seen van Dyck under V.

[dtc]

Yes, this is an old topic. The SWAP function came out of MrC's old regex expression. If you want to add other exceptions, you can simply go back to that regex expression and modify it. Matt introduced SWAP as a simple replacement for the regex expression.  The idea of the Manual (or Override) field is simply that there are always going to be exceptions, so it is best to build in a way to do that.

glynor's analysis is spot on, but can get complicated, given that there are always going to be exceptions. Sometimes simpler is better, even if more manual.

In this case, if you have 1,000 composers, my guess is that 900 or more will work with a simple swap, so the manual part is not all that onerous. And, once you identify a problem, a simple search will find all cases and allow you to enter the Manual field for all the tracks.

Now, what do we do with the Prince symbol?

[EnglishTiger]

Now, what do we do with the Prince symbol?

The obvious answer is replace it with "The artist formerly known as Prince" 

[dtc]

For reference, here are some of the original MrC regex expressions.

https://yabb.jriver.com/interact/index.php/topic,69678.msg469677.html#msg469677

https://yabb.jriver.com/interact/index.php/topic,78210.msg532803.html#msg532803

and the introduction of the SWAP and UNSWAP functions

https://yabb.jriver.com/interact/index.php/topic,94134.msg649219.html#msg649219

[leezer3]

This is a slight aside, but it's got me wondering about a minor old irritation:
I've got a *lot* of Japanese / Korean content.
Unfortunately, one of the real issues with metatadata on this is anglicisation of names; Most Asian cultures work on a Surname => Forename basis.
Whilst this isn't a problem for self-tagged stuff, anything with 'official' english tags is a 50 / 50 shot as to whether it's anglicised the names to Forename => Surname or not. (Not to mention 1001 variants on auto-translate)

Essentially, I'm wondering if there's a way to detect & merge duplicated but reversed entries in this manner.

[glynor]

Essentially, I'm wondering if there's a way to detect & merge duplicated but reversed entries in this manner.

How would it do that? 

[zybex]

How would it do that?

Well... you could create a sort column that sorts similar/reversed names together. You can then use it directly to Sort a view, or to fix the files with similar/reversed values so that they contain the actual same value.

Something like this - it sorts the names+surnames alphabetically, so that "Carmen Miranda" sorts the same as "Miranda Carmen":

Code: [Select]

listsort(listclean(replace([composer],/ ,;),3))
You can improve it to cleanup "dirtier" names so that it handles names with commas, parenthesis, articles, etc:

Code: [Select]

listsort(listclean(replace(RemoveCharacters(clean([composer],2),/(/)/,.-),/ ,;),3))
These split the names into words and then sorts the words alphabetically - "Wolfgang Amadeus Mozart" becomes "Amadeus;Mozart;Wolfgang". This is perhaps more useful to group related files together to then fix their tagging, since the actual order we get is not exactly by name or surname.

[glynor]

I was assuming leezer was asking for something automatic, in field containing a mixture of English-style and Japanese/Korean-style names. Hence, how?

[DJLegba]

I was assuming leezer was asking for something automatic, in field containing a mixture of English-style and Japanese/Korean-style names. Hence, how?

The easiest and best way is to edit the composer tag. A little more work, but it's always right.

[leezer3]

Well... you could create a sort column that sorts similar/reversed names together. You can then use it directly to Sort a view, or to fix the files with similar/reversed values so that they contain the actual same value.

Something like this - it sorts the names+surnames alphabetically, so that "Carmen Miranda" sorts the same as "Miranda Carmen":

Code: [Select]

listsort(listclean(replace([composer],/ ,;),3))
You can improve it to cleanup "dirtier" names so that it handles names with commas, parenthesis, articles, etc:

Code: [Select]

listsort(listclean(replace(RemoveCharacters(clean([composer],2),/(/)/,.-),/ ,;),3))
These split the names into words and then sorts the words alphabetically - "Wolfgang Amadeus Mozart" becomes "Amadeus;Mozart;Wolfgang". This is perhaps more useful to group related files together to then fix their tagging, since the actual order we get is not exactly by name or surname.

Now that's actually genius, splitting into the component parts for browsing- Never thought of that.
Works very well for spotting translation errors / spelling differences too

Not quite automatic yet, but I'll think about that a bit more.

[AndrewFG]

Hi glynor,

I am finally getting round to implementing the solution you proposed in this thread. I got side-tracked on other things, so sorry for the delay, but nevertheless many thanks for your detailed and knowledgeable advice.

Basically it all seems to work as you suggest. However it turns out that [Composer] is indeed a list-type field as you suspected in the post below, so it does indeed need further work.

I left out: I can't remember if [Composer] is a list-type field, like [Artist] and [Actors]. But if so, and you need to handle that, this is possible too with a few modifications to the Expression in [Composer (Sort)]. Swap() does properly handle list-type data, so it is primarily adding the data type to the expression, but there might be other things to consider.

You say "Swap() does properly handle list-type data, so it is primarily adding the data type to the expression" but I am not sure what you mean by "adding the data type". Could you please explain that further.

---

EDIT: after playing around a bit, I figured out the solution to the "data type" question. The correct expression for the Composer Surname (aka Composer Sort) Field Expression is:

Code: [Select]

If([Composer Surname Override],[Composer],Swap([Composer]))&datatype=[list]


[glynor]

Sorry I was so delayed. This is my busy season at work (basically the whole summer) and I'm also in the process of completely rebuilding my network and servers because my firewall machine (which is literally an AMD Athlon64 X2 that has been running nearly constantly since it was brand-new) is finally starting to show its age and needs to be replaced.

My daughter and I are assembling my fancy new rack today. A four poster, with doors, replacing my old 2-poster AV-style shallow rack.

I think you got it?