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

Audacity is able to "guess" the format just by looking at the data - there is no header in the ROM, Audacity just looks at the sequence of bytes and see if they follow a recognised pattern. So, I think it is ignoring any bytes that do not match a pattern. If you look at the Audacity source code you will see it has some clever logic in it to identify the format.

I noticed that the 93 is significant, I think it is probably used for a similar purpose to 53. However, 93 is a valid audio data value so it could be contained inside any block of 128 bytes. In my M1 debug log, when I play the "Welcome" sample only the last three 93 values triggered an action. The very last 93 value was also preceded by 08 which did something?

It's the same with 53, it is a valid audio data value. So I guess when values 53 or 93 are inside the block of the 128 bytes that follow 53, they are considered audio data values; if they are read where expected, right after the 128 bytes, then they must be considered commands.
There are 53 bytes that are indeed audio data values, e.g. one is at offset F0. That's why I'm not sure if the 2nd and 3rd 93 bytes mean something, or if it's a coincidence. Maybe 93 byte means "read audio data values till 00 FF" (hopefully).

A promising little update: I can now hear the new sound in the game!
It's too low and has hissing, but I believe that may have to do with the file Audacity created. I will have to try with different files or formats.
The main idea was this: I took the new sound (raw VOX ADPCM) and I inserted the 53 byte at the beginning and then after every 128 bytes. Instead of the last 53 byte, I inserted a 93 byte.
If I add FF 00 5A A5 at the beginning, the sound still plays.
Unfortunately I would have to move the following sounds, if I wanted to insert a longer sound. For testing, I can insert a longer sound, of course it overlaps with the second sound and the second sound is not heard. But even if I can't move the following sounds, I can change the tempo (and length) of the sound before I convert it, to take advantage of as many bytes as possible :-)

Good job!

You could try using SoX as this has some different export options. I tried to convert a WAV file but could not get anything to sound right when I manually copied the bytes into the ROM data.

Hello everyone :-)
There was almost no time at all, the previous week... Starting from today, I'm back on this, and I'm hoping to understand the problem.

First, here's something interesting I found online: http://www.bitsavers.org/components/nec/_dataBooks/1989_DSP_and_Speech_Products_Data_Book.pdf
NEC used to sell a PC add-on card, called "NV-300 System µPD775X Family Speech Analysis Tool" (or "Speech Analysis System"), that would allow you to digitize the sound, edit it, trim it, filter it, play it, convert it to ADPCM, then back to PCM (for evaluation), and finally "convert the ADPCM data to µPD775X HEX file" for writing to the ROM.
You can search the pdf with "NV-300" to see details, and a photo of the card.
In page 1-35, it shows the chips that NV-300 would create sounds for:
µPD7755C/µPD7755G
µPD7756C/µPD7756G/µPD77P56C/µPD77P56G
µPD7757C/µPD7757G
µPD7759C/µPD7759GC
In page 4-29, 4-30 and 4-31 you can see the product details, including a photo and two diagrams.
In page 4-33 and 4-34, you can see another peripheral, called "EB-7759 µPD775X Demonstration and Evaluation Box", that was used for evaluation of the sounds. It could be used as a stand-alone unit, or be connected to a PC, or "be plugged into the target hardware to emulate the masked ROM parts".
A newer version of NV-300 is NV-301, and there is also a newer model, NV-310.

I found all that very interesting, but not very helpful, with the file :-}

I have some new observations:
1. Using sox, I created 8 different variations of ADPCM sound. If I look at the bytes with a hex editor, I can see that most bytes are the same, but there are differences. I tried them all, and in the game, the sound the same.
2. I found this page: https://rutube.ru/video/87049aff131218a5d9bc3122fd866cc9/ that has a link to a zip file with voice ROM dumps (that are not for a System 16 game, but a device called "AlliedSignal Mk VII Warning Computer").
In Golden Axe, I could see similar repeating bytes near the beginning and the end of the sound files, like many 11 bytes. I don't know if they are sound data, or if they are some kind of command bytes. I see that they are common in these dumps as well. E.g. the first bytes in a sound are:
00 FF 00 01 53 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 12 11 11 11 11 11 11 1A 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 12 12 31 CB 46 4D EA 24 3A 92 51 CC B2 28 BB 93 43
3. I have tried pasting the new ADPCM data after all these 11s, over the original sound file, but the result sounds the same, always.
4. I have inserted sounds from these dumps I found and they sound perfectly, in the game, whether they have 11s, or not. This means I can use sounds from other games, which is good, just not what I currently want.
5. Maybe the first two bytes (FF 00) are not necessary, as the sounds in that dump doesn't have them! I'm thinking they are a kind of command that maybe initializes something.
6. After some attempts, I have noticed a side-effect. After I play the sound, the sound volume is reduced. If I play it again, it's reduced even more. If I play the next sounds, they are also affected. Sound 04, the fifth one, sounds loud again and restores the volume level for all the sounds.
7. I have found M1 written in C#: https://www.codeproject.com/Tips/646359/M1-NET-Decrypt-Arcade-Audio, maybe it will help me read the M1 code :-)
8. I have found a thesis with a title "Subjective tests on 32 kbps CVSDM and ADPCM codecs for business satellite communication systems": https://openresearch.surrey.ac.uk/v...ePid=13140690740002346&download=true
It has a chapter called ADPCM CODECS SOFTWARE IMPLEMENTATION, with these two parts:
The NEC ADPCM encoder algorithm implementation (page 204, 216 in the pdf)
The NEC ADPCM decoder algorithm implementation (page 219, 231 in the pdf)
9. If I convert a sound to wav and then back to ADPCM (and take care of the 53 bytes), the original and the new ADPCM files have big parts that are the same, and small parts that differ. The same happens with different variations of ADPCM. I'm almost sure that the correct ADPCM variation isn't VOX, or IMA, but NEC ADPCM. Probably Audacity can decode NEC ADPCM and that's the reason it produces a clear wav file.

