[PD] audio bit resolution in Pd

Alexandre Torres Porres porres at gmail.com
Thu Apr 23 21:28:41 CEST 2015


According to Wikipedia

"as of 2007 digital audio converter technology is limited to a SNR of about
124 dB (21-bit) because of real-world limitations in integrated circuit
design. Still, this approximately matches the performance of the human
auditory system"

http://en.wikipedia.org/wiki/Audio_bit_depth#Floating_point

So, yeah, apparently there's no circuitry technology to go anywhere near 32
bit, so a 32 bit DAC seems weird and pointless...

I guess a good way to approach this issue I raised is to be able to define
what is the internal dynamic range in Pd for values between -1 and 1.

cheers

2015-04-23 15:02 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> WOW... I just learned something important! So, my whole point here was
> that I had the idea that DAWs like Ardour support 32-bit considering only
> values from -1 to 1. But that is just wrong!
>
> I just learned you can put a sound file with values in the hundreds /
> thousands in 32 bit float, load them into your DAW, and scale it down.
>
> I tried it by creating a sine wave in Pd with values from -100 to 100,
> exported as 32-bit float with writesf~, loaded into soundforge, then scaled
> it down 40 dB, and the sine wave was there!
>
> So yeah, Pd's audio resolution is the same as DAW which say they handle
> 32-bit float sound files. My whole issue was that Pd had a different way of
> dealing with 32-bit float, but not at all. In Principle, other softwares
> out there also deal with 32-bit float outside the boundaries of -1 to 1!!!
>
> That just answers my question then... once and for all and for good.
>
> I guess the discussion I ended up promoting is a parallel issue... let me
> rephrase it then.
>
> Regarding 24 bit DAC converters in sound cards, the 24 bits in there are
> just for values from -1 to 1, right?
>
> If so, then 32 bit float isn't really "8 more bits". And you've been also
> saying 24 bit converters are fixed, not float. So there's a weird
> relationship between this conversion from 32 bit float files to the
> soundcard.
>
> But then, I guess I'm happy with all I've learned so far.
>
> thanks
>
> 2015-04-23 13:26 GMT-03:00 Jamie Bullock <jamie at jamiebullock.com>:
>
>
>> On 22 April 2015 at 19:44:26, William Huston (williamahuston at gmail.com)
>> wrote:
>>
>> On Wednesday, April 22, 2015, Jamie Bullock <jamie at jamiebullock.com>
>> wrote:
>> >
>> > Pd is 32-bit *floating point*, so you have 32-bit resolution between -1
>> and 1.
>>
>> I don't think that's right.
>>
>> The range of a single precision floating point number is from
>>
>> -3.4028234 × 10E38 to 3.4028234 × 10E38 (not from -1 to 1)
>>
>>
>> True, but I didn’t say the range of 32-bit float was -1 to 1!
>>
>> There are only 23 bits of precision for the mantissa + 1 for sign in a
>> single precision float.
>>
>>
>> Also true, but when I said “resolution” I didn’t mean “precision”.
>> Because the exponent can be negative, resolution scales dynamically from
>> 1..0 according to the value of the exponent, whilst precision stays fixed
>> according to the number of bits in the mantissa. Thus for very small values
>> the resolution (or quantisation step size) is far finer than can be
>> represented with the mantissa alone.
>>
>> What I was trying to put across (poorly!) in my original reply is that
>> unlike fixed point where for lower order values fewer bits are available in
>> the binary representation, with floating point, just because e.g. -1..1 is
>> a smaller range than -3.4 x 10E38..3.4 x 10E38 it doesn’t imply “fewer are
>> bits available”, e.g.
>>
>> Sign Exponent Mantissa
>> 0 01111110   11111111111111111111111 -> 0.99999994
>> 0 00000001 11111111111111111111111 -> 2.3509886E-38
>> 1 01000000        0000000000000000000000 -> -1.0842022E-19
>> 1              011111110        0000000000000000000000 -> -1.0
>>
>> Strictly speaking, I guess only 31 bits “count” in the range -1..1 due to
>> a maximum of 7-bits being significant in the exponent.
>>
>> best,
>>
>> Jamie
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150423/67358903/attachment.html>


More information about the Pd-list mailing list