I'll be honest: I don't know how to explain it in 50 characters (I'm sure the title is 100% confusing; I really don't know how to summarize it). And I don't know how to explain it in a general manner even if given any amount of character, so I'll just give a case example.
I planned to map a song, which offset is at 9288 (00:09:288). Strangely enough, if I hover to the tick where the uninherited timing point resides, it shows 00:09:287 instead of 00:09:288. And yes, it's off by 1ms.
What's worse is the fact that you won't be able to slow down a slider at the offset because the note there will be snapped 1ms earlier than the timing points, making it unaffected.
This happens rarely, yet they are so sporadic it feels as if something like an RNG decides what song gets this and what doesn't (I even tried reencoding an mp3 of a song that gets affected by this in the editor, but the reencoded file is also affected too).
This problem has been lying around for years, but I guess it's just never mentioned. Or maybe I missed it and it's already reported but yet to be fixed (and I seriously don't know the keyword to start finding this problem in the forum). I usually just skip mapping the song that gets affected by this, but I figured I have to tell this ASAP.
The only way to fix this for now is to shift the timing points by 1ms earlier, but if you move the slider around it'll be 1ms earlier from the ticks again. Leaving it helps, but then it'll be unsnapped by 1ms.
osu! version: 20150414.2 (latest)
I planned to map a song, which offset is at 9288 (00:09:288). Strangely enough, if I hover to the tick where the uninherited timing point resides, it shows 00:09:287 instead of 00:09:288. And yes, it's off by 1ms.
What's worse is the fact that you won't be able to slow down a slider at the offset because the note there will be snapped 1ms earlier than the timing points, making it unaffected.
This happens rarely, yet they are so sporadic it feels as if something like an RNG decides what song gets this and what doesn't (I even tried reencoding an mp3 of a song that gets affected by this in the editor, but the reencoded file is also affected too).
This problem has been lying around for years, but I guess it's just never mentioned. Or maybe I missed it and it's already reported but yet to be fixed (and I seriously don't know the keyword to start finding this problem in the forum). I usually just skip mapping the song that gets affected by this, but I figured I have to tell this ASAP.
The only way to fix this for now is to shift the timing points by 1ms earlier, but if you move the slider around it'll be 1ms earlier from the ticks again. Leaving it helps, but then it'll be unsnapped by 1ms.
osu! version: 20150414.2 (latest)
