Improve sound quality of GBA games

[Dwedit]

I'm not exactly sure how the original GSF rippers did it, but I think you just zero out large sections of the ROM, until you're just left with the instrument samples, music patterns, and player code.
Instrument samples are easy enough to find.

[tepples]

Look at a ROM in a tile editor such as 8TED in 1-bit, Virtual Boy, GBA, and Mode 7 formats. (Those are the formats that GBA games most often use.) If it looks like tile data, it's not music data now, is it?

If you know ARM assembly language, I'd recommend finding a debugging GBA emulator and using RAM write breakpoints, similarly to how NSFs are ripped. The procedure should look something like this:

1. Watch writes to the source address registers for DMA channels 1 and 2 to see when it sets up the audio FIFO. This will give you the address of the audio ring buffer.
2. Watch writes to the ring buffer. This will give you the address of the mixer code, which usually runs in IWRAM and is compiled as 32-bit ARM instructions (not 16-bit Thumb). The high nibble of each ARM instruction is a branch before every instruction, and $E0000000-$EFFFFFFF is the code for not taken. (In a tile editor, this will appear as vertical lines running through garbage tiles.)
3. Watch writes to the address of the mixer code so you can find the piece of init code that copies the mixer into IWRAM and find the source address. You will need the mixer code and the init code in the final ROM.
4. While the mixer is running, watch reads from ROM ($08000000-$09FFFFFF) for sample data, and trace through it to find the voice state data structure in RAM that holds the source address, volume, playback rate, etc.
5. While not in the mixer, watch the voice state; this is the sound effect and music player.
6. Follow the 'bx lr' (return from subroutine) instructions until you reach something that looks like it gets called once per frame or once per IRQ.

But if you're using a music engine that a bunch of other games have used, you can probably follow the music engine's data structures to find what is in use and then zero out everything else.

[Bregalad]

I'm not exactly sure how the original GSF rippers did it, but I think you just zero out large sections of the ROM, until you're just left with the instrument samples, music patterns, and player code.

I already know how to localize all music/sample data (see in my doccument, which is now on romhacking.net). But not code. Although I suspect it to be right before the music data, yet I have no idea to know where it starts.

If you know ARM assembly language

I don't.

[Bregalad]

OK tepples I tried doing what you said. Localizing the audio buffer is easy with Visual Boy Advance. However, I'm stuck here.
I spend hours looking for various GBA emulators, and none seems to allow breakpoints. So I have no way to localize code that write to the audio buffer(s). Maybe I should try and contact Cait Sith 2 about that (and have 90% of chances to never get any answer) ?

PS : Is there a way to tell how many CPU% is used in an emulator ? Would be useful to know if there is actually room for better sound quality in some games.

[tepples]

PS : Is there a way to tell how many CPU% is used in an emulator ?

An emulator can theoretically tell on which scanline a call to BIOS IntrWait() occurs.

[Dwedit]

Peek at 4000006h - VCOUNT? That tells you what scanline you're on.

[tepples]

That'd work on a Game Boy, GBA, NES+MMC5, or another system with a working VCOUNT, as long as you're capable of hacking the game to replace, say, the score display with the VCOUNT value at the last vblank wait. I actually did that while trying to optimize certain parts of Luminesweeper.

[Dwedit]

I'm working on a program that does stuff with GBA music...


Here's a screenshot of the program reading data out of Shining Force Advance. I'm getting some weird stuff, like a key split instrument containing other key split instruments.

[Bregalad]

OK Folks,
I just revive this thread to make publicity for my new Java tool here :
http://www.romhacking.net/utilities/881/

It allows to play GBA music using exclusively MIDIs and SoundFonts, without even emulating the GBA, and the quality can be clearly superior.

[Dwedit]

I'm kind of a noob to running Java files if they only exist as .class files. Which one is the executable, and which ones are just libraries?

Maybe you could build a .JAR file or something.

[Bregalad]

The executables ones are the ones mentionned in the readme.txt files, the other ones are the libraries.

Basically you'd only need to execute GBAMusRiper really. Exact instructions are given in the readme.txt files about how to run them from command line.

And I have no idea how .jar files works... but I think this if for java programs that have a graphical interface (mines doesn't have any).

[Dwedit]

So what's a good player for MIDI+SF2?
VLC almost works, but not quite.

[Bregalad]

Almost works ?

I'll assume it reads MIDIs fine but probably it uses your default MIDI synth indead of the sound fonts, which makes it sound like crap.

You'll need something like BASSMIDI driver to use sound fonts with any random PC.

Some old PCs with high quality sound carts can also natively use Sound Fonts (with a program that came with the sound cart), but modern PCs tends to have only simple sound cards on the motherboards without any advanced features (since everyone uses SoftSynths nowdays), therfore BASSMIDI is the way to go.

[Dwedit]

VLC actually does not use the system MIDI at all. It requires you to pick a soundfont file before it will play anything.
But after I do that, some instruments play correctly, and others do not.
VLC seems to be powered by "FluidSynth".

[thefox]

XMPlay (with the MIDI plug-in) supposedly also plays MIDIs with SoundFonts, but I haven't personally tried it yet.