forum

[Proposal] Expanding a rule to specify the allowable timing error window

posted
Total Posts
10

Should this/a similar expansion be included in the Ranking Criteria in your opinion?

Yes
12
52.17%
No
11
47.83%
Total votes: 23
Topic Starter
Dabbe_01
Gm gamers

Following the discussion regarding this map which entered qualified recently, it seems it's not always precisely clear where to stop with simplifying timings and it was (rightfully) pointed out that general Ranking Criteria do not consider clear timing error limitations, even though the SEV Handbook for BN evaluations does. As shown in the thread, even Beatmap Nominators occasionally can't get to a consensus where simplifying timing to easen the transitions and benefit playability is still reasonable and where it should stop

The crucial part of the current rule regarding timing accuracy for the sake of this discussion is as follows:

Beatmaps must be perfectly timed. This means BPM and offset of each uninherited timing point are exactly synchronised with the song. Beatmaps with constantly changing BPM may be impossible to perfectly time and should instead be as accurate as possible without negatively affecting gameplay. [...]

The proposal I want to give involves rewriting the above rule to include the recommended timing error windows from the aforementioned SEV handbook to make expectations of timing accuracy in maps more concrete, while expanding on the reason for accurate timings a little and keeping the simplification allowance in place:

No objects in a beatmap should exceed the timing error window of 6ms for simple timings, and 10ms for complex timings. This is to ensure lack of jarring audio feedback or unwarranted accuracy drops while playing. Beatmaps with sections of the timing fluctuating tremendously may be made exceptions for and should instead be as accurate as possible without negatively affecting gameplay. [...]
Ryu Sei
Wait, that means this rule also affected?

Hit objects must be snapped within less than 2 ms of any timeline tick.

I might be uninitiated, but within that span of inaccuracy that probably gives some leeway in determining the start of hit objects. Unsure if I should agree or not, but if it's what was accepted, it should be fine.
FuJu
you just rewrote the rule into being longer but the meaning of it stayed the same. so this seems unnecessary to implement.
Topic Starter
Dabbe_01
These two are different and thus the timeline tick rule mentioned wouldn't be affected - object snaps within the timeline are different than representing the audio behind a beatmap (visible with spectrograms for example) with proper timing adjustments

FuJu wrote:

you just rewrote the rule into being longer but the meaning of it stayed the same. so this seems unnecessary to implement.
I already mentioned what role the suggested expansion serves if it wasn't understood (which should have been clear by the wording, won't argue on it tho). Simply copying the ms values from the SEV handbook right underneath the rule might do just fine as well in case this is deemed to be going overboard
FuJu
the numbers in the handbook just imply how we historically handled severity in dqs so they are kinda arbitrary. "must be perfectly timed." already implies "No objects in a beatmap should exceed the timing error window of 6ms for simple timings, and 10ms for complex timings." which is why i said its unnecessary to add. the conflict you are describing in the original post comes from the last part of the rule, which you just basically reworded in a way where it still keeps the original meaning anyways.
yaspo
I believe including exact timing cutoffs is a bad idea. While it clears things up on paper, it makes the rule very unpractical to apply.

How one person applies timing depends on a multitude of factors:
- hardware, quality of headphones for example
- software, osu's audio engine(s) can provide different results for different people
- timing skill, how experienced they are with timing and the precision they can as a result get
- sample handling (im making up terms), whether or not they prefer to put timing closer to the attack of a sound or further away or if they time using different audio cues, can make a difference
- audio clarity, some songs have sections with more slurred samples (think a flurry of electric guitar)
- quantization, some songs aren't quantized but yet are better of with a single timing point
- preference, in terms of complex timing it's definitely possible to just prefer more exact or simplified timing
- playability, how does the timing affect playing the map and should it be simplified/made more exact for that purpose
- ...

Due to the amount of nuanced factors, this will inevitably lead to differing results for different people. The issue described is by result the natural course of things rather than a real issue. These things can be worked out.

I fear that adding exact timing error windows changes this natural course to trying to one-up each other in being "technically correct", rather than trying to find a contextually fitting solution. This would make it even harder to get a consensus due to different interpretations of the same timing being 10ms late or 11ms late for example.
That would be more unpractical than gathering opinions to lead to an improved outcome.

In other words: this makes the current situation a worse version of itself.

A note on the SEV handbook.
This is not a rulebook. It's simply gathered data to give an idea of how things generally work out for the uninitiated. I would advise against using its exact numbers for anything beyond pure observation.
StarCastler
What yaspo said basically. Don’t think this is needed.
BlackyDay
hum hum for that things, people need to know how to time his map btw... and people need to fix that offset when it's pointed too even when it comes in ranking criteria...
imo if the offset have an issue and it's listed by a modder, it need to be fixed
so i hope people try to get perfect timing, but hard to do it on osu, i recommand to have some staff or other who know how to perfectly time a map
PouletFurtif
Here's an opinion:

Simple timing like single BPM songs should remain "perfect". The new rule should not impact this.

Complex timing should have leniency because it can indeed improve playability.
Just map the musical intention. EG When a you map a piano roll, just make a stair with constant snapping. If you don't, it'll be hard to read/hit accurately to the player. You can't expect them to play every musical error properly.
I have this example in my own map: I made a stair from 02:53:962 to 02:55:291. The start and the end are well timed. The notes in-between are not perfectly accurate, but it's what plays best imho.

I don't think we should specify an amount for the error window because each note has a different context. An isolated note requires more precision than notes that are part of a flowing stream.

TL;DR Disagree with having a defined error window, but why not make the wording a bit more lenient for complex timing.
Okoayu
moving this to finalized for now as the discussion in here kinda died and opinions were rather split.

threw it at the rc cleanup project though!
Please sign in to reply.

New reply