1

Today I started a course on protools 10, there are a few things I just can't get my head around.

  1. What exactly is a 32 bit floating point?

I understand there are 6 Db between each bit (i.e 16 bit= 96 Db) what I dont get is in a 32 bit float point why 23 bits are only used to represent to represent "discrete amplitude levels" (what are discrete amplitude levels?!)

  1. What is the difference between protools and protools HD native hard ware?

It has been my first day of protools 10 so am VERY curious.

1

32-bit floating point format audio has virtually or theoretically an extremely wider dynamic range compared to fixed point formats such as 16 bit (96dB) or 24 bit (144dB) or even 32 fixed bit (192dB).

Thus, it is advantageous to use 32-bit float session during mixing stage as it will provide high amount of headroom.

As an experiment, try this - 1) Try importing a well mixed song into your session. 2) Duplicate the track 3-4 times, so that it overlays over the original track. Obviously, the overall should sound heavily clipped. 3) Export the song in 32-bit float WAV file. 4) Import the newly exported WAV file into the session. The waveform will look badly clipped and will sound heavily distorted. 5) Solo the track and Normalize it. And hear the magic.

  • Would you mind explaining this example please? I'm trying to wrap my head around every step, but it doesn't make sense at all - particulary the paradox of step 4 and 5. It stands to reason that when you clip a file, it's clipped for good. Normalizing only alters the volume AFTER this clipping occurs on the file. So I'm not quite sure how, as you're explaining it here, a file can be bounced out clipped, imported and look/sound clipped, and then sound OK after normalizing the clipped file's levels. – Stavrosound Apr 25 '13 at 19:40
5

Even floating point numbers can clip and degrade.

If I'm mixing, I prefer 64bit floats if available, but I use mostly analogue gear now .. so the mixing happens outside of the digital domain.

I do have some software I wrote to automagically remix music.. the jazz-o-tron 1000. Internally it uses 80bit IEEE samples (YES, 80.. its not a typo).. but I only use 80bit samples when creating experimental sounds usually ie, loading a sound file, applying reverb, saving, and then reloading the outputfile and repeating the process recursively..perhaps as many as 60000 times overnight .. in these circumstances, 32bit float does not cut it.. but usually it does ;)

Btw, 32bit floats are not very accurate, nor as standardized in terms of hardware as you may think. We'll laugh at that post production gold standard in 50years... well I won't, I'll be dead.

Interestingly (to me) 64bit operating systems have dropped support for 80bit floating point in hardware, so we're losing 16bits of precision when creating 64bit apps (I'm keeping mine 32bit for sound)

As stated above, if you're going to clip, or squash your signal.. using floating point will not help you..as its better to get levels correct to start with..


The following is for some of the people who have answered the question above, I'm sure it may confuse some of you, but its a point of language regarding use of dynamic range

I'm a computer programmer, and a musician. I also rent out high end movie cameras.

I have two high end movie cameras. One has 12bit per colour channel output, the other has 16bits per colour channel (ie, 36bit, and 48bit rgb). Both sensors are identical, as is their dynamic range.

But it seems there is a misunderstanding of what is meant by dynamic range by some people who post about it, whether it be sound or photography.

Bit depth DOES NOT AFFECT THE DYNAMIC RANGE that can be stored in a given file, only the device that created the file/data affect that. This is a little deep/non-obvious, btw, and may confuse some people, but it is none the less true.

Bit depth only affects the file's ability to store small changes. Any amount of dynamic range can be stored in just a couple of bits... if you like... but don't like ;)

It's not dynamic range you're losing, it's post production flexibility, which is a more complex subject to discuss, but the short answer is...

  • Work on files using 32bit float if possible, but when you mix a master, if you export to a 16bit file, then a 32bit, and both are normalized identically, both will hold "identical" dynamic ranges at this point... unless you change one of them, even though they are not identical in terms of bits.

  • codecs such a alaw and ulaw use non-linear sampling, so less bits have to be used. Again, dynamic range is not reduced!!

Many digital movie cameras also do, as there is generally very little information in bright highlights, and just noise in the low bits, so a log curve is applied to better store what is deemed useful parts of a signal with more of the available bits allocated to specific ranges. But as long as your brightest pixel doesn't clip, and you can see the darkest pixel.. captured dynamic range has not changed.

@comment below: .. 1 bit can store the same dynamic range as 16bits ..FACT. it may not be practical.. but my comment was trying to curb the notion that you need a separate bit for each db .. or that if there is not "bit space" between stops of light in a camera, or audio signals..dynamic range is lost..it isn't!!! quantization has nothing to do with dynamic "range" .. the phrase just gets misused..

