[BUG] Speed/Pitch/Haste/HasteRate don't get applied correctly

[DarkBahamut162]

Please give System Info

OS: Windows 10 Home 64-bit (21H1)
CPU: Intel Core i7 2600 @ 3.40GHz
GPU: ATI Radeon RX 580 Series 8GB
Storage: HDD

Please give your StepMania Info

StepMania Version: Project OutFox 5.3 Alpha 4.9.10
Theme: Soundwaves (alpha 4.9.9-HF4)

Describe the problem

1. HasteRate doesn't get applied correctly (example is ITG Pro's "Make Haste!" Marathon Course | all songs have "1.0xmusic,Haste"):

On SoundUseOldResampler=0 the HasteRate doesn't get applied at all.
On SoundUseOldResampler=1 the HasteRate gets applied, but not correctly (at least in Extended/Marathon/Course Mode):

Song 1: Gets Haste applied
Song 2: Gets back to Rate 1.0 with the unapplied HasteRate still at 2.0
Song 3+: From here on out, the HasteRate gets re-applied.

During all of this: The BGAnimations don't get sped up because they don't get the missing HasteRate.
Also for outside of Course Mode: If the BGV is large enough, it doesn't get sped up anymore/fully (?).

2. The "Everything else" section:

This is going to be an adjusted copypaste from Issue #393 since they all still apply here (except for the "inverted pitch" issue that have been fixed already):

Haste Oddities:

44100Hz:

Haste+Speed/Pitch: Does absolutely nothing!
Haste+Speed&Pitch: Acts like Haste+Speed

22050Hz|32000Hz|48000Hz:

Haste+Speed: Acts like Haste+Speed&Pitch
Haste+Pitch: Same as above but with an harsher speedup
Haste+Speed&Pitch: Same as above but with an even harsher speedup

Speed Oddities:

22050Hz|32000Hz|48000Hz:

Speed+Rate: Acts like Speed&Pitch+Rate. But the Rate gets applied double (Rate 2.0 -> Rate 4.0 | Rate 0.5 -> Rate 0.25)?
Speed+Pitch: Same as above but harsher
Speed+Speed&Pitch: Same as above but even harsher

I initially thought that it would matter if SoundUseOldResampler is on 0 or 1 but it didn't.

Describe what should happen

I don't know if this was already broken or not, but still:
Fix Speed, Pitch, Speed & Pitch and Haste with consideration of the song's SampleRate.

Logs and Additional context

I don't think this is a log matter but an engine matter.

[Scraticus]

Thanks for keeping up with this for us.

We'll get on the tweaks on this for the next alpha.

We hadn't coded the stuff for courses yet, so it will be done.

[Sudospective]

Tested, I can confirm that haste is no longer functioning correctly in this update.

[aryoadhi]

Some songs are suffering from this issue. Precisely, the speed/pitch doesn't work, which results in the sound and chart to off-sync. In my issue, the sound plays at normal rate, but garbled due to sampling (I don't know, maybe speed up > slow down?). With Speed+Pitch, it's just the same as Pitch (only increase pitch), but still causes the chart to off-sync.

To mention one of the files, I run mediainfo on the .ogg file and pasted the output:

General
Complete name                            : TalliHua.ogg
Format                                   : Ogg
File size                                : 1.87 MiB
Duration                                 : 2 min 13 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 117 kb/s

Audio
ID                                       : 25453 (0x636D)
Format                                   : Vorbis
Format settings, Floor                   : 1
Duration                                 : 2 min 13 s
Bit rate mode                            : Variable
Bit rate                                 : 112 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 48.0 kHz
Compression mode                         : Lossy
Stream size                              : 1.79 MiB (96%)
Writing library                          : libVorbis 1.0 (UTC 2002-07-17)

[DarkBahamut162]

I would like to add that whatever video has been set in BGChanges and got a rate modifier other than 1.0 also seem to be getting this doubly applied. It might be between 4.9.10 and 4.10.0 where that now broke as well.

[DarkBahamut162]

Well, I would like to add a few more things that I've seen/noticed. Not sure if they are known already or not but I'm saying them here anyway (I have encountered them during 0.4.14.x and are still present in 0.4.15):

HasteRate seems to be forgotten on BGChanges: http://y2u.be/YJZpF4cLMRk
Video shows both sides on 1.0xmusic but the right side has haste enabled (audio comes from that side only). Both videos play at the same speed while the right side's music isn't.
It's on Soundwaves (Alpha 0.4.15) by the way.

ScreenStageInformation seems to screw with the music rates: http://y2u.be/aZWM_T757i8
Video shows both on 2.0xmusic. The left side held down TAB to speed up SSI's animation to fix this while the right side just let it play. The BGChanges AND Stepchart on both sides are on 2.0xmusic, but the right side's audio seems to be on 1.95xmusic? The video has audio from both sides but only on their respective side.
It's on TinyFoxes's legacy theme, since it has "ScreenStageInformation".
Soundwaves' "ScreenLoadGameplayElements" is short enough (at least on dance/pump mode) to NOT make this happen aka be on the left side (I know. I've tried.).

For this third thing I don't know if mentioning it here would be the right place or if I should be doing another issue for it. I don't fricking know, so I'm doing it here. Might even be a nitpick then IF I should...
I've mentioned this one once before (#383 | which might have been ignored due to it being out of scope of the issue itself?) but now, HasteRate joins in as well:
In the end of the first video mentioned above, it's clearly visible that (on right side) both graphs end early and flatline (because of it ending early because of the haste).
I noticed that the music rate has been considered with regular songs but not in Course Mode. It might have been that on both songs and courses, the (combined) MusicLengthSecs is being used as the maxwidth.