Home Page Forums Other Emulator Message Boards Modeler and M1 Trying to replace a sound sample in Golden Axe

Hello everyone, this is my first post here, I'm sorry if it's too long :-)
My name is Vagelis, I'm a romhacker and I mostly translate games to Greek. In some rare cases, except from altering the font, the text and the graphics, I have to change the sound as well. I've done it in Street Fighter II for the SNES and in Flight of the Amazon Queen that runs on SCUMMVM. In the past two months I've been translating Golden Axe to Greek. The translation is really finished and it's (technically) of top quality, but there is one more thing I'd like to do and that is to replace one of the sound samples. It's the one that says "welcome", number 65 if you want to play it with M1; all the others are screams or sound effects. I'm seeking for help here, as hopefully someone may know technical details.

First of all, let me tell you some things I have observed and tried.
The sample I want to replace is in the ROM file mpr-12384.ic6, luckily at the beginning.
By looking at the bytes there, I can understand that there is some kind of a header. It seems that each sample starts with FF 00 00 00 00 10 (and if that's absolute, there must be 20 samples in that ROM file). I'm not sure where the samples finish, if it's the next pair of FF FF bytes (most probably though). Before the FF 00 bytes (of the samples following others), there are some FF bytes (fillers?), most of the times followed by FF 00 5A A5 and then another FF 00 00 00 00 10 (the beginning of the next sample).
It also seems there are banks of samples, as well and that's because I can see that every 4000 bytes (hex), there is the start of a new sample, and also, before that, there are many FF bytes.
It makes me think if FF 00 5A A5 is something like a command. I'm not sure if it is really part of the previous sample, or something separate, between the previous and the next samples. It's not part of the next sample, that's for sure, because it exists at the end of some banks. Also, if I alter some bytes in the sample, in the game (in the service menu really), this affects the volume of the next 2-3 samples! After I play one that sounds loud then they also are loud again.
Another thing is that right after the bytes FF 00 00 00 00 10, there can be 53, 01 53, 09 53, 10 53, 0B 53, or 0C 53. Byte 53 is always present, but 6 or 7 bytes after the first FF, the offset varies by 1!
Anyway, these are just observations of the bytes. To tell you the truth, I could also check the equivalent ROMs of other Sega System 16B games, to find similarities or differences.

Except from looking at the bytes themselves, I installed Audacity and tried to extract the sound. This way I found out the type/encoding of the sound. It is Raw, VOX ADPCM, mono, 8000 Hz. If I select Import->Raw data and feed it with the whole ROM file, I'll be able to hear all the sounds. I have to cut the part of the first sample, but I'm not certain where to start and where to stop. Start at the beginning, after FF 00 00 00 00 10, after byte 53? Stop right before the FF 00 of the next sample, before the FF 00 5A A5, before the filling FFs?
Anyway, there is also something unfortunate: Audacity has a bad bug and doesn't export a raw VOX ADPCM, it throws an irrelevant error, see here, it happens to more people: https://www.reddit.com/r/audacity/comments/oh1fve/having_trouble_exporting_audio_to_raw/
I have managed to export a file, only two times! I'm not sure how, I think it worked only after a fresh install of Audacity and then running it as Administrator. I have tried old versions, as well as also installing FFmpeg.
This bug is making it extremely difficult for me to experiment...
I can tell you that the one file that Audacity produced, starts with FF 00 00 00 68 and the last bytes are FF FF FF C0 88 08 80 88. It's somewhat different...

One other thing I should say, is that a byte change on the original sample can corrupt it. The corrupted samples don't break the game, you just hear nothing or a click, but M1 throws an error and quits:
"ERROR: unable to load ROM mpr12384.a11
ROM load error, bailing"

Except from this, I'm wondering if it's possible to take advantage of the empty space, the FF bytes at the end of the banks, to add samples! If you could move the samples to different banks, you could take advantage of almost all the empty space. Even if you couldn't do that, the empty space at the end of the whole file would be enough for two samples that are bigger than the "welcome" sound. A "game over" voice would be fantastic. I'm not planning to do that yet, but if I manage to replace the first sample, I might experiment a little.

I know I can also look into the M1 and MAME source code, but I don't know where to start, and I program in C# and VB.NET, which makes it a little difficult for me.
Does anyone know any details that would help? Or even to point me to certain parts of the source code?

Btw, M1 is great! I only downloaded if because of this, but I'll be using it just to listen to some songs, for sure :-)

A small correction: Before the FF FF bytes, there is always 00, so the sounds probably finish at 00 FF and then there are more FF bytes...

You probably already know, but there's some info on the ROM format here: https://github.com/mamedev/mame/blob/master/src/devices/sound/upd7759.cpp

Hi R. Belmont, thanks for the reply!
I read it, but unfortunately there's much I didn't understand.
E.g. it says "The sample rom has a header at the beginning of the form nn 5a a5 69 55". Obviously, this has to do with bytes FF 00 5A A5, but I don't understand how. As there's no 5A A5 69 55 (that would mean master mode), it means slave mode, right?
For slave mode, it says: "The first command is always 0xFF. A second 0xFF marks the end of the sample and the engine stops. OTOH, there is a 0x00 at the end too. Go figure.".
I believe the 00 is necessary as the FF can be a random byte value? Few sounds do have FF somewhere in the middle...
So, the FF at the beginning means the beginning of the sample, and it ends with 00 FF.
I still don't understand what FF 00 5A A5 is, or why it's not always present. Or what byte 53 is, that's always there, or its offset being 6 or 7. I also don't understand the FF bytes near the end...

Today I spent hours, mostly distracted with "SEGA CRI ADX ADPCM" format, that I now believe is irrelevant (it's for Sega Dreamcast and later, I think).
Btw, Audacity has that bug that shows that error, but produces the file despite saying the opposite.

I think that the long sequences of FF bytes are just the default state of the ROM - I read somewhere that the ROM programmer does not have to write to these areas if FF is set, so it is quicker to burn the ROM. I have seen ROMs for other games that do this also.

From what I can tell, it looks like the string FF 00 00 00 00 10 indicates the start of the sample and FF 00 (or FF 00 5A A5) indicates the end, and FF is used to pad the sample to the correct length? But the last sample in the ROM does not have FF 00 or 5A A5 at the end. I tried overwriting the 5A A5 with random data and the samples still play.

I also tried copying the "welcome" sample and pasting it over the very last sample (this is the sample that plays when the very first enemy is killed) and that works, so I think you could use whatever space is available in the ROM if you wanted to replace the "welcome" sample with a longer version, as long as it is padded to the correct length and the ROM is the same size (131,072 bytes). I tried exporting some audio from Audacity but the values look wrong and the game won't play the audio.

There are a lot of versions of ADPCM, all incompatible. I don't know if any existing tools generate data in the format the uPD7759 uses.

The MAME driver seems to be the most-often quoted source of information about the uPD7759, so perhaps it would be possible to build a copy of MAME that outputs some debug data from that driver? I would do this myself but my Mac is probably too old to build MAME now...

I did find a "user's manual" for an earlier chipset but it says that you were supposed to send an audio cassette to NEC and they would then send you a floppy disk with the ROM code. So, a nice scalable solution. That might explain why there are lots of datasheets available but no ROM programming examples.

Thank you both for your replies :-)

That's really interesting! It's like the ROM chip is not even written there. This will give me a fresh look, as I'm trying to figure out how they work.

I thought it was FF 00 00 00 00 10, but maybe it's only FF 00 and the next bytes happen to be the same in these sounds. If I have time today, I will try to check the equivalent files from other System 16B games.
The end is indicated by 00 FF (FF 00 is probably a typo?). FF 00 5A A5 may be or may not be part of the sound file. Most sounds have it at the end, but not all. Today I will experiment with this, even try to remove it.


It seems that at least the main part is compatible with VOX ADPCM, as I can hear the sound in Audacity, if I import the raw data as that. My intention is to copy-paste part of the new VOX ADPCM file over part of the old one. If it's raw data, it should work. Raw PCM has values, it would work - but ADPCM has value differences, and probably that's why it breaks. Except from any bytes that may not be sound, but some kind of command, the first byte I copy has to be changed, really. Audacity can save an ADPCM sound as text, here's a sample:
-25
-1159
2620
1111
654
1900
2278
561
-1624
-1908
1965
So, depending on the first number I paste, maybe the value goes out of bounds. If that's true, it could happen with the first byte after the bytes I paste, as well. I mean, the format may be compatible, but not the values...

I found programs (and code) that produce the SEGA CRI ADX ADPCM format, only that's for later Sega games, for Dreamcast, Playstation, PC; but at least that gives me some hope that I'll make it with the format in Golden Axe :-)



