[BUGFIX] Fix for strange ChartingState hitsounds offset, i hope

[PurSnake]

Hitsounds had wierd offset, not they dont.
(Flixel thing, i guess)

(Yes, I had to use clideo to compress the video, 10mb for video is CRAZY)

Before:
https://github.com/user-attachments/assets/8fbe0f58-075d-42fe-94e4-0fd8d7f06f3c

After:
https://github.com/user-attachments/assets/9e70898f-08e2-40a5-a60e-327bcfda2373

Aannd DadBattle Erect with fixed hitsounds offsets, because it's charted normally:
https://github.com/user-attachments/assets/afe3a551-a7d4-435b-bb2e-bb232955308e

[Hundrec]

Big if true!

[biomseed]

This just adds another offset of -13 to the playing of the sound. I don't think Eric will approve this but it's a good way to fix it either way if the sound effect itself is delayed without the team knowing. If it is, they should just get rid of the offset of the sound effect itself and that would fix the issue, but if it's not then this may be the only way.

[lemz1]

When I look at the sound in audacity, it doesn't seem like the sound has an offset. Maybe this is an issue with how sounds are played in haxeflixel?

A picture of audacity:

[biomseed]

A picture of audacity:

The opponent one DEFINITELY has an offset that the player one does not, and it's caused by the sound effect starting up it seems, which the player one doesn't do because it may have been edited out of that one. This should not happen unless the devs accidentally slowed down the sound effect (which they can easily fix by just pitching the other sound to the same pitch without slowing down and using that instead) or they edited it out of the player one and forgot to do it for the opponent one.
(For Eric if you read this, the delay is definitely an issue and DOES exist)

[lemz1]

A picture of audacity:

The opponent one DEFINITELY has an offset that the player one does not, and it's caused by the sound effect starting up it seems, which the player one doesn't do because it may have been edited out of that one. This should not happen unless the devs accidentally slowed down the sound effect (which they can easily fix by just pitching the other sound to the same pitch without slowing down and using that instead) or they edited it out of the player one and forgot to do it for the opponent one. (For Eric if you read this, the delay is definitely an issue and DOES exist)

I guess the opponent one does have a small offset but if you look at the time, it is below 3ms. Im pretty sure that, this is not noticable.

[biomseed]

I guess the opponent one does have a small offset but if you look at the time, it is below 3ms. Im pretty sure that, this is not noticable.

Even if it's not the source of the problem (very likely not), it should be fixed to begin with. That is a delay.

[lemz1]

Maybe this is an issue with ogg/mp3 files. I can't really say for certain, but I remember reading something about ogg/mp3 files containing delay, because of the compression algorithm.

wav files shouldn't have that problem because they are uncompressed.

I dont know how haxeflixel handles audio, but if playing an audio requires creating a new thread, then that could also be the problem.

[AbnormalPoof]

Quote from a comment in #2375:

It seems to be an issue with the OpenAL Soft time change on Funkin's Lime fork. I tried the fork on a different non-FNF related project and it seemed to suffer the same issue