C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Choochoo Training Diary

Last 100 entries

EchoNest-based Playlist Generator for MPD

From: andrew cooke <andrew@...>

Date: Fri, 8 Feb 2013 08:23:51 -0300

I just finished a playlist generator for MPD that uses EchoNest.

It works fine, but I can't see how to make it scale - it uses way too many
calls to EchoNest for it to be used by many people (the program uses a single
API ID and multiple people all contribute to the same use, which is limited to
40 calls a minute).

The problem is starting up - I disambiguate artists and construct the graph at
the start.  That takes ~ 1 day of calls for my music collection.

Any practical solution would have to avoid that and do those "real time".
That means relying much more on the quality of the ID3 tags (in particular,
when EchoNest returns a list of similar artists, you need the names used there
to match exactly what is in your ID3 - I avoid that by "normalizing").

Anywya, the code is at https://github.com/andrewcooke/uykfg

Andrew

Comparing UYKFG and UYKFD/E/F

From: andrew cooke <andrew@...>

Date: Fri, 8 Feb 2013 19:49:21 -0300

UYKFG, the EchoNest playlist generator, is my fourth attempt at solving the
problem of exploring related artists.  I think I am finally starting to do it
right.

Compared to previous versions:

 * UYKFG stays simple.  The incomplete UYKFF had web-based configuration and a
   module system.  Which is why it's incomplete.

 * UYKFG does caching right.  Earlier versions cached metadata in a structured
   way (eg by storing LastFM artists in a table).  That meant that each time I
   changed the database during development (because, eg, I wanted to cache
   something new) I had to re-call the web service.  In contrast, UYKFG stores
   web calls as opaque blobs.  There's still some structured data - a table of
   EchoNest users (needed for disambiguation), but when I change that table I
   can rebuild the data "instantly" by re-running code (which transparently
   hits the cache instead of EchoNest).

 * UYKFG is robust.  Scanning and linking is incremental and can occur while
   the system is in use.  The scripts can be run regularly and will mainly hit
   the cache, which decays slowly, meaning that the scripts run relatively
   quickly and new metadata are gradually introduced to the system.  In
   contrast, "rebuilding" the old systems took everything down for a day.

 * UYKFG doesn't try to construct the perfect graph.  Previous systems tried
   to construct a "good" graph of related artists in the database.  UYKFG
   stores a simpler graph (just a simple copy of EchoNest's data) and then
   tries to improve things when selecting tracks.  This makes it easier to
   develope and test new selection algorithms.

Andrew

Comment on this post