dynamic range is a measure of the top and bottom.. not necessarily the middle.. trying to teach, not troll btw ;)

  • While there may be a couple of correct points in there, this answer doesn't really bring them over in a meaningful way, and some of your statements just aren't correct this way. For PCM, bit depth does place a lower limit on the dynamic range that can be stored in a given file, because there'll be an inevitable amount of quantisation noise (though you can cheat a lot with noise-shaped dithering). – leftaroundabout Jul 11 '14 at 12:51
3

With Floating point all recordings are saved usually using fractional values only between -1 and +1 so like when you say -10 DB that will be related to 1.00 as zero Db.

If you want to know the numerical value of -10 DB, it is like Log-1(-10 / 20), or by a calculator the answer is + or - 0.31622776.

NOW, since there are no A/D converters with greater than 24 bit precision the normal form would be like 24 bits per channel, BUT since we now have 64 bit data in our CPUs it now makes best sense to represent a single stereo channel as two 32 bit numbers in a single register.

BUT, that 32 bits will only have the resolution of the original 24 bit sample taken by the sound device.

In the old 16 bit DWORD format, the numbers were like +/- 2^(16 - 1) which was like +/-32768 or +/-32767. Floating point makes much better sense since mathematics within computers are generally carried out with floating point numbers and already the data is in the correct form... in most instances that is.

2

Someone may correct me or refine my response, but...

In this case, floating point is referring to the idea that the decimal point "floats" depending on the need for significant digits. If you need to represent a very large number, the numbers to the right of your decimal point (the non-integer portion) are less important. If you need to represent a smaller number, those decimal places become far more important, but you also have less need for digits to represent numbers in the 10's, 100's 1,000's, etc. Zeros on the left and right of your number aren't actually providing any useful data; for example, 0000569.34891000 can far more easily be written as simply 569.34891. The same value is still represented with fewer digits. So, do you need additional integer values, or additional decimal values.

Let's say we've got a number, 1234.56789123, that can only be represented by 10 total digits. 001234.5678 would be a fixed-point (don't know if that's actually a term) representation of that number, while 1234.567891 would be a floating-point representation. Because the decimal place can float, you can get a more accurate representation of the number.

It's all about where and when you need the precision.

1

ill try and write a clearer answer than my other one above:

floating point numbers can represent a dynamic range of numbers, and can scale to be very large, or very small. this is why they are used

with integer samples (ie, not floating point values), the smallest value increment is 1. if we try and cut an amplitude of "1" down to a 1/3 of its original size (0.3333333) ..we would have to store the result as 0, or 1.. both of which are not accurate..but 0 would be less inaccurate

the problem with 0 is, it cannot be normalized to anything other than 0..once a sample becomes 0 information is effectively lost

digital manipulation of digitized discrete signals (samples) is generally a destructive process because of this, because numbers become too small to be stored (and so get rounded down to 0) during math manipulation by dsp algorithms..floating point numbers help to limit this destruction by scaling their range to suit the output of the process dynamically, and can store fractional values ..as stated above

however, it should be noted that the loudest noise in the world could be represented by a value of 1 (the choice of scale is arbitrary), and the quietest (silence) as 0.. which would only requires 1bit of sample accuracy..

if we started with an extreme 1bit sample example ;).. protools could convert it into a 32bit floating point value, and back again to a 1bit sample without any loss of accuracy. however if the signal was changed in any way before hand, it is likely we could not

..so it would be fair to say we do not use 32bits, or floating point numbers to increase dynamic "r a n g e", merely to preserve the original dynamic range as much as is possible later on during digital signal processing (ie, when you are messing around in protools making changes)

1

Yes... bit depth is about dynamic range, but its more about 'smoothness' of your sampling, and the number of discrete levels you can represent.

If you draw a wave signal on graph paper, then draw points every cm - we sample these values. The x axis (time) is your sample rate, the y axis is the amplitude - and if 1cm is the smallest fluctuation you can measure you won't need many bits to store those numbers. More bits = more accurate sampling of the input wave's signal level (amplitude)

Next, best of breed converters can't physically deliver more than about 22 bits of dynamic range - so why isn't 24 a bit DAW ok for that? CD uses only 16 bits, we're going to compress it down, anyway?

The answer is about the the smallest subtle difference you can keep within the numeric pipeline of the DAW's signal processing chain ... it does mathematical calculations -

I might have a chain of plugins - input -> A -> B -> output

