[PD] headroom in Pd
cgclepper at gmail.com
Wed Jan 1 20:50:23 CET 2014
On Wed, Jan 1, 2014 at 2:03 PM, Martin Peach <martin.peach at sympatico.ca>wrote:
> I can see how a filter circuit following a DAC can swing more than the DAC
> for example if two successive samples are full-scale, but there's no way a
> DAC can output beyond its own full scale except momentarily while it's
> settling to a value inside its range.
> The scaling has to be done before the DAC.
> You just can't reconstruct a clipped signal unless the clipping is very
> mild or the signal is very simple, like a sine wave. What if the signal is
> +12dBFS white noise?
The DAC can't really discriminate based on the aural complexity of a
signal. A peak with N successive clipped samples has a reconstructed value
above full scale and the DAC will attempt to produce that signal. Since
all of the info above full scale is lost, the reconstruction is just a
guess whether the input is a sine or kick drum or random noise. The sine
wave has a pretty clearly correct reconstruction while a percussive sound
might not. A common side effect of doing extreme declipping using
something like iZotope in the box is a softening of transients. Not
I haven't looked too deeply into how various DACs go about their process,
but some of the higher end parts have pretty decent DSP on board or even
allow external SHARC chips to do the work. I do know people that make high
end mastering converters who know quite a lot about this.
There are limits - The Stooges 'Raw Power' CD is so clipped that even high
end DACs with lots of DSP have no hope there!
> I meant that if you take 16 bits to be full-scale but you have a 24-bit
> DAC you _could_ use the 16 LSBs of the DAC as full scale, then you have a
> lot of headroom but your signal to noise ratio is not as good, and maybe
> something like this is happening in the default MacOS headphone driver.
It's not clear what is happening in the Apple codec driver, but the Core
Audio doc linked earlier gives a pretty good idea that they are doing a
'soft clipping' algorithm perhaps much like zexy's [limiter~]. I have seen
some Wolfson codec datasheets that mention doing the soft clip in the
hardware and those parts were aimed at mobile phones and the like. The
intent is to prevent hard clipping from reaching the puny internal speakers
in such devices and not an aesthetic choice.
> On 2014-01-01 13:50, Chris Clepper wrote:
>> Nope, the DAC can freely construct intersample peaks as it sees fit and
>> those can easily exceed 0 dBFS. It has been common practice in the
>> industry for more than a decade to reconstruct clipped samples well
>> above 0 dBFS - partially to make up for shitty mixing and mastering
>> prevalent in music, and also because it's the right way to do it.
>> 16 bits full scale and 24 bits full scale are the same 0dBFS signal.
>> The bits are added at the bottom not the top.
>> On Wed, Jan 1, 2014 at 1:34 PM, Martin Peach <martin.peach at sympatico.ca
>> <mailto:martin.peach at sympatico.ca>> wrote:
>> On 2013-12-31 19:32, Chris Clepper wrote:
>> It's very, very easy to avoid any sort of clipping processing by
>> hardware with drivers that don't have any! Avid, Apogee, MOTU,
>> RME, and
>> many others have bit transparent OSX CoreAudio drivers.
>> Also, any DAC worth it's using can reconstruct far beyond 0dBFS
>> distortion, so hearing volume increase past -1..1 in software is
>> surprising. I recall the ADI 1955 and equivalent TI part
>> putting out
>> +12dBFS or something ridiculous, but those ain't Wolfson low power
>> headphone codecs neither!
>> A DAC can only go to 0dBFS by definition. If it appears to go beyond
>> that then something is scaling the input to be less than full scale
>> at "full scale".
>> For instance a 24-bit DAC could be sent 16 16-bit full-scale streams
>> and not clip. Only if 16-bits is considered "full scale" does that
>> make it +12dBFS.
>> Pd-list at iem.at <mailto:Pd-list at iem.at> mailing list
>> UNSUBSCRIBE and account-management ->
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list