Re: [PD] bit crusher abstraction

[Matt Barber]

Attached is a file with the three different formulas I gave last time
for two-bit quantization, just for illustration -- any of these could
work as a general bit-crusher with a little extra effort.  Number one
has a variant you can toggle on or off.  Also notice how positive
max-amp is an exception in numbers one and three -- it can be clipped
out though.

Matt

On Thu, Apr 29, 2010 at 9:56 PM, Matt Barber  wrote:
>>> Reduced bit depth (which is what I think 'bit-crushing' means)  can be
>>> achieved by dividing the signal by x, pass it through something like
>>> [int~], multiply it by x again. An [int~] can be implemented by using
>>> [wrap~] and [-~], which are both vanilla.
>>
>> It is also worth considering adding a DC offset. Your [wrap~] solution
>> implements a floor-function, that is, rounding downwards. You can make it
>> round to closest, by adding x/2 before rounding downwards.
>>
>> [expr int($v1)] is rounding zerowards (thus output zero corresponds to a
>> twice bigger input range as any other input). Thus it will behave in a
>> weird unequal way.
>>
>> When the volume gets low, the _effective_ bits-per-sample gets very low,
>> because the relative precision of integers is proportional to amplitude
>> (which is not the case with floats). Therefore, even with 16-bit audio, if
>> your amplitude is 0.0001 times the max, it will feel as if it were 3-bit
>> audio. In such circumstances, the differences between the possible
>> roundings will become quite audible.
>
>
> Bit-depth transitions are really complicated things, especially when
> going from normalized float to int (and among different utitlities
> which do this, e.g. libsndfile or ecasound, I've found several
> different standards).  The biggest problem is what to do with the
> asymmetry about zero with int representations -- there are more
> negative numbers than positive in a two's complement int system.
>
> Here are three formulas I've used for noise-shaping dither in csound
> (the first one is more compatible with the bit-depth transitions that
> occur when csound writes a file).
>
> let X = the input signal and N = target bits:
>
> 1)  Y=(floor([2^(N-1)]*X)+0.5)/[2^(N-1)]
> 2)  Y=floor([2^(N-1)]*X+0.5)/[2^(N-1)]
> 3)  Y=floor([2^(N-1)]*X)/[2^(N-1)]
>
> The only difference is whether the 0.5 is added, and whether it's
> added before or after the floor function.
>
> So let's say you're moving from floats (-1 to +1) to 8-bits:
>
> In the first, one multiplies the signal by 2^7, getting a signal which
> varies from -128 to +128 (floats).  Flooring that will result in ints
> in the same range (+128 after the floor will be a relative rarity in
> real signals, though, so the effective range is -128 to 127).  Adding
> 0.5 to all of that gives a range of -127.5 to 127.5 (with the very
> rarely encountered 128.5).  Then division by 128 gives a signal which
> varies between two values equally spaced from 0, but a constant 0 in
> will result in a DC-offset out (it's a mid-rise function with 256
> possible values).
>
> In the second, one multiplies the signal by 2^7, getting a signal
> which varies from -128 to +128 (floats).  Adding 0.5 to this will
> result in a signal that varies between -127.5 to +128.5, and flooring
> this gives -128 to +128 (ints).  This time, +128 will not be as rare.
> This also is really just a rounding function, with x.5 values rounded
> up.  It's a mid-tread function, so zeros in will result in zeros out.
> At first glance it may seem as though this has one more than 2^8
> values (128 negative values, 128 positive values, and 0 = 257 total
> possible values).  However, if one were to graph the rounding
> function, one would find that anything that started out between -127.5
> and +127.5 will be rounded to -127 to +127 (255 values), while
> anything lower than -127.5 will round to -128, and anything higher
> than 127.5 will round to +128 -- the extremes of the staircase
> function have half-quantization-step mappings, so the total effect is
> still 8-bit.  This one has the advantage that both zero in and maxamp
> (positive or negative) give "correct" output values as well, but the
> disadvantage that one of the quantized steps is divided between the
> top and the bottom of the total range.  Also, its graph is a
> reflection of that of the first function about a diagonal.
>
> In the third, one starts with the same math as the first, up to the
> floor function, which gives an effective range of -128 to 127.  Then
> one simply divides by the original scalar, which just gives the
> mid-tread version of the function from the first formula (the first
> formula minus half the quantization step), with zeros-in-zeros out but
> one extra negative value than positive.
>
>
> Maybe sometime later I could post some pictures for two-bit audio.
> I'm sure there are plenty on the web.  There's also the question of
> whether, even for a bit-crushing effect, one would add dither.
>
>
> Matt
>


bitcrushers.pd
Description: Binary data
__

Re: [PD] bit crusher abstraction

[Matt Barber]

>> Reduced bit depth (which is what I think 'bit-crushing' means)  can be
>> achieved by dividing the signal by x, pass it through something like
>> [int~], multiply it by x again. An [int~] can be implemented by using
>> [wrap~] and [-~], which are both vanilla.
>
> It is also worth considering adding a DC offset. Your [wrap~] solution
> implements a floor-function, that is, rounding downwards. You can make it
> round to closest, by adding x/2 before rounding downwards.
>
> [expr int($v1)] is rounding zerowards (thus output zero corresponds to a
> twice bigger input range as any other input). Thus it will behave in a
> weird unequal way.
>
> When the volume gets low, the _effective_ bits-per-sample gets very low,
> because the relative precision of integers is proportional to amplitude
> (which is not the case with floats). Therefore, even with 16-bit audio, if
> your amplitude is 0.0001 times the max, it will feel as if it were 3-bit
> audio. In such circumstances, the differences between the possible
> roundings will become quite audible.


Bit-depth transitions are really complicated things, especially when
going from normalized float to int (and among different utitlities
which do this, e.g. libsndfile or ecasound, I've found several
different standards).  The biggest problem is what to do with the
asymmetry about zero with int representations -- there are more
negative numbers than positive in a two's complement int system.

Here are three formulas I've used for noise-shaping dither in csound
(the first one is more compatible with the bit-depth transitions that
occur when csound writes a file).

let X = the input signal and N = target bits:

1)  Y=(floor([2^(N-1)]*X)+0.5)/[2^(N-1)]
2)  Y=floor([2^(N-1)]*X+0.5)/[2^(N-1)]
3)  Y=floor([2^(N-1)]*X)/[2^(N-1)]

The only difference is whether the 0.5 is added, and whether it's
added before or after the floor function.

So let's say you're moving from floats (-1 to +1) to 8-bits:

In the first, one multiplies the signal by 2^7, getting a signal which
varies from -128 to +128 (floats).  Flooring that will result in ints
in the same range (+128 after the floor will be a relative rarity in
real signals, though, so the effective range is -128 to 127).  Adding
0.5 to all of that gives a range of -127.5 to 127.5 (with the very
rarely encountered 128.5).  Then division by 128 gives a signal which
varies between two values equally spaced from 0, but a constant 0 in
will result in a DC-offset out (it's a mid-rise function with 256
possible values).

In the second, one multiplies the signal by 2^7, getting a signal
which varies from -128 to +128 (floats).  Adding 0.5 to this will
result in a signal that varies between -127.5 to +128.5, and flooring
this gives -128 to +128 (ints).  This time, +128 will not be as rare.
This also is really just a rounding function, with x.5 values rounded
up.  It's a mid-tread function, so zeros in will result in zeros out.
At first glance it may seem as though this has one more than 2^8
values (128 negative values, 128 positive values, and 0 = 257 total
possible values).  However, if one were to graph the rounding
function, one would find that anything that started out between -127.5
and +127.5 will be rounded to -127 to +127 (255 values), while
anything lower than -127.5 will round to -128, and anything higher
than 127.5 will round to +128 -- the extremes of the staircase
function have half-quantization-step mappings, so the total effect is
still 8-bit.  This one has the advantage that both zero in and maxamp
(positive or negative) give "correct" output values as well, but the
disadvantage that one of the quantized steps is divided between the
top and the bottom of the total range.  Also, its graph is a
reflection of that of the first function about a diagonal.

