Problematic tagging for classical music

MusicBrainz Picard
1

When using Picard for tagging classical music, in my opinion there are some problems.

The most important problem… guess what: The “composer” tag is not used.
The current tagging system is very hard to work well with classical music, but there is a composer tag which can be used, but Picard doesn’t seem to use it.

Other problems might depend a bit on how one organises music.
I use Plex and foobar2000 for playback
For Plex, there is the problem that combined release artists, form a separate entry, while for classical music, one obvious way is to gather the work of the same composer under one single entry (exception for recitals etc. where the performer is the choice.)

What worked best for me in the past, is making the composer the Album Artist, and the performer the track artist. But that’s incompatible with MB.

Tagging classical music always felt problematic for me (I only use MB & Picard recently, so the problem is not there.)
I feel like the only way to properly cope with this, is if someone would take the initiative to improve the tagging system up to a new standard that is able to cope with:
-Composer vs. performing artists
-Multiple (main) artists (mutliple performers) per track
-Proper use of the ‘composer’ tag
-Works with subparts
-different handling of tags based on an additional tag (a tag that tells applications whether to handle them as a few types of “pop/rock/…” release, a few types of “classical” releases, etc.

I don’t know this is the right place, but I feel like MB & Picard might be the right players in the world of tagging & indexing music, to discuss how such improvements could look like.

The current tagging system requires to put multiple artists in one single field. Programs reading the tags should be able to read all featured artist (both on release level & track level, including composers/writer of works) as separate artists.

To give a simple example: A program like Plex, should show a Beethoven release performed by the MBO (MusicBrainz Orchestra), conducted by P. Icard under all these artists. (not a combined entry)

On track level playback programs should show the performers & the composer, whenever the nature of the track demands this.

It’s a puzzle to be solved, but someone has to touch the problem, work out a solution towards the future, and try to push it to the online music communities & industries as standard, so all programs can implement a much better handling of using credits embedded in the tags.

I see no reason why digital releases should not be able to contain the full credits, and use this to properly index music, and properly display the most important credits in a tracklist.

Currently, when coping with classical music, it feels like one big workaround…

(This is a brainstorm rant, but I got to start somewhere for this long time frustration regarding music which requires a more complex tagging than the “artist - title” format.)

2

First of all read the documentation on tagging Classical music at Classical Music Tags — MusicBrainz Picard v2.12 documentation

Once you have read that and experimented, do come back with any further questions or for more detailed advice.

2 Likes
3

I used Plex for years, and I found the same solution you did – putting the composer in the AlbumArtist field, and the performer (soloist, orchestra/ensemble, conductor) in the (track) Artist tag. As you noted, though, Plex does not support multiple artists in a field – it assumes everyone in the tag is a single artist.

I wrote an extensive feature request several years ago for Plex to improve their support of classical music, but little of it was ever implemented.

Last November I discovered that Emby, which has long been a promising alternative to Plex, had finally caught up to Plex in many ways, but they have surpassed Plex with regard to classical music. Emby supports the Composer tag, and multiple artists per tag, and this has been a game changer.

My classical albums are now tagged according to MusicBrainz’s guidelines, so whether the album artist is a composer, an orchestra, a soloist, or any combination of those (and even “Various Artists”), Emby handles it very well.

As for getting Picard to tag things properly, you may need to look at the Classical Music plugin. It does a couple things I don’t like, but it may help.

3 Likes
4

You should take a look at the “SongKong” program. It uses the databases of MB and Discogs to automatically tag your music, also using AcoustID. Many of your problems are solved there with lots of easy-to-understand toggles. Everything can be undone, as a separate database logs all changes. It’s a yearly subscription (for updates, the program itself will run indefinitely!), but it’s definitely worth the few bucks if you have a large classical music collection.

2 Likes
5

How painful, it looks like Emby might suit me better… but means starting over again organising everything…
Would there by accident some tool which can import all Plex metadata & images in Emby?

6

I’ve never heard of one, but, since most of your tags are already set, it shouldn’t be too painful.

7

It is painful…:
-I manually set genre/style tags for each album
-I manually set the nicest profile pic for each artist
-I checked everything on details so the output would suit my needs in Plex itself
-I added country info for artists, set relations between artists
-etc.

And this for over 1000 digital albums gathered over the years…taking regular backups on a raid drive to preserve all updates. In the early phase, I made the error to only make correction in Plex itself, rather than in the tags, to make things worse.

But I requested it in the Emby forum.
If there is anything they need to pull Plex users in… it’s an import tool.

8

Oh, yeah, you’ve got a job ahead. If you can get Picard to do it for you, it could save a lot.

9

Well, seems someone wrote a migration script: Plex Migrations Scripts - Tools and Utilities - Emby Community

There is hope!

1 Like
10

I agree with you that metadata for classical music is complicated. Whereas for pop music, it is mostly enough to set Album Title, Track Title, Album Artist, and maybe Track Artist, for classical music, we care also about Composer and Work and many of the Performers.

I disagree that MusicBrainz and Picard are the right players to change in order to make this work better. I think that MusicBrainz has a pretty good database structure for classical music works and composers (and more), while Picard does a pretty good job of placing the MusicBrainz data structure into music file tags. (Note: you should certainly use the Classical Extras plugin together with Picard.)

Instead, you should look for a music player which understands the concept of composer and work and performer, and presents them to you in a sensible way. Apparently Plex does not do a very good job of that.

I play my classical music with QuodLibet. It does an adequate job, and I might eventually write a QuodLibet plugin to make it do a better job.

Some people like Wax.

In any case, I think the problem you identify is real, but the solution lies with the playback apps and their UIs.

2 Likes
11

Yes, the problem is not in MB, or Picard.

(Maybe with the exception that the plugins mentioned by @Sophist could be included as standard, with a button upfront to enable tagging adapted to classical, but for me the plugin also works. Just needed someone to point them out to me.)

But what I had in mind is, that someone should set a standard how to properly handle tags to be adapted by any player, rather than individual players (& streaming sites) each having to work out individually how to handle tagging.

Exactly the fact MB does properly contain all info one needs, might make it the right organisation to work out & propose such a standard.

It’s just a wild idea, of course. I realise such things don’t happen overnight and require a great effort. But keeping wild ideas in the head without expressing them prevents them from being picked up.

Regarding the playback app: there is more than the tags & library to a playback app. Tags should (ideally) be handled uniformly over different apps.

Digital music as a medium to be taken serious is young. You can see this by the lack of a tagging standard, but also by the lack of a standard way to include artwork, liner notes etc. (I can use my nice TV for playback, but all it shows is one single piece of cover art. I expect an evolution in that domain the coming decades, or at least: I hope for it. A more mature ‘album’ format, not only providing digital music, but also a full blown digital sleeve.)

12

Who exactly do you have in mind for this?

AFAIK, tagging has never been subject to any formal standard body defining industry wide standards. The closest to this was probably id3.org which defined the ID3v2.3 and v2.4 de-facto “standards”, and which was AFAIK an ad-hoc committee of sorts formed by a couple of individuals with contributions from a handful of other individuals.

So tagging standards are at best de-facto if they are any sort of standards at all.

Aside from ID3, pretty much all tagging standards have simply evolved. Over the years, the MB team has probably contributed as much to these standards through Picard as anyone else, but I would agree that there is a lack of global leadership in this area.

Personally I would like the MB / Picard team to take a greater lead in defining de-facto standards by:

  1. Implementing all (or as many as appropriate) of the defined ID3 tags in Picard as possible (even if MusicBrainz doesn’t have the metadata to populate them).

  2. Where other music file tagging formats do not have defined ways of storing all the tags Picard supports, then the Picard team should propose how such tags should be stored, and solicit feedback from other tagger / player teams as to whether these would conflict with other de-facto standards.

However we are all volunteers with a limited amount of time to contribute to MB / Picard, and in the end they may not consider this to be sufficiently important to prioritise this over e.g. Picard v3 activities.

1 Like
13

Some interesting thoughts @Aszazin . I think it will be a long time (if ever) before there is a standard approach which suits everyone, I was very frustrated by the lack of classical music support generally, which is why I wrote Classical Extras. I also use Muso as the library/player manager. See more details of my approach here. The support for ‘subparts’ by Muso is still, I think, unsurpassed. Unfortunately, Muso is only Windows-based, was never marketed heavily and is now being ‘retired’ (at least from official support - see the discussion here). It would be nice if someone took it on and ran with it!

2 Likes
14

That is a lovely idea. The big challenge I see is how to gather the people and will-power into one effort which will persist until it succeeds? If there were money to be made, then a profit-driven company could pay people to build and sell the better product. However, I fear there is not much money to be made. And the market is so fragmented — among record labels producing digital music, online stores selling it, MusicBrainz keeping the metadata, tagging software, playback software, and playback hardware — that it is difficult to see where one could assemble enough of the right people and will-power.

That is a good point. One thing I would like from a more mature ‘album’ format: turn away from ‘tracks’ as individual files to a single digital file with a complete ‘album’ of music, along with a table of contents which lets players jump to any point in the middle of the music stream. If I have an opera which is three hours long, I don’t want it stored as 36 files, or even as 3 CDs. I want it as one ‘album’. Playback software is not limited to playing the music stream from beginning to end, so I want it to jump to the middle of the music stream as needed.

1 Like
15

Thank you for posting this. I did not know about Muso, because I don’t much know Windows. It is interesting that you say its support for subparts is so good. It might be valuable to take that User Interaction design into a new model for digital music playback user interaction.

I hope you and others are successful in persuading the Muso developer to share their source code, if only because it makes it easier to carry the design into the future.

2 Likes