The audio is encoded as 8bit, mono, linear PCM @ 25KHz. This is a standard used by a few Roland machines: 707, 505, etc.
It's the simplest audio encoding and the ROM is effectively a WAV file without the header. Audacity can import it as an 8bit, unsigned, mono "raw binary". If you try this you'll find some recognizable drum sounds, but lots of static and strange noises.
The trouble comes from how the address lines are ordered and manipulated. First off, address lines 6 & 8 are swapped. Since the board is single sided, this was probably done for layout purposes.
The rest of the problems stem from the fact that two gate arrays control different portions of the address bus. IC14 (MB63H114) handles lines 1-12(A1-A12). IC13(MB671189PF) has A0 and A13-A17.
Some of the shorter samples are "interleaved", one sample on the odd addresses, the other on the even. IC13 forcing A0 constantly low(or high), while A1-A12 count normally, will select one of the two samples.
The longer samples (cymbals) are fragmented into 8k chunks. With some experimenting, I found that these chunks are just the opposite of the interleaved samples. They are ordered like dealt cards: 1 card(byte) for hand(chunk) A, 1 byte for chunk B, 1 for A, 1 for B, etc.
The service manual actually explains that this is the result of a kind of "retcon". IC13 is there to give IC14 access to a larger ROM. IC14 was not designed with this in mind. IC14 stops counting up once it reaches its max value of 2^12. IC13 gets around this by assuming the role of the least significant bits(the bits that count up the fastest) and making IC14 count the more significant, "slower" bits. By the time IC14 counts up to 2^12 the combination of IC13 and IC14 has actually counted up to, say, 2^14.
The service manual also gives us a nice table with some confusing naming conventions. The negative address lines indicate that you shift all the other lines left to make room. The A0 column serves to show if a sample is on the odds or evens.
