# Audio volume as a floating point value?

This topic is 4861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm just wondering about something: audio (i.e. waves) has their volumes stored as an integer, right? Wouldn't it be possible and beneficial to instead use floating point numbers? Unless there's some hardware restriction, I see no reason not to as it could easily remove a lot of distortion that comes from extremely loud sounds. ...or are floating point volumes already being used?

##### Share on other sites
distortion from extremely loud sounds results from clipping - nothing to do with rounding or precision.

##### Share on other sites
An X-bit floating point number has less accuracy than an X-bit integer because it has a much larger range, so it is beneficial to use an integer.

The best accuracy would probably be to create some kind of non-linear quantization table to use on the samples. A simple logarithmic scale seems usefull since DB is a logarithmic scale.

##### Share on other sites
I can't say I'm an expert on the topic, but I believe floating point values are superior to integers as time-domain sound sample types.

AP: Distortion on loud sounds results from clipping, sure. I t's nothing to do with rounding or precision, true. But it's extremely hard to get clipping with floating point numbers, their maximum magnitudes are normally at least hundreds of times larger than what's being used.

Extrarius: An X bit floating point has less _average_ accuracy over the whole range. But for sounds, the greater the magnitude, the less accuracy matters, since the singal to noise ratio is on average higher for floating point numbers when looking from a logarithmic point of view.

The loudest sound a 16-bit sample can make is 2^15 times as large as the quietest. (= 3.27x10^4 = 45 db).

The loudest sound a 16-bit floating point number (6 exponent bits) can make is 2^42 times as large as the quietest. (= 4.39x10^12 = 126db).

At 0db (relative to peak integer volume):
Integer maximum error (relative) = ~3x10^-5. (45db)
FP maximum error (relative) = ~1.9x10^-3. (27db)

At -20db (relative to peak integer volume):
Integer maximum error (relative) = 3.1x10-3 (25db)
FP maximum error (relative) = ~1.9x10^-3. (27db)

At -45db (relative to peak integer volume):
Integer maximum error (relative) = 1. (0db)
FP maximum error (relative) = ~1.9x10^-3. (27db)

The maximum error is sort-of the signal-to-noise ratio, so higher is better. For a 20db s/n ratio, think of a listening to a sound at 60db while 40db static is playing in the background.

And these margins are more in favour with greater bit widths.

Many speakers can put out sounds much louder than 45db above the human limit of hearing.

SAMPLES: Most game sound samples are normalised, but a significant proportion of them have sections where the maximum volume is a very small fraction of the overall maximum volume of the sample. (Eg a weapon firing / reloading sequence, or a mechanical sound with a very loud clang at the end).

INTERNAL: The internal sound channels are likely to blend lots of high-volume and low-volume sounds. During segments of quietness you would prefer not to have a significant decrease in s/n ratio. Floating point samples will be more important here.

OUTPUT: Speakers are also able to be more precise at lower volumes, so floating point DAC is more suitable from the speakers point of view.

Extrarius: floating point is a non-linear scale, as close to the logarithmic scale as you can get while still maintaining an acceptable degree of operations per second.

BTW: I'm an avid supporter of integers and think floating point numbers should really only be used in rare circumstances, but this is one of them. (The other big one being color intensity). I think using floating point numbers for model/world co-ordinates should be considered a big no-no, but everyone seems to do it.

The main advantage of using integers in sound is the speed of calculations, and a floating point software sound soultion is going to require more CPU grunt, which is not necessarily insignificant.

##### Share on other sites
Not to mention that sound cards won't handle floating point values - hence a 16 bit sound card has an amplitude range of 65536 values, and an 8 bit card has a mere 256.
Unless you're talking about redesigning the way sound cards currently operate.

##### Share on other sites
Er, some cards do. Just not cheap ones. My friend was looking at importing (NZ) a card from somewhere that was 24-bit floating point. A quick search on google showed some professional cards with float, but nothing in the consumer range that I could see.

Audigy 2 has 24 bit. I can't see whether that's int or float though.

But good point, if your output is 16-bit integer I suppose there's not much you can do with the greater flexibility.

Another point: some (most?) sound compressers use logarithmic amplitude data.

