[CodyZeppelinR]

Hi,

I am attempting to extract the sound tracks directly from a variety of Gameboy games to visually document as sheet music or through Synthesia as MIDI. I would like to teach myself how to play each one properly on the piano. I have found the MIDI files for most of the songs I wish to learn already on the web, however the majority of them are hand-made and are unfortunately incorrect.

I have searched into ripping the actual game files into GBS (.gbs) format, and was successful up to a point. I was able to get an exact rip of Pokémon Red Version as a GBS using "GBgbsV1.0", however the only program I am aware of that will take from the ".gbs" is the Linux software "gbsplay-0.0.91". Unfortunately, this program is limited as to how it outputs each track as a MIDI. Each ".mid" has a problem in that the individual channels are not separated, and clash with one another when played through any MIDI software. Notes are often elongated, or overtake each other, leaving the sound choppy and incorrect.

I am wondering whether there is any better way of going about what I am doing.

[Jorpho]

Well, I can at least tell you that the Meridian Winamp plugin will play GBS files.  That's what I use.
http://www.zophar.net/utilities/gbs/meridian.html

I don't know about GBSplay, but Meridian will let you selectively mute each of the four audio channels.  Perhaps you can make a WAV of each of the channels (using Winamp's Disk Writer output plugin), and then use the WAV in some kind of WAV-to-MIDI program?  I have no experience with those.

[Bregalad]

The only proper way to do that is to

