This was done before John ffitch (I believe it was he) changed the filter samples in even the single-precision version of Csound to use double-precision. And I think this change may have been made as a result of my report.
Regards, Mike ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Fri, Feb 6, 2015 at 2:04 PM, Victor Lazzarini <victor.lazzar...@nuim.ie> wrote: > Yes, but note that in the case Michael is reporting, all filters have > double-precision coeffs and data storage. It is only when passing samples > between unit generators that the difference lies (either single or > double precision is used). Still, I believe that > there can be audible differences. > > Victor Lazzarini > Dean of Arts, Celtic Studies, and Philosophy > Maynooth University > Ireland > >> On 6 Feb 2015, at 18:43, Ethan Duni <ethan.d...@gmail.com> wrote: >> >> Thanks for the reference Vicki >> >>> What they are hearing is not noise or peaks sitting at the 24th >>> bit but rather the distortion that goes with truncation at 24b, and >>> it is said to have a characteristic coloration effect on sound. I'm >>> aware of an effort to show this with AB/X tests, hopefully it will be >> published. >> >> I'm skeptical, but definitely hope that such a test gets undertaken and >> published. Would be interesting to have some real data either way. >> >>> The problem with failing to dither at 24b is that many such truncation >>> steps would be done routinely in mastering, and thus the truncation >>> distortion products continue to build up. >> >> Hopefully everyone agrees that the questions of what is appropriate for >> intermediate processing and what is appropriate for final distribution are >> quite different, and that substantially higher resolutions (and probably >> including dither) are indicated for intermediate processing. As Michael >> Goggins says: >> >>> In my own work, I have verified with a double-blind ABX comparator at >>> a high degree of statistical significance that I can hear the >>> differences in certain selected portions of the same Csound piece >>> rendered with 32 bit floating point samples versus 64 bit floating >>> point samples. These are sample words used in internal calculations, >>> not for output soundfiles. What I heard was differences in the sound >>> of the same filter algorithm. These differences were not at all hard >>> to hear, but they occurred in only one or two places in the piece. >> >> Indeed, it is not particularly difficult to cook up filter >> designs/algorithms that will break any given finite internal resolution. At >> some point those filter designs become pathological, but there are plenty >> of reasonable cases where 32 bit float internal precision is insufficient. >> Note that a 32-bit float only has 24 bits of mantissa, which is 8 bits less >> than is typically used in embedded fixed-point implementations (for >> sensitive components like filter guts, I mean). So even very standard stuff >> that has been around for decades in the fixed-point world will break if >> implemented naively in 32 bit float. >> >> E >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, dsp >> links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
