Metadata musings pt2

Discuss Muso, or get help

Metadata musings pt2

Postby MDE » Fri Mar 17, 2017 12:03 pm

Sorry for the long post - hope it is not TLDR.
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)
So I undertook some detailed analysis as to how to fit MusicBrainz metadata into Muso to achieve a rich and elegant result, the aim being to minimize manual tagging as far as possible and make the process as simple as possible.
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.
  1. Title, Work, Movement etc. The earlier discussion http://musoware.com/forums/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.
  2. 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).
  3. 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".
  4. 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.
  5. 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.
  6. 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.
The result of this approach, if it works, would be a series of "shadow tags" for Muso to import. All would be created automatically on accessing MusicBrainz from Picard, but manual intervention, or use of Mp3tag, may still be necessary in certain cases. There is an issue in that the Muso tag writing capability is rendered ineffective as it will, for example, write the Title field to <Title> not <Musotitle>. However, with the quick and easy links on the album page ("Browse album folder" and "Re-import album folder"), it is not much of an issue as an external tag editor can easily be used. If it works, it might even form the basis of a programmed interface in the future ;)
Well done for reading this far! Any thoughts most welcome.
MDE
 
Posts: 450
Joined: Sat Feb 02, 2013 12:05 am

Re: Metadata musings pt2

Postby MDE » Fri Mar 17, 2017 11:19 pm

I should add that I am continuing to look at Jaikoz/SongKong to provide the required metadata in a more automated way. While not a complete solution at present, there is quite a lot of promise and the development is quite active - potentially a good complement to Muso.
MDE
 
Posts: 450
Joined: Sat Feb 02, 2013 12:05 am

Re: Metadata musings pt2

Postby MDE » Sat Mar 18, 2017 7:28 pm

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.

Jaikoz/SongKong deal with this by extracting structure from the MusicBrainz database as well constructing "Work: Movement" from the Title (it would seem). This structure is saved as tags (Top level): MUSICBRAINZ_WORK, (Intermediate levels): MUSICBRAINZ_WORK_PARTOF_LEVELn where highest n is the highest intermediate level, and (Bottom level): MUSICBRAINZ_WORK_COMPOSITION. In theory it would be possible to construct <Group Header>:: <Sub-header> from this (by enhancement to Jaikoz/SongKong or use of, eg, Mp3tag). Alternatively, Work and Movement (with or without movement number) or Work and Part could be used by Muso directly (but then any sub-header would need to be added manually). But bear in mind that one approach is based on the (canonical) work name whereas the other is based on the name used in the recording.
MDE
 
Posts: 450
Joined: Sat Feb 02, 2013 12:05 am

Re: Metadata musings pt2

Postby MDE » Sat Mar 18, 2017 7:33 pm

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.

This is handled very well in Jaikoz/SongKong. Tags are created for Ensemble, Choir and Orchestra. Performer tags are then only for individual performers. Muso only has one Ensemble field, so an import action would be required to merge the three into one.
Discussions are ongoing with the Jaikoz/SongKong developer. At present this looks a better approach than custom Picard scripts, Will post any further significant developments in due course.
MDE
 
Posts: 450
Joined: Sat Feb 02, 2013 12:05 am

Re: Metadata musings pt2

Postby steveoat87 » Sat Sep 09, 2017 4:13 pm

I don't know if others have the same impression, but for classical music, especially newer releases, discogs seems to have more "hits" than musicbrainz. I use dbpoweramp to tag, and especially for newer releases, I don't seem to get many hits for musicbrainz and primarily use discogs as the tagging source. Not sure how muso handles this -- does it import the discogs information, or only if musicbrainz has a hit?

Rovi and Gracenote seem to have the most "hits" for a particular title, though the information is generally not as rich.
steveoat87
 
Posts: 49
Joined: Thu Aug 31, 2017 5:55 pm

Re: Metadata musings pt2

Postby MDE » Mon Oct 02, 2017 9:48 pm

I'm going off dBpoweramp. It often shows nothing for MusicBrainz when the release is there and data-rich. I haven't worked out what the problem is, but it may be that it is just using discId to look up and/or that it uses an out-of-date copy of the MB database. Also it doesn't create metadata for the MusicBrainz Id tags, so even if it found it in MB, you still have to do another lookup (e.g. in Picard) to get all the classical music tags. I'm becoming a big fan of MusicBrainz because (a) the classical music content is becoming very good, (b) the data is very rich and subject to good style guidelines, (c) it is open source and (d) it is easy to be an editor and there is lots of help from the community.
I'm considering switching from dBpoweramp to CUERipper - it seems to pick up the MusicBrainz releases better. You still need to re-tag in Picard, but the lookup works better (even though the MBIDs are still not populated).
CUERipper seems easier to use and better documented than EAC.
Add to that the irritation of being asked to pay for upgrades which seem to bring few improvements....
MDE
 
Posts: 450
Joined: Sat Feb 02, 2013 12:05 am

Re: Metadata musings pt2

Postby MDE » Mon Oct 02, 2017 10:43 pm

For example, I just loaded this one into my CD drive https://musicbrainz.org/release/0bc95c7 ... 74e8cd51ea
dBpoweramp did not have any MusicBrainz tags for it, but clearly it is in MB (and the discID is there too - Picard can look up the CD with no problem).
CUERipper got the MB tags with no trouble also.
MDE
 
Posts: 450
Joined: Sat Feb 02, 2013 12:05 am

Re: Metadata musings pt2

Postby steveoat87 » Tue Oct 03, 2017 8:47 pm

I took a look at cueripper and it doesn't appear to have had an update since 2014. Is this software still being maintained?
steveoat87
 
Posts: 49
Joined: Thu Aug 31, 2017 5:55 pm

Re: Metadata musings pt2

Postby MDE » Tue Oct 03, 2017 9:02 pm

Not sure. That seems to be the last program update but there seem to be website updates to 2016. Also MusicBee gets the MusicBrainz tags better than dBpoweramp as well. I haven't tried EAC.
Alternatively do what I do and use Picard's CD lookup before ripping to find the CD in MB. If it's there, use the tagger button (URL suffix ?tport=8000 or whatever port you are using for Picard) on the web page of the release to get it into Picard (preferably with the "Classical Extras" plugin for classical music). You can then rip with any old tags and just drag the ripped folder into Picard to tag it. Then import to Muso.
See http://music.highmossergate.co.uk/enhanced.php for how to make this all work with Muso.
MDE
 
Posts: 450
Joined: Sat Feb 02, 2013 12:05 am

Re: Metadata musings pt2

Postby grunter » Sat Jan 20, 2018 9:25 pm

Great work MDE, I start to study your method, it seems very interesting.
Thanks.
grunter
 
Posts: 37
Joined: Wed Jan 06, 2016 10:11 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron