Sitemap

Some Thoughts on Audio Data Types

9 min readDec 29, 2025

--

For audio programmers, listeners, and creators, data types are often a source of confusion and misinformation that can exacerbate that confusion. I wanted to write this article to provide some insight into how these data types affect the audio that you listen to or perform computations with, while hopefully also clearing up some misconceptions.

Fixed-Point Audio

In my career (thus far), I’ve worked with or listened to 4 variants of fixed-point audio encodings: 8-bit, 16-bit, 24-bit, and 32-bit.

8-bit Audio

While 8-bit audio was prevalent in classic video game audio, it is rarely used today, outside of effects that intend to re-create the sounds of the past. Still, it’s useful for us to get a sense of how fixed-point encoding works on a smaller scale.

An 8-bit number has 2⁸=256 possible values. If we choose to represent our audio using a signed 2’s complement format, then we can represent any integer value on the range [-128, 127]. In order to keep our encoding symmetric, we can choose to further restrict this range to [-127, 127].

Now let’s say that we have a microphone connected to our computer, and we want to be able to represent the electrical signal coming out of the microphone as a digital signal in the computer. If we know the maximum/minimum possible signal coming from the microphone, we can “map” those values to +/-127 and construct the rest of our encoding as evenly spaced integers to fill out the range. Note that if we want to play audio out of a speaker connected to our computer, we can perform the same process in reverse.

Press enter or click to view image in full size
A digital computer playing audio through a loud-speaker. Adapted from “The Digital Computer as a Musical Instrument”, Max Mathews, 1963.

Now as you may notice, in going from the “continuous” analog domain to the “discrete” digital domain, we are going to have some rounding errors. For example, what happens if we have a number that ideally would be mapped to 99.5? To store that number as an 8-bit integer, we either need to “round up” to 100, or “round down” to 99… either way resulting in a “rounding error” of 0.5.

Fixed-Point Audio and Dynamic Range

You may have heard that the dynamic range of your audio can be calculated as 6*N, where N is the number of bits used for encoding. Let’s see if we can figure out where that number comes from!

To make our lives easier, let’s say that the “ideal” range for an audio signal is [-1, +1]. In this range, the “step size” between any two quantized values will be D = 2/256. As we saw above, the maximum error in a single quantized value will be in the range [-D/2, D/2]. If we assume the quantization error is a uniform random variable then we can try to estimate the mean square error of the quantization process:

From there, we can try to estimate the signal-to-noise ratio:

Press enter or click to view image in full size

So it’s true that the dynamic range of our audio is roughly 6dB/bit, but it’s worth remembering that we took a couple of approximations to get to that number, so it may not always be exactly right in reality.

Press enter or click to view image in full size
Simplified fixed-point error. From tonmeister.ca.

For the Listener…

So if you’re a music listener (or someone who creates audio content), you can think of the typical audio bit depths as follows:

16-bit: 98 dB
24-bit: 146 dB
32-bit: 194 dB

For an audiophile, you might say that you always want the best quality you can get… and while that’s admirable, I think the effects of bit depth and quantization noise are sometimes a little bit exaggerated. First off, the dynamic range of human hearing is only ~100 dB. Second, when you’re listening to music, there are likely many other sources of noise that would render the quantization noise irrelevant, like amplifier noise, background/environmental noise, or even the sound of your own breathing.

So if you are in a situation where you can listen to music in a pristine environment, where you’ve made painstaking efforts to reduce noise and other audio quality issues, then sure, maybe listening to your music at a higher bit depth is worth it. But the rest of the time, 16-bit is probably fine.

For the Programmer…

While fixed-point audio signal processing is no longer as prevalent as it once was, there are still times and places when it is used to great effect. While I’m not an expert on fixed-point DSP, I’ll leave a couple of notes here:

  • Watch out for overflow! For engineers used to floating-point DSP, make sure that whenever you’re multiplying or adding numbers, you have some sense of what the ranges of those values should be, and make sure that you’re using the appropriate data types, and taking the appropriate precautions to avoid overflow.
  • Is fixed-point DSP faster than floating-point DSP? It depends on your hardware as well as the algorithms that you’re implementing. For most algorithms that I’ve worked with, when running on a modern consumer CPU, there’s little to no performance difference, so the convenience of the floating-point implementation often makes that the right choice for me. It’s also worth noting that if you only want to implement parts of your algorithm in fixed-point, then you’ll need to pay the cost of converting between data types, which could obviate the performance gains of using fixed-point in the first place.
When implementing an IIR filter in fixed-point, be careful that the “accumulator” does not overflow!

Floating-Point Audio

The IEEE 754 standard defines floating point numbers as being made up of a single “sign” bit, several “exponent” bits, and the remaining “fraction” or “mantissa” bits. Specifically a 32-bit floating point number has E = 8 exponent bits and M = 23 mantissa bits.

Press enter or click to view image in full size
A 32-bit floating-point number (as defined byIEEE 754)

