Waveform in editor has visual delay

[Dopaminos]

Type

Cosmetic

Bug description

Waveform is visually delayed by ~+15-20ms. Screenshot with some ranked maps waveforms attached. Obviously it shouldn't work like this because it's wrong

Screenshots or videos

Version

20221228

Logs

no need in logs

[bdach]

This has been claimed before several times and turned out to be incorrect (#12064, #11400 (comment)).

Please link the maps you're testing with for verification.

[Dopaminos]

https://osu.ppy.sh/beatmapsets/1839226/discussion/-/generalAll#/3474615

tested maps - https://osu.ppy.sh/beatmapsets/594170
https://osu.ppy.sh/beatmapsets/1736332#osu/3548649

[bdach]

Yeah I dunno I'm not seeing it.

https://osu.ppy.sh/beatmapsets/594170#osu/1256809 @ 03:35:230-03:35:309:

lazer	audacity

https://osu.ppy.sh/beatmapsets/1736332#osu/3548649 @ 01:13:419-01:13:488:

lazer	audacity

So either both lazer and audacity are wrong, or this information "from experience" is not correct. @Hiviexd care to explain further?

[Dopaminos]

Stable has some delay and that may be the reason of this visual de-sync in Lazer

[Hiviexd]

whenever i try to observe the waveform it feels like ticks are earlier than where they're supposed to be visually, mayb it's normal and i'm misunderstanding something? it feels like they should be around the circled area below, because that's usually the start/peak of the sound that we try to time for

map: https://osu.ppy.sh/beatmapsets/1860311#taiko/3824662
white tick on 02:33:523

[IceDynamix]

the waveform is correct, the issue comes from somewhere else, requires deeper discussion in order to be solved properly and also needs to be addressed before the lazer editor can be fully used as the primary editor

all maps that were timed using stable were timed with audio only, which specifically includes hitsound delay and other sources. other rhythm games whose editors include waveforms show that the waveform is equally off, by about 20-25ms for each map.

to solve this issue, either all maps timed in stable need to receive an online offset of 20-25ms, or the lazer waveform needs to be visually shifted to line up with past timing.

tl;dr all maps are mistimed by 20-25ms in relation to the true waveform

[peppy]

We've already had discussions regarding this internally, and it was recently fixed for the editor from an audible perspective. The visual display may still need updating if it's not being correctly applied there for whatever reason. Or maybe it doesn't as it should match the actual track. Either way, as mentioned it requires further investigation.

See

osu/osu.Game/Beatmaps/FramedBeatmapClock.cs

Line 85 in 7bc8908

platformOffsetClock = new OffsetCorrectionClock(decoupledClock, ExternalPauseFrequencyAdjust) { Offset = RuntimeInfo.OS == RuntimeInfo.Platform.Windows ? 15 : 0 };

If it is currently not looking right, this either needs to be applied visually, or moved to another level of implementation (ie. at import / export time rather than a clock offset) if we want to fix the underlying issue. Probably the first for now, for simplicity.

Claiming lazer is "unusable for timing" is a tad misleading though. It should match to the millisecond in audio and gameplay. Please don't use the waveform alone for timing - use your ear.

Related issues:

• Editor should be using GameplayClockContainer for correct offsets #11400
• Beatmap offset seems incorrect on non-windows platforms (and in the editor) #12064

[ghost]

See

osu/osu.Game/Beatmaps/FramedBeatmapClock.cs

Line 85 in 7bc8908

platformOffsetClock = new OffsetCorrectionClock(decoupledClock, ExternalPauseFrequencyAdjust) { Offset = RuntimeInfo.OS == RuntimeInfo.Platform.Windows ? 15 : 0 };

I forced this offset to be 15 on my platform (Linux with JACK):

platformOffsetClock = new OffsetCorrectionClock(decoupledClock, ExternalPauseFrequencyAdjust) { Offset = 15 };

Issue went away and the editor AND stable maps sounds correct again. Still, I use JACK which most Linux users don't (they either use Pulse or Pipewire, both of which has different latency-related behaviour depending on how the user configures their system), and I don't know what this value does as I'm too lazy to read through the code, so take this testing result with a grain of salt.

EDIT: stable maps sound correct enough for most players. The ~20ms offset inherent in stable maps is still there but I don't think people care that much.

[peppy]

Thanks for your feedback. That's also what I was seeing on macOS. I believe previously when I was testing this (and applied it only to windows), I may have been using incorrect assumptions that it was being applied in areas of the game that it wasn't at that point.

I still haven't concluded my investigations here, and in addition, if it's decided that this should be applied across all platforms it may be that we want to move it to a different layer.

[ghost]

Changing JACK's period size does affect how late / early the metronome plays on my system. Wild guess: 15 probably happened to be just enough because I was using 256 samples at 48000Hz (5.3ms) and Bass.DeviceBufferLength was at 10.

[Trung0246]

I'm curious if a song that requires 0 offset would sufficient to calibrate the visual waveform?

I think I found some beatmap that seems to have "wrong offset" in lazer but when revert offset back to 0 things looks fit (probably mistimed in stable since all maps that were timed using stable were timed with audio only, which specifically includes hitsound delay and other sources). I don't really know if the original offset from these beatmap is correct tho, just speculation. All that in mind here's the beatmap:

https://osu.ppy.sh/beatmapsets/217935 (mistimed by -24 offset, you can see clearly in lazer editor the waveform fits perfectly when offset changed to 0)
https://osu.ppy.sh/beatmapsets/1317808 (mistimed by -18 offset, same as above when changed to 0 offset)
https://osu.ppy.sh/beatmapsets/1846720 (mistimed by -16, same here)

All these songs are viewed in editor on my Windows machine so these maybe affected by 15 offset hardcoded. Can anyone test on other platform?
Feels free to reply if there's more beatmaps that have same 0 offset situation.

[ghost]

I'm curious if a song that requires 0 offset would sufficient to calibrate?

I think I found some beatmap that seems to have "wrong offset" in lazer but when revert offset back to 0 things looks fit (probably mistimed in stable since all maps that were timed using stable were timed with audio only, which specifically includes hitsound delay and other sources). I don't really know if the original offset from these beatmap is correct tho, just speculation. All that in mind here's the beatmap:

https://osu.ppy.sh/beatmapsets/217935 (mistimed by -24 offset, you can see clearly in lazer editor the waveform fits perfectly when offset changed to 0) https://osu.ppy.sh/beatmapsets/1317808 (mistimed by -18 offset, same as above when changed to 0 offset) https://osu.ppy.sh/beatmapsets/1846720 (mistimed by -16, same here)

All these songs are viewed in editor on my Windows machine so these maybe affected by 15 offset hardcoded. Can anyone test on other platform? Feels free to reply if there's more beatmaps that have same 0 offset situation.

This is a common occurence if the .mp3 file is obtained directly from the artist and if the artist didn't insert any funny extra silence at the beginning of the track.

[peppy]

Most MP3 encoders themselves add silence to the start. It's not related to this conversation / issue.

Please take discussion elsewhere for now, I don't think anything further is required to be discussed here (next step would be to test each platform further and implement a fix in code). This issue is already assigned to me and I will take responsibility for that.

[peppy]

TODO: separately check https://osu.ppy.sh/beatmapsets/1676482#osu/3902488 as noted in #23897, which looks to have 200ms discrepancy.

[Trung0246]

Further notes, I think the time rate for 1676482 are misaligned, not just 200ms offset delay. It weird this only happens for this particular song. I seemingly cannot find this happens anywhere else. Probably metadata issues.

What I mean time rate issue is osu! editor have "slower" time advancement (visually, not sound) than Audacity.

Edit: uploading metadata here.

[i77xd]

#21947 (comment)

the waveform is correct, the issue comes from somewhere else, requires deeper discussion in order to be solved properly and also needs to be addressed before the lazer editor can be fully used as the primary editor

all maps that were timed using stable were timed with audio only, which specifically includes hitsound delay and other sources. other rhythm games whose editors include waveforms show that the waveform is equally off, by about 20-25ms for each map.

to solve this issue, either all maps timed in stable need to receive an online offset of 20-25ms, or the lazer waveform needs to be visually shifted to line up with past timing.

tl;dr all maps are mistimed by 20-25ms in relation to the true waveform

I see no one mentioning what I think is the main reason that contributes to mistiming of maps.
Mappers are mistiming maps because of the distorted slowed playback speed (specifically 25%) which they use for timing and finding offset.
Stable doesn't adjust these slower playback speeds by pitch - which results in distortion and the sound appear to start earlier than it actually is.

Here's a demostration using this map which is perfectly timed as shown on waveform in lazer ver. 2023.1224.0 (before the visual delay waveform update)

Slowed.speed.comparison.mp4

You can clearly hear and see in the video that the slowed speed (default, not adjusted by pitch, distorted) sounds earlier which confuses mappers to set the offset incorrectly.

I managed to adjust the playback speed by pitch by switching audio devices on Windows back and forth. This might be a bug or a hidden feature; regardless, it should have been a visible toggle switch (by pitch being the default) in the editor since the inception of osu! - maps would not have been this much mistimed.

#26136
In a recent lazer update, there was a decision to add a 20ms visual delay to the waveform to compensate for this error mappers do on stable and I am heavily against it and want it to be reverted. The waveform was correct and now it's useless.

[bdach]

Mappers are mistiming maps because of the distorted slowed playback speed (specifically 25%) which they use for timing and finding offset

users are not supposed to do this and they are told they are not supposed to do this

see ppy/osu-stable-issues#447 (comment), https://osu.ppy.sh/wiki/en/Guides/How_to_time_songs#finding-offset

also see https://discord.com/channels/188630481301012481/1189078742555951214/1189106682622644224 for procedure of determining said offset value