Page 2 of 5

Re: Classical Music Tagging

Posted: Mon Mar 25, 2013 11:05 pm
by MDE
Sort order is now fixed, thanks. Wiki updated to reflect use of the Toolkit. Still a bit of tidying up and some more pics to add. Slight problem in that I was planning to provide mp3tag action files for download. These have extension .mta and would need to be added as allowable file types before I can do that.

Re: Classical Music Tagging

Posted: Mon Jul 29, 2013 7:23 pm
by MDE
For information, I am not planning to update the wiki on this any more as I really don't like the wiki interface. I am starting my own page (currently at http://music.highmossergate.co.uk/jooml ... ewing.html) which I hope to develop further. Links are provided to the Muso site. The Joomla interface is so much easier to use and more powerful than the wiki.

Re: Classical Music Tagging

Posted: Tue Jul 30, 2013 7:14 am
by musoware
OK, I think the wiki interface is standard and it does take some getting used to (I haven't yet!) since it's not WYSIWIG. But many thanks for all your input to the wiki!

Re: Classical Music Tagging

Posted: Sun Nov 16, 2014 11:59 pm
by MDE
Just getting back into this after quite a break. Things have moved on as regards the functionality of Muso & LMS, and also using the system over time and seeing how some record companies have decided to tag. In addition, iPads and other tablets have revolutionised the capabilities of the available controllers.
I also did a review of the available software and have concluded that Muso is still by far the best for classical music lovers who use the squeezebox environment. In fact it is still the best overall, but lacks integration into the upnp world (is that a feature request?).
The LMS 7.9 version has improved "additional browse modes" that reduce the need to use the (useful but rather complex) "Custom Browse" plugin. Also, the current Muso version allows you to write underlying tags directly to the music files. As a consequence, I am trying to revise the tagging method so that it is simpler but achieves the same effect: namely a cd-insert like presentation on Muso plus a meaningful display on the player.
The existing method uses quite a lot of custom field import actions in Muso. Unfortunately this can cause a conflict if you choose to write tags from the "edit tracks" screen as the import actions do not operate in reverse (another feature request: not to write if the tag is created from an import action?).
This is work in progress, but the initial ideas are:
To use Album Artist for the main performer.
To use Track Artist for other performers (map onto performer in Muso)
To include Work as well as Movement in the title in Muso as well as LMS.
The last of these has a slight problem in that, although Muso removes the duplication of the Work name (already in the group heading), the web interface does not do this. At the moment the web interface is useful for accessing the sleevenotes which are stored as PDFs files. Otherwise I don't use it much as VNC to the server from the iPad works well enough, but this is not so good for displaying the PDFs. Of course a full Muso iPad app would be Nirvana!
An important criterion for the revised method is that it will be possible to implement automatically using the current tagging and an MP3tag action (and a re-scan into LMS and Muso). The method will be designed so that future changes can also be accommodated automatically (by using base tags for raw metadata which are not used by Muso or LMS directly).
I will update this thread when I think I have something that works well. Meanwhile any comments and input would be welcome (including any comments on the embedded feature requests).
Just for the record, my system is LMS 7.9 on an old XP machine, squeezebox touches, iPad and iPod with iPeng. iPod also has MP3 files managed under itunes for playing away from home. Naturally the method will be targeted at this environment, but input as to how it works in other environments would be useful too.

Re: Classical Music Tagging

Posted: Mon Nov 17, 2014 8:43 am
by musoware
On the muso tagging feature, I've strived to make this entirely optional, it shouldn't happen without the user requesting it. When in the Edit Track Fields window, changes (on pressing Apply) are buffered (and highlighted) in the Edit Tracks grid, but not yet pushed (committed) to the database; so you can roll all changes back if required, but assuming you want to commit you can either choose Apply or Write & Apply depending on whether you want to write tags back to the song files or not (as documented in the wiki: http://musoware.com/wiki/index.php?titl ... te_Mapping). There's a separate "Write Tags" option to write tags to the song files for an arbitrary selection of grid tracks (those you have selected via click, shift-click, control-click). However the idea of always excluding the tags that are the result of custom actions on import is a good one.

Re: Classical Music Tagging

Posted: Sat Dec 13, 2014 7:22 pm
by MDE
I have now completely revised my classical music tagging scheme. I have tried to apply the same principles as before - optimising the tags for Muso and LMS with as much information for as little effort as possible, and keeping all the base meta data in custom tags which can be used to create standard tags either using my scheme, or any variant that others (or indeed myself in the future) may wish. I have also tried to take advantage of the new "additional browse modes" in LMS (7.9+).
The scheme is described at http://music.highmossergate.co.uk/jooml ... nd-viewing
All the hard work is done by a single Mp3tag action which can be run repeatedly if any base tags are changed. It is also desigend to be resilient if the Muso "write tags" overwrites standard tags in a way that was not intended.
There isn't a facility to comment on my web pages, but any Muso users are welcome to comment here with bugs and suggestions.

Re: Classical Music Tagging

Posted: Sun Jun 28, 2015 11:30 am
by MDE
As previously posted, I have been revising my classical music tagging system, with a view to making the templates and actions freely available to other Muso users. I was not entirely happy with my efforts last December as I felt it was over-complex so have tried to improve it. This new version will be released shortly (but see comments later).
The objectives of the system are:
a) To enable a rich metadata set to be used in Muso.
b) To optimise the displays on squeezebox-type devices attached to Logitech Media Server.
c) To allow changes to be made to metadata either inside Muso or on the files themselves using Mp3tag.
d) To be compatible with files that do not take advantage of the advanced metadata.
e) To be as simple as possible, consistent with enabling a rich metadata set.

