Classical Music Browsing

  • Peter Wurmsdobler


    I am quite new to UPnP and media tomb, so I am still trying to figure out whether the following is in the scope of the specification and/or already implemented in media tomb.

    Generally speaking, my feeling is that most of the music related software was written by and for people with mostly pop music in mind, and even the uPNP spec shows that the authors did not necessarily think of classical music or jazz. IMHO a uPNP server should allow:

    1. model music and a logical hierarchy beyond id3 tags though some maintenance interface
    2. allow more sophisticated content browse and search.

    Perhaps media tomb can already offer what I am after, I'll study the source code.

    To start with, this is the way I would like to use uPNP on a client. There should be some kind of browse mode, which will determine how the database is organised into a tree:

    Mode/ :

    Mode is not necessarily Genre, but the way music is browsed. For popular music the approach artist/album/song is sufficient, for Jazz composers and arrangers are as interesting to know as performers.

    In classical music, Epoch exists and would be something along the lines of:
    Epoch/ :
    Epoch/Wiener Klassik/
    Epoch/Wiener Klassik/Haydn
    Epoch/Wiener Klassik/Mozart
    Epoch/Wiener Klassik/Beethoven

    In Type I would like to see:

    Type/String Quartett
    Type/Piano Sonata/

    Obviously, the same subtree could appear for busy composers if they apply, i.e. if a set of works can be combined into a logical group:

    Mode/Classical/Composer/Beethoven/String Quartett
    Mode/Classical/Composer/Beethoven/Piano Sonata

    Going beyond that, if I have several recordings of one sonata:

    ../Beethoven/Piano Sonata/No32 Opus 111/
    ../Beethoven/Piano Sonata/No32 Opus 111/Alfred Brendel
    ../Beethoven/Piano Sonata/No32 Opus 111/Emil Giles

    A recording could then even be on two different compilations, or be remastered ...

    Is there a data model for music, or is it up to the user to define it. If so, is there a GUI through a web browser which helps to define the model (and in the background generates the right SQL tables)?


    • Jin

      Jin - 2008-12-14


      I think what you want is our import scripting feature. It allows you to define the layout of the media the way you want it. It is quite easy to use, there are a lot of examples and a good documentation.

      You can also use additional tags that are not present in UPnP and base the layout upon those tags (see the aux options).

      Please have a look at the scripting documentation and also at the scripting wiki on our website for some examples. If you write a custom import script for classical music - please submit it to the wiki.

      Kind regards,

      P.S. you are not quite right about pop music, I wrote the software with death metal in mind ;)

    • Peter Wurmsdobler


      Thanks for your response which partially answers my questions. As far as I can understand from the documentation, MediaTomb extracts tags from imported media, stores it in a database and uses that data to generate media trees through JS scripts. However, I still think of something beyond imported meta-data: meta-meta-data.

      Meta-data is data about a data-item stored within the very item, which is certainly very useful when conveying the item from one location to another. The source of a media tombs database is the media files with their tags, id3 or ogg vorbis tags. These tags only reflect some aspects of the works and repeat themselves, e.g. every track in an album stores the same information about the album in addition to the track specific information. I would like to see some form of relational database which has a logical structure representing the media.

      For instance, a classical work has usually several parts (often movements), is composed by a composer usually in a certain key for an instrument, classified quite often into a certain epoch, and sometimes completed by another composer. The work is in some cases arranged by another musician for the same, or another instrument, and eventually performed by one or more performers. Such a performance may be recorded somewhere by some label; eventually the entire recording of such a work, or sometimes only parts of it appear on a media such as a CD and become available to a listener. If I wanted to represent these relationships several tables are required, just from the top of my head at least:

      KeyTable { int ID, string key}
      EpochTable {int ID, string name, date start, data end, …}
      ComposerTable {int ID, int epochID, string name, data dob, date dod, … }
      ArrangerTable {int ID, string name, data dob, date dod, … }
      WorkTypeTable { int ID, string name, }
      WorkTable {int ID, int composerID, int workTypeID, string opusName, int opusNumber, Key mainKey, string name, string alias, …}
      PartTable {int ID, int workID, int orderNumber, string name, …}
      LabelTable {int ID, string name, …}
      RecordingTable {int ID, int labelID, int partID, int arrangerID, date when, …}
      MediaTable {int ID, int labelID, string name, string identifier, …}
      PerformerTable {int ID, string name, data dob, date dod, … }
      TrackTable {int ID, recordingID, mediaID, string FILENAME…}
      RecordingPerformerMap {int ID, int recordingID, performerID}

      Some of this information could be provided by tags, but some not. So what I envisage is some form of relational database and its maintenance interface that caters for what I have outlined above. When new media is imported, its tags would help to insert the item(s) into the database but the tags alone are not sufficient. The user will be prompted to provide more data, or some tags might be used to add an item into the appropriate list.

      Only in a second step the JS scripts would become important as now a dynamic list of items can be created. Imagine you browsed to /Epoch/Klassik/Beethoven and now the clever script gets first a list of works, then looks whether grouping is possible and sensible, i.e. several instances of the same workTypeID, e.g. Piano Sonata 1-32. If so return the list. Once a sonata is selected, look for recordings and if several recordings exist, return a list, otherwise return the list of parts (movements).  Alternatively imagine, you are in Jazz and you would like to see all arrangements of “summertime” from “Porgy and Bess”.

      The database layout sketched above is not complete and would require additional entries for other media types; for opera you would like to see the librettist, for vocal music the lyrics which again are a property of the work and not the track which is one materialisation of a recording.

      I reckon that radio stations would use such databases or benefit from this approach as would many music lovers. If it does not exist yet && I had the time && the money, I would write it.

      Kind regards,

      • rinc0

        rinc0 - 2008-12-16

        Seems those fellas over at MusicBrainz are also into classical music metadata.  They even have a FAQ and styleguide -

        Any additional metadata you add to a music file is stored in their database.  ie: no need to modify Mediatomb.

        So you'll just need to create an import.js that can work with MusicBrainz metadata. 

        • Peter Wurmsdobler


          Thanks for the hint. I have already looked into MusicBrainz some time ago. Their database employs the Artist/Album/Song paradigm and uses some workarounds to bend classical music to it. Maybe I am mistaken, but it does not feel right. I have a relational database in mind where classical music (or Jazz, or anything that goes beyond the Artist/Ablum/Song paradigm) is part of the concept. The first step must be to build a data model which is comprehensive and powerful enough to encompass all styles of music, without restrictions of current tagging practices. Importing and exporting id3 tags is a secondary issue.


    • Jin

      Jin - 2008-12-17

      Hmm... sounds almost too complicated for an average use case. What about the following suggestion, this could also be done with the existing functionality, but would require some coding outside of MT.

      If you had a program that would group the music the way you want it... and if you then could tell that program write a playlist... you could even define your own playlist format, so that you could store all the data that you need in order to group the content later on... then adjust the playlist parser script, so it parses your customized playlist and organizes the music the way you want it?

      Of course the main part here is the code that will take care of all the things that you mentioned in your previous posts, and if I am very honest - this sounds like quite some effort and I doubt that I will do it. You would have better chances if I needed it myself :)

      But well.. I indicated a way on how it could work and interact with MediaTomb, so i guess it's up to you now. On the positive side - you can use whatever programming language you like and only the playlist parser script (this one is in JS) would have to be adapted on MT side.

      Kind regards,

      • Peter Wurmsdobler


        thanks for the suggestion it is certainly an interesting idea to use the playlists facility to organise the music.

        Over the past few days I have started to think about a datamodel for classical music and realised that different types of music require different models. these ideas have to mature in y head until I start coding:

        - a client application that imports flac files from a NAS and build a database with composers, arrangers, recordings, etc
        - a server application publishing the database with its comprehensive views from the information in the database.

        Or perhaps should I use my time to simply listen to the music.



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks