unsigned integers

[exonerate]

I've come across a situation where I need unsigned integers.

I'm making a basic bit reducer and wanted to reduce the bits by setting bits to zero.

For instance I would like to do this...

Code: Select all

streamin in;
streamout out;

unsigned int bits8=4278190080;
movaps xmm0,in;
andps xmm0,bits8;
movaps out,xmm0;

To reduce the audio to 8 bits. But because we only have unsigned integers this isn't possible.

Of course I'm just going to end up doing it the normal way, but this method would be much faster, and well, I like it.

Cheers

Exo

[MegaHurtz]

cvtps2dq and cvtdq2ps are way too heavy.
This would be a nice feat.. Strange all the lighter rounding (wo truncation) is beyond our reach.

[exonerate]

Actually forget it I don't need unsigned integers at all I'm just being dumb.

Cheers

Exo

[exonerate]

ok so I figured out this should work but it doesn't...

Code: Select all

streamin in;
streamout out;

int bits8=-2130706432;

movaps xmm0,bits8;
andps xmm0,in;
movaps out,xmm0;

So I guess I've over looked something, that int in binary is 11111111000000000000000000000000.

So I assumed that anding a float with that value would set all the bits after the 8th bit to zero.

Cheers

Exo

[trogluddite]

The representation of floats is a bit hard to explain, but if I remember right the 32 bits of a float are...

SYYYYYYYXXXXXXXXXXXXXXXXXXXXXXXX - S=sign, YYYYYYY=exponent (representing -63 to 64) , XXX...=mantissa

where the number represented would be

S(sign + or -) * XXXXXXXXXXXXXXXXXXXXXXXX * (2 ^ YYYYYYY) ...or... Sign * Mantissa * (2 ^ Exponent).

So your example is leaving the exponent (YYYYYYY) in place, multiplied by only the first bit of the mantissa, I think.
Hope someone can show how to make this work - I've tried myself a couple times, but it quickly defeated my maths ability! - the other methods can be real CPU hogs.

[exonerate]

The representation of floats is a bit hard to explain, but if I remember right the 32 bits of a float are...

SYYYYYYYXXXXXXXXXXXXXXXXXXXXXXXX - S=sign, YYYYYYY=exponent (representing -63 to 64) , XXX...=mantissa

where the number represented would be

S(sign + or -) * XXXXXXXXXXXXXXXXXXXXXXXX * (2 ^ YYYYYYY) ...or... Sign * Mantissa * (2 ^ Exponent).

So your example is leaving the exponent (YYYYYYY) in place, multiplied by only the first bit of the mantissa, I think.
Hope someone can show how to make this work - I've tried myself a couple times, but it quickly defeated my maths ability! - the other methods can be real CPU hogs.

Yeah thanks for that, my maths isn't so hot either. I know it's possible though there are a couple of plugins I know that do this. Guess I need to understand the representation of floats a bit better.

Cheers

Exo

[Disco_Steve]

the dither module has a bit crusher in it. is that not fast enough?

[trogluddite]

The dither module uses the same technique that I've used myself before - the divide gets exteremely expensive on CPU. The project I wanted it for had several hundred lines of code running at sample rate - yet that one divide nearly doubled the CPU load! Never really got to the bottom of why that was - there are several other divides in the code, so it must depend on the range of the operands.

[MichaelBenjamin]

maybe you got some denormals.

[Disco_Steve]

why dont you do all the maths using the large numbers, and then do one divide at the end. that should be fast enough.

[MegaHurtz]

Srry but I think that dither is for dummies.
Dont know about the rounding though.. Was going to upp an attachment
but cant do that here.. sow.. If you pm me your email I might have a suggestion you like.
cheerio`s

[trogluddite]

why dont you do all the maths using the large numbers, and then do one divide at the end. that should be fast enough

That was my thinking too, to keep the numbers big for as long as possible - but it really made very little difference. Tried some of the usual anti-denormal techniques too with very little success.

Srry but I think that dither is for dummies.

Yup, it is rather crude - I'll stick with my old uv22 plugin for now I think.

[trogluddite]

BTW the equations for the floating point representation that I gave aren't quite right. This thread got me thinking about the bitcrusher again after a long break, so I went back and checked my previous work. This Wiki article gives the correct IEE standards for 32bit floats...
http://en.wikipedia.org/wiki/IEEE_754-1985

P.S. Have a look at DigitalWhiteByte's binary-to-decimal and decimal-to-binary conversion modules, just posted in the developer's toolkit. I'm just doing some tests, but I think that if you feed the decimal to binary with an assemby module with the code...
streamin in;
streamout out;
movaps xmm0,in;
cvtdq2ps xmm0,xmm0; //pretend that the input was really an integer (cheating) and turn to float
movaps out xmm0;
...You should be able to peek at the actual layout of the bits in whatever float you feed to the code.

EDIT - posted the schematic on the developer's toolkit thread - still needs some experts to check that it is 100% correct.

[Disco_Steve]

I think you will find the dither works, and works well!
and you can use it in your code. so your plug-ins sound nice.
but a plug-in afterwards will not work, because the quantisation has happened and it is already too late.

if you can make a better dither. one that does more than work (however that is possible)
please upload so that I can use it in my projects

[trogluddite]

I think you will find the dither works, and works well!

Sorry Disco, no offence meant - 'crude' wasn't the best choice of words - more that the assembly can be optimised quite a bit still. e.g. the rounding can use the cvtps2dq and cvtdq2ps commands instead of all the one channel floating point maths that the code expands to - it really does save a lot of CPU cycles. It's also quite possible I wasn't even looking at the most up to date version.
I'd be interested to know more about your thoughts on dithering within a plugin - I was always taught that dithering was somethihg that should only be done once (final output of a signal chain), so that dithering multiple times could not occur (which would bring the noise level above the last bit of resolution). AFAIK, most hosts keep all their maths in the floating point domain, so I would have expected dithering to not be an issue until D/A conversion - hence using my uv22 as the last process before the soundcard outputs.
As for using bitrate reduction as an effect - I personally don't want it to sound nice, I want to use it deliberately as a form of distortion (I'm one of those oddballs that quite likes a bit of aliasing too!)