5

I am working on a project to try and replace the samples in some old arcade game hardware which uses either the NEC μPD7756 or μPD7759 chips and have been unable to find much information about the specifics of the ADPCM algorithm NEC used. These chips were also used in a number of other applications, including telephony and aircraft warning call-out systems.

These chips are emulated in the MAME (Multiple Arcade Machine Emulation) project but they only decode, not encode, and I haven't been able to determine whether it is possible to derive an encoding solution from just the decoder. There are a very wide range of ADPCM schemes in commercial use but none of the available codecs that I've found in FLOSS software is able to generate a ADPCM sample that will play back correctly with the NEC chips.

Does anyone have any knowledge of these chips or how the ADPCM algorithm differed from some of the commercial ones like Dialogic, OKI or Yamaha? I am asking this question here as it straddles retrocomputing/programming/electronics and figured that RC.SE might be a good place to ask, but please accept my apologies if it's not appropriate.

Thank you in advance for any help or advice.

Improve this question
2
  • Why would it not be possible to work out an encoder from the decoder?
    – user3840170
    Commented Dec 2 at 2:08
  • I'm assuming that there would be quantization errors of some kind, so what you get once you've decoded the ADPCM data isn't necessarily what you started with. If I look at the output generated by some of the other ADPCM encoders, although the audio sounds fairly close the waveforms can look very different to the original WAV files after decoding, and with the NEC codec I don't have any of the original audio files to compare with the decoded audio.
    – Noel Whitemore
    Commented Dec 2 at 9:57

1 Answer 1

Reset to default
4

There's a pretty good description of the operation of the decoder in the MAME source here, and the tables it mentions (the PCM deltas for each state and ADPCM codeword, and the state transitions for each input codeword) are slightly below. Note that the state update is a saturating addition, so if you're in state 13 and the transition table says +3, you go to state 15 (the maximum). Likewise a -1 transition from state 0 does nothing.

As for writing an encoder, you should get acceptable results using a simple one-sample-lookahead algorithm: from a given decoder state, simulate all 256 possibilities of the next two ADPCM codewords, and choose the one that minimizes the sum of squared errors between the decoder output and the next two samples. Then output the first of those two samples, advance the input by one sample, and repeat (obviously the last input sample is a special case, and you can output two samples then).

The only remaining wrinkle is detecting periods of silence and loops in the input so that they can be coded using the special compressed forms. If you really need to squeeze ROM space you can have a threshold for "almost silence" and "almost exact loops" in your encoder; if you don't care about space at all you can ignore them entirely. Otherwise, obvious algorithms should do the trick.

Improve this answer
1
  • Thank you, that's sounds like a good approach to the problem. I'll try and implement your suggestions and will report back. Using a very early MAME driver I was able to determine how the values in the OKI codec step table were calculated but this calculation does not work for the NEC codec step table values in the MAME driver.
    – Noel Whitemore
    Commented Dec 3 at 22:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .