21 Jul
2010
21 Jul
'10
7:55 p.m.
On 2010.07.21. 19:26, Paul Davis wrote:
If I code program to handle attenuation of sounds depending on their
source (emitter) position in virtual 3D space, I guess then there's no
simple way to relate the effect to real world.
How this is usually handled?
I guess you misunderstood me a bit. I use floats internally regardless
of inputs or outputs. I simply don't (won't) divide integers by 2^(16-1)
(or whatever bit depth else) when converting.
I expect to divide the internal float value when file output is of
floating point type.
I think this should reduce problems with two conversions to/from floats,
when both inputs and outputs are of integer type.
-- JohnLM
- How does
floating point (and perhaps fixed point/integer) values relate
to dB notation?
floating point -1.0 == minimum value of an integer sample == -inf dBFS
floating point 1.0 == maximum value of an integer sample == 0dBFS
relationships to dBU, dBV etc are not fixed.
- If I muliply float by 2.0, do I get twice the
sound pressure or twice the
sound intensity, or something else?
you get samples that are twice as loud. this doesn't have a linear
relationship with sound pressure or intensity or perceived volume
other than "its louder" Well as for
internal processing. If I mostly use integer formats for inputs,
it doesn't appear I gain anything from "normalizing" them (scale to [-1.0,
1.0]) during internal processing. I just output integer part directly to
integer formats (adjusted for different bit resolutions when necessary), and
normalize only when saving to float format. What do you think?
the reason you gain from using floats is that you will not clip when
adding or scaling values. this is a huge win.