In the third, one starts with the same math as the first, up to the
floor function, which gives an effective range of -128 to 127.  Then
one simply divides by the original scalar, which just gives the
mid-tread version of the function from the first formula (the first
formula minus half the quantization step), with zeros-in-zeros out but
one extra negative value than positive.


Maybe sometime later I could post some pictures for two-bit audio.
I'm sure there are plenty on the web.  There's also the question of
whether, even for a bit-crushing effect, one would add dither.


Matt

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[Mathieu Bouchard]

On Thu, 29 Apr 2010, Roman Haefeli wrote:

Reduced bit depth (which is what I think 'bit-crushing' means)  can be 
achieved by dividing the signal by x, pass it through something like 
[int~], multiply it by x again. An [int~] can be implemented by using 
[wrap~] and [-~], which are both vanilla.


It is also worth considering adding a DC offset. Your [wrap~] solution 
implements a floor-function, that is, rounding downwards. You can make it 
round to closest, by adding x/2 before rounding downwards.


[expr int($v1)] is rounding zerowards (thus output zero corresponds to a 
twice bigger input range as any other input). Thus it will behave in a 
weird unequal way.


When the volume gets low, the _effective_ bits-per-sample gets very low, 
because the relative precision of integers is proportional to amplitude 
(which is not the case with floats). Therefore, even with 16-bit audio, if 
your amplitude is 0.0001 times the max, it will feel as if it were 3-bit 
audio. In such circumstances, the differences between the possible 
roundings will become quite audible.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[Roman Haefeli]

On Thu, 2010-04-29 at 16:47 +0200, Roman Haefeli wrote:
> On Thu, 2010-04-29 at 16:15 +0200, tim vets wrote:
> > there's a very simple way do do 'sample rate reduction' (which is i
> > think the sound you're looking for)
> > [readsf~]
> > |[phasor~ 100]
> > |/ 
> > [samphold~]
> > |
> > instant lo-fi gratification :)
> 
> This is a crude way to reduce sample rate, but not quite so to reduce
> bit depth.
> 
> I say crude, because if the frequency of the phasor~ is not a dividable
> whole number of the sampling rate, it will additionally add some jitter
> (which even enhances the lofi effect).
> 
> Reduced bit depth (which is what I think 'bit-crushing' means)  can be
> achieved by dividing the signal by x, pass it through something like
> [int~], multiply it by x again. An [int~] can be implemented by using
> [wrap~] and [-~], which are both vanilla.

As mentioned in Martin Brinkmann's previous mail and assuming x is a
number greater than 1, it would make more sense to multiply first and
divide after.

Roman 



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[Dan Wilcox]

Try these:

rc-bitcrusher~-help.pd
Description: Binary data


rc-bitcrusher~.pd
Description: Binary data


rc-aliaser~_-help.pd
Description: Binary data


rc-aliaser~_.pd
Description: Binary data
rc-bitcrusher is a modified s-bitcrusher from s-abstractions and rc-alisaser~ is from an example posted to the list awhile ago.On Apr 29, 2010, at 2:54 PM, David Schaffer wrote:Hi everybody,    I'd like to know if there's a bit crusher/ lo-fi/ sonic destructor abs. somewhere out there. I'd like to take a look inside to see how it works, just out of curiosity.Thanks D.Shttp://www.flickr.com/photos/schafferdavid/http://audioblog.arteradio.com/David_Schaffer/Hotmail: Free, trusted and rich email service. Get it now.
Dan Wilcoxdanomatika.comrobotcowboy.com

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[Roman Haefeli]

On Thu, 2010-04-29 at 16:15 +0200, tim vets wrote:
> there's a very simple way do do 'sample rate reduction' (which is i
> think the sound you're looking for)
> [readsf~]
> |[phasor~ 100]
> |/ 
> [samphold~]
> |
> instant lo-fi gratification :)

This is a crude way to reduce sample rate, but not quite so to reduce
bit depth.

I say crude, because if the frequency of the phasor~ is not a dividable
whole number of the sampling rate, it will additionally add some jitter
(which even enhances the lofi effect).

