Modelling and Presenting Music for Streaming Services

Peter Wurmsdobler
8 min readMar 6, 2020

--

Searching and playing Classical Music on two exemplary streaming services

Around the time Spotify was launched I was (still) in the process of ripping all my Classical music CDs into a collection on a file system using FLAC compression; this effort was futile from the outset given that more Classical music was becoming available on streaming services. However, my issue at the time was and still is that on most streaming platforms Classical music was organised according to the ID3 tag model, i.e. the Artist -> Album -> Song paradigm which may be appropriate for Pop music but is definitely not suitable for Classical music.

Unhappy with the product offering I produced my own player, the XMBC based Eumeles Media Player & Stereo Amplifier, with additions to allow browsing and displaying of Classical music at least according to an Artist -> Work -> Performer -> Piece paradigm. While this project has been evolving in several iterations, better services have since appeared on the market, e.g. Idagio, which is nearly what I was looking for. However, there is still room for improvement, in my opinion. I have the impression what is missing is both thorough modelling and clear presentation of the music genre in question. The following is an attempt on those two.

Modelling Music

The music industry works certainly in different ways for different musical genres and each can be represented in a certain way. Pop music may be well served with the Artist -> Album -> Song paradigm. Jazz music, as far as I know, revolves often around standards and would need its own model, too. Generally speaking, a streaming service should be using a music model for every genre rather than treating all with the Artist -> Album -> Song paradigm. In this story, however, I want to focus on Classical Music.

Modelling Classical Music

I am not an expert on the matter, other than being an avid listener to Classical music and having a limited ability to play the piano. The only formal credential I can bring is having read History of Music at the Musikhochschule Wien some time ago with Professor Constantini, the best lectures I have attended during all my university days.

To put it simplistically, in Classical Music, there are some people producing or having produced pieces of musical art, a composition, or work, or Opus; these people are called Composers. Sometimes an Opus is arranged in a certain way by another kind of Artist, the Arranger, or even by the Composer; the resulting piece of art is rarely considered an Opus in its own right. And there are people cataloguing pieces of musical art into catalogues, e.g. Ludwig Ritter von Köchel for works by Wolfgang Amadeus Mozart known as the Köchelverzeichnis (KV); they may be Artists, too.

In order for an Opus to become audible for an audience, there are people performing an Opus, or the Arrangement of an Opus, the Performers, creating a Performance. Sometimes the Performer is a collective term for an Ensemble or Orchestra, and sometimes Composers and Performers are in personal union. Furthermore there are people carrying out the recording of the Performance producing Recordings, and finally people mixing and releasing parts of one or several Recordings onto a medium as a Release of a collection of Tracks. This way an Opus becomes available to the public who did not have the chance to be present at the performance.

The following diagram tries to show participants and artefacts of the process in a UML style, from Opus and/or Arrangement by Artists over Performance by Artists to a Release of Tracks.

Diagram of a simple model for Classical Music with participants and artefacts

Artists and their Roles

The central participant in this model is the artist in various guises. Here, the concept of the AbstractArtist is introduced, who is either a single person, the Artist, or a group of AbstractArtists which may be of a certain type, an Ensemble, an Orchestra, all with name and certain properties. Note that this notation is recursive as a group may contain another group, etc. The AbstractArtist would have a name and properties; the real Artist would have a date of birth and many additional properties such as epoch or any other affiliation that could be relevant.

In the context of a piece of art, the composer is an AbstractArtist in a composing role and may be a single person. Sometimes there is a group of people working on an Opus, like the Groupe de Six. Sometimes a composer may arrange one or several parts of his/her own compositions, or create a transcription of the Opus; sometimes the arrangement is made by other artists or a Performer. In general, a Composer, the composing AbstractArtist created or creates a collection of AbstractOpus explained later.

When it comes to the performance, an AbstractOpus can be performed by an AbstractArtist, i.e. a single artist or a collection of individual artists, each in a certain role, e.g. a conductor of an orchestra, the orchestra members and their roles, and a soloist, or the composer conducting and performing his own work. The performing AbstractArtist would be performing a collection of AbstractOpus and/or Parts in a Performance explained later.

Opus, the Works

The work, the artefact may come in various shapes. Here, the concept of the AbstractOpus is introduced, which can be either a concrete Opus, or a Derivative of an Opus, e.g. arrangement, transcription or adaptation, work derived from an Opus by the same or another AbstractArtist. An important property of an AbstractOpus is the global unique identifier (GUID) among various other properties such as title, genre, type, instrumentation, version, composition or publication date and various generic tags. A concrete Opus may be one Part, or contain many Parts, but always has a number. The Part is the smallest entity. It is identified through a GUID and have some properties like the Key.

Depending on the epoch, composers would have created certain types of Opus (e.g. Sonata, Symphony, Divertimento), in a genre of Opus (Chamber, Orchestral, etc. which would be linked to the type), with an instrumentation of the Opus in mind (which is linked to both type and genre). Composers usually followed more or less a certain expected layout for each Opus, like the classical sonata form, which defines its Parts. Also, composers would have created a series of a specific type of Opus, a whole series of that type which they may have enumerated themselves. The genre, types and instrumentation are creating all sorts of permutations which can be represented as a tree of genres, depending on the order of attributes, e.g. Chamber Music -> Quartets -> String Quartet -> Quartet # X.

The composer may have catalogued the works, or the Opus could have been posthumously catalogued by other people. Some of the works would be edited and published as collections, or later form part of a greater whole. In the best case, the composer’s Oeuvre, all instances of Opus combined, can be presented in a tree or graph form as an Opus tree according to a data model which is specific to the genre, types and instrumentation as well as the Opus — Part relationships. An additional or complementary organisation of the Oeuvre is possible where there is a Catalogue with CatalogueEntrys; the latter would point to an AbstractOpus. The resulting Opus tree includes organisation of works according to established catalogues, Hoboken, Köchel, etc. If a hierarchical representation of the works is not possible, then the Oeuvre may be presented as a collection with various tags that allow subsequent classification, in addition to the genre/opus/piece tree.

To this point, however, the music exists on paper only and is independent of any performance or release. This is important to be understood.

Performance, Recording and Release

An Opus, parts of one or several Opus or whole collection of Opus may be performed at a single session by a collection of Performers. The performance takes place at a certain location at a certain time. Hence there are specific properties associated with any performance. Assuming that the performance is actually recorded, at this point the single or the collection of several Opus exists as a single or a collection of master Recordings, respectively, each with a GUID and pointing to an AbstractOpus or its constituent Parts. (In the following any Performance is understood to be a recorded Performance as any other performance will be lost to history).

Later on, a single Performance, or part of a Performance, or a whole collection of Performances may be released, perhaps digitally remastered, as a Release, usually as a collection of Tracks where each Track points to a Part of the Opus performed and recorded. Each Track also uses a GUID for identification. At this point only the Opus becomes available through the recorded Performance and Release to the public, e.g. in form of a CD or an online streaming service.

Presentation Layer

The question here is obvious: how is the model presented to the user? Given the object model of the Oeuvre of all Artists, it should be possible to create search trees dynamically, as a hierarchy or in full text search.

Hierarchical Presentation

If I used a touch screen device, or a simple remote control with a couple of buttons for up/down, left/right and enter/back, then I would wish that the model is presented in a tree form (or graph) which allows quick navigation that is generated dynamically based on properties, with a maximum of say 8–10 entries per level. For instance, you start at the root by browsing by performer, composer, etc. If you go down by composer, you could choose by epoch, century, alphabetically, or other properties.

Once you narrowed down to a composer, then I would expect the works being listed according to the model for that composer, generated from the Oeuvre and all available types, genres, instrumentations and tags. For instance, for Beethoven, at first instance a course list of genres is applicable e.g. Chamber, Orchestral, etc. (one could be Arrangements, too). Continuing on Chamber, works to be grouped by collective terms derived from the type and instrumentation, “String Quartets”, “Piano Trios”, etc. Should you select String Quartets, you get the list of those by number, and you select the one you are interested in. Only then you will be presented with a list of Performers, Recordings and Releases.

Search Presentation

Given all properties of all data nodes in the model, it is also conceivable to carry out a search using property-value pairs with some support for auto complete, e.g. Composer = Mozart, instrument = keyboard, key = C major, etc. This necessitates a keyboard as an input device.

Conclusion

The model presented here can only be a starting point. What I would hope for is creating a community project that allows building a multi-lingual Opus & Artist database collectively as no single person would be able to do that alone. There are already some projects well under way, e.g. Klassika. The aspiration would be that the web platform works across several languages with Opus names being translated and Keys presented in the country specific culture. The next stage is to link the Opus & Artists database to a Recording database with recording and release specific information. Both together could be available through a web API to be embedded in browsers running on various devices such as media players.

--

--

Peter Wurmsdobler
Peter Wurmsdobler

Written by Peter Wurmsdobler

Interested in sustainable mobility, renewable energy and regenerative agriculture as well as music and audio.

No responses yet