On Nov 21, 2011, at 15:25, Conrad Parker wrote:
> 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 p
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
Giulio Paci wrote:
> These are good news.
> Do you know if there is any patent pending for ALAC and CAF?
I do not know of any pattent issues with either of these formats.
CAF is a very simple container format like WAV and AIFF. It does
not contain anything that could possibly be patented (ignori
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 under
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
dup
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 th
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
> >
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 ar
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). De
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 con
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/d
11 matches
Mail list logo
