If you could find an externally usable tool for automatically detecting BPM, then what you suggest is theoretically possible, but Traktor wouldn't work for it very easily, as it would be work to get it to do it without human intervention. I don't know of any command line or otherwise externally automatable BPM detection tools off the top of my head.
mostapha is right, though... the hardest part is determining the beat. The basic idea isn't too bad, you take an FFT with a high enough resolution, check the frequencies for where the different drums normally lie, and mark up where those frequencies are high.
However, the problem is that you get a lot of frequency cross-over all over the place, bass fighting the kick, singer fighting the snare, lead fighting the hats, etc. So, after you have the frequency domains determined, then you need to start looking for patterns in the data that looks like a beat... such as "In the kick range, we have thumps here, here, here, and here. That one seems out of place, so is probably the bassline, but the others suggest... etc. etc."
Now, the intelligence your program requires to be able to do this part has one really big advantage - the assumption of a single tempo. You may not know the tempo, but because your code assumes a single tempo, it can look for these patterns and be relatively accurate about it.
However, when you are actively looking for tracks where this tempo changes, the problem domain becomes larger. Your heuristics start to get a whole lot uglier. Slicing it up into pieces would work with limited success, but the accuracy you would enjoy at that point would be low enough that I am confident you would get a lot of false negatives.
That's not to say it can't be done, but to do it properly would require someone with a lot of audio programming knowledge.
Bookmarks