Reduced bit depth (which is what I think 'bit-crushing' means)  can be
achieved by dividing the signal by x, pass it through something like
[int~], multiply it by x again. An [int~] can be implemented by using
[wrap~] and [-~], which are both vanilla.

Roman


 
>  
> 2010/4/29 Pierre Massat 
> Same here! Only i want to use it, too. 
> 
> Pierre
> 
> 2010/4/29 David Schaffer 
> 
> Hi everybody, 
> 
>I'd like to know if there's a bit crusher/
> lo-fi/ sonic destructor abs. somewhere out there. I'd
> like to take a look inside to see how it works, just
> out of curiosity.
> 
> Thanks 
> 
> D.S
> 
> http://www.flickr.com/photos/schafferdavid/
> 
> http://audioblog.arteradio.com/David_Schaffer/
> 
> 
> 
> 
> 
> 
> __
> Hotmail: Free, trusted and rich email service. Get it
> now.
> 
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[martin brinkmann]

David Schaffer wrote:
>I'd like to know if there's a bit crusher/ lo-fi/ sonic destructor abs.

a bit-reduction effect is quite easy to build:
multiply the signal by a (larger) number,
throw away the fractional part (by using expr~ int($v1), or building
something with wrap~)
and divide the signal by the same number.
the higher the number, the 'smoother' (less crushed) the result.
for 'authentic bit-reduction' you can use powers of 2,
but numbers inbetween are also fine (imho often better sounding).
there is something like that in my 'instrument collection'
(quantizer.pd) http://www.martin-brinkmann.de/mnb_instruments_wip.zip

bis denn!
martin

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[tim vets]

there's a very simple way do do 'sample rate reduction' (which is i think
the sound you're looking for)
[readsf~]
|[phasor~ 100]
|/
[samphold~]
|
instant lo-fi gratification :)
gr,
Tim


2010/4/29 Pierre Massat 

> Same here! Only i want to use it, too.
>
> Pierre
>
> 2010/4/29 David Schaffer 
>
>>   Hi everybody,
>>
>>I'd like to know if there's a bit crusher/ lo-fi/ sonic destructor
>> abs. somewhere out there. I'd like to take a look inside to see how it
>> works, just out of curiosity.
>>
>> Thanks
>>
>> D.S
>>
>>  http://www.flickr.com/photos/schafferdavid/
>>
>> http://audioblog.arteradio.com/David_Schaffer/
>>
>>
>>
>> --
>> Hotmail: Free, trusted and rich email service. Get it 
>> now.
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[Frank Barknecht]

Hi,

On Thu, Apr 29, 2010 at 02:54:18PM +0200, David Schaffer wrote:
> I'd like to know if there's a bit crusher/ lo-fi/ sonic destructor abs.
> somewhere out there. I'd like to take a look inside to see how it works, just
> out of curiosity.

The rj library has some, check out the "Effects" section in the OVERVIEW.pd
from here: http://osc.rjdj.me/~fbar/rj-100423.tgz There's e_bitchrusher,
e_alias and a nice exotic one: e_apdist.

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] bit crusher abstraction

[Pierre Massat]

Same here! Only i want to use it, too.

Pierre

2010/4/29 David Schaffer 

>  Hi everybody,
>
>I'd like to know if there's a bit crusher/ lo-fi/ sonic destructor
> abs. somewhere out there. I'd like to take a look inside to see how it
> works, just out of curiosity.
>
> Thanks
>
> D.S
>
> http://www.flickr.com/photos/schafferdavid/
>
> http://audioblog.arteradio.com/David_Schaffer/
>
>
>
> --
> Hotmail: Free, trusted and rich email service. Get it 
> now.
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] bit crusher abstraction

[David Schaffer]

Hi everybody, 

   I'd like to know if there's a bit crusher/ lo-fi/ sonic destructor abs. 
somewhere out there. I'd like to take a look inside to see how it works, just 
out of curiosity.

Thanks 

D.S


http://www.flickr.com/photos/schafferdavid/
http://audioblog.arteradio.com/David_Schaffer/

  
_
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list