Downbeats detection not adapting to BPM constraints

[clelf]

Hello,

I'm trying to use DBNDownBeatTrackingProcessor and RNNDownBeatProcessor to identify beats and bars positions on classical music. I have access to the scores of the audio so I'm able to check the results manually as well as infer information such as the time signature or the mean BPM. Yet I've faced several problems:

1. the algorithm aligns correctly with most beats but there are still regions where the number of beats found does not match the real number of beats
2. the algorithm finds twice too many beats (i.e. identify half-beats as beats)
   --> for comparison, DBNBeatTrackingProcessor & RNNBeatProcessor do, in most cases, a better job at finding the "right" tempo, even though not always
   --> I've tried to align both beat and downbeat tracking algorithms results, but due to misidentification regions like in point 1), aligning them together does not ensure the final result will match the real beats

To force the algorithms to detect the beats better I've tried to use the constraints parameters beats_per_bar (only available for downbeats tracking) or min_bpm & max_bpm, but faced the following failure:

3. forcing min_bpm and max_bpm to a range close to the actual mean BPM (different range closeness tested, from 5 to 30%) doesn't seem to have any effect on the results: both beat and downbeat tracking algorithms still find ~twice the amount of beats that the score shows

Do you have any possible explanation on why these constraints do not work? Or any suggestion on how to get around this?

Thanks a lot for your time!
Clémentine

[superbock]

You're on the right way. I am wondering myself a bit that it always gets back to the wrong tempo (which should be outside the search range). There are a couple of more things to try:

• If the tempo is relatively constant, you can try to increase transition_lambda which makes it less probable to switch tempi.
• You could try to clip the activations fed into DBNDownBeatTrackingProcessor to a certain range, e.g. 0..0.5. This could help to prevent switching to the wrong tempo which can be due to high peaks in the activation function.
• You can try CRFBeatDetectionProcessor which has shown better performance on Chopin's Mazurkas than the DBN approaches. If you have the tempo at hand, you can change its process() method to use a pre-determined tempo as additional input instead of estimating it (in line 755 of madmom.features.beats

It would be further helpful to see one of the problematic pieces, then I might have better suggestions.

Last but not least, you could try to train your own model if you have annotated training material. The models are by no means trained on classical music. Together with Magdalena Fuentes and Matthew Davies, I gave a tutorial last ISMIR, you can find the material online.

HTH