Add BPM field for songs

[kateabr]

A suggestion: field for storing songs' tempo.
Some producers provide it for their songs themselves, or it can be extracted from ust/midi/vsq etc. Being able to look the tempo up can save cover artists lots of time and nerve: trying to adjust voice synth to fit the instrumental's tempo is usually a pain (at least, for me).
It could also be a useful searching parameter for browsing faster/slower songs.

[riipah]

Is variable BPM relevant? There's definitely some songs like that, usually progressive rock / metal, but I think most songs have some tempo changes. Easiest way to handle variable BPM is to provide only one average BPM value. Or median? Is there an official way to measure BPM when it varies? A range would also be possible, but it would be more complicated and would make sorting impossible.

This task only includes the field. Filtering and sorting can be added later.

[riipah]

Related Discussion thread.

[andreoda]

For example iTunes has only one BPM field.
I am using BeaTunes to analyse my music library. It uses two fields. One for the one that it analysed and the second one is an alternative BPM.
Anyway, I think that one field is enough. Usually songs have only one BPM as its base.

https://vocadb.net/discussion/topics/268

[ycanardeau]

I think having minimum and maximum BPM values is the best compromise for the purpose of searching (just like event's start and end dates). For example, the BPM of this song varies from 94 to 160, but it doesn't make sense to have only one average or median BPM value.

[dset0x]

I'm a little late here! I see there's a minBpm and maxBpm field in the commit. I see why it's useful for searching, but those can be tricky to calculate in a reasonable way, and might be indicative of the song.

In the vocadb discussion I see that there is usefulness in the BPM of (a) the beginning and (b) ending of the song (for mixing purposes). I also think it's good to have a (c) "Base (average) BPM". You can also go all out (like you mentioned in another issue) and have an arbitrarily long list of BPM segments.

Another important thing is to be able to detect whichever values we need. It would be interesting for me to see if I can put something together to detect these values and then auto-update songs.

[riipah]

I don't know about min-max BPM vs. average BPM. But "arbitrarily long list of BPM segments" sounds overkill for VocaDB. I suggested earlier that detailed BPM is complicated enough to justify having it on a separate website (linked to VocaDB). Adding it on the main website would only complicate things too much and also harm the performance. So if we're going to have a BPM value on VocaDB, it should be kept as simple as possible, 1 or 2 values.

[dset0x]

Sure, that's overkill (unless we really do want it for some reason and just provide it over API but don't render all the details on the Song page). Unfortunately I don't see an auxiliary page existing like that with any popularity.