nesdev.comhttp://forums.nesdev.com/ What filters does Blargg's Blip_Buffer use?http://forums.nesdev.com/viewtopic.php?f=3&t=16709 Page 1 of 1

 Author: zeroone [ Wed Nov 15, 2017 11:11 am ] Post subject: What filters does Blargg's Blip_Buffer use? 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.

 Author: tepples [ Wed Nov 15, 2017 11:40 am ] Post subject: Re: What filters does Blargg's Blip_Buffer use? 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?

 Author: zeroone [ Wed Nov 15, 2017 12:11 pm ] Post subject: Re: What filters does Blargg's Blip_Buffer use? Thanks for the long response. What order FIR is used?

 Author: tepples [ Wed Nov 15, 2017 12:23 pm ] Post subject: Re: What filters does Blargg's Blip_Buffer use? 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.

 Author: zeroone [ Wed Nov 15, 2017 12:53 pm ] Post subject: Re: What filters does Blargg's Blip_Buffer use? 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?

 Author: lidnariq [ Wed Nov 15, 2017 3:09 pm ] Post subject: Re: What filters does Blargg's Blip_Buffer use? 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.

 Author: zeroone [ Wed Nov 15, 2017 3:26 pm ] Post subject: Re: What filters does Blargg's Blip_Buffer use? lidnariq wrote: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.

 Author: lidnariq [ Wed Nov 15, 2017 3:43 pm ] Post subject: Re: What filters does Blargg's Blip_Buffer use? 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.

 Author: Rahsennor [ Wed Nov 15, 2017 8:35 pm ] Post subject: Re: What filters does Blargg's Blip_Buffer use? 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.

 Author: zeroone [ Thu Nov 16, 2017 7:57 am ] Post subject: Re: What filters does Blargg's Blip_Buffer use? 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.

Author:  tepples [ Thu Nov 16, 2017 8:20 am ]
Post subject:  Re: What filters does Blargg's Blip_Buffer use?

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.