hello
i understand that for sound level representation in the digital domain, a special dB scale is used: The dB full scale (or dBFS). In this scale 0dB represents the maximum possible magnitude of a sample before clipping (e.g.: |x(n)|=1=0dBFS). I noticed the scale on the vu object and it seems it has an analog look, meaning it has some 12dB "headroom" above 0dB. Now, in most audio software (editors like audacity, plug-ins etc..) level meters go usually to 0dB max, and there is just an indicator to notify when clipping occurs.
So what is the use of the analod style scale of vu? Would it be meaningful to offset the incoming values to make use of the visual space above 0dB or would it mess up the scaling?
thanks :)
(sorry, forgot the prefix!)
On 3 February 2010 01:59, ypatios ypatios@gmail.com wrote:
hello
i understand that for sound level representation in the digital domain, a special dB scale is used: The dB full scale (or dBFS). In this scale 0dB represents the maximum possible magnitude of a sample before clipping (e.g.: |x(n)|=1=0dBFS). I noticed the scale on the vu object and it seems it has an analog look, meaning it has some 12dB "headroom" above 0dB. Now, in most audio software (editors like audacity, plug-ins etc..) level meters go usually to 0dB max, and there is just an indicator to notify when clipping occurs.
So what is the use of the analod style scale of vu? Would it be meaningful to offset the incoming values to make use of the visual space above 0dB or would it mess up the scaling?
thanks :)
-- ypatios
hello :-)
just in case: nobody (well, almost) adds the [PD] prefix to the subject.
this is done automatically by the mailing-list server.
i thought this would be the most probable case, however, not seeing the prefix on my email (since I don't receive them from the pd-list server) looks weird.. well, i'll get used to it.
alabala
embarrassed to say that i have been adding it myself all these years. i even take care to make [PD] in capital letters.
it is information like this that needs more chapters in miller's books.
embarrassed to say that i have been adding it myself all these years. i even take care to make [PD] in capital letters.
it is information like this that needs more chapters in miller's books.
hehe :)
the thing is, i don't see your messages with a double prefix "[PD] [PD]" which probably means that the server is clever enough to take care of us "pluralists".
alabala
just checking how 'clever' the server is....
On Wed, Feb 3, 2010 at 8:29 PM, ypatios ypatios@gmail.com wrote:
embarrassed to say that i have been adding it myself all these years. i
even take care to make [PD] in capital letters.
it is information like this that needs more chapters in miller's books.
hehe :)
the thing is, i don't see your messages with a double prefix "[PD] [PD]" which probably means that the server is clever enough to take care of us "pluralists".
alabala
-- ypatios
On 2010-02-03 01:59, ypatios wrote:
hello
i understand that for sound level representation in the digital domain, a special dB scale is used: The dB full scale (or dBFS). In this scale 0dB represents the maximum possible magnitude of a sample before clipping (e.g.: |x(n)|=1=0dBFS). I noticed the scale on the vu object and it seems it has an analog look, meaning it has some 12dB "headroom" above 0dB. Now, in most audio software (editors like audacity, plug-ins etc..) level meters go usually to 0dB max, and there is just an indicator to notify when clipping occurs.
So what is the use of the analod style scale of vu?
the dBFS has the implicit assumption that there is a "full scale". this makes total sense when you have a fixed-point arithmetic, where no value can go beyond a certain maximum point. e.g. if you have a 8bit signed signal, the values will always be in the range of [-127,128], you will never ever encounter a value of (say) 270, simply because it cannot be expressed in 8bit.
now in Pd we are not using fixed-point math (well, in PDa you do; but not in "proper" Pd) but floating point math, with the agreement that values in the range of [-1.0,+1.0] are the equivalent of "full scale".
this has really only a meaning when Pd interfaces with the real world: e.g. many (but not all!) audio APIs (ALSA, MMIO,...) will take the audio data as fixed point (e.g. 16bit), which has an absolute "full scale". [-1,+1] will be mapped to the audio APIs full range. therefore if you send values between [-2,+2] to the [dac~], you will notice clipping (because the conversion process between fixed pint and floating point will have under/overruns).
within Pd you are free to do whatever you want with your signal: e.g. you can run your internal signals in a range [-1e5,+1e5], and it will all be just the same (as long as you take care to scale the signals back into the standardized range before your [dac~]). there is no "clipping" in Pd [1].
this means, that you can have signals louder than 0dBFS, and this is the reason why the vu-meters show a little bit of "headroom". the notion of "headroom" is obviously owed to the normal use of the meters with sort-of-normalized signals.
fgmasdr IOhannes
[1] for the sake of simplicity it is; obivously even floats have their limits, and there is a maximum at about 840dBFS. you probably don't want a vu-meter that has a range of almost 1000dB where you are usually using the lower 10%!
hallo IOhannes and thanks for your reply :)
within Pd you are free to do whatever you want with your signal:
e.g. you can run your internal signals in a range [-1e5,+1e5], and it will all be just the same (as long as you take care to scale the signals back into the standardized range before your [dac~]). there is no "clipping" in Pd [1].
i understand that 32bit floating point handling pd makes it possible to use audio signals in many other ways than just send them to dac to produce sound (like table lookup for example). the other benefit is that the manipulation of signals is much more accurate and this applies also after the conversion to fixed point signals. There is software that uses 64bit float internally for that reason. let's assume now that we need a vu just before the dac, e.g. to monitor the signal before it becomes analog. in this (rare?) case, why lose the upper 1/3rd of the GUI object?
can you please answer the last question of my first mail? "Would it be meaningful to offset the incoming values to make use of the visual space above 0dB or would it mess up the scaling?" e.g.
[osc~ 100] | [env~ ] | [-94] (instead of [- 100]
would give about +3dB rms and the peak would be at +6dB. so you just consider "+6dB" as the real 0dB.
thank you
On 2010-02-03 11:58, ypatios wrote:
can you please answer the last question of my first mail? "Would it be meaningful to offset the incoming values to make use of the visual space above 0dB or would it mess up the scaling?"
meaing lies in the eye of the beholder.
nevertheless: the scale of the vu is highly non-linear, so a difference of say +3dB will take more pixels at around 0dB than at +10dB or at -12dB.
mgasdr. IOhannes
nevertheless: the scale of the vu is highly non-linear, so a difference of say +3dB will take more pixels at around 0dB than at +10dB or at -12dB.
i see it now, also above "0dB". It's pretty obvious.
how about vu having an option to change the scale to strictly dBFS? I guess that would be very useful for many people.
-
hard off -
IOhannes m zmoelnig -
ypatios