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.
Don't use the assembly function since it seems to be slower than
the current version of FLAC__bitreader_read_rice_signed_block.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
The NUL char is written at incorrect place when the destination string
is longer than 0, which causes memory corruption. It was broken by
commit 2d6354ff2a.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
FLAC now defaults to building with -fvisibility=hidden on GCC4-ELF
platforms. This breaks the XMMS plugin. At least get_iplugin_info()
needs to be externally visible.
Patch from Christian Weisgerber <naddy@mips.inka.de>
The changelog declared "charset=ISO-8859-1", but used a UTF-8 encoded
name. Change the declaration to UTF-8 to fix this.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
* Mac OS X has incomplete installations of gettext/iconv. So stop
checking for gettext command on Darwin, and install some additional m4
scripts so it can be bootstrapped on Mac OS X.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Use Benjamin Stiglitz' MIN macros from gcc 4.3 (according to the
changelog, __COUNTER__ was introduced in this version). Previously,
the macros weren't used on any existing gcc version; the first one
would have been 5.5.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Commits a7e3705d05 and
a4c321e492, while trying to simplify how
the FLAC_API_SUPPORTS_OGG_FLAC global variable was initialized,
inadvertently caused it to be always set to false, whether Ogg support
was compiled in or not.
This commit reverts the relevant part to how it looked in the 1.2.1
release, which is verbose but correct.
The problem was found by Robert Kausch <robert.kausch@freac.org>.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Erik de Castro Lopo