Re: [Banshee-List] Crossfading and BPM detection

[Neil Loknath <neil loknath gmail com>]

Correct BPM detection is very difficult -- the errors a BPM detector
makes are often quite fatal.

But just try it out yourself: Listen to music, start tapping the bea
untill it fits, now double (or half) your tapping-speed -- your
tapping-beat will still fit to the music piece. Thats the typical
error a BPM detector makes - e.g. 180 BPM instead of 90 or 90 BPM
instead of 180 - These fatal errors make it very hard to integrate
tempo in a music similarity algorithm - that means usually results get
worse...

Good point about the BPM detection.  I wouldn't go as far as to call it fatal, however.  In my eyes, the goal of a playlist generator is to find songs that go well together.  In that sense, a BPM algorithm that detects the double time of a song is not fatal.  Playing a song with 180 BPM after a 90 BPM one will still work together, and vice versa.  I think, at least for me, tempo is an important component to a playlist.  I have a bunch of my songs' BPM tags updated just for that purpose.  For the last few months, I have been a bit lazy in that respect, so this type of feature would come in very handy.  When songs of similar BPM transition from one to the next a very cohesive flow is created.  Even if the songs are not similar in genre or timbre, for example, the uninterrupted tempo brings things together.  To account for BPM errors, users should be able to update BPM  manually.  Banshee already allows this. 

Apart from that a nicely working tempo descriptor could be used to
maybe postfilter the playlist or rerank the top 10(?) playlist items.

Your suggestion about postfiltering may be a good starting point for incorporating tempo into playlist generation as well.  However, depending on the songs, the effect may be almost unnoticeable.

Hm. you can try guessing the tonality by using this approach:
http://ismir2004.ismir.net/proceedings/p018-page-92-paper164.pdf
but they've only tested it with classical music. I'm sure they
published something better on another ismir conference. I can ask a
colleage of mine tomorrow if you're interested.

greetings,
domi.

This is the algorithm I had in mind for key detection:
http://www.hcrc.ed.ac.uk/cogsci2001/pdf-files/0206.pdf


Since you are the Mirage author, Domi, you are definitely much more experienced with sound processing than I.  So, if you can provide any suggestions for key detection, I am all ears.

Thanks,
Neil