Hi Martijn, thank you for your answer. So the problem would be suboptimal compression due to suboptimal assumption about the input signal, right? 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? 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 would prefer to avoid having multiple file format around (I mean containers format here) if possible. Do you know of any container that supports both flac and *-law streams? Thank you again. Bests, Giulio. Il 18/11/2011 19:13, Martijn van Beurden ha scritto:> Because u-law and a-law are non-linear algorithms and the mathematics of > FLAC (and AFAIK all lossless encoders) are build for linear PCM. Adding > these formats would change the FLAC format altogether, decoders are not > made to work with it (they can only output plain PCM) Best option would > be converting these files to 16-bit plain WAV and compressing, but I > guess files won't be much smaller that way. IMO best is to keep them as > they are. > > Op 18-11-11 12:34, Giulio Paci schreef: >> Hi to all! >> I have a database of audio files that I want to losslessly compress. >> Unfortunately I have several 8bit A-law and mu-law files in the database >> and I see from here >> http://flac.sourceforge.net/documentation_tools_flac.html >> that they are not supported by the reference flac encoder/decoder. >> Is there a reason for this? >> Would it be possible to add support for these files in the reference >> encoder? >> >> Bests, >> Giulio. >> >> _______________________________________________ >> Flac-dev mailing list >> Flac-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/flac-dev > > _______________________________________________ > Flac-dev mailing list > Flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > >
On Sun, 2011-11-20 at 01:42 +0100, Giulio Paci wrote:> 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 would prefer to avoid > having multiple file format around (I mean containers format here) if > possible. Do you know of any container that supports both flac and *-law > streams?Ogg - see http://wiki.xiph.org/OggPCM#Supported_PCM_Formats Richard
Richard Ash wrote:> On Sun, 2011-11-20 at 01:42 +0100, Giulio Paci wrote: > > 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 would prefer to avoid > > having multiple file format around (I mean containers format here) if > > possible. Do you know of any container that supports both flac and *-law > > streams? > > Ogg - see http://wiki.xiph.org/OggPCM#Supported_PCM_FormatsThe last update of that wiki page was in September of 2009. I do not know of any actual software that implements that spec. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Giulio Paci wrote:> thank you for your answer. So the problem would be suboptimal > compression due to suboptimal assumption about the input signal, right? > 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).FLAC is in maintenance mode. Good luck getting new features.> 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 would prefer to avoid > having multiple file format around (I mean containers format here) if > possible. Do you know of any container that supports both flac and *-law > streams?Apple's CAF format supports both ALAC (Apple's lossless audio format, not FLAC) and ALAW. I am currently in the process of adding CAF/ALAC support to libsndfile: http://www.mega-nerd.com/libsndfile/ Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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
Thank you all for your answers. They were all useful. Il 21/11/2011 07:37, Erik de Castro Lopo ha scritto:> Giulio Paci wrote: > >> thank you for your answer. So the problem would be suboptimal >> compression due to suboptimal assumption about the input signal, right? >> 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). > > FLAC is in maintenance mode. Good luck getting new features. > >> 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 would prefer to avoid >> having multiple file format around (I mean containers format here) if >> possible. Do you know of any container that supports both flac and *-law >> streams? > > Apple's CAF format supports both ALAC (Apple's lossless audio format, not > FLAC) and ALAW. > > I am currently in the process of adding CAF/ALAC support to libsndfile: > > http://www.mega-nerd.com/libsndfile/These are good news. Do you know if there is any patent pending for ALAC and CAF? Bests, Giulio.
Hi, 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. cheers, Conrad. 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 > >