[PD] 64 bit audio?

[Matt Barber]

​You probably don't want Pd dithering behind the scenes without you knowing
it. There are a couple of things to consider, though:

Dithering for 24-bit output isn't generally necessary, since most audio
devices don't have true 24-bit ADC/DAC, and even with perfect equipment the
noise floor is lower than the threshold of hearing given a reasonable
maxamp level.

Dithering for a 16-bit audio device might be worth while, but most of these
devices I've ever worked with already have more than enough analog
component noise not to worry so much about truncation error.

Dithering for output to a 16-bit sound file for playback on a device with
more precision is probably worth it, but you want to be able to control the
kind of dither you're using, whether or not you're going to employ any
noise shaping, etc. That's all stuff you can do in Pd if you want, but
there are probably better (and easier!) options.​

On Fri, Nov 27, 2015 at 4:00 PM, Alexandre Torres Porres <porres at gmail.com>
wrote:

> What about "dithering" or whatever... when Pd sends a 32 bit (or even 64
> bit) how is it handled and reduced to 16 bits or 24 bits according to the
> soundcard?
>
> Is it up to Pd or not? One case or another, how is it done?
>
> thanks
>
> 2015-11-27 14:19 GMT-02:00 Alexandre Torres Porres <porres at gmail.com>:
>
>>
>>
>> 2015-11-27 9:59 GMT-02:00 katja <katjavetter at gmail.com>:
>>
>>> This topic keeps popping up on Pd list with stable frequency.
>>
>>
>> And I'd say I'm guilty for a few of those
>>
>>
>>> the price seemed to be acceptable at the time of writing (2011).
>>
>>
>> I'm aware of the writing for a few years now, and I was actually
>> wondering/asking if by now, 2015/2016 if this move ahead was being
>> considered.
>>
>> By the way, I learned this days that Max did make this move a while ago
>> in Max 6 (that's about 2011, btw), which was quite surprising for me.
>>
>>
>> That was before the advent of pico computers like Raspberry Pi
>>
>>
>> Exactly, I had that in mind too, but one way or another, I was thinking
>> of a move to 64 bits as an extra (and supported/distributed) feature, but
>> still keeping the 32 for legacy reasons and the usage in pico computers.
>>
>>
>>> Also I realized only later that making _all_
>>> external libs double-precision-aware is mission impossible.
>>>
>>
>> well, there's a curious and relevant fact, I wonder why, but I'll just
>> believe it.
>>
>>
>>> double precision build is mainly valuable for evaluation. It helps
>>> finding out how important precision is for some routine, and may even
>>> provide insights which help to fix some precision issue within the
>>> constraints of single precision Pd.
>>
>>
>> Cool, I was really curious in knowing more about all this, so I was
>> researching again. Specially after learning that max has been 64 bits for a
>> while, it seemed nice to evaluate what it has that Pd and SC don't.
>>
>> Here's the only video I found about it anyway...
>>
>> https://www.youtube.com/watch?v=QTZlWaIVjTg
>>
>> It just shows about reading long buffers, that's it, and we know that...
>>
>> Seems like feedback loops in filters is something to note as relevant in
>> 64 bit precision from what I was reading, and also from the answer I got in
>> the SC list, which they seem to deal with internally anyway.
>>
>> Sorry for insisting, but then, is that really only it?
>>
>> Since the long buffer issues have a workaround with the onset inlet in
>> [tabread4~], that's something I'd let go. And seems like 64 bit is just too
>> much hassle for audio processing and quality. The only issue still worth
>> noting seems to be the quality in filters, but, what I understand here is
>> that you couldn't "work that out internally" in Pd like they're saying
>> they're doing in SC, right?
>>
>> cheers
>>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151201/85b2e8c6/attachment.html>