I believe the only way would be to implement the "NEC ADPCM encoder algorithm", as it's in the previous pdf. All other ADPCM variations will have noise and hissing, because too many bytes are different, even though the voice can be heard because of the common bytes. I will keep searching in the Internet for a possible implementation, but I don't think there is one.

Good research there When I have time I will read the documents.

It does appear that NEC used its own ADPCM format. Maybe the chip was designed to take advantage of some of NEC's optimizations to improve performance, reduce cost or allow inline bytes to control the chip? Audacity uses a rule-based system to decode raw ADPCM data so NEC's implementation should be fairly close to the others but with extra bytes to control the chip. Also, the documentation I have read says that NEC's implementation uses a 9-bit algorithm rather than 8-bit? They also called their implementation "repeated phoneme ADPCM".

I'm not sure that M1.NET supports Golden Axe so maybe it will not help? I think it would be easier for you to use the M1 source (the most recent version of the source code is available on this forum somewhere) if you can build it. The latest MAME driver for the chip has slightly different code to the version in M1, but it is very similar. If you can understand how the decoding works and compare it to the information in the thesis, it should be possible to understand how the encoding works too.

It seems the file is encoded in 4-bit APCM, and there's a conversion to 9-bit by the chip, when the sound is to be decoded. That was confusing, I searched for 9-bit APCM, but couldn't find any programs that support that.

One thing I could try, is the M1 code. I may check the C# version, but first I will search some more, in case I find an existing solution.
I'm also wondering what would happen if I find out which are the common bytes in VOX and in IDA ADPCM (in a new sound), because most probably they would also be common in NEC ADPCM, and then combine these with the original sound's bytes that differ. Obviously I could do that only if the new and the original sounds have the same number of bytes, but that's doable, if I change the duration of the new sound, before creating the ADPCM files.
That's a lot of work to do manually, even for one file; maybe it would be easier to write a program that compares the new VOX ADPCM and IDA ADPCM, marks the bytes that are common, then replace only these bytes in the original NEC ADPCM file with the data of the new VOX ADPCM. It doesn't have much chance, but I'm curious, maybe the noise will be much less then.

Edit:
I uploaded the pdf (with the algorithm) to ChatGPT (it has a "Data Analyst" GPT now) and asked it if it can write code according to the algorithm in page 204.
It replied that the listing of the NEC ADPCM Encoder program is also included! :-P
Haha, the pdf was so big, written in a typewriter and scanned, that I missed it!
Anyway, the listing for the encoder is in page 301 (316 in the pdf) and for the decoder, in page 314 (326 in the pdf).

Although it is not about the NEC chip this ADPCM encoder/decoder guide from Microchip has some information that I found helpful to explain the ADPCM process at a basic level with some code examples.

This does not add much information, but:

I noticed in my M1 debug log when I play the samples that the 53 byte also sets a frequency value of 0x13 - the 0x13 is calculated using a bitmask. Based on the information in the MAME driver, this gives a sample rate of 8000Hz because the 0x13 frequency value is converted to decimal + 1 (which is 19 + 1 = 20) and the sample rate is then calculated by 640000 / 4 / 20 = 8000.

There is also the bit rate to consider. I am not sure how this is determined, but it might explain why your samples are noisy. Maybe the bit rate is not correct?

EDIT: You saw in the thesis that the assembly code is meant for the PC-8000 computer? Now that you have an algorithm, it should be possible to rewrite the assembly code in C or another language.

I thought that myself at first. But the bit rate is determined by the bit depth and the sampling frequency. The frequency is 8000 Hz, the bit depth is 4-bit, so the bit rate is 32 kbps. It's not a separate setting.

Well, there are two options. The one is to directly compile that assembly code for the PC-8000, and the second one is to convert it to another language (I would prefer C#).
The first option means I have to look for an emulator (I have never used one for the PC-8000, but there are many), and also an existing tool, to compile the assembly code. That would be straightforward and it would work out of the box, without any bugs. But I have to find tools for that. We'll see...
The second option is the best if you want to be able to replace other sounds in the future. It will be more time-consuming for sure, but the result would be much better. A Windows program, preferably a command line program.
I have a friend who's willing to assist me, his name is ChatGPT, we'll try the PC-8000 solution first :-/

Edit: Maybe it's a good opportunity to take a look at the games of PC-8000! Maybe I should also translate a PC-8000 game, as well :-)

Yes, I am stupid and forgot that Do you think the noise is due to incorrect quantization values when the audio is encoded?

MAME supports the PC-8801 and there is a list of floppy disk images here which includes CP/M (there are no images for download but you can find out what the filenames are and search for them elsewhere). A long time ago I built QUASI88 from source and it works fine, although I don't know if it can fully emulate the PC-8801. I think it would be easier to rewrite the assembly code in C or C# although that would not be as authentic as writing the assembly using the original computer!