[Flac-dev] Support for CAF in flac command-line?

Brian Willoughby brianw at sounds.wa.com
Mon Mar 7 09:15:06 PST 2011


On Mar 7, 2011, at 08:46, Paul Davis wrote:
> On Mon, Mar 7, 2011 at 11:25 AM, Brian Willoughby  
> <brianw at sounds.wa.com> 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



More information about the Flac-dev mailing list