Classical Music Tagging

Discuss Muso, or get help
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Classical Music Tagging

Post by musoware »

I did actually think of one:
https://en.wikipedia.org/wiki/Was_%28Not_Was%29

I'm now thinking that any Muso field could have "attributes" or "tags" (though in Muso that means something else), identified in a specific or configurable way, eg. Placido Domingo [Tenor], which would be ignored in lookups & grouping, and automatically applied as a sub-level in the hierarchy drill-down.

This could even apply to things like Album title eg. "Nevermind [24kbit|Special Edition]", though that overlaps Album Subheader functionality a bit.

Much to think about.
MDE
Posts: 479
Joined: Sat Feb 02, 2013 12:05 am

Re: Classical Music Tagging

Post by MDE »

Maybe square brackets are best then! Classic parsing problem. I guess you don't want to get into escaping them. I actually put in voices as instruments anyway btw.
MDE
Posts: 479
Joined: Sat Feb 02, 2013 12:05 am

Re: Classical Music Tagging

Post by MDE »

Some thoughts to (hopefully) contribute to your thinking.
The original idea was that bracketed text would simply be ignored in look-ups (Muso internal or external web). That does not introduce any complications about how to deal with it in structured (hierarchy) views. Once you start structuring the hierarchy using the bracketed "annotations", it seems to me that there are complications.
For example, how do you handle sorting? If the sort table lookup is just looking for (say) performer name, but the table holds "Firstname Lastname [instrument] -> Lastname, Firstname" then will it still find it? Maybe, but only if brackets are ignored in looking up the sort table. The underlying tag will of course have the brackets and there may not be a another tag for that performer which excludes the brackets. The sort tag which matches this is of course up to the user, but my practice is to remove the bracketed stuff in creating the sort tag - automatically via the Mp3tag action. Others may have multiple sort tags depending on bracketed text; then you would want to include the bracketed text in the lookup. Maybe there is an obvious answer, but it looks a bit tricky to me.
As regards using brackets to annotate non-role fields, do any of those actually generate lookups? Maybe for Amazon albums etc?
Anyway, my suggestion, fwiw, is to just do the "simple" bit - ignoring brackets in look-ups - first and just leave the performers etc in the hierarchy where they are at the moment (i.e. separately listed for each instrument they are shown with).
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Classical Music Tagging

Post by musoware »

OK I'll do as you suggest and just strip attributes of role fields for lookups and aggregation first, then look at perhaps extracting the attributes for hierarchical analysis later. By aggregation I mean ensuring that albums with artists "Janos Starker (cello)" and just "Janos Starker", for example, are all found under "Janos Starker".

In feeding the sorting table I'd also strip off attributes before-hand. Isn't that the simple answer?

I'm finding lots of examples in my tag data of "Artist A (feat. artist B)" which would obviously benefit from this enhancement. There are some instances I found where I wouldn't want it to ignore the bracketed text, Johann Strauss (sr) and Johann Strauss (jr) for example - so I'll have to identify and change those.
MDE
Posts: 479
Joined: Sat Feb 02, 2013 12:05 am

Re: Classical Music Tagging

Post by MDE »

You may have already done this, but if you load your music into Mp3tag, make sure the relevant tags are visible in columns and filter on (say)
%artist% HAS "("
then you can see what artists have brackets.
Assuming you want to use square brackets for annotations you can select all the ones you want to change (or select all and deselect the ones you don't want to change) and carry out an "action" to replace ( by [ and ) by ] as required.
BTW, my database makes frequent use of round brackets in titles where they definitely are part of the core data required to identify the piece - e.g. "Trumpet Concerto in E flat (Hob. Vile.1)". However, I'm assuming that titles are unaffected by the proposed change.
Searching my database, I have no roles using square brackets at the moment, but plenty of albums with them, as I have used them as follows "Stravinsky: The Firebird (Suite); Le Sacre du Printemps [Abbado]". I also have about 20 track titles with square brackets.
I am assuming that the user will be able to choose from () [] {} and <>.
As regards the sorting, I strip the brackets from the sort tag anyway. I'm assuming what you are suggesting is to strip them from the sort lookup column as well. That seems fine (and shortens the table) so long as "Performerfirstname secondname [instrument]" is shown in full in the hierearchy list and the brackets are only removed to look up the sort order.
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Classical Music Tagging

Post by musoware »

MDE wrote:I am assuming that the user will be able to choose from () [] {} and <>.
That's what I'm planning, yes.
MDE wrote:As regards the sorting, I strip the brackets from the sort tag anyway. I'm assuming what you are suggesting is to strip them from the sort lookup column as well. That seems fine (and shortens the table) so long as "Performerfirstname secondname [instrument]" is shown in full in the hierearchy list and the brackets are only removed to look up the sort order.
I wasn't planning on showing the attribute in the hierarchy structure no, otherwise it would split "artist (instrument)" from "artist". But this is where I'm planning later to list the attributes under the artist as a further break-down. Though perhaps for performer (only) I could have the option to include or exclude suffixes in the one level.
MDE
Posts: 479
Joined: Sat Feb 02, 2013 12:05 am

Re: Classical Music Tagging

Post by MDE »

musoware wrote: I wasn't planning on showing the attribute in the hierarchy structure no, otherwise it would split "artist (instrument)" from "artist". But this is where I'm planning later to list the attributes under the artist as a further break-down. Though perhaps for performer (only) I could have the option to include or exclude suffixes in the one level.
Not a big deal, but I put arrangers in the composer tag and (under the proposed scheme) will tag these as e.g. "Johann Sebastian Bach; Camille Saint-Saëns [arr.]". When listing composers, I feel it may be helpful to differentiate between them composing in their own write (ack. JL) as opposed to their role as arrangers - i.e. the roles are subtly different. Also, I have started adding some librettists/lyricists as composers (since Muso does not have a separate tag) and am annotating them as such, e.g. "Henry Purcell; Anthony Henley [lyrics]; Olivia Chaney [arr.]". Not sure what the best practice is for that. But in the listing (currently) it is immediately clear that Henley is a lyricist not a composer - that would be lost if only names were listed.
Whatever, I recognise that this is a first step and that actual usage and feedback will help inform any subsequent developments.
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Classical Music Tagging

Post by musoware »

Hmm I see. Perhaps stripping off the attributes for lookups is as far as I should take it.
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Classical Music Tagging

Post by musoware »

OK first stage of this is in 2.3.07 - just to use the stripped name for lookups. It's a useful addition I think. We'll evaluate whether more is needed in due course.
MDE
Posts: 479
Joined: Sat Feb 02, 2013 12:05 am

Re: Classical Music Tagging

Post by MDE »

I have revised my classical tagging regime. Hopefully the revised version is both simpler and more complete. It also takes advantage of the added Muso functionality. See http://music.highmossergate.co.uk/joomla30/index.php for details. This is probably best described as a beta version. I welcome comments and suggestions for improvements.
Post Reply