Audio offset in offline analysis

[KCFindstr]

Thanks for the great library. I am wondering if it is possible to add time offsets to each BPM candidate? A use case would be in rhythm games, the chart designer often wants to align notes with beats, so having both start offset of the first bar and BPM will make the alignment much easier and more accurate.

[dlepaux]

Hi @KCFindstr,

I’m not sure to understand what do you need.

Could you please provide details for the use case ?

Typically, what you would expect. Please also provide a sample to implement tests.

Thanks

[KCFindstr]

Example: this is the auto BPM detection from a rhythm game Malody.

After setting the correct offset & BPM, it's expected that a lot of the strong beats lie on the start of each bar.

The start of each bar in seconds is calculated as $$bar_i = \frac{60}{BPM}i - offset$$

(+offset or -offset does not matter here as long as it's exposed in the API)

[dlepaux]

@KCFindstr Ok thank you for your clarification.

It is possible to add this information in each BPM candidates.

In order to be sure while implementing the feature could you provide a sample with the expected result please ?

[KCFindstr]

Great, thanks for the prompt reply! I have attached an example song. song-bg.zip Expected BPM is 130 and offset is 429ms. (any offset like 429±(60000/130)*i will be correct too, and if the offset is off by ~10ms it would also be acceptable)

[dlepaux]

@KCFindstr Thanks for those informations. I'll keep you informed when the feature will be released. I have a last question, in which context is this feature useful to you ? Are you a contributor of Malody App ?

[KCFindstr]

@dlepaux Nope - Malody is a commercial app and it already has a BPM detector with very good accuracy, but the algorithm is closed source. I am developing an open source lyrics editor in which displaying beat information will also be helpful, and I am looking for an open source alternative.

[dlepaux]

@KCFindstr I've done an experimental implementation of the feature but it implies more complex issues related to the algorithm.

You might not know this, but the algorithm to compute BPM is based on amplitude thresholding. We basically look for the highest peaks and then we can compute the BPM with the intervals, etc.

To get the information we're looking for, we would need to identify each peaks, and then we would be able to compute the duration in second to reach it from the beginning of the audio. So, we would need to wait a deep refacorization of the library to get this information.