Well, I haven't ever built MAME, so I won't try it for now. But maybe I should try with M1, to see what it checks and doesn't like, and throws that error. Maybe with trial and error I could manually correct the bytes that break it.

Yes, that is a good option if you can build M1. I will look at my copy of M1 if I have some time tomorrow. I think 53 may be the code to play the next 128 bytes (256 nibbles) because this appears at regular intervals throughout the data. There is a bitwise operation using 0x53 in the driver code which is used to calculate the sample frequency, and the calculation works out to 8000 (Hz).

That's a great observation, thanks! :-)))

As the sound can be heard normally after you import the file to Audacity, I had made the assumption that there must be some kind of a header, then you have the raw data and then maybe some bytes at the end. Maybe Audacity takes the 53 bytes for samples, sound data, but they pass unnoticed when you hear the sound.
It seems that what's between the 53 bytes, is indeed raw sound data. I checked the 53 bytes one by one, and near the end, where 53 was expected, there's 93, followed by a number of bytes, before the 00FF. These bytes look similar to the previous raw sound data, I guess they are also raw sound data. I checked the next sounds, and the number of these bytes varies (it's 57, 12, 122, 69 and so on). My guess is that 53 means it should read the next 128 bytes, like you said, but as the sound can have any length and the total number of raw bytes doesn't have to be divided by 128, the last group can have a different number of bytes.
The first sound though has 190 bytes after 93, which means that if it was that simple, it would have byte 53 instead and then byte 93, followed by 62 bytes (190-128). But it doesn't! It has 93, then 66 bytes, then 93 again, then 67 bytes, then 93 again... I don't know if the 2nd and 3rd 93 bytes mean something, or if it's a coincidence.
I will have to experiment with the data. I won't have much time today, till late in the evening, but I think we're getting very close now :-)