if neither of the above is known to be the case, avoid using the term dB at all for that signal?.if a signal is known to be 'root-power-like' (including audio signals, magnitude spectra, and any other signal with a unit of V associated with it), show dB calculated as 20log10.power spectrum or something else calculated from square of voltage), then show dB calculated as 10log10 if a signal is known to be 'power-like' (e.g.Would you say it would be correct to do the following? I should stop trying to rationalise the existing behaviour. You're right, my comment was badly put - thank you for following up again. Out of these digital quasi voltage values you only could compute quasi power values, but the original stored sample values are not. In other words, the SV program always reads digital values which correspond proportionally to voltage values, not power values. And then the 10 log(100) would produce the same dB value -> 20 dB and not 10 dB. If Audacity would have made it by power values, then the values would have a ratio of 100 instead of 10. This digital value corresponds proportionally to voltages, that is always the case when you are writing or reading a soundfile. In my first posting I have applied a soundfile with two levels with a ratio of 20 dB, because one signal is made with a FS ratio of 0.8 and the other is 0.08.

All other displays in dB are either ratio only or it is the ratio of the digital value in respect to fullscale. This would at least require a calibration for the used hardware. For instance dBV would assume that the system knows about the correlation of the digital values and the output of the soundsystem amp. Normally you always have to use just dB without any unit. I think there is still a misunderstanding of some kind. The solution to this at least starts with never using dB as if it were a unit without a suffix, but I'm not sure that just displaying dBFS (which is what we actually have everywhere) instead of dB would be all that helpful, since it's not the unit that people are expecting. For example when showing a dB scale for the output of a plugin, should we use 10log10 if the output has a unit other than volts and 20log10 if it has a unit in volts? What about data loaded from a CSV file, which probably has no units specified in it? One reason it hasn't been changed before is that changing the meanings of reported values between releases seems hazardous in itself - it should at least put up a warning and maybe even give the option to fall back to the old behaviour (even though probably nobody will use it).īut it does also mean making a potentially tricky determination about when to show which sort of ratio. It has been on my radar to change this for some time, and I'd like to do so in the (forthcoming) 4.4 release, but it's a slightly sensitive thing to do.

The behaviour we have is not wrong exactly - dB is after all just another way to write a ratio, and has no more meaning than that unless you have context about what the ratio is of - but the convention that for audio signals dB (without qualification) refers to power rather than voltage is strong enough to make it surprising that we didn't do that. To do otherwise, we would need to give special treatment to a plot whose units happen to be volts, or that is known to be an audio signal, or some such. For voltage values, that means you get dBV. It treats dB as a simple ratio in the same way regardless of the unit of the signal, meaning for example that a spectrogram will be shown with the same dB values as a plot generated from the same data as the spectrogram (but lacking any units) would use. The principle, I think, was that SV is internally consistent in always using a dBFS value that just tells you the level as a ratio of full-scale.

I agree with you, and it's puzzling that we released SV with this logic in the first place. Thanks for posting this - I hadn't realised we didn't have an issue about this in the Github tracker yet.

Sonic visualiser filter