Matching on BPM picks up secondary (faulty) BPM values
When I am matching with BPM as the only filter the matching list inludes not only the selected BPM range but also include songs that have the selected BPM as secondary faulty BPM
ie. if I select a song with 140 BPM as and only filter in the matching list is BPM. Then the maching list includes songs around the selected 140 BPM range OK.
But the list also includes songs with the selected BPM range in the secondary false BPM field.
songs in list
140/(70) ok
etc
then
70/(140) also in the matching list. this is not OK, since the BPM for this song isi 70 completely wrong.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by hendrik on 13 Mar, 2022 11:29 AM
Hey Hakan,
for machines (and sometimes even for humans) it remains difficult to distinguish between, say, 80 and 160 BPM (factor 2). This is the so-called octave-error. beaTunes reports the BPM value it believes is most likely as main BPM value, but also offers an alternative, i.e. a less likely, but possible value. That's the alt(ernative) value you see in the main table.
During matching, beaTunes assigns a high match value when the BPM value corresponds to the main value and a lower match value, when it corresponds to a value that has a factor 2 relationship to the main value. The reasoning is, that two songs that are for example 80 and 160 BPM, respectively, can still be mixed very well, as their beats align perfectly.
I understand that this explanation does not solve the issue for you, but wanted to at least explain, why you see the behavior you are seeing.
Cheers,
-hendrik
2 Posted by Håkan Lindholm on 13 Mar, 2022 01:13 PM
Från: hendrik <[email blocked]>
Skickat: den 13 mars 2022 12:29
Till: [email blocked]
Ämne: Re: Matching on BPM picks up secondary (faulty) BPM values [Problems
#67703]
Thanks for the information it makes it more clear.
But I still would have expected the matching algorithm to use the value in
the main BPM field. I.e. the BPM that I have switched in to be the most
correct.