Closes https://github.com/ppy/osu/issues/25633.
The reason why that particular beatmap did not have a double skip
on stable is here:
e53980dd76/osu!/GameModes/Play/Player.cs#L1761-L1770
The particular place of interest is the `leadInTime < 10000` check.
If `leadInTime < 10000`, then `leadIn == leadInTime`, and it turns out
that `AudioEngine.Time` will always be more than or equal to `leadIn`,
because it's also the gameplay start time:
e53980dd76/osu!/GameModes/Play/Player.cs#L2765
This essentially means that if the `leadInTime` is less than 10000,
that particular check is just dead. So a double skip can only occur
if the gameplay starts at time -10000 or earlier due to the storyboard.
Temporary workaround for https://github.com/ppy/osu/issues/26404.
It appears that some audio files do not behave well with BASS, leading
BASS to report a contradictory state of affairs (i.e. a track that is
in playing state but also not progressing). This appears to be related
to seeking specifically, therefore only enable the validation of
playback rate in the most sensitive contexts, namely when any sort of
score submission is involved.
- Closes https://github.com/ppy/osu/issues/25248
- Possibly also closes https://github.com/ppy/osu/issues/20475
Regressed in e33486a766.
`StopUsingBeatmapClock()` intends to, as the name says, stop operating
on the working beatmap clock to yield its usage to other components on
exit. As part of that it tries to unapply audio adjustments so that
other screens can apply theirs freely instead.
However, the aforementioned commit introduced a bug in this. Previously
to it, `track` was an alias for the `SourceClock`, which could be
mutated in an indirect way via `ChangeSource()` calls. The
aforementioned commit made `track` a `readonly` field, initialised in
constructor, which would _never_ change value. In particular, it would
_always_ be the beatmap track, which meant that
`StopUsingBeatmapClock()` would remove the adjustments from the beatmap
track, but then at the end of the method, _apply them onto that same
track again_.
This was only saved by the fact that clock adjustments are removed again
on disposal of the `MasterGameplayClockContainer()`. This - due to async
disposal pressure - could explain infrequently reported cases wherein
the track would just continue to speed up ad infinitum.
To fix, fully substitute the beatmap track for a virtual track at the
point of calling `StopUsingBeatmapClock()`.
