PladsElsker
commented
2 years ago Better idea to find the right bpm (finding the right offset is gonna be really hard if the detection was actually not broken, so I'm not talking about the offset for now. However, the bpm finder based on dft is stable enough to start thinking about how to statistically analyse bpm based on it).
Let's say we computed a list of bpms on the song for different windows. We need to run some sort of dbscan on the bpm list to get clustered bpm data. Then, we can:
- Trash any dbscanned cluster that doesn't have enough data (the threashold could be dependant on the length of the song);
- Try to find the variance (could be useful?) and the mean of every cluster;
- "Match" the means of all clusters that are very close to be a multiple of 2 in both directions (try to match for 2x faster and 0.5x slower bpm);
- Keep the means that have the most matches;
- Do an average with the remaining bpms. The mean that is the closest to this average is the one that we are gonna select. Take every bpm that is faster or slower, and scale them down/up so that they match with the selected bpm mean;
- Compute the new mean with the remaining bpm list (or the median? What kind of data merging do we need here?). We can also compute the variance to know how certain the algorithm is about its guess.
Running 5 seconds of audio data into the fft algo is probably not enough time to get consitent bpm for every window.
We might need a window the size of half the audio length, or something like that.
Then, we take every bpm, and we only keep the one that was computed the most. We also keep the bpms that are like 5% off of the most computed bpm. Then, we can compute head bangs. Then, we can compute a bpm + offset that fits best the head bangs.