As well as being useful for classical music, I hope it also works for jazz, while not causing a problem for any simpler albums.
The core of the system is a Mp3tag "action" which is run after making any changes to the tags (whether directly or via export from Muso). One action makes all the tags into the consistent format, including interpreting custom tags from Muso, creating Performer entries for Artists and Instruments and creating all sort fields. This action will be available for download.
I have re-tagged all my library and tested it out as far as I can - it seems to work well.
Note that some initial preparation of tags is necessary - I will provide the relevant settings for ripping from CDs via dBpoweramp; also I have developed some Mp3tag actions for downloads of certain labels (so far Hyperion and Linn) to put the tags into the consistent format; otherwise some manual tag editing may be required initially.
While I have been doing this, I have also been keeping an eye on competitor products which might do the job better than the Muso/Mp3tag/LMS combination. This does seem to be a developing area and products like Roon look very interesting (particularly if they develop a squeezebox interface as promised) albeit expensive. However I have concluded that the Muso functionality still takes a lot of beating, even when compared with much more expensive solutions. I have therefore continued to invest some time and effort in making everything work to my liking - the only downside of the multi-product solution is that it is not so simple as an integrated product. I also note with interest the HQPlayer developments which may make for a good combination with Muso for audiophiles.
Before finalising and releasing my tagging system there are a few issues that I would like to resolve, some of which have already been referred to elsewhere on this forum. These are listed below. I would be grateful for any comments, solutions or alternative suggestions as regards any of these.

