t/111701&start=0

After a discussion with the community, it seems like the vast majority agrees that average BPM is useless and most-common bpm is useful and much preferred.

I like this post:

bwross wrote:

It's a common statistical mistake to apply mean where it doesn't belong, when mode or median are more appropriate as a representative of what's "average". This is one of those cases, the mode is far better. The current mean calculation is at best misleading, and is often nonsensical or way off (see the example image above, where the mean is outside of the range). At the very least, it still needs work.

As for measuring mode, I wouldn't go with ms, but with beats. Ties broken with the highest BPM seems appropriate.

So, please introduce this new feature and address the issue. Thanks.

Support :3
I agree that the "average" bpm to be used should be an existing bpm in the map

Support. Sadly I don't have any stars to give you.

Kanye West wrote:

Support. Sadly I don't have any stars to give you.

Support, and yeah i dont have any star too

How is this even possible.

Anyway, support. Average BPM really tells nothing.

My money is all on this one. I thought of the exact same thing a few days back. Full support.

I agree. Support.

I've changed this, since I too do not agree with the current implementation. Is up on test build if you would like to test it out.

peppy wrote:

I've changed this, since I too do not agree with the current implementation. Is up on test build if you would like to test it out.

Would median or 75th percentile (or some other percentile) make more sense? (eg. on maps like ΔMAX)

Anyway it's broken on 2012-12-28T16:19:30Z test build

Edit: x% percentile := y bpm so that ≤x% of draining time is in <y bpm sections and ≤(100-x)% of draining time is in >y bpm sections

While this is marked as [added], I feel the implementation still needs reworking.
The priority right now is emphasized on highest bpm in the map. There should be more emphasis on /most common/ than /highest/ and highest should only be used as a tiebreaker between two very similar length parts.

For example:
http://osu.ppy.sh/s/45935
Right now this map displays "195". It has about 3 seconds total of 195bpm segments, compared to 1:17 minutes of 186bpm. The value that should display is 186, not 195.

http://osu.ppy.sh/s/40233
This map has 14 seconds of 240bpm, and 2:20 minutes of 160bpm. The value that should display is 160, however right now 240 is displayed.

Please fix the issue. Highest bpm should only be used where there is, for example, two segments where one is like 41 seconds and the other is 42 seconds. When there's a difference like 20 seconds vs over a minute, the value which lasts over a minute should be picked regardless of how smaller it is bpm-wise.

Draw the line at less of a 5% difference. i.e. if one bpm is featured on a map's timeline more than 5% than any other bpm, display THAT one, and not anything else; only if there are two or more bpms that appear within less than 5% deviation on a map's timeline display the highest one from those.

---

On algorithm level, per map, osu should go over every red timing section and check how long it lasts until the next timing section, build a list of elements where each element is (bpm, length) where length is milliseconds, and the list would be checked for existing bpm elements to add into their time before adding new elements i.e. if a map has 100bpm -> 150bpm ->100bpm the second 100bpm will add to the first 100bpm ms length.
Once this list is fully populated, sort it by the length values. Then once it's sorted, compare the element on top (highest length) to the one below it (you're comparing their length elements).
If the length of highest element is at least 5% bigger than the element below it, return the bpm of the top length element. If there is less than 5% difference, compare element3 to the length of 1, and so on, until you make a new list of only elements that are within 5% length difference of the top one, and then display the highest bpm element from this sub list.

Aqo wrote:

While this is marked as [added], I feel the implementation still needs reworking.
The priority right now is emphasized on highest bpm in the map. There should be more emphasis on /most common/ than /highest/ and highest should only be used as a tiebreaker between two very similar length parts.

That doesn't explain the oddness of Flutter Girl (as I commented on in the Tech Support thread), where the 75 is the lowest BPM, as well as by far the least used.

The feature has been added, but it still needs bug-fixing. There's a tech support thread for that, please use that instead.