On Wed, Mar 25, 2009 at 6:27 PM, Russell Ryan <[email protected]> wrote: > Hey guys, > > I'm also of the opinion that there are at least a few subtle memory > corruption problems at work in Mixxx that are causing some of our > heisenbugs. I've always felt like there was a buffer overflow somewhere > in our BPM code. Since I rewrote the bpmanalyser to work with our > AnalyserQueue, I had pretty high confidence that it was ok (after Nick > found an embarrassing stack overflow I added =) ) . Today I was talking > with Sean on IRC about how we need to take a close look at > bpmdetect.cpp, because that's the SoundTouch code, because I think > there's a buffer overflow in it. Math` on IRC, did the very sane and > reasonable thing of looking at the latest updates to SoundTouch, since > our fork of it was last updated by Olli in 2006: > > http://soundtouch.svn.sourceforge.net/viewvc/soundtouch/trunk/source/SoundTouch/BPMDetect.cpp?revision=61&view=markup > "Fixed buffer overflow bug in BPMDetect.cpp & changed version to 1.4.1" > > Right... :) So we should update our fork of bpmdetect.cpp and see if > that helps these guys out. The only difference I can see in our fork > (The version that Micah is the author of) is that it allows for > configurable minimum and maximum BPM, and auto-correction of BPMs that > are outside of the valid range. > > Also, looking at the diff between ours and his, it appears that there > are some casts to float that were changed to double. It's possible that > Olli discovered some round-off errors, which might mean we will get some > higher-accuracy BPMs as well.
Awesome find. Can we migrate the range hacks out of SoundTouch's bpmdetect.cpp and into bpmdetector.cpp, so we're running a "clean" fork? Thanks, Albert ------------------------------------------------------------------------------ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
