On Oct 12, 2008, at 22:32, Paul Davis wrote:> On Sun, 2008-10-12 at 19:26 -0700, Brian Willoughby wrote: >> Is anyone here potentially up to the task of adding support for CAF >> (the CoreAudio Format) into the flac command-line? This would >> present minimal difficulty under OSX, due to the presence of the >> CoreAudio API, but the real challenge would be to support CAF on Unix >> and Windows - everywhere that flac is now available. >> >> Although the format is rather unknown, there are some very specific >> advantages to adding CAF support. > > I am a little suprised that you don't know that CAF is already > supported > by libsndfile, on every platform where libsndfile works (which > includes > just about every unix and windows platforms i know of).I realize that I'm a couple of years late in saying so, but you're right. I finally took the time to download libsndfile and compile it (for Leopard), and sndfile-convert easily handled converting a 1.8 GB FLAC recording (from a Sound Devices 702) to a 2.9 GB CAF file. I haven't done extensive testing for conversion errors, but a quick scan of the file seems to indicate that it plays fine. The true test will be the next time I master a recording of a long performance. I still support enhancements to the flac command line to support direct conversion to one or more formats that do not have a 2 GB limit, but for most audio formats libsndfile might be acceptable. 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. Brian Willoughby Sound Consulting
Erik de Castro Lopo
2011-Mar-06 09:22 UTC
[Flac-dev] Support for CAF in flac command-line?
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. However, there is a way avoid that feature of libsndfile by avoiding the use of floats during the conversion. For instance, when convering from one format to another, sndfile-convert does this: if ((outfileminor == SF_FORMAT_DOUBLE) || (outfileminor == SF_FORMAT_FLOAT) || (infileminor == SF_FORMAT_DOUBLE) || (infileminor == SF_FORMAT_FLOAT) || (infileminor == SF_FORMAT_VORBIS) || (outfileminor == SF_FORMAT_VORBIS)) sfe_copy_data_fp (outfile, infile, sfinfo.channels) ; else sfe_copy_data_int (outfile, infile, sfinfo.channels) ; That is the second path (sfe_copy_data_int) would be used for FLAC -> CAF and CAF -> FLAC conversions. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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