Dumping Audio Ram to Take Audio Samples

I've been trying to do this exact thing, using BSNES Debugger to dump audio ram and playing it in Audacity, but it all sounds like garbage, and I'm wondering if maybe I'm doing it wrong because it gives you a bunch of options as how to play it. It asks you as to whether the sample is: (unfortunately, I have no clue what any of this means)

8 bit unsigned PCM,
8, 16, 32, or 64 bit signed PCM,
32 or 64 bit float,
U or A Law,
GSM 6.10,
12, 16, or 32 bit DWVW,
VOX ADPCM,

and it also asks if the sample is little or big endian. I know the sample rate would be at most 32000kHz, but that's probably very unlikely it will ever be that, and I imagine it fluctuates for each sample.

SNES BRR is most nearly similar to IMA/VOX ADPCM, but is sufficiently different that you're not going to get a generic importer to work.

Audacity does not support Super NES BRR format out of the box. You might want to try using a program called SNESSOR to rip samples out of the RAM dump and turn them into wave files.

Tip: If you've never seen an .spc file, it's a SPC700 save state.

Unfortunately, my computer says the "software is not compatible" with my computer.

I forgot about how samples were compressed though. I didn't think sound was compressible enough to even bother. The only reason I thought this would work is because I've done it with Gunforce 2, as it has a file solely dedicated to sound samples (And they aren't compressed).

Edit: Actually, I imagine someone could have the sounds for this game dumped already.

Yeah, someone did: http://www.williamkage.com/snes_soundfonts/ (Kind of unfortunate R-Type III is not on this list, but I think that's expecting too much...)

It's funny you posted a thread about ripping PCM samples from games. I was just about to post a thread asking if it's possible to play uncompressed samples through the channel volume registers, and if you can get the spc700 to update several channels fast enough.

If you want to play uncompressed samples on the S-DSP, you'll have better luck writing them to the echo buffer.

Not even through an emulator like DOSBox?

Oh... I forgot about DOSBox... I still have what I need though.

I just checked the asm docs for spc700 and found this:



Is that what I think it is? Adding a direct page register to another direct page register? I can't believe I didn't notice this instruction before.

The problem with that is that the echo buffer is 32 kHz 16-bit stereo, meaning you need to write four bytes every 32 cycles, and I can't think of many good ways to cheat on that. blargg's demo has the SPC700 going flat out, and it only works because he's set it up to not need indexing.


No, that was BRR files specifically. Even a modern compression scheme is almost useless on them, because they're already compressed.

Audio in general isn't as compressible as, say, text, but it's often possible to get around 50% if you need lossless compression, or far better if you don't.

Let's see how fast the spc700 is at simulating a PCM channel.



Counted 34 cycles. Slightly too slow, but I think it can be optimized further.

Wait? How do Genesis devs do PCM playback with the Z80 without interrupting the music?

My utility has more advanced features than SNESSor and can read the index from within a .spc dump directly to point to the loaded instruments already.

SNESSor is better at looking for samples from a ROM directly, however this do not seem to be like what you want to do.

Since we're on the subject, I believe there was a typo which caused the decoder's gaussian filtering option to muffle the output unduly. Has that been looked at?

@Espozo: you probably don't want that option anyway if you're extracting the samples, so this shouldn't matter much.

Actually many Genesis Z80 drivers does not handle that really well, notice how some games (ThunderForce serie for instance) interrupts music while playing voice. Some others (as SF2) chosen to take FM on 68K while Z80 handle (badly) PCM.
But with cleverly designed driver you can do everything (and even more) on Z80, buffering and cycle counting are the key
The driver i made mix 4 PCM channels (8 bit @14 Khz) while playing FM and PSG music. Here's the source, maybe it can inspire you about how handle similar things with SPC :
https://raw.githubusercontent.com/Steph ... 80_xgm.s80

Is the music stored as just register addresses and data? It says your format is based on VGM which is like that, plus I can find an unrolled loop doing that.

Yeah music is basically couple of register address & value writes. I have to store some extra state info here and there for correct pause and resume operation and the format use better storage rules than vgm (sort of RLEed commands) to optimize xgm data size but that is it. Per frame the driver accept up to 256 bytes of command (well not exactly but sort of) and except in very specific case (init / instrument change of many channel at same time) that never happen...
I think the unrolled loop you saw was just the part which buffer the xgm commands strean inside z80 memory.

Of course this was fixed as soon as I saw that post back then.

I'll investigate this tomorrow.

Where is the updated version? The files at your link are all from January 2014.

Is it just me, or do some of the samples have the wrong loop points, when used in OpenMPT? Does the BRR compression smooth out the loop points when played on an SNES?



How much memory does an XGM file take up?

Really depends about how much samples you use, as well as music complexity...
Thunder Force 4 uses FM / PSG only music (no sample) but are quite complexes and consume about 50 KB (average).
Streets of Rage 2 - Go Straight consume about 95KB in XGM with samples.
Simple music can take as low as 7/8 KB where very heavy music with lot of samples probably up to 150/180 KB.
The thing is that you can share some samples between different music to reduce rom size.
Today i think rom usage optimization is not that important, don't mean i want to waste it but using 1 MB just for (good) music is not shocking Super Street Fighter 2 uses about 1.3 MB of sample data because of the waste use of long samples (simulated echo when dying for instance).