http://www.jamminpower.com/PDF/48-bit%20Audio.pdf I suspect he's describing a non-problem, or a problem in pretty extreme corner cases. -- Les Cargill
I can't tell what this guy is on about.
Started by ●April 25, 2015
Reply by ●April 26, 20152015-04-26
On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill <lcargill99@comcast.com> wrote:>http://www.jamminpower.com/PDF/48-bit%20Audio.pdf > >I suspect he's describing a non-problem, or a problem in pretty >extreme corner cases.Actually, no. I only skimmed the article, but it appears that Moorer is advocating not 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the 48/56-bit internal architecture of the Motorola/Freescale/whatever DSP56K.) That double-precision integer processing is superior to single-precision floating point processing has been known for a very long time. In fact, back in 1995 I proved it in an internal memo for my employer at the time: I simulated the same set of filters, implemented in both 32-bit float and 48/56-bit integer, and the integer implementation performed better, particularly in terms of dynamic range. To be fair, the integer implementation was highly optimized while the floating point implementation was unoptimized (i.e., without any regard to such things as the order-of-operations problems that occur when adding multiple floating point numbers of wide-ranging magnitudes). But it did prove that making a switch to floating point, at least to single-precision floating point, while allowing one to avoid overflow and underflow problems, does not necessarily improve audio performance.
Reply by ●April 26, 20152015-04-26
Greg Berchin wrote:> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill <lcargill99@comcast.com> > wrote: > >> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf >> >> I suspect he's describing a non-problem, or a problem in pretty >> extreme corner cases. > > Actually, no. > > I only skimmed the article, but it appears that Moorer is advocating not > 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the > 48/56-bit internal architecture of the Motorola/Freescale/whatever > DSP56K.) That double-precision integer processing is superior to > single-precision floating point processing has been known for a very > long time. In fact, back in 1995 I proved it in an internal memo for my > employer at the time: I simulated the same set of filters, implemented > in both 32-bit float and 48/56-bit integer, and the integer > implementation performed better, particularly in terms of dynamic range. > > To be fair, the integer implementation was highly optimized while the > floating point implementation was unoptimized (i.e., without any regard > to such things as the order-of-operations problems that occur when > adding multiple floating point numbers of wide-ranging magnitudes). But > it did prove that making a switch to floating point, at least to > single-precision floating point, while allowing one to avoid overflow > and underflow problems, does not necessarily improve audio performance. >I got this off Facebook, and somebody came up with exactly the same explanation as you did - it's about the DPS56K. Turns out the paper is 20 years old. Thanks! -- Les Cargill
Reply by ●April 26, 20152015-04-26
On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote:> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill <lcargill99@comcast.com> > wrote: > >>http://www.jamminpower.com/PDF/48-bit%20Audio.pdf >> >>I suspect he's describing a non-problem, or a problem in pretty extreme >>corner cases. > > Actually, no. > > I only skimmed the article, but it appears that Moorer is advocating not > 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the > 48/56-bit internal architecture of the Motorola/Freescale/whatever > DSP56K.) That double-precision integer processing is superior to > single-precision floating point processing has been known for a very > long time. In fact, back in 1995 I proved it in an internal memo for my > employer at the time: I simulated the same set of filters, implemented > in both 32-bit float and 48/56-bit integer, and the integer > implementation performed better, particularly in terms of dynamic range. > > To be fair, the integer implementation was highly optimized while the > floating point implementation was unoptimized (i.e., without any regard > to such things as the order-of-operations problems that occur when > adding multiple floating point numbers of wide-ranging magnitudes). But > it did prove that making a switch to floating point, at least to > single-precision floating point, while allowing one to avoid overflow > and underflow problems, does not necessarily improve audio performance.Using floating point doesn't allow you to avoid overflow and underflow problems; it just masks them in hard-to-find ways. I warn about this in my controls book, and give some tools to figure out what's going on. For DSP, if precision matters then carefully crafted code with 32-bit integers is going to be better than anything you could do with 32-bit floating point. 48-bit integers would just make it betterer. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●April 26, 20152015-04-26
On 4/26/15 8:01 PM, Tim Wescott wrote:> On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote: > >> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill<lcargill99@comcast.com> >> wrote: >> >>> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf >>> >>> I suspect he's describing a non-problem, or a problem in pretty extreme >>> corner cases. >> >> Actually, no. >> >> I only skimmed the article, but it appears that Moorer is advocating not >> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the >> 48/56-bit internal architecture of the Motorola/Freescale/whatever >> DSP56K.) That double-precision integer processing is superior to >> single-precision floating point processing has been known for a very >> long time. In fact, back in 1995 I proved it in an internal memo for my >> employer at the time: I simulated the same set of filters, implemented >> in both 32-bit float and 48/56-bit integer, and the integer >> implementation performed better, particularly in terms of dynamic range. >> >> To be fair, the integer implementation was highly optimized while the >> floating point implementation was unoptimized (i.e., without any regard >> to such things as the order-of-operations problems that occur when >> adding multiple floating point numbers of wide-ranging magnitudes). But >> it did prove that making a switch to floating point, at least to >> single-precision floating point, while allowing one to avoid overflow >> and underflow problems, does not necessarily improve audio performance. > > Using floating point doesn't allow you to avoid overflow and underflow > problems; it just masks them in hard-to-find ways. > > I warn about this in my controls book, and give some tools to figure out > what's going on. > > For DSP, if precision matters then carefully crafted code with 32-bit > integers is going to be better than anything you could do with 32-bit > floating point. 48-bit integers would just make it betterer.here's a little more of interest regarding the same author (Andy Moorer). he was sorta the subject of this recent NPR All Things Considered story 2 weeks ago: http://www.npr.org/2015/04/11/399034279/know-that-thx-sound-before-movies-thats-actually-20-000-lines-of-code i didn't know this until this story that Andy was the guy who created that ubiquitous and annoying monster THX sound at the beginning of movies. same guy. i think i did a better job (in 2008 http://www.aes.org/events/125/tutorials/session.cfm?code=T19 ) than Andy regarding the float vs. fixed-point issue. i tried comparing apples to apples, where the word size was the same for float and fixed. comparing 32-bit IEEE-748 float (with 8 exponent bits) to 32-bit fixed, you would have to require a 40 dB headroom (or more) in order for floating-point samples to have better S/N ratio than with fixed. i have seen a special in-house implementation of floating point (non-IEEE) with 5 exponent bits and that seems about optimum for audio. otherwise fixed point is better given limited bits in the word width, as long as you're willing to pay a little attention to where the rails are. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●April 27, 20152015-04-27
robert bristow-johnson <rbj@audioimagination.com> writes:> On 4/26/15 8:01 PM, Tim Wescott wrote: >> On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote: >> >>> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill<lcargill99@comcast.com> >>> wrote: >>> >>>> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf >>>> >>>> I suspect he's describing a non-problem, or a problem in pretty extreme >>>> corner cases. >>> >>> Actually, no. >>> >>> I only skimmed the article, but it appears that Moorer is advocating not >>> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the >>> 48/56-bit internal architecture of the Motorola/Freescale/whatever >>> DSP56K.) That double-precision integer processing is superior to >>> single-precision floating point processing has been known for a very >>> long time. In fact, back in 1995 I proved it in an internal memo for my >>> employer at the time: I simulated the same set of filters, implemented >>> in both 32-bit float and 48/56-bit integer, and the integer >>> implementation performed better, particularly in terms of dynamic range. >>> >>> To be fair, the integer implementation was highly optimized while the >>> floating point implementation was unoptimized (i.e., without any regard >>> to such things as the order-of-operations problems that occur when >>> adding multiple floating point numbers of wide-ranging magnitudes). But >>> it did prove that making a switch to floating point, at least to >>> single-precision floating point, while allowing one to avoid overflow >>> and underflow problems, does not necessarily improve audio performance. >> >> Using floating point doesn't allow you to avoid overflow and underflow >> problems; it just masks them in hard-to-find ways. >> >> I warn about this in my controls book, and give some tools to figure out >> what's going on. >> >> For DSP, if precision matters then carefully crafted code with 32-bit >> integers is going to be better than anything you could do with 32-bit >> floating point. 48-bit integers would just make it betterer. > > > here's a little more of interest regarding the same author (Andy > Moorer). he was sorta the subject of this recent NPR All Things > Considered story 2 weeks ago: > http://www.npr.org/2015/04/11/399034279/know-that-thx-sound-before-movies-thats-actually-20-000-lines-of-code > > > i didn't know this until this story that Andy was the guy who created > that ubiquitous and annoying monster THX sound at the beginning of > movies. > > same guy. > > i think i did a better job (in 2008 > http://www.aes.org/events/125/tutorials/session.cfm?code=T19 ) than > Andy regarding the float vs. fixed-point issue. i tried comparing > apples to apples, where the word size was the same for float and > fixed. comparing 32-bit IEEE-748 float (with 8 exponent bits) to > 32-bit fixed, you would have to require a 40 dB headroom (or more) in > order for floating-point samples to have better S/N ratio than with > fixed. i have seen a special in-house implementation of floating > point (non-IEEE) with 5 exponent bits and that seems about optimum for > audio. otherwise fixed point is better given limited bits in the word > width, as long as you're willing to pay a little attention to where > the rails are.Robert, Was there a preprint or other document associated with that tutorial? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●April 27, 20152015-04-27
On 4/26/15 11:17 PM, Randy Yates wrote:> robert bristow-johnson<rbj@audioimagination.com> writes: > >> On 4/26/15 8:01 PM, Tim Wescott wrote: >>> On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote: >>> >>>> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill<lcargill99@comcast.com> >>>> wrote: >>>> >>>>> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf >>>>> >>>>> I suspect he's describing a non-problem, or a problem in pretty extreme >>>>> corner cases. >>>> >>>> Actually, no. >>>> >>>> I only skimmed the article, but it appears that Moorer is advocating not >>>> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the >>>> 48/56-bit internal architecture of the Motorola/Freescale/whatever >>>> DSP56K.) That double-precision integer processing is superior to >>>> single-precision floating point processing has been known for a very >>>> long time. In fact, back in 1995 I proved it in an internal memo for my >>>> employer at the time: I simulated the same set of filters, implemented >>>> in both 32-bit float and 48/56-bit integer, and the integer >>>> implementation performed better, particularly in terms of dynamic range. >>>> >>>> To be fair, the integer implementation was highly optimized while the >>>> floating point implementation was unoptimized (i.e., without any regard >>>> to such things as the order-of-operations problems that occur when >>>> adding multiple floating point numbers of wide-ranging magnitudes). But >>>> it did prove that making a switch to floating point, at least to >>>> single-precision floating point, while allowing one to avoid overflow >>>> and underflow problems, does not necessarily improve audio performance. >>> >>> Using floating point doesn't allow you to avoid overflow and underflow >>> problems; it just masks them in hard-to-find ways. >>> >>> I warn about this in my controls book, and give some tools to figure out >>> what's going on. >>> >>> For DSP, if precision matters then carefully crafted code with 32-bit >>> integers is going to be better than anything you could do with 32-bit >>> floating point. 48-bit integers would just make it betterer. >> >> >> here's a little more of interest regarding the same author (Andy >> Moorer). he was sorta the subject of this recent NPR All Things >> Considered story 2 weeks ago: >> http://www.npr.org/2015/04/11/399034279/know-that-thx-sound-before-movies-thats-actually-20-000-lines-of-code >> >> >> i didn't know this until this story that Andy was the guy who created >> that ubiquitous and annoying monster THX sound at the beginning of >> movies. >> >> same guy. >> >> i think i did a better job (in 2008 >> http://www.aes.org/events/125/tutorials/session.cfm?code=T19 ) than >> Andy regarding the float vs. fixed-point issue. i tried comparing >> apples to apples, where the word size was the same for float and >> fixed. comparing 32-bit IEEE-748 float (with 8 exponent bits) to >> 32-bit fixed, you would have to require a 40 dB headroom (or more) in >> order for floating-point samples to have better S/N ratio than with >> fixed. i have seen a special in-house implementation of floating >> point (non-IEEE) with 5 exponent bits and that seems about optimum for >> audio. otherwise fixed point is better given limited bits in the word >> width, as long as you're willing to pay a little attention to where >> the rails are. > > Robert, > > Was there a preprint or other document associated with that tutorial?hi Randy, if your address is correct (i check with previous email), i can send you the powerpoint, including the soundfiles that went with it. expect a big turd in your Inbox. i think i might have it all zipped up somewhere. and likewise for anyone else interested. just lemme know. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
