Page 3 of 5

Re: Classical Music Tagging

Posted: Thu Jul 02, 2015 9:29 am
by MDE
Screenshot of performer hierarchy:
Performers.jpg
I think the display of instruments in brackets is helpful (although as you can see, not complete).
See also the draft revised wiki page here - http://music.highmossergate.co.uk/jooml ... he-results (You may need to click the "Results" tab).
Currently I duplicate the artist (in Artist [without instrument] and in Performer [with instrument]). This would not be necessary if the "brackets" scheme discussed above is implemented.
Many of the complications in the current scheme will be removed by the various Muso enhancements currently being discussed or proposed. Indeed, it may be possible to by-pass Mp3tag altogether, although I think it will still be needed (under current proposals) at least to generate sort keys. Being able to go straight from ripping classical music to Muso and edit any tagging errors there would significantly enhance Muso's competitive edge among a pretty demanding user group ;) . It would of course mean that my time spent writing devious Mp3tag actions is ultimately wasted, but I won't mind one bit!

Re: Classical Music Tagging

Posted: Thu Jul 02, 2015 4:46 pm
by musoware
I'm releasing the tagging changes in 2.3.05 so you can play with that, then we can better evaluate what we still need to do :)

Re: Classical Music Tagging

Posted: Thu Jul 02, 2015 8:57 pm
by MDE
First impressions - very good! Just a few little bugs (posted separately on bugs forum too).
The sort keys seem to work OK.
I have reduced the import actions substantially:
Import actions.jpg
The first two of these could be eliminated if the "bracket notation" for instruments etc is implemented. PERIOD could be eliminated if Muso's own period search looked for albums containing tracks by composers in the relevant period, rather than albums having said composers as Titled Artists. CUSTOM10 is just to flag to Mp3tag that there are custom fields to process, so that would not be necessary if there weren't any!
One minor issue regarding TITLE: I have eliminated the action which imported MOVEMENT. This means that the Title gets imported in full - including the GroupHeading. Muso strips GroupHeading out of Title when displaying, but the Remote does not, which means that the Title can be unnecessarily long on small screens:
Remote.jpg
Not a big deal but maybe add to the list of possible Remote enhancements?
The exporting of Title seems to work OK - i.e. export "GroupHeading: Title", but do not duplicate GroupHeading.
There are some inconsistencies in tag naming which cause errors:
1. GroupHeading is imported OK as such, but is exported as GROUPHEADER (which is not imported)
2. AlbumSubheader is imported OK as such, but is exported as ALBUMSUBPHEADER and this exported tag contains the GroupHeading rather than the AlbumSubheader.
DiscSubheader seems OK.
Continued in next post because of image constraint...

Re: Classical Music Tagging

Posted: Thu Jul 02, 2015 9:01 pm
by MDE
..contd:
The Conductor now appears after the Band - which is good:
Muso.jpg
However, I thought Band and Conductor used to be displayed on the Remote (in the right sequence), but now I can't see them (see image in previous post).
Finally, there may be some interest in a "Classical Custom Clock" I have designed for the Squeezebox Touch (it does not use any custom tags):
Squeezeplay.jpg

Re: Classical Music Tagging

Posted: Sat Jul 04, 2015 8:09 am
by MDE
Just a further thought about instruments. Semantically there are (at least) two different contexts for "Instrument", which have subtly different meanings. The first is as a sub-genre, e.g. Piano Concerto. The second is as a characteristic of a performer - i.e. what they are playing. I think the latter is probably best dealt with via the "bracket" notation and there is no real need to maintain a (programmed) connection with the first. One way of dealing with instrument as a sub-genre, without using a custom field is just to put it explicitly into the genre name - e.g. "Concerto - Piano". Ideally there would be a sub-genre capability, although Muso already has and implicit, albeit limited, capability in defining certain genres as being "classical".

Re: Classical Music Tagging

Posted: Sat Jul 04, 2015 8:23 am
by musoware
Indeed, I just maintain two of the custom fields for sub-genre (which I call "musical form") and (main) instrument:
Capture.PNG
Though this does add an extra maintenance task to either tag these in the files (and import into the custom fields with import actions), or just add the detail into Muso after importing (which is what I tend to do). Here I'm using the main instrument to further classify the type of music when it's a concerto or solo, rather than associating instruments with performers (which I generally add to performers using the bracket notation).

Re: Classical Music Tagging

Posted: Sat Jul 04, 2015 8:27 am
by musoware
Just made a new release 2.3.06 which addresses some of the Remote UI issues, but I haven't yet tackled the performer<>instrument issue, which I'll review again soon.

Re: Classical Music Tagging

