Echonest Analyze XML to Music Ontology RDF
By Yves on Tuesday 1 July 2008, 23:07 - Permalink
I wrote a small XSL stylesheet to transform the XML results of the Echonest Analyze API to Music Ontology RDF. The Echonest Analyze API is a really great (and simple) web service to process audio files and get back an XML document describing some of their features (rhythm, structure, pitch, timbre, etc.). A lot of people already did really great things with it, from collection management to visualisation.
The XSL is available on that page. The resulting RDF can be queried using SPARQL. For example, the following query selects the boundaries of structural segments (chorus, verse, etc.):
PREFIX af: <http://purl.org/ontology/af/>
PREFIX event: <http://purl.org/NET/c4dm/event.owl#>
PREFIX tl: <http://purl.org/NET/c4dm/timeline.owl#>
SELECT ?start ?duration
FROM <http://dbtune.org/echonest/analyze-example.rdf>
WHERE
{
?e a af:StructuralSegment;
event:time ?time.
?time tl:start ?start;
tl:duration ?duration.
}
I also added on that page the small bit to add to the Echonest Analyze XML to make it GRDDL-ready. That means that the XML document can be automatically translated to actual RDF data (which can then be aggregated, stored, linked to, queried, etc.).
<Analysis xmlns:grddl="http://www.w3.org/2003/g/data-view#"
grddl:transformation="http://dbtune.org/echonest/echonest.xsl">
...
</Analysis>
This provides a lot more data to aggregate for describing my music collection !
If there is one thing I really wish could be integrated in the Echonest API, it would be a Musicbrainz lookup... Right now, I have to manually link the data I get from it to the rest of my aggregated data. If the Echonest results could include a link to the corresponding Musicbrainz resource, it would really simplify this step :-)
Comments
hi Yves, this looks wonderful.
Re: MusicBrainz. The analysis data is very dependent on an exact music file, not a global notion of a "track" because of all the timing information in the analysis. It's my understanding that MB's data links to tracks, not files (e.g. radio edit, bad encoding, chopped off at the end.) The global Echo Nest analysis features could be used to associate with a track, however.
Hello Brian!
Indeed, MB is more focused on "tracks" than on "signals". But I still think it'd be interesting to have the MB corresponding track identifier (when one exists) in the result set (really just to join up with editorial data from MB, and other datasets that MB links to). I guess there's two ways to do that easily: either by fingerprinting using MusicIP service (although I guess your database could power quite a good fingerprinting service :-) ), or by making a look-up on MB using the embedded metadata in the audio files you receive.
In MO terms (sorry, I am biased, but it makes it clearer for me :-) ), it'd be joined up as:
:signal a mo:Signal.
:musicbrainz_track a mo:Track.
<myfile.mp3> a mo:AudioFile.
:signal mo:published_as :musicbrainz_track.
<myfile.mp3> mo:encodes :signal.
:signal is the actual signal the Echonest Analyze service describes, :musicbrainz_track is an identifier of the corresponding track in Musicbrainz, and myfile.mp3 is a file encoding the signal, somewhere in my collection.
Cheers!
y
When the door of happiness closes,http://shopcheaplv.com another opens but often times we look so long at the closed door that we don’t see the one which has been opened for us http://coachpurses4u.com