Bit Crusher effect

A bitcrusher effect (Bitcrusher - Wikipedia)
Low numbers of bits are only really suitable for simple (monophonic) sounds and tend to just sound like a mess with complex sounds.
Higher settings work well for making more complex sounds sound “low-fi”.

  1. Bits per sample: The number of bits per sample. Lower is more “crunchy” / “noisy”.
  2. Sample Rate: The effective sample rate. Lower reduces the frequency range (bandwidth).

Tip: The effect may slightly boost the level, so leave a bit of headroom before use or amplify / normalize back below 0 dB after processing.
Update: The latest version includes an output level control, so no need to leave headroom before processing - better to use the full track height range and adjust the output level as necessary.


Original version:
BitCrusher.ny (993 Bytes)
Latest version: BitCrusher.ny

“BitCrusher,ny” is working for me, (but I’m still on Audcaity 2.3.2).

Thanks Trebor.
I used Nyquist’s resampling rather than a sinc filter as sinc filters are extremely slow prior to the latest big Nyquist update.

As you are using a version of Nyquist that predates the last big update, could you check that you get the expected number of “steps” for the selected “bits per sample”. For example, if set to 4 bits per sample, and the sample rate is set to maximum, you should see 16 distinct steps over full-scale.

Resampling occurs after bit reduction, so the “steps” are bandwidth limited. At lower sample rates you should see that the steps are smoothed.
Do you think it’s worth adding an option to resample before reducing the bits per sample? (Doing so mostly sounds horrible :smiley:)
If you want to try that, change the last line from:

(qrate (abs-quantize *track* bits) rate)

to:

(abs-quantize (qrate *track* rate) bits)

Yes: 16 treads when set to 4 bits per sample …

I think bitcrush users want the artefacts from quantization and/or decimation.
(perhaps with the option of a wet/dry slider to dilute the effect with the original audio).

How about this:

BitCrusher.png
Parameters:

  • Bits per sample: [1 to 16 - default 8] Number of bits per sample.
  • Sample Rate: [1 to 40 kHz - default 8 kHz] Effective sample rate.
  • Process order: [choice: Crush->Resample, Resample->Crush, Crush Only, Resample Only - default “Crush->Resample”]
    “Crush->Resample” means, reduce the bits per sample first (bitcrush) , then resample.
  • Mix: [0 to 100 % - default 100%] Dry / Wet mix. 100% = wet (effect only). 0% = dry (unprocessed sound only)

I’ve also fixed the scaling / offset so that the steps fit in the range +/- 1 and zero (silence) remains at zero. To do this, there has to be an odd number of steps, so the number of steps is now: (2^bits) - 1
1-bit has to be handled slightly differently because having only one level would be silence. Thus 1 bit is rendered as +1 for positive input samples, and 0 for sample <= 0.

8-bits: 255 levels
4-bit: 15 levels
3-bit: 7 levels
2-bit: 3 levels
1-bit: 2 levels (0 or 1)

The plug-in:
BitCrusher.ny (1.74 KB)

For low bits per sample it makes sense for the input audio to be normalized to 0 dB so as to get the full bit-range, but then the preview will clip. So I’m wondering if it would be best to add an output level control (default to say 0.9).

What do you think?

Working as advertised.

I would end up using a (hard) limiter on it anyway, so sounded as loud as the original …

But it seems logical to give users no-clipping as the default.

With an output level control:
BitCrusher-screenshot.png
And the plug-in:
BitCrusher.ny (1.83 KB)

Having just tried 1-bit-depth for the first time, now I see what you mean: everything becomes really loud …

:smiley: Yes. By definition, it’s either full on, or full off.

Hello.
This is this effect, which I want to use for lo-fi recordings effect.
Big thanks for this effect.

You’re welcome Giovani. Thanks for the feedback.

Hmm the sample rate reducer doesn’t seem to be upscaling correctly, it seems like it’s doing the vanilla audacity resample? Rather than the usual “nearest” like resample that bitcrushers are known for. I tried all the process order modes.
Here’s an example:
image_2022-01-05_053439.png
I was hoping to use this to give my projects that DSi Flipnote/XP Movie Maker bitcrush style, since the script I normally use doesn’t work on the latest audacity since it uses the older version 3 syntax
https://github.com/Kippykip/Kippykip-2009/blob/master/audacity_bitcrush.ny.txt

What precisely does “upscaling” mean in this context?


It’s doing vanilla Nyquist resampling :wink:

Do you have a technical description / specification for that?

I don’t really have a specification document or anything, but from what I understand, if I was to resample something down to like 11025hz, then resample/playback it at 44100 it shouldn’t smooth out the points (like the native audacity resampling does) but instead just have repeated points.


This is usually how retro consoles handled audio, such as music playback on a Gameboy Advance.
I’ve attached some examples:


Windows XP usually played back audio in this way, in either sound recorder when resampling or straight up dragging some low hz songs in Movie Maker. A lot of early YouTube videos in the late 2000s sounded like this as a result.
Flipnote Studio DSi is another example I can think of that resamples audio this way.

Hmm. Looks like you want “Resample->Crush” rather than “Crush->Resample”.

I’ve already tried that and all the other process order settings, but I’m not getting the same output as the older Nyquist 3 bitcrush script I linked.
It still seems to resample it as if it was just a normal vanilla audacity resampling instead of the “nearest neighbour” like effect.
I’ve attached how it’s rendering in this plugin here:

Where can I find that script?

I don’t remember which thread in this forum it was taken from, but I always had a mirror here:
https://github.com/Kippykip/Kippykip-2009/blob/master/audacity_bitcrush.ny.txt

It was a VERY basic one that ran in the nyquist prompt directly.
You change this line to the source hz, such as 11025hz or something.

(setq sourcerate 4000) ; Source samplerate

This new bitcrush script in this thread, does seem to crush the vertical movement correctly (such as 8bit, 16bit etc) but it isn’t crushing the horizontal movement correctly.
The old bitcrush script only edited horizontal (essentially just a sample rate upscale algorithm if anything)

Interesting. That looks like my code :slight_smile: