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>
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.
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>
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>
The smaller patch makes the utf-8 library use ANSI codepage by
default. When frontends call the "get_utf8_argv" function it
changes Unicode conversion codepage from ANSI to UTF-8.
Patch from Janne Hyvärinen <cse@sci.fi>.
Libraries that are used internally by libFLAC(++) but are not part of
their API should be listed in pkg-config "private" clauses. Otherwise
executables that are linked dynamically against libFLAC(++) will have
unneeded direct dependencies (overlinking).
Based on a patch by Brad Smith from
https://sourceforge.net/p/flac/bugs/397/
that I updated to only include ogg if libFLAC is actually built with
ogg support.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Add explicit extern to functions that are locally declared inline
but which also have non-inline public prototypes.
It seems MS VS does not quite meet the C99 spec (section 6.7.4).
The files src/flac/encode.c and src/libFLAC/stream_encoder.c use
functions in libFLAC that are marked as 'unpublished debug routines'.
This patch moves these functions to new file include/share/private.h
and marks them as 'unpublished debug routines'.