• Reverse engineer the sound engine of the game
• Figure out how the musical data is stored in the game (so far, all music engines I've ever encountered uses some sort of musical byte code)
  
• Write a PC program that rips the musical byte code from the game into MIDI format

The main problem being that this only work for a single game, or in the best cases for a couple of games by the same company who happens to share the same musical bytecode.

This is precisely what the SongRipper part of GBAMusRiper does by the way. Unfrotunately it's for GBA, not GB or GBC, but the concept applies to all sound engines.

[CodyZeppelinR]

This was the conclusion I came to as well, and ultimately the reason I am here. I was able to use "GBAMusRiper" no problem for a few games, but the difficulty of the songs are too high, and there are too many different instrument tracks. Not to mention they are not the originals.

Alright, would anyone be able to point me in the right direction as to where to begin, then? I am up for the task, I am just at a loss for how to go about doing it. :S

[Jorpho]

If you really wanted to, you could open the .gbs file in a hex editor, look for patterns, try changing something, and then listening to what difference it makes in the music.  Though trail-and-error you might eventually be able to deduce the format.  (I understand a .gbs file is basically a Game Boy ROM from which everything has been stripped away except for music-playing code.)

A less crude method might be to use the gbsplay source code to output something that can be more readily changed to MIDI than straight-up WAV output, or perhaps a MIDI directly. The MIDI file format seems pretty straightforward.

[Bregalad]

I have only cracked the musical byte code of a couple of sound engines, but I belive what I have done can help. I am probably one of the first romhackers ever interested in this since I first cracked the byte code for Secret of Mana + Final Fantasy Mystic Quest + Final Fantasy V + Hanjuku hero (they have identical sound engine) something like 10 years ago (but I kept everything private for a very long time). Only this year I made a (very dirty) program to convert it to MIDI for my FF5 advance hack. The key to craking byte code is, as usual, pointers.

On the GBA this was relatively easy because it's very obvious if a word is a pointer or not, all ROM pointers ends with the 0x08 byte. On the NES or GB there's no equivalence unfortunately, so your best guess is see words of increasing values following themselves, then you have a chance of them being a pointer table.

A good way is to know the RAM pointers that points to the musical byte code of each track. (in the case of the GB/GBC you'll have 4 pointers) If you have a debugger/RAM viewer, you should see them increase little by little as the music plays. If you see them increase by 1 (or 2) every time a new note plays, then it's definitely the pointers to musical byte code. Once you have the location of musical bytecode of a particular piece, everything is open to you : Just change it randomly and see what this changes, noting everything it does.

Another good way to do this is locate where the sound engine is located, disassemble it, and study.

However I'd definitely recommand a mix of both for easier & faster results. Usually music engines involves notes of many different lengths, and it's hard to "crack" the lengths just by hearing, so by looking at a part of the disassembly you'll figure out the relation between byte code and note length. Also some effects are sometimes hard to notice in some circunstances by just randomly trying bytecode, so disassembly will definitely help.

Some japanese guy however cracked much more byte codes than I did, mainly for the SNES, I guess his pseudo was lovemu or something. You could ask him for better advice.

In order to know what to expect, here is an very typical exemple of what a musical byte code could be :
0x00-0x0F : Play C note with different lengths
0x10-0x1F : Play D note ....
....
0xB0-0xBF : Play B note with different lengths
0xC0-0xCF : Play silence with different lenghts
0xD0-0xFF : Some random commands such as octave change, instrument changes, vibratos, end track, etc, etc...

It's also common to see "subroutine calls" or repeats in the byte code.

[CodyZeppelinR]

These are fantastic ideas, and extraordinarily useful, as well!

On the subject of pointers and the hex addresses, I have glanced over http://datacrystal.romhacking.net/wiki/Pok%C3%A9mon_Red_and_Blue:ROM_map. I checked into the Title Screen Theme pointer in Bank 1F, at 7C249-7C254 to check for consistencies, and noticed the addresses that track notes at 0xC066, 0xC067, 0xC068, although several other spots in the area show similar changes, and I am unsure of the correlation between them. They remain constant with the music as it progresses within the game.

I shall have to load up the RAM Watch on a better computer, though, as my laptop is murdering the sound and overall performance.

Knowing these values is of great use, however I will admit I would not know how to change, or otherwise manipulate them upon doing so, anyway. I apologize, but I am new to the world of hex editing and ROM hacking. Any suggestions?


Thank you all, by the way. Definitely much appreciated! 

[Jorpho]

Knowing these values is of great use, however I will admit I would not know how to change, or otherwise manipulate them upon doing so, anyway. I apologize, but I am new to the world of hex editing and ROM hacking.

It's pretty much exactly like editing any other kind of file.  You get a hex editor (I like XVI32) and you open the file.  Typically the left side of the hex editor window displays the raw binary data, byte by byte, in the form of hexadecimal numbers ranging from 00 to FF (that is, 00000000 to 11111111 in binary, or 0 to 255 in decimal).  The right side shows the ASCII representation of the data, which will typically be complete gibberish.

If you want to change a value, you just select the value and type in a new one in the range of 00 to FF.  It is important to only replace values and not insert them, as inserting values changes the relative position of everything and can easily render the file unusable.

To be clear, only some values represent data – program code also takes the form of hex values.  Unfortunately, it's pretty hard to tell the difference at a glance.  But a quick look at the .gbs files I have sitting around suggests that there are visible patterns in the hex values that probably represent data.

[IIMarckus]

Note that Pokémon Red and Blue have been completely disassembled, and the music has been dumped (in a custom text‐based format).

Pokémon Crystal hasn’t been completely disassembled, but its music has similarly been dumped. In fact, there’s a modified version of the Crystal disassembly, CrystalComplete, with music imported from Pokémon Red, Pokémon Pinball and Pokémon TCG 1 & 2, as well as some custom tracks.

[CodyZeppelinR]

The disassembled audio is almost exactly what I am looking for in terms of the notes that are played! Is there any way to export it as a MIDI or other visual representation of it, where the notes are grouped and played together?

As for searching through the game's code to find the note values (which now seems pointless as it has already been done), aside from finding the locations of the actual sound channels, I am not really sure what else to do or look for. I don't know what affects what and where those notes are being pulled from. I do not know the sound engine at all to be able to pinpoint how the notes are affected by pitch or velocity. I am completely new to this, and was wondering if there are any specific places to start past the introduction and very basics. I am very lost on a lot of these concepts. 

[Jorpho]

The disassembled audio is almost exactly what I am looking for in terms of the notes that are played! Is there any way to export it as a MIDI or other visual representation of it, where the notes are grouped and played together?

...Are you suggesting that over the last eighteen years, no one in the multitudinous fanatical legions of Pokemon devotees has ever once put together satisfactory sheet music derived from the games?  I would find that very surprising.

Even if you could export it to MIDI, and even if the result sounded something like the original, I suspect the MIDI won't make for particularly usable sheet music.  You can see for yourself by downloading any old MIDI from somewhere and importing it into whatever you might have in mind for making sheet music.

As for exporting disassembled audio to MIDI, as I suggested above, you'll probably have to put together something manually.  If I had to do it, I would start by looking for a suitable Python module.  https://wiki.python.org/moin/PythonInMusic lists a bunch; PyMIDI looks promising.

As for searching through the game's code to find the note values (which now seems pointless as it has already been done), aside from finding the locations of the actual sound channels, I am not really sure what else to do or look for. I don't know what affects what and where those notes are being pulled from. I do not know the sound engine at all to be able to pinpoint how the notes are affected by pitch or velocity. I am completely new to this, and was wondering if there are any specific places to start past the introduction and very basics. I am very lost on a lot of these concepts. 

Like I said, trial and error and experimentation is the way to proceed.  Of course it isn't easy – if it was, everyone would be doing it already.

[IIMarckus]

The disassembled audio is almost exactly what I am looking for in terms of the notes that are played! Is there any way to export it as a MIDI or other visual representation of it, where the notes are grouped and played together?

https://github.com/mtolly/pokemid

I’ve never used this but have been told that it supports round‐trip conversion of music from the Red disassembly without issue.