having tried out several media players I have finally settled for mopidy. Not only does it appear to be well designed, implemented and documented, it is also the only one I have found that goes beyond the simplistic artist, album performer paradigm as it acknowledges composers and performers, both being artists as shown in the mopidy.models — Data models — Mopidy 3.1.1-1-gf17acacf documentation . There are a few aspects I would like to clarify.
Given that mopidy handles different streams, including file systems, where does the assignment to the data model happen? And what is the mapping, e.g. from an artist found in an ID3 tag to a performer or composer? Or is only the artist populated if no performer can be found? If both performer and composer can be found, will the artist be left empty?
Then to the album, a concept that does not really apply to classical music where one would talk about the oeuvre of a composer which has several parts. There were concept albums in the 1970ies which would be something like an oeuvre. In most cases, however, the album was more related to a release of a collection of works and their pieces on a medium. As it happens the smallest item becomes a track. How could all that be modelled?
The reason I am bringing that up is my hope to use or contribute to a project that is more appropriate to handling classical music, e.g. browsing by period, composer, oeuvre, performer, etc., perhaps even function as a playback for the Idagio streaming service. As it happens I have written up my thoughts on https://peter-wurmsdobler.medium.com/modelling-and-presenting-music-for-streaming-services-2627f52c1fb4 for those interested.
Thanks @jjok , this means that the music model is the hub between backends and frontends Since both are independent extensions, it also means that there is not necessarily a consistency across different backends that is enforced. One backend could map artist to composer, the other to performer; the frontend would not necessarily know their interpretation.
Conversely, if a frontend such as a music browser should work across several data sources (backends?), then it has to make assumption on what tags are available. For instance, if a classical music aware frontend relied on sorting for composers, it would only work if the backends put in the relevant tags. So it would always be a pair that would work once you go beyond the smallest common set.
I expect you’d want to focus on the specific backends that you’d want to use, to make sure they’re putting in the meta data that you need. Then see how that works with the frontends that already exist, and either add any missing features, or come up with a new frontend that is more focused on classical music.
That sounds sensible: metadata from backend → mopidy model → frontend, and determine where the bottleneck is.
Since the model is the hub, it ought to be the super-class accommodating all possible needs of backends and frontends. I hasten to add that mopidy implements perhaps the most comprehensive model I came across, so well done for that.
But there is scope for improvement. For now some track fields such as album have to play a dual purpose role, but ideally one would like different models for different genres, rather than having one model that fits all. For instance, if track.genre is "classical:
track.composers is a list of composers, e.g. “Ludwig van Beethoven”
track.oeuvre is the Opus, e.g. “Piano Sonata No. 32 Op. 111”
track.part is the movement, e.g. “II. Arietta: Adagio molto semplice e cantabile”
track.performers is a list of performers, e.g. “Alfred Brendel”
track.album is the title it was released on, e.g. “Brendel plays Beethoven”
track.release is “1998 CD remastered”
else, for pop at least:
track.artists is a list of artists, e.g. “Jethro Tull”
track.album is “Aqualung”
track.song is “Locomotive Breath”
track.release is “1996 CD reissue”
In the end a track is the smallest recorded and playable entity that ought to reference other things such as the part of the album or opus recorded and released by an artist or performer:
