flac dev - Mar 2011 - 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

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

--p

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

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/