Posted: Sat Jul 04, 2015 8:43 am
by MDE
Just a further thought about instruments. Semantically there are (at least) two different contexts for "Instrument", which have subtly different meanings. The first is as a sub-genre, e.g. Piano Concerto. The second is as a characteristic of a performer - i.e. what they are playing. I think the latter is probably best dealt with via the "bracket" notation and there is no real need to maintain a (programmed) connection with the first. One way of dealing with instrument as a sub-genre is just to put it explicitly into the genre name - e.g. "Concerto - Piano". Ideally there would be a sub-genre capability, although Muso already has an implicit, albeit limited, capability in defining certain genres as being "classical". I will do a bit of research as to what naming systems are in use.

Re: Classical Music Tagging

Posted: Sat Jul 04, 2015 9:02 am
by musoware
MDE wrote:Part of the problem is if you have structured data (a field called "Instrument") as well as unstructured data, such as "Artistname (instrument)" in the Artist and/or performer field. I wonder if the simplest approach might be to just go for the unstructured data - i.e. not implement an Instrument field. Provided all lookups (internal and external) ignore everything in brackets, I can't see why that wouldn't work. It also means that the user can put whatever they like in brackets, not just "instrument". This could be used in a number of ways. For example, at the moment, I deal with "arrangements" by putting the arranger's name after a description, so a composer tag might read "Johann Sebastian Bach; Arr. Camille Saint-Saëns" - my Mp3tag action strips the "Arr." in creating the sort key, but Saint-Saëns is not available for look-ups in Muso. If instead we had say "Johann Sebastian Bach; (Arranged) Camille Saint-Saëns" and Muso ignored the brackets, then Saint-Saëns would be available for lookups (and the album with this track would be included under his name in any Composer hierarchy). In a Conductor tag, you could include something like "(Directed from the keyboard)" - again the words in brackets would be for display purposes only (on Album/Now playing in Muso [EDIT - see below] and, of course, on the player).
I am assuming that this would only be applied to the six "contributor" fields, by the way.
So I think the "brackets" approach has merit as a significant enhancement, not only in addressing the "instrument" problem. The main feature it lacks, compared with a structured "Instrument" field, is that you can't combine it in a hierarchy. So, for example, you can't browse Piano music by Composer (a fix for that would be to allow filters and hierarchies to work together, but I realise that is a different issue).
Thoughts?
[EDIT: I think maybe displaying the full tag in the hierarchy view is also useful - it helps when in "browse" mode to see the role of artists more clearly - I'll try and do some screenshots to demonstrate this]
I like the idea of ignoring any text in brackets after any of the 6 role fields for lookups, and for aggregating the artist groups, but otherwise to display it as entered. Though I'm wondering if there are any legitimate cases where brackets are part of an artist's name? I suppose I'll make this functionality optional anyway.

Then I could possibly extract the text in the brackets to add it to the hierarchical drill-down structure. Though I'm wondering whether these suffixes for all 6 role fields should be combined into one hierarchical entity (eg. "role suffix"), or they should be kept separate: composer (suffix), band (suffix), performer (suffix), etc.

NB. I think I like the term "role" as a generic term for the 6 artistic role fields, "artist" gets confused with the artist field, "contributor" is a term we've used for supporting roles [http://musoware.com/wiki/index.php?title=Titled_Artists].

Displaying the full tag in the hierarchy view might sometimes be useful, but it would still separate "Lisa Beznosiuk" from "Lisa Beznosiuk (flute)", for example, in cases where your tags are not fully in synch. By having "Lisa Beznosiuk" and "flute" as separate entities, you could drill down from performer to instrument (though it would be labelled "Performer suffix" rather than "Instrument" for example - as you said the suffix could be used for many things).

EDIT: a nagging doubt has just popped into my head concerning the above idea of separating role from suffix as hierarchical entities: how to ensure that for a given role, we only show HIS suffixes, not any suffixes for other roles appearing on the same album.... Will think this through.... I think I had the same issue showing conductor/orchestra combinations where there are more than one combination on an album, but I got round that somehow (eg. C1/O1 and C2/O2 on an album - don't show C1/O2 and C2/O1 as conductor/orchestra combinations!).

Re: Classical Music Tagging

Posted: Sat Jul 04, 2015 12:53 pm
by MDE
Fwiw "contributor" is the LMS terminology. Happy to use "role" for clarity. I'm not sure I had envisaged such a sophisticated drill-down as you describe (and not sure I completely understand anyway). As you see from the screen I posted, currently a separate entry is listed for each role/suffix combination which works ok for "instrument" as there will only be a small number of different suffixes for each role. However, if someone uses suffixes more widely it could get cumbersome and grouping (by role without the suffix) would certainly help; in that case how about showing the role/suffix combination under each role, rather than just the suffix - would that fix your problem?
Re making it optional - probably a good idea, but I can't find any cases of brackets being part of an actual role. It would be best, just in case, to allow the user to define the bracket type. I see that MusiCHI (shh) has examples of instrument in square brackets after performers (actually listed as Album Artists!).
BTW I hadn't envisaged that the use would be purely as a suffix - simply that stuff in brackets would be ignored in lookups. Perhaps "annotation" is a better description?