Beatmap offset seems incorrect on non-windows platforms (and in the editor)

[Vitaliaosu]

As the title says, the wafeform is offset and it makes the wave form totally pointless.

This image shows the wafeform clearly being offset.
https://i.imgur.com/MyQnPmm.png

v. 2021.312.0

[peppy]

We cannot do anything with this information, sorry. Please re-read the issue template and include all information required, then comment on this issue so we can consider re-opening it.

• Include the beatmap you are seeing this issue on
• Include your universal offset setting value

[Vitaliaosu]

Sorry for leaving little information.

This happens on all maps I've downloaded.

I have no audio offset.

Polyphia - O.D.
https://osu.ppy.sh/beatmapsets/1378026#osu/2847746

gi(a)rlish number - Bloom
https://osu.ppy.sh/beatmapsets/1378026#osu/2847746

[bdach]

Well, to tell you the truth, on comparing with external software I'm not sure that the waveforms are incorrect.

Comparing on one of the maps you gave (Polyphia - O.D., https://osu.ppy.sh/beatmapsets/1378026#osu/2847746), on one bar (00:52:082-00:52:193)

lazer	audacity

As you can see in both cases the start of the bar does not coincide with peak intensity of the waveform. And I'd hope audacity would get this sort of stuff right.

Also note that at that scale, what seems like huge offsets is actually 20-30 milliseconds of difference. In fact, as there is some offset fudging done for windows:

osu/osu.Game/Screens/Play/GameplayClockContainer.cs

Lines 87 to 89 in a86a7b0

	// Lazer's audio timings in general doesn't match stable. This is the result of user testing, albeit limited.
	// This only seems to be required on windows. We need to eventually figure out why, with a bit of luck.
	platformOffsetClock = new HardwareCorrectionOffsetClock(adjustableClock) { Offset = RuntimeInfo.OS == RuntimeInfo.Platform.Windows ? 15 : 0 };

this might as well boil down to something of that sort.

[Vitaliaosu]

You're completely right, although I do think that it's off-putting for new users or even old users to set the timing point at what is supposed to be it's peak loudness, but then realising it's not timed properly. Otherwise the waveform would look distracting and confusing.
All samples do seem to have a bit of an attack roll-off, which is perfectly normal for a lot of music, but in a case like this i do think it's better for the peak loudness to be the impact. This is only if possible of course, I do think a lot of mappers would like this.

[Vitaliaosu]

It’s not really an issue with the audio it’s just the waveform that would make a lot more sense if the initial peak is where the bar would reset.

Red indicates the gap between the peak loudness of the sound and the start of the bar.

[peppy]

You don't need to respond to this thread any more. Please. There is an issue and we will investigate, but what you're doing is spam.

[peppy]

both of the beatmaps you provided match waveform and match in audible difference. the maps are mistimed or the sections you are aligning are intentionally not in time. to my ear both sound mistimed.

[peppy]

That said, this mistiming seems to apply to other beatmaps, which would suggest something is actually incorrect with lazer's underlying offset (at least for me, on macOS). Wondering if the "platform offset" which is being applied for windows is actually something we need to apply everywhere?

[jansenmtan]

I believe lazer's beatmap offset is correct. I see this in Windows 10 as well. As bdach mentioned, the waveform timings match on Audacity. I believe that osu! (standard's) ranked beatmap standards for timing are 26 ms off-time (26 ms late in terms of judgement, 26 ms early relative to audio). I explored this phenomenon in this Twitter thread, and came up with 26 ms from this spreadsheet I made after.

I don't know why exactly this is the case, I suspect it has to do with audio latency and hitsounding. This reddit comment agrees with my thinking.

However, 26 ms is a bit much for just audio+hitsounding. I've measured audio latency on my previous PC to be at worst 10 ms by using ThePoon's method. The PC I currently use seems to have 1-2 ms audio latency on Linux and 15-16 ms audio latency on Windows 10. This is based off my audio/global offset on osu!, which is -28 ms on Linux and -42 ms on Windows. Assuming audio latency on most Windows machines is around the range of 10-15 ms, this still leaves 15-10 ms of discrepancy.
I just noticed this from bdach's comment, which explains why my audio offset on Windows is 15 ms off from Linux.

osu/osu.Game/Screens/Play/GameplayClockContainer.cs

Lines 87 to 89 in a86a7b0

	// Lazer's audio timings in general doesn't match stable. This is the result of user testing, albeit limited.
	// This only seems to be required on windows. We need to eventually figure out why, with a bit of luck.
	platformOffsetClock = new HardwareCorrectionOffsetClock(adjustableClock) { Offset = RuntimeInfo.OS == RuntimeInfo.Platform.Windows ? 15 : 0 };

This means that my current Windows audio latency is the same as on Linux, which leaves a whole 25-26 ms of discrepancy.

idk. 10-15 ms of discrepancy is unplayable for me, but everyone else seems to play okay, so there must be something else to this.

also, idk for sure if it's something lazer is getting wrong, or something wrong with ranked beatmaps. i'd have to study .osu beatmap files and compare them to the waveform timings.

[peppy]

Yes osu! maps are historically timed not matching waveform, due to the audio library changing over the years and needing backwards compatibility.

Going to close this issue as a path to resolution is being tracked in #11400

[jansenmtan]

#11400 was closed a few days ago and yet this issue still remains. Waveform is still offset from timing; changing audio offset or local offset does nothing.

[peppy]

Please open a new issue with video showing you adjusting universal offset and what you are expecting to see.

This has been confirmed through review by multiple people to be working as expected.