Having some trouble playing a few GSF rips. by AnOldGuyNamedFinch at 3:14 AM EST on January 29, 2018
I'm not sure if the issue is with Foobar2000, the GSF decoder plugin, or the rips I'm using, but there are two soundtracks that I can't play any files from - F-Zero Maximum Velocity and WarioWare Inc., Mega Microgames.
Both of these used to work just fine, but then it started throwing up error messages saying that they were in an unsupported format (despite other GSF rips working just fine), and after recent updates, they just play a second of silence before stopping without ever showing a single error popup.
What's happening here? Is anyone else having this problem?
I was so close to creating this thread a few days ago :3
Mario & Luigi: Superstar Saga is another broken gsf as well, and I recently found out about the Donkey Kong Country 3 GBA soundtrack. With the latest version of the gsf plugin, it makes the soundtrack sound like someone jacked the gain up by quite a bit and it sounds terrible. Downgraded to 2.0.6 and it sounds perfectly fine.
Last thing to note is that Warioware Twisted was only ever ripped from the JP version; we have no english rip of Mona Pizza. Just thought I'd mention that.
Edit: @mariofan12ify You posted that as I was typing this out :3
Oddly enough, Superstar Saga works fine for me - the only ones I'm having issues with were the two that I mentioned, and I have absolutely no idea why.
Unfortunately, that is far beyond my abilities as of this moment. I might look into it later on down the road when I know more about how it's done (assuming someone else doesn't beat me to the punch by then, of course).
All you need is a GBA ROM dump that's stripped of unneeded data, and boots directly to music playback code. minigsfs will set the song number to play, and the gsflib will contain the base image.
The existing rips can often be fixed by debugging them and removing any extraneous code that mGBA doesn't like, such as unneeded save memory initialization and loading code.
I made a GSF unpacker, it's on my Github gists page, I think. IDA Pro can debug GBA rom images.
Using a disassembly tool and reading ARM assembly would be considerably easier, especially if said disassembly tool knows about system libraries and function calls.
I have investigated 2 games above for a little. Both GSF sets will work when unoptimized gsflib is used, but it will stop working after the optimization by gsfopt. I had experienced a similar issue with a few games before, that's the reason why I made my own gsfopt forked by viogsf in those days.
I don't have enough motivation to fix the problem for now. However, I can provide IPS patches that will make unoptimized music player ROM.
1. Decode original gsflib `gsfopt -r oldlib.gsflib` 2. Copy erased part (filled with 0) from unaltered ROM (done by simple script) 3. Write back some 0s when it is wrongly replaced (using some hex editor) 4. Done
Another option may be to use the mGBA core to build yet another fork of gsfopt, since that's the emulator the current version of the foobar2000 plugin is based on. That's some work, though.
I know it's a huge game, but I was wondering if WarioWare is possible to be re-ripped? Not only does the current set not work on newer versions, but there's some music missing (the title screen music for the 2-player minigames is one).
I restored a couple of functions which have gotten partially wiped by gsfopt, by hand.
I know the gsfopt (VBA-M) and foo_input_gsf (mGBA) are using different emulation core, but I don't understand the exact point of the cause of the issue. I think WAITCNT relates to the issue, but have no more idea than that.
TL;DR Make sure to remove every Cart RAM accesses before the optimization.
I have experienced similar cases in multiple games and I have concluded that the issue is caused by Cart RAM (SRAM/Flash/EEPROM etc.) access. A good rip should not have such an extra I/O access, however, it can be missed easily on manual rips, since there was no auto detection mechanisms and it somewhat works well on the emulator.
My gsfopt (based on old viogsf of VBA-M core) doesn't emulate Cart RAM accesses and always returns 0 for read access. This behavior obviously makes unexpected branching. GSF player will try to operate unknown opcode and stops working, when the player reaches to the code wiped by unexpected Cart RAM handling.
I have added a little code to my gsfopt, which will generate warnings on the Cart RAM access. I hope it will help rippers to notice that the gsf contains unwanted code inside.
While debugging on no$gba, the following breakpoint syntax is handy to check the Cart RAM access.
[0d000000..0effffff]!!? !? ... syntax for breaking on any read or any write
I don't know whether VRAM/OAM/Pallete accesses may cause a playback/optimization issue, however, they should be removed as well. They can roughly checked via the addrest range [05000000..07ffffff]
Edit: The F-Zero gsflib above still have some VRAM write accesses. Oh! I probably won't try to fix it for a while, since it probably won't cause any problems.