22 Mar
2004
22 Mar
'04
9:14 p.m.
Jay Dolan wrote:
--- Simon Jenkins <sjenkins(a)blueyonder.co.uk>
wrote:
ok:
~ Downsampling by 50??? That's *got* to require some
filtering. In keeping with your need for speed - not to mention
my lack of DSP guru-head - i've implemented the crudest
imagineable.
~ fseek()-ing the pipe wasn't working. I've removed the
first fseek(), but that means that g_startTime is no longer
honoured and must be left at zero. The (ahem) "filter" i
added means the second fseek() is no longer required.
~ A couple of math corrections.
~ Widened expected bpm range: It now looks for 100 - 199 bpm.
You should probably narrow that back down again if you know
your source is in a narrower range.
I actually ran it a couple of times and it seems to produce plausible
results now though i don't have the exact bpms for the mp3s i tried.
Also, my test mp3s contained looped samples and/or programmed
drum parts. I'm not sure this algorithm will work so well (or at
all for that matter) on less regular material.
Simon Jenkins
(Bristol, UK)
Try this?
[...]
Definitely closer! I'm embarassed to admit how long
I've looked at this code and didn't see that I was
initializing lowestDiffFound (was previousDiff) to 0,
doh!
It's now returning 120.0 (g_minBpm) for every file,
tho. So there's still a problem somewhere. Perhaps
in phaseShift? I've re-attached the improved version.
Thank you for your help.