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”.
Bits per sample: The number of bits per sample. Lower is more “crunchy” / “noisy”.
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.
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 )
If you want to try that, change the last line from:
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).
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.
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.
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).
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:
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
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.
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:
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)
)
