Working for a Speed Difficulty meter

[ReynBolt]

Remember that this topic's proposal is at the moment very incomplete and is continuously growing. Once mentioned this, let's check the proposal.

Hi, this topic is about finding a solution to speed variable by rationalizing it. The intention of this topic is giving speed difficulty enough independence from aim. Meaning that what we are searching is for a way to evaluate speed without being heavily influenced by aim.

On here we're assuming speed is mostly your general tapping speed meaning that this variable will grow the faster you tap without too much influences of aim.

This is a very basic speed formula which I'm going to explain

1.- First we do our calculus of 60/bpm and then a division with X which is the kind of tapping (1/2 , 1/3 , 1/4 , etc) and we a get a separation in time between some circles. There's nothing new on this part. For this we use seconds as our unit of measurement not ms.
2.- To get the SSRD (Speed Star Ratio Difficulty) in a part we use the formula on the step's 1 obtained value.

For this we get the ^-1/3 potency of the result in the first parentesis [time interval (in seconds)].

Let's say a stream practice map of 180 at 1/4's will be 2,28942 ☆ SSRD while a "stream compilation" with only 1/2's of 180 bpm will be 1,81712☆ SSRD

But hey! we're talking about a map of ONLY that is only consistent single tapping 180's (circles only) which is why the speed star rating is that HIGH.. Note that maps commonly have sliders, little breaks or slow parts that will decrease its speed star difficulty.

Obviously, the higher average SSDR that a map is exposed to it will increase its Speed Star Rating and obviously length will have an impact on this. But, if the stream parts are consistent in a map, those will matter the most in SSDR (note that if a map is mostly about single tapping but have few streams it won't raise that much in SSDR; while a slower map that is more consistent in streams will have higher SSDR)

SSR (Speed Star Rating) will be continuously growing faster the higher is the SSDR it's exposed to while lower SSDR will degrade (a bit) the global SSR by a kind of averages. Obviously peaks will have certain impact in SSR in a permanent way (but, the longer the map is and the stream disappears, it will be slowly losing SSR if following patterns are only single taps)

3.- At the moments we have no idea how to compute Z variable, but basically Z is a value between 1 and 1.50 (limit is arguable, but for higher values it will becoming much more difficult) which would help spaced streams (A variable that depends on aim bonus) and aim flow in overall. Z bonus might be much lower in jumps of 1/2 even if their spacing is extremely large while it will increase by more the shorter the time interval is even if the circles aren't that distant.

On here, we have a table in which I have posted some values of time in seconds and speed star difficulty ratio of some examples (didn't work in more cases because each value was obtained manually, but much more is coming!)

https://docs.google.com/spreadsheets/d/1AbLQBPCuU3WF2OhQVIm88Tm_rE4sq1ew9LrR_sd4GhU/edit#gid=0

Important notes: This may be under-weighting a bit some extremely high bpm maps, so interventions to the original formula will be needed !!

ENORMOUS ADVANTAGES

1. It will rationalize the way to judge map's speed once this proposal becomes clever, complete and applicable.
2. Will do a fair nerf on speed difficulty rating value to very jumpy maps that for some reason are over-weighted in speed. This will impair mostly those maps with large jumps with only 1/2 of not so high bpm like Future Sons [OK DAD] and Choco Cookie +DT maps and many other overweighted jumpy maps that only have single tappings or very simplistic rhythms.

PENDING

1. Finding a way to judge better the sliders (reversals, long ones, etc)
2. Finding a way how AR and CS can intervene in speed difficulty rating.
3. Improving the fluidity of the English that is on this proposal.
4. Finding a way how length can influence speed difficulty rating depending various factors.
5. Modify the Pioneer formula for better results.
6. More content to add and debate.

Known comparations in https://osu.ppy.sh/b/207692 (best map for this kind of evaluations)

[Ai no Niwa BPM120]

• Actual global SSR: 1.86
• Proposal's SSDR: 2

[SHK - Identity Part 4 BPM 140]

• Actual global SSR: 2.16
• Proposal's SSDR: 2.1054

[Cuvelia - Tenkuu no Yoake BPM150]

• Actual global SSR: 2.31
• Proposal's SSDR : 2,15443

[sakuzyo - AXION BPM160]

• Actual global SSR: 2.46
• Proposal's SSDR : 2,20128

[Eoin O' Broin - Oblivion BPM170]

• Actual global SSR: 2.61
• Proposal's SSDR : 2,24622

[sakuzyo - Neurotoxin BPM180]

• Actual global SSR: 2.61
• Proposal's SSDR : 2,28942

NOTES:

1. DO NOT confuse global SSR (Speed Star Rating) with SSDR (Speed Star Difficulty Rating) itself, global one is the final result and it's real Speed Star Rating while SSDR is a value that judges a interval of a map.
2. Proposal's SSR can become higher than its SSDR value the more time you have to maintain that SSDR (some kind of stamina bonus)

[girantinas]

I haven't fully dissected your proposal yet. However I already see one flaw in your formula. The expression inside the parentheses has the wrong unit. A macrobeat is every beat, and a microbeat is the subdivision we are currently using. This means 1/4 is 1 macrobeat/4 microbeats. Let's give the units. The numerator has units of (sec/min) / (macrobeats/min) = sec/macrobeat. Next the denominator has units macrobeat/microbeats. So the fraction as a whole has units (sec/macrobeat) * (microbeat/macrobeat) = sec*microbeat/(macrobeat)^2. Instead we want to find the time interval between notes, or sec/microbeat. We would have to multiply by 1/x instead of dividing by it. So your formula should be
60/(x*BPM)
However this only works for constant subdivisions (macrobeat to microbeat ratio). There are other ways to find the time between notes (they are in beatmap files). Therefore, I would recommend finding another way to do this.
You might want to polish this idea and post a link to it on the main discussion on this topic, in an issue under the normal osu GitHub.