##### Share on other sites
Frankly, I can't hear much difference between 16 and 24 bit - well; 24 sounds a little crisper, but not much to me.
I was reading this topic in view of game development, (what with this site being called GameDev.net and all) and so ignored the high-end floating point cards, and was thinking of your bog-standard card in your home PC.

##### Share on other sites
This page goes over the basics of DAC (digital to analog conversion).

But all you really need is one bit anyway.

##### Share on other sites
Quote:
 Original post by KrylloanBTW: I'm an avid supporter of integers and think floating point numbers should really only be used in rare circumstances, but this is one of them.

Can you tell us why? The output waveform is necessarily filtered, so the output waveform should be smoothed. At the kind of output sample rates you'd get for high fidelity audio, I really doubt you need a voltage level between two existing levels. Also remember that your ears are sensitive to the change in output level, not the level itself, so it's fundamentally different than color. Constant 0V output sounds exactly the same as constant -1V and +1V--silence. Sound is only interesting when it is transitioning between voltage levels, so if the waveform's always moving then you're only going to get very small gainst as you move from 16-bit to above.

Quote:
 The main advantage of using integers in sound is the speed of calculations, and a floating point software sound soultion is going to require more CPU grunt, which is not necessarily insignificant.

I think this argument puts the cart before the horse. ADCs have historically had linear levels, therefore fixed point is fine.

Also, if you move to a mantissa + exponent method, you've automatically made your ADC curve non-linear. It actually might be needed (I think there might be some non-linearity already in the system, but now I'm confusing myself if that were really ADCs for audio or for communications; it's been a while). But if you're going to do that, a non-linear ADC is probably fine. (There's a term for this but I'm blanking on it now).

EDIT: I've been saying ADC when I mean DAC. Is it Friday? Why yes, yes it is.

##### Share on other sites
FWIW, Csound does its calculations internally with floating-point numbers, then outputs integer PCM data. It does seem to make things easier. E.g., if you want to compose your sound out of a thousand little voices each with a peak amplitude of 3 (assume 16-bit sound), the quantization might not matter most of the time statistically (law of averages) but it could get really nasty if sounds synchronize in certain ways.

Of course, it could probably all be done in fixed-point too, but I don't suppose it would be much benefit. (There's also a "compile-time" flag to use either float or double values globally when rendering your sound.)

##### Share on other sites
having last worked at an audio console manufacturer, I can tell you that their products are all using DSP processors to manipulate audio, and the current generation they use is all 40 bit floating point SHARK processors.

24 bit integer is better than 16 bit for the increased range AND/OR precision, 16 bit floating point has greater range, but lower precision, 24 bit floating point or higher has much much greater range than 16 bit int (of course), and still has greater precision as well.

I would rather have 24 bit int vs. 16 bit float for all FINAL storage values - but float makes for a much better intermediate calulation format.

##### Share on other sites
Quote:
 Original post by XaiI would rather have 24 bit int vs. 16 bit float for all FINAL storage values - but float makes for a much better intermediate calulation format.

I can buy that. I work in low-power land, but I suppose if I had all the juice in the world I'd want 64-bit floating point precision for my internal calcs.

Can you _really_ tell the difference between 24-bit and 16-bit DAC? Like double-blind test certain?

##### Share on other sites
Krylloan: I agree with what you said, except that you missed out on the last comment I made: The integers don't have to represent a linear scale. You could use a spline-based algorithm of some sort to get exactly the level of accuracy and range you want without having to worry about how to get an extra tenth of a bit for the exponent. You could store the spline as part of the sample (if you're using files, or possibly in the setup phase for streams) and have exactly the correct precision in each part of any samples =-)

Stoffel: Only 64 bits? Why not go for 128, and then you can used fixed point to get more accuracy than you want as well as a larger range =-) Hell, if I had 'all the juice[computing power] in the world' I'd probably go quite a bit higher

##### Share on other sites
Extrarius: When talking of integers here, I think most of us are referring to values whose _final_ representation is a linear scale, (eg constant voltage steps between values in output). You could classify floats as integers that

Quote:
Krylloan: BTW: I'm an avid supporter of integers and think floating point numbers should really only be used in rare circumstances, but this is one of them.
Quote:
 Stoffel: Can you tell us why.

Because precision is more important at lower overall volumes. In a game where gunshots can reach, say 100db on a decent speaker system, you don't want to have a minimum volume of 55db, because quiet sounds like footsteps will never get rendered.

