Forums » General Discussion Search

So I've been playing around with the bars and beats info from the track analysis file and in general, I've found their accuracy to be pretty inconsistent.

I know that there is huge complexity to the algorithms for finding beats, bars, etc. and I definitely don't expect it to be 100% perfect. But based on other EchoNest apps I've seen – particularly Tristan's Swinger – it seems like it should be possible to very accurately identify the placement of beats and bars in a track.

In one experiment I've done (which you can play with here: http://www.jordansthings.com/blog/?p=16), I play a sine beep at the exact time the EchoNest track analysis file tells me a beat falls. Sometimes it's pretty on, many times it falls on the upbeat, and other times the tempo seems correct but the beep falls nowhere near the actual beat. I'm also seeing the similar issues with the bars information.

I was hoping someone at EchoNest could speak to the accuracy of the beats and bars data and possibly confirm that the level of inconsistency I'm seeing is expected. Did Tristan do any massaging of the beats / bars info for The Swinger app?

Thanks!

Beats used in "the swinger" are the same you're getting, with no special treatment. But you're right in noticing that there are occasional inconsistencies. Some of those issues have been fixed in the new release that is coming soon. Bar detection is an even harder problem. Improvement there is also on the roadmap.

Also, note that you may occasionally fall into cases where your mp3 decoder generated an offset that's significantly different than ours: we've noticed that ffmpeg, quicktime, and mpg123 generate unpredictable offsets from each other and handle error correction differently, which may result in alignment issues, independent of the analysis. We have a coming fix for that as well. Bear with us.

Very interesting, thanks Tristan. The inconsistencies in timing I'm experienceing seem to be the norm rather than the exception though – would you say it's likely due to the mp3 decoder in Flash handling things differently than the decoder on your server? I'm definitely looking forward to the new updates when you guys push them live and I'm just curious if I can do any tinkering on my end in the meantime to see if I can offset the offset...

Offset issues are likely the ones that have a consistent tempo, but which don't fall precisely on the beat (other than potential precise offbeats). Also, there probably is a decoder issue when the beat suddenly gets slightly out of sync and stays out of sync for no given reason (the decoder might have eaten some frames without filling the missing time with samples or silence). The Flash decoder is probably optimized for playback, and possibly browser dependent. I'm certain that if you're syncing and mixing the clicks live, then you'll get offset issues. Unfortunately, there's no trick to offset those offsets reliably until you get additional information (i.e. a syncing code) from our analysis. Typical offsets I've measured are under +/- 30 ms though, but actually quite frequent. It should generally be acceptable for a beat click. I haven't tried Flash though. Error correction offsets can be measured in hundreds of ms. That is definitely bad!