nesdev.com

Blargg's Blip_Buffer performs band-pass filtering and decimation. What specific filter (or filters) are used?

The source is available, but it's just a bunch of equations with little explanation of the mechanics behind it. And, formulae for many filters look very similar to each other.

A BLEP (band-limited step) is a Heaviside step convolved with a low-pass filter. It's generated at the input frequency and then decimated to the output frequency at offsets from zero to the frequency ratio minus one.

If the Gibbs wiggles are the same on both side of the step, the low-pass filter is a linear-phase finite impulse response (FIR) filter. These are usually some windowed sinc function, such as the Lanczos filter. Convolution of an FIR kernel or any other discrete signal with a Heaviside step is the same as taking a running sum.

Choice of sinc cutoff and window shape varies from one BLEP implementation to another, though the sinc frequency is usually about 45% of the sample rate, which provides some headroom below the Nyquist frequency (half the sample rate) to compensate for finite window width. Or were you seeking to identify the exact parameters of the window in Blargg's implementation?

Thanks for the long response. What order FIR is used?

Blargg's library appears to make the low-pass filter as wide as 8, 12, or 16 output samples depending on the chosen resampling quality. If you are making your own BLEP, you can vary the order based on how sharp you want the cutoff to be.

For my NES emulator, I used a 13th-order Elliptic filter. I'm considering working on a Game Boy emulator, but it produces sound samples at a faster rate: ~2.34x the NTSC NES and it has stereo sound. Consequentially, my elliptic filter implementation will eat up ~4.7x the CPU, possibly making it impractical to use.

My filtering knowledge is limited. How bad would it be if I averaged together every 5 samples and then fed it into an elliptic filter?

DSP wise, "averaged together every 5 samples" is equivalent to:
* Convolve with 5-sample long "boxcar" filter i.e. [1 1 1 1 1]
* Decimation by 5. (i.e. retaining one, then discarding the next four)

This, in turn, is roughly the same as a 1st order lowpass at 1/5th the sample rate, and then some alias folding. There are also some very specific frequency bands that it will attenuate perfectly. Would the frequency content line up such that the aliases won't end up in the audible band? That's basically the context under which it would work well.

You will probably get better results from multiple rounds of resampling. Also, polyphase FIR filters might be worth trying.

Well, I guess I'm looking for a balance between computational time and quality. I can always use Blargg's filter if that really is the best option. It's difficult to evaluate without knowing all the details.

Sure? Boxcar filters are almost always the worst option¹, unless all of the nulls just happen to line up usefully, such as bisqwit's NTSC decoder.

¹ (Carefully carved out exception: the 2-sample FIR filter [1 1] has perfect rejection of the nyquist rate)

Filtering is always a calculus of "how much undesired signal is allowed to stick around" (-40dB is ≈8-bit sound quality), and when you decimate, you fold this correlated high-frequency content over the signal you want to keep, producing aliasing noise.

But each time you decimate, you also get to reduce your computational load for successive stages.

Blargg's bit_blep is very likely the mostly computationally effective solution.

The vast majority of the computational load difference between FCEU-0.98 and modern FCEUX is the latter spends lots of time in its audio filtering, so you do have company here.

If your signal is entirely pulse waves/sample-and-hold signals, BLEP resampling is almost certain to be the best speed/quality tradeoff. It only has to do work on transitions, so the input samplerate is irrelevant - performance depends entirely on the switching rate of the signal.

Which can do more harm than good when some idiot decides to mute the triangle channel by making it ultrasonic, but that's another story.

Does anyone have a Bode Plot of Blargg's Blip_Buffer decimating from NES NTSC APU rate to 48 KHz? I'm curious how it compares to the Elliptic Filter. I can always rig up the Elliptic Filter with a lower order to make it compute faster.

Suggested test procedure:

1. Make a module in FamiTracker with only the note D-# (corresponding to period setting 1, or 112 kHz) in the noise channel. This gives enough headroom over the Nyquist rate that it should be flat before the rolloff associated with the zero-order hold.
2. Export to NSF.
3. Render to 16-bit LPCM (WAV, etc.) with an NSF player based on Game_Music_Emu, which uses Blip_Buffer. I used gmewav, which has the drawback that it's currently hardcoded to 44.1 kHz, not 48 kHz.
4. Run spectral analysis using your preferred tool.

I've done steps 1, 2, and 3 for you. When attempting to upload the result of step 3, I received the following error messages:

The extension wav is not allowed.
The extension flac is not allowed.
The extension aif is not allowed.
The extension aiff is not allowed.

Presumably this is to encourage users discussing NES music to use lossy codecs such as .ogg for storage and bandwidth efficiency. That's fine for music, not so fine for the precise spectral analysis that you are requesting. This means you will need to extract the result of step 3 from a zipfile before proceeding to step 4.

Thanks tepples. When I get a chance, I'll open that in Audacity. I think it can generate something similar to a Bode Plot.

I wish I could plug Blargg's filter directly into my own toolset, but unfortunately, I'm a Java coder. If I end up translating his code, I might strip out the low-pass filter part if that provides an extra speed boost. On a side note, the Game Boy supposedly contains some low-pass filtering to prevent interference noise from being rendered as speckles on the LCD matrix. But, there were suggestions on various forums to not emulate that to improve the sound quality.

Side note #2: Since my filtering knowledge is limited, I wrote a program that simply generates sine waves and it records how they get attenuated or amplified by a filter. It slowly tries all possible frequencies within some range. There is probably a much better way to generate Bode Plots, but taking direct measurements at least checks against possible coding bugs and it also enables me to see how fast the filter reacts to a signal.

I tried making a pink noise and sine sweep generator a few months ago, but the sine sweep ended up extremely aliased, and I couldn't tell why.

There's another test for "how fast the filter reacts to a signal". The procedure resembles the above, except instead of FamiTracker's noise channel, use Z00 and Z7F effects in the DPCM channel to generate Heaviside steps. Then render as before and read the step response off the wave.