Incorrect Sound Pressure Level from FFT in Matlab
in [Matlab]
|
From: Cris Luengo on 12 Apr 2010 06:32 "Johannes Buechler" <jb_spam(a)gmx.DELnet> wrote in message > However I have to find the reason for the discrepancy before I can proceed with my work (drawing of the Campbell is not the goal, it is just a way of easily comparing calculation results). The calculation of SPL is defined with p0 so the question is why does the FFT deliver different numerical values already before the logarithmisation. In order to find the reason, I'll have to start with a simple sinusoidal signal. > > I'll probably try to get some help as soon as I can define the problem in a more detailed way. Thanks a lot so far, Joe You might want to look for the solution in the differences between the Fourier Transform (which you want to compute) and the FFT (which you are computing). For one, the FFT is unitless. This means that the output values are not in Pascal, and the coordinates are not in Hz. Frequencies go from 0 to <1, and the value at f=0 is the sum of all input values, not the integral over the signal. I have no experience whatsoever with your application, so I cannot help you further. But I'm sure you can compute the correct normalisation based on this. Good luck!
From: dpb on 12 Apr 2010 09:12 Johannes Buechler wrote: > "Mark Shore" <mshore(a)magmageosciences.ca> wrote in message > <hpncnd$3q7$1(a)fred.mathworks.com>... > >> > So let me redefine the problem just for you: I'd like to get the >> same Levels in the Matlab plot as in the professional 20,000+ EUR >> software PAK. I also have ArtemiS on my computer which delivers >> identical results to PAK. They are the two most common >> acoustical/vibration measurement and analysis tools in the world, >> together with LMS maybe. >> > > Joe >> >> I take a very empirical approach to this sort of thing, so it could be >> that I'm missing something, but if you have dB values you trust from >> PAK and want to reproduce in MATLAB (you've managed to create >> remarkably similar output plots by the way), then why not simply >> adjust the value of p0 in L_p = 20*log10(abs(B)/p0) until the dB >> levels match? (And figure out why it works afterward.) > > Thanks Mark for this comment. It is a quite refreshing remark > considering that some people obviously think that they are the most > clever in the world and if they don't know something then they haven't > been provided with all necessary information. > > However I have to find the reason for the discrepancy before I can > proceed with my work (drawing of the Campbell is not the goal, it is > just a way of easily comparing calculation results). The calculation of > SPL is defined with p0 so the question is why does the FFT deliver > different numerical values already before the logarithmisation. In order > to find the reason, I'll have to start with a simple sinusoidal signal. > > I'll probably try to get some help as soon as I can define the problem > in a more detailed way. Thanks a lot so far, Joe I'd venture as another respondent just noted it's all in the normalization assumed by TMW in the FFT algorithm as compared to the computed values and the suggestion there and the one above are your Rosetta stone. If you were to simply compute the difference (ratio) I suspect a short amount of experimenting w/ the various quantities of length of the sample record, sampling units, etc., etc., will uncover the difference. Waiting for magical insight will probably come in behind the empirical observation a la tortoise/hare--maybe not as magical as an "aha!" moment of divine inspiration but undoubtedly satisfying when uncover it... --
From: Rune Allnor on 12 Apr 2010 09:21 On 12 apr, 15:12, dpb <n...(a)non.net> wrote: > I'd venture as another respondent just noted it's all in the > normalization assumed by TMW in the FFT algorithm TMW does not 'assume' anything about how to normalize the FFT, but rather uses the de facto standard definition. There is the omnipresent discussion about the 1/N factor not being symmetric in the FFT/IFFT pair, but that's the convetional way of defining the FFT/IFFT pair. Presumably, it has to do with saving FLOPs, as there usually are more FFTs than IFFTs computed, and any computations shifted from the FFT side to the IFFT side will result in an overall computational gain. Apart from that, the OP is looking in the wrong place for explanations of his trivial conundrum. Rune
From: dpb on 12 Apr 2010 09:25 Rune Allnor wrote: > On 12 apr, 15:12, dpb <n...(a)non.net> wrote: > >> I'd venture as another respondent just noted it's all in the >> normalization assumed by TMW in the FFT algorithm > > TMW does not 'assume' anything about how to normalize the FFT, > but rather uses the de facto standard definition. There is the > omnipresent discussion about the 1/N factor not being symmetric > in the FFT/IFFT pair, but that's the convetional way of defining > the FFT/IFFT pair. Presumably, it has to do with saving FLOPs, > as there usually are more FFTs than IFFTs computed, and any > computations shifted from the FFT side to the IFFT side will > result in an overall computational gain. > > Apart from that, the OP is looking in the wrong place for > explanations of his trivial conundrum. I've seen others in both computations and literature than the particular de facto 'standard' in ML...plus windowing corrections, etc., that may be in the other software that aren't in ML w/o manual incorporation. --
From: Rune Allnor on 12 Apr 2010 09:36
On 12 apr, 15:25, dpb <n...(a)non.net> wrote: > Rune Allnor wrote: > > On 12 apr, 15:12, dpb <n...(a)non.net> wrote: > > >> I'd venture as another respondent just noted it's all in the > >> normalization assumed by TMW in the FFT algorithm > > > TMW does not 'assume' anything about how to normalize the FFT, > > but rather uses the de facto standard definition. There is the > > omnipresent discussion about the 1/N factor not being symmetric > > in the FFT/IFFT pair, but that's the convetional way of defining > > the FFT/IFFT pair. Presumably, it has to do with saving FLOPs, > > as there usually are more FFTs than IFFTs computed, and any > > computations shifted from the FFT side to the IFFT side will > > result in an overall computational gain. > > > Apart from that, the OP is looking in the wrong place for > > explanations of his trivial conundrum. > > I've seen others in both computations and literature than the particular > de facto 'standard' in ML... Examples? > plus windowing corrections, etc., that may > be in the other software that aren't in ML w/o manual incorporation. The FFT is a well-defined operation that you might use as a building block in other algorithms. The FFT/IFFT pair as such are for all intents and purposes standardized as what is implemented in matlab. What the FFT/IFFT pair is used for, is not standardized. If you want to implement, say, a periodogram spectrum estimator based on the FFT, then by all means do that. To get the numbers to match up - e.g. Parseval's relation - you need to introduce some additional scaling constants. Those have nothing to do with the FFT, but with the periodogram. If you want the numbers to match up to the physical world, you need to introduce calibration constants. Which have nothing to do with the peridogram or the FFT, but with the sensors. Again, all this is trivial. One only needs to know what one is talking about. Rune |