1) Non-LMS tags. The main metadata elements used in Muso are: Title, Album, Album Artist, Artist, Composer, Genre, Track Group Header, Conductor, Performer(s)/Soloists(s). Of these, there are two elements which are not natively provided by LMS - Track Group Header and Performer(s)/Soloists(s). To get these into Muso via the LMS import requires the use of the "Custom Scan" plugin in LMS. While this plugin does provide the tags required, it seems to introduce a considerable overhead to the scanning process - this means that the time taken to add new music and see how it appears in Muso is excessive. Also, when Custom Scan is running it degrades LMS performance, so you can't even listen to music while you wait. My solution was to use the "Import from Specific Folder" option in Muso, rather than importing from LMS. However, this does not update the Artist Sort Table, which is only updated by the LMS import (or manually!). My system does supply all the right sort keys (although see separate issue below on this), but I need to run an LMS import to get them. My suggested approach on this (failing any Muso enhancement to read sort keys directly) is to turn off Custom Scan, use Import from Specific Folder to get the custom tags and Import from LMS to get the sort keys. Not ideal, but it works.
2) Sort tags. LMS has been fixed to read sort tags for all contributors including conductors and composers. However, since Performer/Soloist is not a LMS tag, it cannot be given a LMS sort key in the same way - so, ordinarily, unless I fix the Muso sort table manually to include them (YMBJ), they will be sorted by first name. I tried to fix this by putting supporting artists into the TRACKARTIST tag with a TRACKARTISTSORT key. However, this tag is non-standard, even in LMS and is not included in the "contributor sort" fix. I did a (one-word!) patch to LMS to make it work, but this will not suit many, or even me long-term. An alternative is as follows: Put the main artist in the "Album Artist" tag and the supporting artists in the "Artist" tag; in order not to mess with Muso's Titled Artist logic, import "Album Artist" into "Artist" and import "Artist" into "Performer"; if a separate Album Artist is needed in Muso, use a custom tag (presuming such an artist will always be in another artist tag and thus get a sort key anyway). Not elegant, but it should work. A directly created sort table would of course fix this.
3) Instruments. I like to include instruments in the metadata where possible. The way I have done this is to (a) add an Instrument custom tag for the instrument(s) used by the main artist(s) and (b) put the instrument in brackets after the name of the supporting artists. The Mp3tag action creates a Performer tag which includes the main artist(s) with their instrument(s) in brackets followed by the supporting artists. This means that there is an Instrument tag available for use in a hierarchy view but that you don't need to enter it twice to include all the artists with their instruments in the performer list. The only disadvantage with this is that the main artist appears twice in Muso - without and with their instrument. Ideally the Artist tag would include the instrument and the Performer tag could then just be for the supporting artists; however that would cause the Artist lookups, e.g. on last.fm, to fail. Ideally the lookups would ignore anything in brackets so that (instrument) or any other artist notes in brackets would not cause the lookup to fail. Comments on that or any other matters relating to instruments?
BTW, I put the main artist(s) with their instrument(s) in the Artist tag so that LMS displays this, so an enhancement here would also eliminate a custom tag import into Muso.
4)Import actions. One objective is to reduce the import actions in Muso to genuine custom tags only. The current import actions is shown in the screen below:
Imports.jpg
I could remove the Artist import if there were a fix to (3) above. The three heading imports are there because using the @ tags does not seem to work (bug?). The Title import may not now be necessary given the fix in Muso to avoid duplication when exporting. As regards Period, the Muso Period lookup is in theory preferable to manually tagging them, but it only picks up works by composers in their role a Titled Artist. If this were changed to pick up works by composers in any role, that would be best. That would only leave one custom import - Instrument. Now if that were included as a standard Muso field, that would be really great (and possibly provide a better route to solving issue (3)). The final custom tag is just used as a flag to tell Mp3tag when it is handling a Muso export - if there is a better way of doing that then possibly all custom tag import actions could be eliminated.

As I said, any thoughts on the above (particularly but not exclusively from our esteemed Muso creator) would be helpful so that I can finalise the tagging scheme and associated macros, at least for now. Happy to provide any further information/examples if required.

Re: Classical Music Tagging

Posted: Mon Jun 29, 2015 5:07 pm
by musoware
Hi Mark, I think the main things to come from the above are:
a) the need to get the planned enhancement to read SORT tags from the file scanner prioritorised, and
b) to come up with a mechanism whereby instruments can be associated with performers, while also available as search criteria and in the hierarchical drilldown.

b) is a challenge. I could just add Instrument as a standard muso field to be tied to performer/soloist, and appended in brackets after the performer/soloist in track/group views - but where there are multiple (a string quartet for example), they would have to be given in the same order as the performers. Or, as you said, I could just extract instruments from the performer list by assuming the bracket notation.

Re: Classical Music Tagging

Posted: Mon Jun 29, 2015 5:53 pm
by MDE
On the assumption that sorting is in the plan, I will stick with TRACKARTIST = PERFORMER for now and keep the patch. I will put Artist (without instrument) in the Artist field and put all performers (including Artist) with instruments (in brackets) in the Performer field. The custom field "Instrument" will hold the instruments of the main artists in the same order. The Mp3tag action creates the TRACKARTIST/PERFORMER tag without needing to enter the main artist(s) and their instruments twice. I'll probably change the LMS display so that it is consistent with this - in which case an import action for Artist will be unnecessary [EDIT: Currently, if Artist is blank, I fill it with Band or Composer in LMS to avoid a "no artist" message on SBs, so an import from a custom field ("MainPerformer") will still be necessary to keep the Muso field "clean"].

Re: Classical Music Tagging

Posted: Wed Jul 01, 2015 3:14 pm
by MDE
musoware wrote: b) to come up with a mechanism whereby instruments can be associated with performers, while also available as search criteria and in the hierarchical drilldown.

b) is a challenge. I could just add Instrument as a standard muso field to be tied to performer/soloist, and appended in brackets after the performer/soloist in track/group views - but where there are multiple (a string quartet for example), they would have to be given in the same order as the performers. Or, as you said, I could just extract instruments from the performer list by assuming the bracket notation.
I agree that this is not straightforward. 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]