| Home |
| Search |
| Today's Posts |
|
#1
|
|||
|
|||
DAW: floating point vs fixed point calculation
Hey!
From what I've been reading, (The Art of Digital Audio, Mastering Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs" on Rane's website), there appears to be little doubt that as far as audio is concerned, fixed point calculations are superior to floating point calculations. 32-bit floating point predominates in our industry (Protools, Nuendo, DP, etc) because the calculations are cheaper to achieve from ready-made chips. Fixed point calculations are superior (i.e., more accurate), leave nothing for the chip to assume, but have *a lot* more work involved from the developer's point of view. Very expensive.The problem is, who makes software that works at fixed 40 bit, or even double-precision 24 bit? I don't know of any. __________________________________________________ _____ As an example of 32 bit inaccuracies, create a stereo 96-24 1Khz sine wave - say five seconds. Create another one 180 degrees out of phase. Import them into separate tracks your 32 bit DAW (let it convert the 24-bit files to 32) then play. If all goes well, then you should hear nothing. Now export both the in-phase waveform and the out-of-phase tracks from your DAW - separately, of course. Reimport them to separate tracks again. Mute the originals. Play. In Nuendo 2.2, at least, the result is no longer zero. The result of 32 bit rounding? Harry |
|
#2
|
|||
|
|||
|
From what I've been reading, (The Art of Digital Audio, Mastering
Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs" on Rane's website), there appears to be little doubt that as far as audio is concerned, fixed point calculations are superior to floating point calculations. 32-bit floating point predominates in our industry (Protools, Nuendo, DP, etc) because the calculations are cheaper to achieve from ready-made chips. Fixed point calculations are superior (i.e., more accurate), leave nothing for the chip to assume, but have *a lot* more work involved from the developer's point of view. Very expensive.The problem is, who makes software that works at fixed 40 bit, or even double-precision 24 bit? I don't know of any. __________________________________________________ _____ As an example of 32 bit inaccuracies, create a stereo 96-24 1Khz sine wave - say five seconds. Create another one 180 degrees out of phase. Import them into separate tracks your 32 bit DAW (let it convert the 24-bit files to 32) then play. If all goes well, then you should hear nothing. Now export both the in-phase waveform and the out-of-phase tracks from your DAW - separately, of course. Reimport them to separate tracks again. Mute the originals. Play. In Nuendo 2.2, at least, the result is no longer zero. The result of 32 bit rounding? Probably it's a faulty inversion plug-in, but there's also the 1-bit-sample offset from having an even number of possible sample values (no exact center). There has been a reasonably comprehensive study of many types of summing buses, analog and digital, and there were over 10 32-bit floating-point digital summing engines that rendered identical results despite being different software from different developers on entirely different platforms. Either they all made the exact same mistakes, or they are dead accurate. There was an error produced by the Digidesign inversion plug-in (TDM) that was caught midway through testing. It's something of a mess to follow, but here's the forum: http://www.3daudioinc.com/cgi-bin/ul...ubb=forum&f=19 The way I see it, if a summing engine can be accurate, any errors from plug-ins are the result of poor design, and not the type of processing itself. |
|
#3
|
|||
|
|||
|
"Harry Houdini" wrote in message
From what I've been reading, (The Art of Digital Audio, Mastering Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs" on Rane's website), there appears to be little doubt that as far as audio is concerned, fixed point calculations are superior to floating point calculations. At the 32 bit level, we've got a clear case of dueling moot points. 32-bit floating point predominates in our industry (Protools, Nuendo, DP, etc) because the calculations are cheaper to achieve from ready-made chips. Fixed point calculations are superior (i.e., more accurate), leave nothing for the chip to assume, but have *a lot* more work involved from the developer's point of view. Very expensive.The problem is, who makes software that works at fixed 40 bit, or even double-precision 24 bit? I don't know of any. Double=-precision 24 bit? That puts spurious responses more than 280 dB down. Why should *anybody* doing audio care? As an example of 32 bit inaccuracies, create a stereo 96-24 1Khz sine wave - say five seconds. Create another one 180 degrees out of phase. Import them into separate tracks your 32 bit DAW (let it convert the 24-bit files to 32) then play. If all goes well, then you should hear nothing. Yup, here's your chance to obsess over possible spurious responses that are more than 140 dB down. Now export both the in-phase waveform and the out-of-phase tracks from your DAW - separately, of course. Reimport them to separate tracks again. Mute the originals. Play. In Nuendo 2.2, at least, the result is no longer zero. The result of 32 bit rounding? Why should anybody in their right mind care about spurious responses that are more than 140 dB down? |
|
#4
|
|||
|
|||
|
Harry Houdini writes:
Hey! From what I've been reading, (The Art of Digital Audio, Mastering Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs" on Rane's website), there appears to be little doubt that as far as audio is concerned, fixed point calculations are superior to floating point calculations. 32-bit floating point predominates in our industry (Protools, Nuendo, DP, etc) because the calculations are cheaper to achieve from ready-made chips. "Cheaper to achieve from ready-made chips"? I'm not sure what that means, but floating-point hardware (either processors or discrete hardware) is more expensive, in power consumption, board size, and cost, than fixed-point. The labor to program them, however, is less expensive. It takes less knowledge. Fixed point calculations are superior (i.e., more accurate), leave nothing for the chip to assume, but have *a lot* more work involved from the developer's point of view. Very expensive. Oh it's not really THAT much more work, but you do have to know what you're doing. The problem you're probably referring to results when performing MACs (multiply-accumulates): y[n] = sum_{m = 0}^{M-1} x[n - m] * h[m]. Since most fixed-point digital signal processors have wide accumulators, the entire MAC can be performed at full-precision without overflow. Only the final store to lower-resolution memory has to be requantized. For example, the TI 54x fixed-point DSPs have a 40-bit accumulator and a 16-bit data path. Thus you can accumulate 256 samples (e.g., perform a 256-tap FIR filter) before even beginning to think about overflowing. Contrast this to floating-point in which each and every multiplication result is requantized before being added. For a single-precision floating point, the mantissa requantization is back to 24 bits for each addition. The problem is, who makes software that works at fixed 40 bit, or even double-precision 24 bit? I don't know of any. Why do you think you need 40 bits? 32 bits is 192 dB dynamic range. Even with the degradation from multiple stages of processing, you're probably well-above 24 bit final SNR. -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA , 919-472-1124 |
|
#5
|
|||
|
|||
|
Harry Houdini wrote:
From what I've been reading, (The Art of Digital Audio, Mastering Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs" on Rane's website), there appears to be little doubt that as far as audio is concerned, fixed point calculations are superior to floating point calculations. 32-bit floating point predominates in our industry (Protools, Nuendo, DP, etc) because the calculations are cheaper to achieve from ready-made chips. Fixed point calculations are superior (i.e., more accurate), leave nothing for the chip to assume, but have *a lot* more work involved from the developer's point of view. Not necessarily. A few months ago, I ported a bitmap image resizing program from one platform to another, and the platform I ported it to does not really have floating point available. So, I used fixed point instead. I wrote a little tiny library to do fixed point calculations (addition, multiplication, etc., etc.), and it all worked out fine. In fact, writing the library to do 32-bit fixed point (24-bit integer and 8-bit fraction) was really easy, and it only took me 2 or 3 hours. It is more difficult to work with fixed point for one reason, though: you have to be very careful to avoid overflow and underflow. With floating point, this is taken care of for you automatically, and unless you go to astronomically large or small values, you don't lose precision unless it's really necessary. So, in that sense, floating point is easier. However, with audio, it seems like it shouldn't be all that hard to keep things in the right ranges, because the values are always in generall the same range. However, if there's any validity to the idea that 32-bit floating point isn't accurate enough, then with today's hardware there is an obvious solution that will take care of that problem quite handily. Virtually all processors these days support IEEE double precision floating point, which gives 11 bits for the exponent and 52 bits for the mantissa plus one bit for the sign. Since the sign can be counted as part of the signal if you want, that means 53 bits of precision. 53 bits ought to be enough for audio. - Logan |
|
#6
|
|||
|
|||
|
That's fine, Lisa. But we're not in math class, we're in the *studio*!
quote: The problem you're probably referring to results when performing MACs (multiply-accumulates): y[n] = sum_{m = 0}^{M-1} x[n - m] * h[m]. Since most fixed-point digital signal processors have wide accumulators, the entire MAC can be performed at full-precision without overflow. Only the final store to lower-resolution memory has to be requantized. For example, the TI 54x fixed-point DSPs have a 40-bit accumulator and a 16-bit data path. Thus you can accumulate 256 samples (e.g., perform a 256-tap FIR filter) before even beginning to think about overflowing. Contrast this to floating-point in which each and every multiplication result is requantized before being added. For a single-precision floating point, the mantissa requantization is back to 24 bits for each addition. |
|
#7
|
|||
|
|||
|
"Sugarite" wrote in message
... ...there were over 10 32-bit floating-point digital summing engines that rendered identical results despite being different software from different developers on entirely different platforms. We weren't performing any multiplys in that test, just addition so the rounding could still easily be screwed up in some of them. There are also lots of double precision fixed and floating point applications which includes most of the better sounding stuff. -- Bob Olhsson Audio Mastery, Nashville TN Mastering, Audio for Picture, Mix Evaluation and Quality Control Over 40 years making people sound better than they ever imagined! 615.385.8051 http://www.hyperback.com |
|
#8
|
|||
|
|||
|
"Bob Olhsson" wrote in message
"Sugarite" wrote in message ... ...there were over 10 32-bit floating-point digital summing engines that rendered identical results despite being different software from different developers on entirely different platforms. We weren't performing any multiplys in that test, just addition so the rounding could still easily be screwed up in some of them. There are also lots of double precision fixed and floating point applications which includes most of the better sounding stuff. How can the LSB of a 24 or 32 bit number affect sound quality when there's all that real-world noise swamping it out? |
|
#10
|
|||
|
|||
|
I agree - It is funny how people will go on about stuff that bats and
dogs can't ever hear. There is something screwy though with FP math in DAW these days though - and you CAN here it  ... The dreaded denormalization bug - Ihaven't followed it that much because thankfully I use a minimal amount of plugins, but here goes. Basically when the FPU part of PIVs and some AMD chips deal with really really tiny floating point numbers - like the kind that DSP algorithms generate as they dither on the edge of silence), the CPUs freak out and throttle as they try to process the data down there at the -192db level.... all that your ears could never process. The result? All the throttiling can overcome your audio interrupt handling and bring up the nasty clicky-poppy-dropouts. Ick. It just kinda makes me laugh... ah. It's like a tape machine that only overheats when there's no signal into it... Anyway, the moral is, if we'd only had 32bits of integer data instead, none of this would have ever happened. Ok, ok, bad stuff would have heppened, just different bad stuff... Ok,ok, that's no moral, is it? Cheers, Dave |
|
#11
|
|||
|
|||
|
"DaveDaveDave" writes:
[...] Anyway, the moral is, if we'd only had 32bits of integer data instead, I propose a new, sane standard: 32 bits and 64 kHz. -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA , 919-472-1124 |
|
#12
|
|||
|
|||
|
Randy Yates wrote:
"DaveDaveDave" writes: [...] Anyway, the moral is, if we'd only had 32bits of integer data instead, I propose a new, sane standard: 32 bits and 64 kHz. Not enough. I want to record my 455 KC IF from the radio directly. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
|
#13
|
|||
|
|||
|
(Scott Dorsey) writes:
Randy Yates wrote: "DaveDaveDave" writes: [...] Anyway, the moral is, if we'd only had 32bits of integer data instead, I propose a new, sane standard: 32 bits and 64 kHz. Not enough. I want to record my 455 KC IF from the radio directly. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." But of course. How about 32 bits and 10 GHz. This should allow direct conversion of WiFi, CDMA, and other lesser comm signals. -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA , 919-472-1124 |
|
#14
|
|||
|
|||
|
In article ,
Randy Yates wrote: (Scott Dorsey) writes: Randy Yates wrote: "DaveDaveDave" writes: [...] Anyway, the moral is, if we'd only had 32bits of integer data instead, I propose a new, sane standard: 32 bits and 64 kHz. Not enough. I want to record my 455 KC IF from the radio directly. But of course. How about 32 bits and 10 GHz. This should allow direct conversion of WiFi, CDMA, and other lesser comm signals. That would be a violation of the ECPA, though! Wideband recording is illegal without notch filtering 800 MHz! --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
|
#15
|
|||
|
|||
|
On 22 Mar 2005 10:19:12 -0500, Randy Yates
wrote: I want to record my 455 KC You just dated yourself G IF from the radio directly. , _ , | \ MKA: Steve Urbach , | )erek No JUNK in my email please , ____|_/ragonsclaw , / / / Running United Devices "Cure For Cancer" Project 24/7 Have you helped? http://www.grid.org |
|
#16
|
|||
|
|||
|
Arny Krueger wrote:
Double=-precision 24 bit? That puts spurious responses more than 280 dB down. Why should *anybody* doing audio care? j Because they can! /j -- ha |
|
#17
|
|||
|
|||
|
"hank alrich" wrote in message
Arny Krueger wrote: Double=-precision 24 bit? That puts spurious responses more than 280 dB down. Why should *anybody* doing audio care? j Because they can! /j Agreed. Also, because they can write pompous technical papers about the differences. |
|
#18
|
|||
|
|||
|
Arny Krueger wrote:
"hank alrich" wrote Arny Krueger wrote: Double=-precision 24 bit? That puts spurious responses more than 280 dB down. Why should *anybody* doing audio care? j Because they can! /j Agreed. Also, because they can write pompous technical papers about the differences. Now you've gone all technical on me, selling advertising and stuff. g Meanwhile, the noisefloor of the ads is astonishing. -- ha |
|
#19
|
|||
|
|||
|
"hank alrich" wrote in message
Arny Krueger wrote: "hank alrich" wrote Arny Krueger wrote: Double=-precision 24 bit? That puts spurious responses more than 280 dB down. Why should *anybody* doing audio care? j Because they can! /j Agreed. Also, because they can write pompous technical papers about the differences. Now you've gone all technical on me, selling advertising and stuff. g Meanwhile, the noisefloor of the ads is astonishing. ....giving rise to the new spec: "noise to signal ratio". |
|
#20
|
|||
|
|||
|
Randy,
Thank you so much for your thoughtful and generous response. My reason for asking about high-resolution fixed point processing comes from the information in the articles I mentioned; apparently, floating point rounding or requantization - as you call it - has a significant impact to frequencies in the lower end of the spectrum: frequencies less than 800 Hz, I believe. As far as you know - which seems to be a lot more than me - is this a fact? Harry On 21 Mar 2005 15:12:35 -0500, Randy Yates wrote: Harry Houdini writes: Hey! From what I've been reading, (The Art of Digital Audio, Mastering Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs" on Rane's website), there appears to be little doubt that as far as audio is concerned, fixed point calculations are superior to floating point calculations. 32-bit floating point predominates in our industry (Protools, Nuendo, DP, etc) because the calculations are cheaper to achieve from ready-made chips. "Cheaper to achieve from ready-made chips"? I'm not sure what that means, but floating-point hardware (either processors or discrete hardware) is more expensive, in power consumption, board size, and cost, than fixed-point. The labor to program them, however, is less expensive. It takes less knowledge. Fixed point calculations are superior (i.e., more accurate), leave nothing for the chip to assume, but have *a lot* more work involved from the developer's point of view. Very expensive. Oh it's not really THAT much more work, but you do have to know what you're doing. The problem you're probably referring to results when performing MACs (multiply-accumulates): y[n] = sum_{m = 0}^{M-1} x[n - m] * h[m]. Since most fixed-point digital signal processors have wide accumulators, the entire MAC can be performed at full-precision without overflow. Only the final store to lower-resolution memory has to be requantized. For example, the TI 54x fixed-point DSPs have a 40-bit accumulator and a 16-bit data path. Thus you can accumulate 256 samples (e.g., perform a 256-tap FIR filter) before even beginning to think about overflowing. Contrast this to floating-point in which each and every multiplication result is requantized before being added. For a single-precision floating point, the mantissa requantization is back to 24 bits for each addition. The problem is, who makes software that works at fixed 40 bit, or even double-precision 24 bit? I don't know of any. Why do you think you need 40 bits? 32 bits is 192 dB dynamic range. Even with the degradation from multiple stages of processing, you're probably well-above 24 bit final SNR. |
|
#21
|
|||
|
|||
|
Logan,
Really appreciate your input here. Thanks. Is there any truth to the claim that the floating rounding operations or requantization - as Randy put it earlier in the thread - adversely affect the lower frequencies? (See the sources I mention) Harry On Mon, 21 Mar 2005 20:20:11 GMT, Logan Shaw wrote: Harry Houdini wrote: From what I've been reading, (The Art of Digital Audio, Mastering Audio, and Greg Duckett's "Superior Audio Requires Fixed-Point DSPs" on Rane's website), there appears to be little doubt that as far as audio is concerned, fixed point calculations are superior to floating point calculations. 32-bit floating point predominates in our industry (Protools, Nuendo, DP, etc) because the calculations are cheaper to achieve from ready-made chips. Fixed point calculations are superior (i.e., more accurate), leave nothing for the chip to assume, but have *a lot* more work involved from the developer's point of view. Not necessarily. A few months ago, I ported a bitmap image resizing program from one platform to another, and the platform I ported it to does not really have floating point available. So, I used fixed point instead. I wrote a little tiny library to do fixed point calculations (addition, multiplication, etc., etc.), and it all worked out fine. In fact, writing the library to do 32-bit fixed point (24-bit integer and 8-bit fraction) was really easy, and it only took me 2 or 3 hours. It is more difficult to work with fixed point for one reason, though: you have to be very careful to avoid overflow and underflow. With floating point, this is taken care of for you automatically, and unless you go to astronomically large or small values, you don't lose precision unless it's really necessary. So, in that sense, floating point is easier. However, with audio, it seems like it shouldn't be all that hard to keep things in the right ranges, because the values are always in generall the same range. However, if there's any validity to the idea that 32-bit floating point isn't accurate enough, then with today's hardware there is an obvious solution that will take care of that problem quite handily. Virtually all processors these days support IEEE double precision floating point, which gives 11 bits for the exponent and 52 bits for the mantissa plus one bit for the sign. Since the sign can be counted as part of the signal if you want, that means 53 bits of precision. 53 bits ought to be enough for audio. - Logan |
|
#22
|
|||
|
|||
|
|
|
#23
|
|||
|
|||
|
"Harry Houdini" wrote in message
Randy, Thank you so much for your thoughtful and generous response. My reason for asking about high-resolution fixed point processing comes from the information in the articles I mentioned; apparently, floating point rounding or requantization - as you call it - has a significant impact to frequencies in the lower end of the spectrum: frequencies less than 800 Hz, I believe. As far as you know - which seems to be a lot more than me - is this a fact? Rounding error associated with processing complex broadband waveforms is itself broadband. IOW, its not limited to just a certain part or parts of the frequency spectrum. One of the components is the sampling rate, which is of course outside the band. |
|
#24
|
|||
|
|||
|
Harry Houdini writes:
Randy, Thank you so much for your thoughtful and generous response. My reason for asking about high-resolution fixed point processing comes from the information in the articles I mentioned; apparently, floating point rounding or requantization - as you call it - has a significant impact to frequencies in the lower end of the spectrum: frequencies less than 800 Hz, I believe. As far as you know - which seems to be a lot more than me - is this a fact? Harry, I haven't analyzed, or read of any analysis, (at least that I can remember) on the quantization noise spectrum of floating-point quantizations. But, if it is like fixed-point (and that could be a very big "if"), it is highly signal-dependent. For fixed-point quantizations, the quantization noise can vary between highly correlated (for clean, periodic inputs such as a clinical sine wave), to random (for "sufficiently complex" input signals). In neither case, however (again, this is for fixed-point quantization), is the quantization spectrum constrained to be predominately in any specific band of frequencies. Finally, once again, that is "if" floating-point requantization is like fixed-point. -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA , 919-472-1124 |
|
#25
|
|||
|
|||
|
Here's another paper favoring fixed point:
http://www.jamminpower.com/main/articles.jsp On 24 Mar 2005 10:17:39 -0500, Randy Yates wrote: Harry Houdini writes: Randy, Thank you so much for your thoughtful and generous response. My reason for asking about high-resolution fixed point processing comes from the information in the articles I mentioned; apparently, floating point rounding or requantization - as you call it - has a significant impact to frequencies in the lower end of the spectrum: frequencies less than 800 Hz, I believe. As far as you know - which seems to be a lot more than me - is this a fact? Harry, I haven't analyzed, or read of any analysis, (at least that I can remember) on the quantization noise spectrum of floating-point quantizations. But, if it is like fixed-point (and that could be a very big "if"), it is highly signal-dependent. For fixed-point quantizations, the quantization noise can vary between highly correlated (for clean, periodic inputs such as a clinical sine wave), to random (for "sufficiently complex" input signals). In neither case, however (again, this is for fixed-point quantization), is the quantization spectrum constrained to be predominately in any specific band of frequencies. Finally, once again, that is "if" floating-point requantization is like fixed-point. |
|
#26
|
|||
|
|||
|
Harry Houdini wrote:
Here's another paper favoring fixed point: http://www.jamminpower.com/main/articles.jsp Are you referring to the one titled "48-BIT INTEGER PROCESSING BEATS 32-BIT FLOATING POINT FOR PROFESSIONAL AUDIO APPLICATIONS"? That sort of only stands to reason. I bet 64-bit floating point would beat 48-bit integer too. And 48-bit integer probably also beats 32-bit integer. And 64-bit floating point probably beats 32-bit floating point. Also, 48-bit integer probably does NOT beat 32-bit floating point if you don't watch your ranges and you only end up using 16 bits of your 48 because the upper 32 are all zero. With 32-bit IEEE floating point, you have only 24 bits of mantissa. If you are eventually converting to 24 bit integer at the end, it's definitely possible you could loose some precision that could be detected even in the finished product. OF COURSE 48-bit won't suffer from that (unless you really screw up) since its integer part is twice as many bits as 24. Floating point is not magic. You only get as much true precision as the mantissa allows for. Just because 32-bit floating point has a wider range of possible values than 32-bit integer does not mean you are getting something for nothing with 32-bit floating point. - Logan |
|
#27
|
|||
|
|||
|
Logan Shaw wrote:
Harry Houdini wrote: Here's another paper favoring fixed point: http://www.jamminpower.com/main/articles.jsp Are you referring to the one titled "48-BIT INTEGER PROCESSING BEATS 32-BIT FLOATING POINT FOR PROFESSIONAL AUDIO APPLICATIONS"? That sort of only stands to reason. I bet 64-bit floating point would beat 48-bit integer too. And 48-bit integer probably also beats 32-bit integer. And 64-bit floating point probably beats 32-bit floating point. Also, 48-bit integer probably does NOT beat 32-bit floating point if you don't watch your ranges and you only end up using 16 bits of your 48 because the upper 32 are all zero. With 32-bit IEEE floating point, you have only 24 bits of mantissa. If you are eventually converting to 24 bit integer at the end, it's definitely possible you could loose some precision that could be detected even in the finished product. OF COURSE 48-bit won't suffer from that (unless you really screw up) since its integer part is twice as many bits as 24. Floating point is not magic. You only get as much true precision as the mantissa allows for. Just because 32-bit floating point has a wider range of possible values than 32-bit integer does not mean you are getting something for nothing with 32-bit floating point. And AFAICT, the effects of rounding/truncation (as opposed to dithered bit reduction) when floats are de-normalized in preparation for, say, addition/subtraction are completely unknown. As are the effects of normalization after multiplication/division (or after a carry or borrow). |
| Reply |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Forum | |||
| What are they Teaching | Audio Opinions | |||
| Improved AM Detector | Vacuum Tubes | |||
| point to point wiring | Vacuum Tubes | |||
Linear Mode
