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@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@gmail.com:
2015-11-27 9:59 GMT-02:00 katja katjavetter@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list