The resulting number can be constructed as S * m * 2^e, where S is the sign bit and m and e are the integer mantissa and exponent values respectively. Note that IEEE 754 is a “base-2” floating-point number system… while this is common, it’s also possible to construct a system that uses “base-10”, or any other base for that matter.

Dynamic Range and SNR

One interesting wrinkle about encoding audio using floating-point numbers is that the dynamic range and the signal-to-noise ratio are no longer the same! Specifically, we now find the following:

Press enter or click to view image in full size

So for a “single-precision” (32-bit) float the dynamic range is roughly 1,536 dB (way larger than any of the fixed-point ranges that we looked at earlier), and the SNR is approximately 138dB (slightly less than 24-bit fixed-point). For audio, that dynamic range is definitely overkill, but the SNR might be too low for certain applications.

Is Double-Precision Worth It?

Press enter or click to view image in full size

IEEE 754 also defines a 64-bit “double-precision” floating-point type, with 11 exponent bits and 52 mantissa bits. This results in a 12,288 dB dynamic range and 312 dB SNR. Again, the dynamic range is way larger than what we need for audio applications, but the SNR is now large enough that it should suffice for all audio applications (outside of something super exotic).

Some audio developers believe that double-precision is the right choice for audio processing given the greater SNR, however there are trade-offs to consider. The obvious downside of using double-precision numbers is that they require twice as much memory, so if you’re working on a platform with limited memory you probably want to avoid them. However, even on modern CPUs that have plenty of memory, double-precision numbers use cache space less efficiently, and have half the bandwidth for most SIMD operations, so there can still be a significant performance hit.

In my experience, it’s best to stick with single-precision floating-point DSP except in situations where you know that the extra SNR of double-precision will be necessary. Even then, it may be preferable to perform your calculations in double-precision, while continuing to use single-precision for long-term storage.

Press enter or click to view image in full size
Visualizing how different data types fit into SIMD registers. From ggbaker.ca.

Half-Precision: The New Kid(s) on the Block

In recent years, 16-bit “half-precision” floating-point numbers have started to become more popular in computing, with several CPUs, GPUs, and DSPs offering native half-precision support. Even more interesting, we’ve seen two unique 16-bit floating-point types start to gain popularity.

Comparing float16 and bfloat16. From nhigham.com.

The IEEE 754 standard defines a 16-bit float with 5 exponent bits and 10 mantissa bits (DR = 192 dB, SNR = 60 dB). However, in the 2010s, researchers at Google Brain noted that neural networks typically work with data that vary across many orders of magnitude, but was often relatively noisy. As such, they designed the 16-bit “brain float” to have 8 exponent bits and 7 mantissa bits (DR = 1,536 dB, SNR = 42 dB). A brain float has the same dynamic range as an 32-bit floating point number (better for handling the varying dynamic range), and although it has significantly worse SNR, that may not matter if you’re working with noisy data anyway.

Similar to what we saw when comparing 32- and 64-bit floating-point numbers, it is possible to achieve better performance with 16-bit floating-point numbers due to better memory efficiency and SIMD bandwidth.

In my experience the brain float does not have sufficient SNR to be used for most audio applications, however the IEEE 16-bit float does have some use cases. Although the 60 dB SNR is far from ideal, it can be acceptable in situations where the SNR is already limited by other parts of the system. For example, I was recently working on an ARM-based guitar pedal that only had ~48 dB of SNR to begin with, so implementing my DSP using ARM’s float16_t resulted in a significant performance improvement with minimal change in the noise floor.

Press enter or click to view image in full size
Performance improvements using 16-bit floating-point numbers on NVIDIA GPUs.

What if…?

All this discussion begs the question: what would be the ideal number format to represent audio signals? To start, I think it would have to be a floating-point type… I don’t think the potential benefits of fixed-point are worth the additional effort required from the programmer (for most applications). To be honest, I think 32-bit floating-point fits the bill for the most part, and strikes a good balance between dynamic range, SNR, and size. But can we do better?

The IEEE 16-bit float is pretty close to sufficient… if only the SNR were a little bit better. One idea would be to limit the values to the range [-1, 1]. This would mean that the floating-point exponent would always be negative (or zero) and could be represented with an unsigned number. In that case, you could assign 3 exponent bits and 12 mantissa bits, for a dynamic range of 96 dB and a 72 dB SNR. Unfortunately, that SNR still probably isn’t good enough for general audio applications, and now we’ve sacrificed some dynamic range, which could be problematic as well. Additionally, limiting our range to [-1, 1] could pose problems when performing DSP algorithms that have the potential to “overshoot”.

What if we had a 24-bit floating-point type? Yuriy Yakimenko on GitHub has a software implementation of a 24-bit float with 5 exponent bits and 18 mantissa bits (19 if you don’t need negative numbers). This format would provide 192 dB of dynamic range (same as IEEE float16) and 108 dB of SNR. I think this format would be sufficient for many audio applications, but unfortunately it’s not available on any hardware platforms that I am aware of.

In any case, it’s a fun thought experiment!

Wrapping Up

I hope this article has been able to shed some light on the wide and weird world of audio data types. If you could design your ideal data type for audio or any other form of digital information what would it look like and why?

--

--