If the first object of a beatmap is placed near the start of an audio file, there will be a tangible lag or stutter (in stable). This is, of course, a poor experience for players and we should be avoiding this if possible. Conventionally, this is fixed by adding silence between the start of the file, and the time of the song starting.

1. Link to peppy talking about this issue, which recommends this solution
2. Link to beatmap discussion which spawned this thread

I propose this as a starting point, phrased assuming it'd be a guideline:

The first object should be placed at least 200 milliseconds after the start of the audio. This is to avoid gameplay stutters at the start of a beatmap. It is recommended that the song begins after this duration in the audio file.

The 200ms figure comes from what Hivie usually recommends, but that's open to further investigation to see what's the optimal duration

yes please, if this issue won't be fixed then the next best option is to actually enforce it via RC, it's quite silly to keep "highly recommending" this to people instead of it actually being a required fix at this point

this was shot down hard by peppy when I suggested it internally ~3-4 months ago

he believes this type of stuff should not be added in the ranking criteria but should instead be fixed in the code itself

we will get to see if this ever becomes a reality!!!

if it was shot down then i do want some sort of explanation as to what we should be doing as beatmap nominators. enforce this? if that's the case, why do we have an unspoken rule/guideline that every beatmap nominator is expected to know but not be able to look up in the singular place where all rules and guidelines are?

These are some arguments I would consider before adding this to RC:

- There's no doubt that this has been ranked before.
- People could play on osu!lazer, which makes this rule irrelevant. With the fact that osu!lazer will hopefully become mainstream at some point, this rule would eventually get removed off RC anyway.
- Hard to explain, but making an extra rule in the RC for a bug in the game seems like a long way round for an issue that should be solved by fixing code. (I am aware it's not that easy, I really do understand, but I can't word this better.)
- We should strive for a concise RC since making too much rules will already make the job harder for NAT/BN-members and modders to be able to mod correctly. Making the learning curve bigger for modding is something we should not work towards. (*)

There are some counterarguments to this that I agree with:
- It's bad for user experience. I absolutely agree for obvious reasons.
- It's not gonna be fixed as read in the github issue thing https://github.com/ppy/osu-stable-issues/issues/686#issuecomment-803227136. TLDR: not gonna be fixed because of compatibility issues for older maps.
- Adding to RC is quick and defines rules easier, better than having "unwritten rules". Additionally, as @Hivie mentioned, highly recommending is kinda goofy, + the fact that it would get the map DQ'd anyway, would actually benefit us.

(*)
I feel like RC changes should be advertised better. I am thinking a news post with broad explanation and changelog for RC changes. I knew about a recent change because I follow NAT on twitternhttps://twitter.com/osu_nat, but most people (modders and BNs alike) will *definitely* miss it. I already had experiences with people (BNs included) that just weren't aware of new changes.

I strongly am against making more and more rules for RC since it's gonna be as long as a bible at some point.
Although I am very conflicted on this issue.
I am leaning towards making this a rule, because I think the good outweighs the bad.

Agree, this is both noticeably annoying and avoidable

200 ms is too much. Make it 50 to 100 ms instead.

add to RC, stop with all this stupid oh yeah peppy should just fix it BS, once it is fixed (if ever) it can be removed from RC

I forgot to mention that the very first absolute note in the editor can only be placed at 15 ms. In stable editor, you can't reach below 15 ms unless you're entering design/storyboard mode, in which it will revert to 15 ms anyway.

To make it harsher since we will DQing these maps anyway, we need to enforce it. The wording can be like:

15 milliseconds would not be enough. The linked beatmap's first object begins at 21ms (and induces the stutter), and the GitHub discussion talks about needing offsets as large as 65ms. 200ms comes from Hivie as that is a safe figure - I'd expect this to vary from user-to-user so going big like this should cover 99.99% of people.

I could potentially see the duration going down to something like 100ms though, if the GitHub required 65ms for one sytem and we also want to be safe with it

Glad to see a 9 year old issue finally get some attention.