and the numbers flowing out of them are 1.000 -> 1.001[945] -> 1.002[413] -> 1.002

We can see that, because A and B are doing subtle shimmery sexy tape emulation, by adding really small amounts of second order harmonic distortion, internally their maths need to have more precision, but the DAW's pipeline (here, only 5 decimal floating point!) is cutting off all their subtle [0.000045] and [0.000013] stuff!

And that is going to sound crap!

So, here we have only a 4 digit DAW (a sample range of 9.999 to -9.999 in 0.001 steps). The number of steps we need to represent that is 20/0.001 = 20,000 - so a 15-bit DAW would be needed for this (2 to the power 15 is 32768, 2^14 is only 16384 discrete levels, not enough to store enough permutations). This is one reason old 16 bit digital guitar gear sounds so crappy.

To go back to the truncation issue, chopping stuff off as predictably as this, always, in the same place, has a monotony about it, and mathematically it causes a nasty spike in the signal, so to mask the effect of this, we brick wall filter and add a random +/-.001 signal at the output, to make some of the chopped off stuff visible - an amazing idea called DITHER!

So, if we can keep full resolution all the way down, and just dither and truncate once at the end, we lose less information.

1.000000 -> 1.001945 -> 1.002716 -> 1.003[123]

Using nonsense numbers in this example, but can you see how quite often, with lower bit depth, we might frequently get the 'wrong' result compared to what a 'perfect' pipeline would do.

I think the best analogy here is the colour depth in a photograph. - Get a nice photo with beautiful colours (maybe lots of fades from one colour to another = subtle timbre) - Save a copy at the same res as '1.gif', reducing the colour depth to say 64 colours (so starts to look 'bandy') - Run the original through the a series of photoshop plugins, e.g. adjust levels, contrast, sharpen, denoise etc. - Now run the 1.gif through the same process, each time saving to 64 colour GIF format, to reduce the colour depth in your DSP pipeline. - Lastly, save the original as 2.GIF (same colour depth) and compare the end results

You should see that the same processing gets a better end result if your plugins are able to work against a full depth source, then only render down once at the end... this is because of rounding error in small numbers represents loss of information.

In sound, colour depth equates to tibre or tonal colour, esp of bass tones. Lack of it means frequencies have are cut out, leaving spikes either side, see mp3.

So, at the top end of the scale, the dynamic range, headroom in the mix bus. At the low end of the scale, the numerical accuracy and our ability to not destroy small signals as they are operated on by faders, processors, scalars, summers. The more numbers and more resolution you store the better the end result, but more CPU needed to crunch and retrieve the bigger numbers - so you may need to have more powerful hardware - but it's worth it.

I think rounding errors have a huge effect on audio and one of two reasons analogue sounds best - Neve component bandwidth is always well over 100khz (sample rate needed to capture it is > 300k), and the dynamic range in current models is big because of 90v rails.

Most converters won't do that, but internally Pro Tools swaps its bus range into macro / micro modes to achieve an effective 56-bit pipeline, which is why Avid claim HD sums as nicely as a Neve.

0

Well, the more simple explanation is that, when working with Integer formats (such as the 48-bit integer). Once the signal clips in the mix, you can't never restore that information later. With floating point, no information is lost when the signal clips, so you can later reduce the level of the channel that clips and fix the problem. Note that this only works when mixing. When you record, if your signal clips, that means lost information.

0

What exactly is a 32 bit floating point?

Tutorial: Floating-Point Binary http://kipirvine.com/asm/workbook/floating_tut.htm

What is the difference between protools and protools HD native hard ware?

From your perspective:

  • processing speed (I/O latency, speed of run computations)
  • processing capacity (number of plug-ins, tracks etc. that can be run simultaneously without lag)

You find information about these by reading "benchmarks" that test those capacities.

0

32-bit floating point in audio does provide a higher range of bits, but it's up to you to use them. Most people set their input signal too hot and don't actually gain anything from 32-bit FP or even 24-bit.

However, from a computing standpoint, 32-bit means longer "words". Typically, 32-bits is limited to a certain amount of information that can be stored in that block of data.

Floating point, however, is kind of like "decimal point capabilities", so it appears to the computer as a smaller number, but one that can still fit within the bit range.

This allows for a larger range (not amount or size) of data to be stored, meaning that it has more possible bits, and higher fidelity.

This is to say, a theoretical 32-bit would have lower definition than 32-bit floating point. The floating point allows it to "fit" more data into the word limit (but not really). It's kind of like the TARDIS. It's bigger on the inside...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.