As mentioned in an earlier post, I have been reviewing my "classical music tagging" scheme to see if there is a better, simpler and more useful approach.
In doing this, I have looked at a range of complementary and competitor products to Muso and at the various metadata sources on the net. I have ignored Roon on grounds of cost.
My conclusions are that (a) Muso is still by far and away the best Windows-based library management software (but still under-exposed) and that (b) probably the best metadata source is MusicBrainz.
Muso users will be well aware of my reasons for concluding (a). As regards (b), my reasons are:
- It is open
- It is pretty comprehensive in its coverage
- It has a very rich metadata model
- The model is well-documented, including style guidelines as well as a clear data model
- It is widely used
- The metadata components are accessible via tools such as Picard. (Jaikoz also looks interesting but does not seem to have a full scripting capability at present)
Now, in an ideal world (?!), Muso would integrate directly with MusicBrainz as a metadata source, but I thought that would be a big ask at the moment. In any case, there are some important syntactical and semantic issues to resolve first.
As a first step, therefore, I have started to develop a "Tagger Script" in Picard which would provide the tags needed by Muso while not changing the source tags from MusicBrainz (so that source tags can be edited and uploaded to MusicBrainz if required, also to minimize issues if the tags are subsequently refreshed). This development appears to demonstrate in principle that the proposed approach can work. Thus, all that would be necessary would be to load the album(s) in Picard and get the metadata automatically from MusicBrainz, with all tag manipulation happening automatically in the background. Then just re-import into Muso and it should look right.
However (and there always is a however!), there are a number of issues to resolve. I will attempt to list them here to gain others' views on the best approach. Almost all can be resolved by Muso import actions, but that raises issues of its own.
- Title, Work, Movement etc. The earlier discussion viewtopic.php?f=2&t=374 clarified the Muso approach. This works well if <Title> is well-structured with at most one single colon and at most one double colon (in the text preceding the single colon). MusiBrainz does not follow this structure. Generally, but not always, a colon separates the work from the movement. There is also a <Work> tag, which (confusingly) includes the movement (in the MusicBrainz database, a work can compose multiple levels of "parts" but this structure is flattened in the <Work> tag). <Work> is often the same as <Title>, but not always. <Work> may include more detail, e.g. opus numbers, key etc. and will be the same for different performances, but the titles on each performance may vary (e.g. language translations). The style guidelines say to use a colon to separate a movement from its containing work, in the Work entity, but no such guideline exists for Title. In practice <Work> may contain many colons and <Title> may omit them. Unhelpfully, MusicBrainz does not provide a "Movement" entity; in any case, it can be argued that Muso should base its display on the actual title in the current recording, not a canonical Work/Movement name. So my preliminary conclusion is to create <Musotitle> from <Title> to be as automatic as possible, assuming <Title> to be structured <Group Header>:<Sub-header>:<Movement>, substituting a double colon for the first colon. Manual amendment would be required if the <Title> does not have colons in the right places (it is frequently OK). Muso will then import <Musotitle> into its Title field. LMS will display <Title> not <Musotitle>. I will raise this issue separately in the MusicBrainz forum as it seems to date from a time when all players just showed Song & Artist.
- Artist. The MusicBrainz classical style guideline says to use Composer in the Artist field. I suspect this dates from a time when <Composer> was not widely supported. It is completely unnecessary (and unhelpful) to do this in Muso and in quite a few other apps also. To avoid corrupting the (current) style guidelines, a <Musoartist> tag could be created for import into Muso. Unfortunately this does not help LMS, which will still have the duplicated <Artist>/<Composer> tags. Also, the question arises as to how such a field could be automatically populated: MusicBrainz does not seem to have a way of designating a Lead Artist for a track, other than to designate a Performer as [solo]. Perhaps the solution is to add [solo] to the <Performer> tag, if it is not there, as it complies with the style guidelines (but unless the MusicBrainz database is updated, there is a risk of reversion at the next refresh). <Artist> could then be constructed from an appropriate combination of Solo Performers and Ensembles (see below).
- Album Artist. Muso provides its own logic for "Titled Artist", based on track artists. Unless wanting to over-ride this, it is usually better to leave <Album Artist> blank. The MusicBrainz style guideline is extensive and quite sensible, but there are slight issues (e.g. the Composer is frequently just quoted by his/her surname). Nevertheless it does mean we have a range of options. For now, if <Artist> is resolved, it is probably be better to have a blank <Musoalbumartist> tag which can be manually amended and is imported to Muso as "Album artist".
- Ensemble. This is rendered in MusicBrainz as <Performer[orchestra]>, <Performer[choir]> or <Performer[group]>. It is perfectly feasible to combine these into Muso's Ensemble field via a Picard tagger script and a Muso import action. It is also possible to add (choir) etc to the description, as is done for <Perfomer[instrument]> (which maps perfectly). There will then be duplication between Ensemble and Performer in Muso. This could be eliminated by creating a <Musoperformer> tag with only the non-ensemble performers and importing that into Muso's Performer field.
- Arranger. This is a separate role in MusicBrainz which is not in Muso. Ideally, Muso would support this. A work-round would be to create a <Musoarranger> tag = "ArrangerName (arr.)" altering arranger role as required, and merging with other composers on import. Most of this could be done automatically. In theory it would not need a <Musocomposer> tag as the combining could be done on importing.
- Genre. Not normally provided by MusicBrainz, but may be created on ripping. It is important for Muso (to distinguish classical genres). It could be defaulted to "Classical" if blank. Otherwise manual intervention is required. This is an area of possible development by MusicBrainz.
Well done for reading this far! Any thoughts most welcome.