For some reason all documentation lists the max rice partition
order to be 16, while the maximum is 15. This fixes flac -H, the
man page and the HTML source code documentation
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Before this patch it was possible to set or get data.ia32.sse3 value
from x86-64 code, etc which is a potential source of errors.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
This patch removes all content that is better viewed online (i.e.
downloads, links etc.) and not necessary for development.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
While developing FLAC Frontend, there where several occasions where
I felt little restrained because the FLAC logo is available only in
gif. I made an SVG version and rendered a new GIF version from it.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
A preprocessor macro FLAC__ALIGN_MALLOC_DATA is defined in the Makefiles
but absent in *.vcproj files. This patch adds it to libFLAC_static.vcproj
and libFLAC_dynamic.vcproj.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
For the 32 bit x86 ASM functions there were already versions of this
function for lags (N = 4, 8, 12). They require lpc_order less than N.
The best compression preset (flac -8) uses lpc_order up to 12; it
means that during encoding FLAC also uses unaccelerated C function.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
When compiling for ia32 on an x86_64 kernel, the configure script
was not detecting the ability to do asm optimisations because the
configure script was detecting the x86_64 kernel not the ia32
user space.
The AWK script used to generate tones for this test fails with gawk
version 4.0.1, but used to work for earlier versions. Use mawk instead
if it exists.
The previous fix (patch 6f7ec60c) had the undesireable effect of slowing
down encoding speed on 16 bit files where the arithmetic overflow was
less likely to happen.
This fix forces the use of a FLAC__uint64 accumulator for 24 bit files
and restores the use of a FLAC_uint32 accumulator for 16 (and less) bit
files.
Unfortunately, I have not been able to prove to myself that this overflow
*cannot* happen with 16 bit files.
Gcc 4.8 has a new warning about use of un-initialized data. In particular
this new warning can detect if an automatic variable is defined in one function
and then passed to another and used before it is initialized.
For a specific 24 bit WAV file provided by Leigh Dyer
http://lists.xiph.org/pipermail/flac-dev/2013-July/004284.html
encoding with compression level 7 was generating a file a couple of
orders of magintude larger than the original.
Debugging showed that variable abs_residual_partition_sum (a FLAC__uint32)
in function precompute_partition_info_sums_() was suffering from an
arithmetic overflowing on some 24 bit input files although this value
overflowing did not always cause larger output files.
Since the value abs_residual_partition_sum is eventually stored in an
array of FLAC__uint64, it makes sense to make abs_residual_partition_sum
a FLAC__uint64 anyway.
Debugging this problem was made easier by use of the Clang compiler's
-fsanitize=integer option.