I think it is important to maintain a decent S/N ratio right through the entire available audible amplitude range, especially in games as the ratio of maximum / minimum(audible) amplitudes is likely to be typically a lot higher than that of music or communications.

Most sound environments are centered about 0 (no DC component because there is typically no constant velocity air current, and it is undesirable to have high motion air around a recording device (you've probably all heard recorded wind noise on microphones that isn't really audible to humans at the time of recording, since ears neutralise this.) So floating point data types should have their highest precision around the center of most sounds, which is good.

Change in volume is what we hear, and a sound sample recorded this way with very small negative feedback (to prevent DC buildup) is likely to be superior to a direct voltage-level sample until you start considering frequencies close to the sampling frequency, but unfortunaltely nobody uses this except maybe in compressed sound.

##### Share on other sites
Er, I think my DB measurements may have been incorrect since I was only multiplying by 10 (not 20, which is required for audio pressures). So you might want to double them. This changes some thiggs, sorry.

##### Share on other sites
by the way, the concept of INTEGER isn't some made up thing to do with C data types, we are talking about the math that would happen to properly do various math operations ...

an "integer" on a "logrithmic scale" isn't an integer for most usefull purposes. Sure, you can add 6db to 36db as an int, but then you get 42db, which is NOT what 6db added to 36db sounds like.

To add logrithmic scaled numbers required more complex math, that is NOT built into computer chip, and therefore very slow by comparison to int and float operations (if computers had such circuits in them, languages like C would have a "log" data type :).

For example, with sound, adding 36db + 36db yields 39db (because on the db scale 3db == double the sound pressure level). So what people do in computers is convert the sound level (in db) into a linear scale FIRST, and store that as an int ...

for instance a table for a linear conversion might be sipmly this (although you may multiply these values by any factor you prefer):

3db == 30
6db == 60
9db == 120
12db == 240
15db == 480
...
27db == 7680
30db == 15360
33db == 30720
36db == 61440

so you see, a 16bit int would already be exhausted at 37db if we used a precision of 30 for the first 3db. we could of course have used only a precision of about 8, and made it to 42db, but no matter what precision we use, we cannot simultaneous get more than a few numbers in the first 10db and still have enough range to reach 60db of distance.

Of course, 32 integers pretty much fix this, as then you have 4 billion as your max ... so using the same starting scale we can reach about 84 db of FULL PRECISION dynamic range (which is actually pretty amazing). But believe it or not, using this scale for internal computations of DSP systems which provide sound processing such as reverb, compression, gain, etc, can very easily cause clipping and banding.

Hence the reason floating point numbers are prefered, the idea of the benifit of floating point is this - the amount of precision for any given sample is fixed based on the magnitude of the sample, not a predetermined fixed precision. So a quite (16 bit float) sound has say 11 binary digits of precision, and an exponent that is low, and in the quite range. And then a loud sound has the same 11 bits of precision, but a higher exponent. Then, adding 2 loud sounds together is very accurate, adding 2 quite sounds is very accurate, and it is only when you add a quite and a loud sound together that you get a loss of detail (the quite sound has less effect on the loud sound than it should - but since the magnitude difference is high, no one will notice anyway - because the quite sound is expected to be washed out by the loud sound).

Now, this 16 bit float sound system would really suck, cause 11 bits precision for sound is NOT ENOUGH. 32 bit floating point is really great, because it has a 24 bit mantisa, giving the same precision as a 24 bit integer, while still having a sign and 7 bits of exponent too. A 24 bit float is a decent compromise, because it has as much precision as the 16 bit int it will eventually be converted into, while providing the ungodly dynamic range only a floating point number can yield.

##### Share on other sites
My point of a 'logarithmic intergral scale' is one of storage type, just as floating point is. If you're talking about the math you'll be doing, then you should be talking about integers and fractions instead of integers and floating points (since floating point is a storage type - or at least I've never heard it used in math).
I should have been more clear, but my point was that you neednt use a traditional storage type (like a simple int or floating point number) in order to get good precision, and that using some kind of quantization table as is used in most audio/video/image/etc compression is probably a good idea since even with 'uncompressed' audio you're still losing information due to the limits of the representation type.

##### Share on other sites

This topic is 4861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628667
• Total Posts
2984138

• 12
• 9
• 10
• 9
• 9