CrepeGoat
commented
3 years ago I do want to emphasize a couple things.
First, the calculation canNOT generate a single dB-scale data sample from a single pressure-scale audio sample. It's not a one-to-one conversion in that way.
A dB-scale sample needs to instead be calculated from some RMS quantity; this could be a scalar RMS over the whole time series, samples from a rolling RMS, or samples from a PSD (which relates to the time-domain RMS via Parseval's Theorem). Additionally, the data should likely also be zero-mean'd before calculating the RMS (this is equivalent to calculating the standard deviation of the samples). The reason for calculating the RMS first is because this is indicative of the energy content of the signal, which is what our ears are detecting when we hear sound.
The second thing is, there are two different dB scales for sound pressure:
- sound pressure level (SPL) - this uses
20 log10, and uses a reference of2e-5N/m^2 (Pascal) - sound intensity level - this uses
10 log10, depends on air density and the speed of sound as parameters (you can calculate these from ambient pressure/temp & relative humidity), and uses a reference of1e-12W/m^2
While these appear to be effectively identical at STP, they diverge under other conditions, so it should be noted which one we're calculating.
I'm basing ^this on the handful of articles I've been using as references:
CFlaniganMide
Work done in endaq-python-calc has done the math for converting the units, and in IDELib it'd be easier to utilize the on-board pressure sensors to find the actual ambient pressure.
Adding a new non-linear transform to
idelib/unit_conversion.pywould be fairly straightforward and add value to us and customers.