Sign in with
Sign up | Sign in
Your question

DAW: floating point vs fixed point calculation

Last response: in Home Audio
Share
Anonymous
21 March 2005 22:35:06

Archived from groups: rec.audio.pro (More info?)

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
Anonymous
22 March 2005 01:43:53

Archived from groups: rec.audio.pro (More info?)

> 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/ultimatebb.cgi?ubb=fo...

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.
Anonymous
22 March 2005 01:48:44

Archived from groups: rec.audio.pro (More info?)

"Harry Houdini" <harry@houdini.com> wrote in message
news:t30u31d48du4ct300ien91gmv67kois61n@4ax.com

> 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?
Related resources
Anonymous
22 March 2005 02:12:35

Archived from groups: rec.audio.pro (More info?)

Harry Houdini <harry@houdini.com> 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
randy.yates@sonyericsson.com, 919-472-1124
Anonymous
22 March 2005 04:15:51

Archived from groups: rec.audio.pro (More info?)

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.
Anonymous
22 March 2005 07:20:11

Archived from groups: rec.audio.pro (More info?)

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
Anonymous
22 March 2005 13:26:17

Archived from groups: rec.audio.pro (More info?)

> That's fine, Lisa. But we're not in math class, we're in the *studio*!

Welcome to the new studio. As if the scientific subtleties of tape are any
less complex or noteworthy.
Anonymous
22 March 2005 16:27:44

Archived from groups: rec.audio.pro (More info?)

"Sugarite" <nobody@home.com> wrote in message
news:srF%d.11594$RM2.10323@read1.cgocable.net...

>...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
22 March 2005 16:56:37

Archived from groups: rec.audio.pro (More info?)

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 - I
haven'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
Anonymous
22 March 2005 17:16:10

Archived from groups: rec.audio.pro (More info?)

"Bob Olhsson" <olh@hyperback.com> wrote in message
news:k1O%d.161282$Th1.13589@bgtnsc04-news.ops.worldnet.att.net
> "Sugarite" <nobody@home.com> wrote in message
> news:srF%d.11594$RM2.10323@read1.cgocable.net...
>
>> ...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?
Anonymous
22 March 2005 18:03:19

Archived from groups: rec.audio.pro (More info?)

genericaudioperson@hotmail.com writes:

> That's fine, Lisa. But we're not in math class, we're in the *studio*!

Ignorance combined with impudence. What a winner.

In future I suggest that, if the material in a post is
incomprehensible to you, you simply ignore it.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124
Anonymous
22 March 2005 20:42:26

Archived from groups: rec.audio.pro (More info?)

"DaveDaveDave" <DaveSheremata@yahoo.com> 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
randy.yates@sonyericsson.com, 919-472-1124
Anonymous
22 March 2005 21:08:41

Archived from groups: rec.audio.pro (More info?)

Randy Yates <randy.yates@sonyericsson.com> wrote:
>"DaveDaveDave" <DaveSheremata@yahoo.com> 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."
Anonymous
22 March 2005 21:19:12

Archived from groups: rec.audio.pro (More info?)

kludge@panix.com (Scott Dorsey) writes:

> Randy Yates <randy.yates@sonyericsson.com> wrote:
> >"DaveDaveDave" <DaveSheremata@yahoo.com> 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
randy.yates@sonyericsson.com, 919-472-1124
Anonymous
22 March 2005 21:39:06

Archived from groups: rec.audio.pro (More info?)

In article <xxpzmwvzp1r.fsf@usrts005.corpusers.net>,
Randy Yates <randy.yates@sonyericsson.com> wrote:
>kludge@panix.com (Scott Dorsey) writes:
>
>> Randy Yates <randy.yates@sonyericsson.com> wrote:
>> >"DaveDaveDave" <DaveSheremata@yahoo.com> 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."
Anonymous
23 March 2005 05:34:34

Archived from groups: rec.audio.pro (More info?)

On 22 Mar 2005 10:19:12 -0500, Randy Yates
<randy.yates@sonyericsson.com> 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 dragonsclawJUNK@JUNKmindspring.com
, / / / Running United Devices "Cure For Cancer" Project 24/7 Have you helped? http://www.grid.org
Anonymous
23 March 2005 17:39:08

Archived from groups: rec.audio.pro (More info?)

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
Anonymous
23 March 2005 18:40:48

Archived from groups: rec.audio.pro (More info?)

"hank alrich" <walkinay@thegrid.net> wrote in message
news:1gtuiq9.1vorrdh1yb78w8N%walkinay@thegrid.net
> 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.
Anonymous
24 March 2005 05:15:50

Archived from groups: rec.audio.pro (More info?)

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
Anonymous
24 March 2005 05:15:51

Archived from groups: rec.audio.pro (More info?)

"hank alrich" <walkinay@thegrid.net> wrote in message
news:1gtvgch.ihdvxpf3k0aaN%walkinay@thegrid.net
> 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".
Anonymous
24 March 2005 08:17:19

Archived from groups: rec.audio.pro (More info?)

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
<randy.yates@sonyericsson.com> wrote:

>Harry Houdini <harry@houdini.com> 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.
Anonymous
24 March 2005 08:20:13

Archived from groups: rec.audio.pro (More info?)

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
<lshaw-usenet@austin.rr.com> 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
Anonymous
24 March 2005 19:56:22

Archived from groups: rec.audio.pro (More info?)

"Harry Houdini" <harry@houdini.com> wrote in message
news:mg84415v9qlnnrlv8lrotut4ad00rr7dj3@4ax.com
> 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.
Anonymous
24 March 2005 21:17:39

Archived from groups: rec.audio.pro (More info?)

Harry Houdini <harry@houdini.com> 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
randy.yates@sonyericsson.com, 919-472-1124
Anonymous
25 March 2005 00:46:55

Archived from groups: rec.audio.pro (More info?)

On 22 Mar 2005 10:39:06 -0500, kludge@panix.com (Scott Dorsey) wrote:

>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!

This is audio group. Take your amateur radio operater mumbo jumbo
elsewhere.
Anonymous
28 March 2005 20:40:20

Archived from groups: rec.audio.pro (More info?)

Here's another paper favoring fixed point:

http://www.jamminpower.com/main/articles.jsp


On 24 Mar 2005 10:17:39 -0500, Randy Yates
<randy.yates@sonyericsson.com> wrote:

>Harry Houdini <harry@houdini.com> 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.
Anonymous
29 March 2005 09:57:00

Archived from groups: rec.audio.pro (More info?)

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
Anonymous
29 March 2005 09:57:01

Archived from groups: rec.audio.pro (More info?)

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).