nesdev.org

I can't figure out how the 3 "filters" have any mathematical reasoning behind them. They seem pretty random, like Ken Kutaragi just picked some random math equations out of a hat.

The first "filter" makes a little sense, since it practically a DPCM decoder, but why must the last sample be multiplied by 15/16?

The other 2 "filters" I can't make any sense out of them. If they are called "filters" what do they filter out and why?

psycopathicteen wrote:The first "filter" makes a little sense, since it practically a DPCM decoder, but why must the last sample be multiplied by 15/16?

So that errors don't build up over time and become DC offsets. This is a fairly standard leaky integrator.

The other 2 "filters" I can't make any sense out of them. If they are called "filters" what do they filter out and why?

They're second-order resonant IIR filters. The filters are used to whiten the signal, in much the same way as the "floors" in Vorbis. I haven't analyzed the filters to see their exact center point and Q value, but a good converter will end up picking the one whose frequency response most closely matches the spectral shape of the 16-sample block.

I guess there is some math behind it. Some really confusing complicated math that is over my head.

A good converter need not do that much. An acceptable but expensive converter can brute force every possible filter and scale value combination for the least mean square error compared to the input sample data.

One would need only to brute-force each of the four filters, as the peak of the prediction residues would give the scale that doesn't clip.

Good idea. Maybe somebody can work that into the decoder I wrote ages ago, or maybe there's a better one floating around now?

psycopathicteen wrote:I guess there is some math behind it. Some really confusing complicated math that is over my head.

Well don't worry, you're not alone. I barely understand the S-DSP myself. I just think of it like the CRC32 seed value. I'm sure it has a significant and complicated history, so I just make sure to use the right magic number and move on.

I'd really enjoy a step-by-step walkthrough of the entire DSP, "this is what this does, this is why it does it, here are two audio samples to demonstrate the effect, here's a video and some pictures showing the effect."

It's amazing how humble blargg is, given that his DSP emulator is genius.

byuu wrote:It's amazing how humble blargg is, given that his DSP emulator is genius.

I mostly took the genius existing work of previous people and refined it, as I've done with other things (NES APU for example). Most of my "genius" is hundreds of hours of hard work, rather than merely divine inspiration

psycopathicteen, the filters are pretty simple to understand at a high level. You've got a set of 4-bit PCM samples, which clearly won't sound good for some waveforms if they just generate a rough stair-step waveform. So you smooth it out. These filters use different smoothings. Why multiple ones? They make different shapes that fit the sample points, and presumably the BRR encoding tool tries each filter and uses the one that fits best.

Good idea. Maybe somebody can work that into the decoder I wrote ages ago, or maybe there's a better one floating around now?

I did that about one year ago - I ported your encoder to java and improved it a little. Search "BRRTools" on romhacking.net to get it.
I asked you if I could use it so you should have remembered it.

An acceptable but expensive converter can brute force every possible filter and scale value combination for the least mean square error compared to the input sample data.

What are you talking about ? It's freeware.

An acceptable but expensive converter can brute force every possible filter and scale value combination for the least mean square error compared to the input sample data.

What are you talking about ? It's freeware.

He may be referring to computational cost. Not that it matters much on a modern PC.

Yes, exactly, I was referring to computational cost.

The pseudocode still looks a hell of a lot computationally cheaper than, say, what LAME does for MP3 audio: VAG on PS1/PS2 has a couple more filter options and 28-sample blocks, but otherwise it's the same thing.

Why run the whitening filter once, discard the results, and run it again? The prediction filters in BRR are based on the two previous samples of the decoded data. If you quantize the already whitened data, the errors will compound.

My computer is having trouble running BRRtool. It keeps giving me ERROR: currupted file window.

Who cares if it is long to convert the samples, it's a one-time process in the development of a game. If you develop a game, just convert your .wav once and save them as .brr to include in your source. Even if you have a slow PC, it will probably not be this much of a problem.
Also I removed the unnecessary step to compute the root of the mean (I just compare means, which is equivalent) which should make things faster. You could also disable some of the filters if you want it to be faster - you don't have to leave all 4 enabled.

@psyco : are you using a valid .wav file ?

My computer doesn't know what file type to open with.