Closed ruby-R53 closed 7 months ago
I can confirm this :-/
Additional info:
Very strange, the issue seems to be triggered by playing subsong 9 and reversed by playing subsong 12...
I'm guessing this is intentional as far as the sound design of the game is concerned - subsong 9 is the "hurry up" jingle when little time is left for the level. So it presumably sets a flag in RAM for the sound routine to increase playback pitch and tempo. Subsong 3 and 12 are "stage end" class subsongs so they probably reset the flag.
yeah, that's what i was thinking too but couldn't say it in understandable words lol
Oops, GitHub automatically closed the issue when the pull request was merged to the master branch.
@ruby-R53 Could you please check out if this fixes the problem for you?
it fixed it indeed! nice job :)
I noticed subtune 11 and 10 of SML2's .gbs plays faster than it's supposed to play. It sounds higher-pitched. I'm not sure why it's happening, but I think it could be because gbsplay is not reading the dump correctly as it plays just fine on another player.
If it matters, I'm using alsa output, and building it with pulseaudio doesn't do anything (pipewire output doesn't work properly here for whatever reason).
However, I also noticed that if I put the start subtune to 11 or 10 on the command line, it plays normally. So maybe there's a code on the dump that sets the song speed to a different value and then gbsplay misreads it or something? I'm not really sure, this could be the dump's fault too.
I'm using the latest build of gbsplay currently.