[Flac-dev] A-law and mu-law

Conrad Parker conrad at metadecks.org
Mon Nov 21 15:25:54 PST 2011


sndfile-convert already converts from all these formats to FLAC, but
the flac tool itself has more flac-specific options. Is it possible to
use sndfile-convert to provide the input data?

In any case Erik is maintaining both libsndfile and libflac, and it's
unlikely he'd want to duplicate the code. If anything it'd make more
sense to remove code for reading other formats from the flac sources
and just use libsndfile for that part.



On 21 November 2011 21:01, Brian Willoughby <brianw at sounds.wa.com> wrote:
> On Nov 19, 2011, at 16:42, Giulio Paci wrote:
>> So the problem would be suboptimal compression due to suboptimal
>> assumption about the input signal, right?
> The problem is more that FLAC should not be a collection of code to
> read every possible file format in existence.  That would be a
> duplication of at least two other audio file format conversion
> utilities, and quite bug ridden, at best.  Instead, FLAC supports the
> two major lossless file formats plus totally raw data (no container
> or formatting besides the raw samples).  Between those three options
> you have everything you really need for lossless audio compression.
> The only totally new file format that would make sense as an addition
> is CAF, and only because it allows larger files and is also lossless.
>> What I do not understand is how the format of a FLAC format would be
>> affected by supporting A-law and mu-law files as input (and thus
>> output). Despite of suboptimal performance, is it possible to treat
>> 8bit
>> *-law samples as 8bit linear PCM files and write down the original
>> format information in the output while decoding?
> If you were to treat *-law data as 8-bit, then you would have a
> couple of problems.  First of all, I don't think that FLAC supports 8-
> bit.  It's really rather pointless to develop lossless compression
> algorithms for 8-bit audio.  More importantly, reinterpreting *-law
> as 8-bit linear PCM would introduce nonlinear distortion that would
> affect the compression algorithms.  FLAC would still be lossless, but
> it probably wouldn't be able to compress distorted audio as small as
> clean audio.
>> For my needs converting them to 16bit linear PCM is an option, but I
>> will need to keep track of the original format outside the file, which
>> is something that I would prefer to avoid.
> I think the biggest problem here is that you have two types of sound
> files or audio data in your overall collection.  All of the A-law and
> mu-law files are not up to the same lossless recording quality as an
> 8-bit AIFF, for example.  Trying to shoehorn two different quality
> levels of recordings into the same file format doesn't really make
> much sense.  You're probably better off by archiving the *-law files
> with a slightly modified organization to reflect the different
> quality level.
> Unless conversion to 16-bit lossless audio followed by FLAC
> compression shows substantial savings in space, then you're probably
> better off just leaving the *-law files as they are.
> Brian
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev

More information about the Flac-dev mailing list