Re: [Flac-dev] Support for CAF in flac command-line?
Brian Willoughby wrote: > > On Mar 6, 2011, at 01:22, Erik de Castro Lopo wrote: > > Brian Willoughby wrote: > >> Hopefully, libsndfile no longer uses the incorrect 0x7FFF (32767) > >> factor for float to 16-bit integer conversions, because that would > >> make it unacceptable for lossless file conversions. > > > > That is a statement of opinion rather than fact but I won't go into > > that here. > > > It is a statement of mathematical fact, not opinion. There are at least three different suboptimal solutions to this problem. The FAQ here: http://www.mega-nerd.com/libsndfile/FAQ.html#Q010 explains my choice of sub-optimal solutin. That FAQ question also provides two ways of using libsndfile that avoid all suboptimal solutions. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support for CAF in flac command-line?
On Mar 7, 2011, at 08:46, Paul Davis wrote: > On Mon, Mar 7, 2011 at 11:25 AM, Brian Willoughby > wrote: >> All professional tools use conversion factors such as 0x8000 for >> float-to-int and int-to-float because it has a single significant >> bit, and thus this factor does not increase the bit depth of the >> samples passing through. > > i'm not sure what "all" means, but i don't think its remotely as clear > cut as you insist: > >http://blog.bjornroche.com/2009/12/int-float-int-its-jungle-out- > there.html > > moreover, its critically important to note that this issue arises > primarily for float<=>16 bit int conversions, where generally > dithering should be done anyway. the noise introduced by dithering > will be at least on the same order of magnitude as the 0.005% error > caused by different choices in the conversion factor. conversions to > other bit depths don't face (precisely) the same issue. > > its great that you're absolutely convinced that your view of this is > right. i generally have a lot of respect for your opinions. the > problem is that there are 4 other people whose opinions i respect > equally, and when i've discussed it with them, my only conclusion in > aggregate has to be "it depends". Thanks. I should qualify my statements by explaining that I'm talking about real music that comes from an A/D, with the understanding that 24-bit integers in twos-complement format are the standard. I should also point out that my goal is to preserve the original bits unless an operation other than format conversion is specifically enabled. In the context of FLAC - a lossless audio codec - this is entirely compatible. My statements would not be appropriate for synthesized waveforms that did not originate in the real world by way of A/D converters. In that world, there is freedom to deviate from the specific limitations of A/D converters, and thus there might be some hesitance to apply a default conversion that might clip certain synthesized waveforms that were created without concern for the realities of analog conversion. In that case, I would suggest that those who create such entirely synthetic waveforms should take the extra steps necessary to condition their signals for actual D/A converters, and then a transparent float-to-int conversion would not cause any additional problems. It's only when the synthetic algorithms rely on side effects of a lossy conversion that things get hairy. Brian ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support for CAF in flac command-line?
On Mon, Mar 7, 2011 at 11:25 AM, Brian Willoughby wrote: > All professional tools use conversion factors such as 0x8000 for > float-to-int and int-to-float because it has a single significant > bit, and thus this factor does not increase the bit depth of the > samples passing through. i'm not sure what "all" means, but i don't think its remotely as clear cut as you insist: http://blog.bjornroche.com/2009/12/int-float-int-its-jungle-out-there.html moreover, its critically important to note that this issue arises primarily for float<=>16 bit int conversions, where generally dithering should be done anyway. the noise introduced by dithering will be at least on the same order of magnitude as the 0.005% error caused by different choices in the conversion factor. conversions to other bit depths don't face (precisely) the same issue. its great that you're absolutely convinced that your view of this is right. i generally have a lot of respect for your opinions. the problem is that there are 4 other people whose opinions i respect equally, and when i've discussed it with them, my only conclusion in aggregate has to be "it depends". --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support for CAF in flac command-line?
On Mar 6, 2011, at 01:22, Erik de Castro Lopo wrote: > Brian Willoughby wrote: >> Hopefully, libsndfile no longer uses the incorrect 0x7FFF (32767) >> factor for float to 16-bit integer conversions, because that would >> make it unacceptable for lossless file conversions. > > That is a statement of opinion rather than fact but I won't go into > that here. It is a statement of mathematical fact, not opinion. Any conversion factor with more than exactly one significant bit is lossy by definition. The coincidental fact that certain rounding and truncation processes happen to recover the correct result under some conditions does not disprove the basic mathematics. All professional tools use conversion factors such as 0x8000 for float-to-int and int-to-float because it has a single significant bit, and thus this factor does not increase the bit depth of the samples passing through. There are a number of erroneous software tools out there in the wild based on mistaken assumptions. One common misconception is that +1.0 is a valid value for two complement representations, which leads people to synthesize test signals using the standard sin() and cos() functions, but those are also flawed techniques. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