Anyways, AR0 with HT gives you a full 2400ms (2.4s) for the approach circle to collide with the hitcircle, and mania with absurdly low scroll speed can have the notes on screen for even longer than that. Plus the offset can currently be set to +-300ms so that's even more to add on to that amount. I'm all for fixing this issue so players don't have to guess/memorize when to actually hit the first note in songs (which is especially stupid and annoying and can even potentially decide matches in tourneys), but if you truly want to accomodate for every player then simply adding a silence to the beginning is not a valid fix, and even if the silence is settled on as a bandaid fix, 200ms is nowhere near enough.

It's better than adding 1000 ms (1 s) of silence, which might be used to evade drain time rules.

The case of AR 0 with HT is almost too unrealistic to even happen most of the times. So does mania with low scroll, even though personally I use low scroll. The main problem in here is the stutter, not the consistency of actual played first note in tournament use case. 100-200 ms of silence/first note time should fix the stutter issue only, and adding unnecessary rules that accomodate tournament use case would be catastrophic since we need to modify almost all beatmap templates in featured artist listing.

Ryu Sei wrote:

It's better than adding 1000 ms (1 s) of silence, which might be used to evade drain time rules.

Silence in the beginning of beatmaps does not count towards drain time.

Ryu Sei wrote:

So does mania with low scroll, even though personally I use low scroll. The main problem in here is the stutter, not the consistency of actual played first note in tournament use case. 100-200 ms of silence/first note time should fix the stutter issue only

Personally testing with 0 global offset and a map with first note at 600ms, the stutter is visible at the top of the screen with 17 scroll speed. If I remember when you first install osu it sets your scroll speed to 12(?) so I heavily doubt just 100-200ms would fix the issue.

Ryu Sei wrote:

adding unnecessary rules that accomodate tournament use case would be catastrophic since we need to modify almost all beatmap templates in featured artist listing.

Tourney fix would just be requiring all maps to have like a 1s audio leadin time, I don't see how that would be catostrphic compared to having to remember when the notes will juke you.

And what does this have to do with FA listing? It is already as scuffed as it is. The few maps I have used .osu files with always had to be re-timed or even had to find another source for the mp3 sourced because the original (from the FA listing) was bloated and unrankable. Even then there are bots out there that you can use to just add a set amount of emptiness to the beginning of the audio file.

Either way, I'm all in towards putting this to rules if we can't fix it from the game system. Now, what would be the optimal distance required for the very first note?

my opinion is if something can be handled at system level, then dont add it to RC

dont push the responsibility on BNs and mapper when its a peppy problem.

if player suffer, let them complain to peppy. its his fault to begin with and hes just being lazy or dont care cuz lazer is more important.

yes please

It must be done one way or another. Besides, we're eventually DQing maps with first object placed at really close to 15 ms since it causes playability/stutter issue. Why don't we implement it as rules instead of making it unwritten instead? I believe someone can argue that their map shouldn't be DQed because "there are no rules requiring so."

Rather than waiting for something uncertain, this rule proposal is closer to certainity in some degree. If it's fixed from the system, then simple; we just pull back and delete this rule. I don't see why are you neglecting in map quality where stutters are definitely an issue in playability.

This might just be my opinion, but since AudioLeadIn exists I guess this could be used instead of adding some time (editing the audio file), after all this does add time (in ms) before the first note.

I personally, with no knowledge of how to edit an audio file, I think it would be more of a hindrance to force mappers to edit the mp3, instead of just saying "Add additional Lead-In time" for example.
Lead-In time is already part of the RC, for when the epilepsy warning is overlapping/interfering with gameplay.

Using Lead-In time also seems to be the safer option, as editing or replacing the audio file could potentially lead to the offset being wrong or ending up with an audio file that is worse in quality.

Wiki entry: Lead-In Time

in o!m this issue is pretty frequent if you're using global offset and 0% effects to listen your keyboard sounds instead of hs

i agree this is kinda annoying stuff we have to deal with.

Jason X wrote:

This might just be my opinion, but since AudioLeadIn exists I guess this could be used instead of adding some time (editing the audio file), after all this does add time (in ms) before the first note.

Clearly this does not work on my side. I have a map with exact 0 ms offset, and adding audio lead in doesn't solve the stutter issue. The map was updated to newer version with +1000 ms silence, but luckily I managed to find the backup of that map.

https://r-sei.s-ul.eu/y0220Gu6

The lead in on the map I linked above has defective lead in value, so you might want to change it before testing (which I did).