In parsing certain types of metadata blocks, it was not checked
whether certain length fields were at all possible. A small file
of 64 byte was enough to let the decoder allocate 4GiB of memory
by simply stating a field was 4GiB in length, while metadata
blocks in FLAC cannot be larger than 16MiB.
This commit adds a mechanism to the bitreader to set a length
limit upon reading. This limit is checked at each read, at each
memory allocation and after reading the block. In case anything
is deemed wrong, parsing metadata is aborted, as 'resyncing' is
only possible on audio frames, not on metadata blocks.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37865
This changes the names of the two fuzzers so they align with
current oss-fuzz usage (to provide continuity in test data and
corpora) and adds a dictionary to the decoder fuzzer. It also
removes some unnecessary configuration, as it clashed with oss-fuzz
defaults
This changes the calculation of autocorrelation from single precision
float to double precision. With this, compression improves on average
by about 0.5% with compression level 4, with some tracks (espcially
material with high samplerates) seeing improvements of 10% or more.
This commit removes SSE intrinsics and MMX assembler routins, adds
SSE2 and changes VSX autoc[] routines and changes the regular C
code.
When writing a FLAC file with over 2^36 samples, the total samples
entry in streaminfo will overflow and wrap around. Setting it to 0
(which means unknown number of samples) makes sure the decoder
doesn't rely on this number
Co-authored-by: Ralph Giles <giles@thaumas.net>
commit 585e3b added an overflow check in the residual bits
calculation, but actually hitting this causes problems further
down the line. This fixes the problem described in
https://hydrogenaud.io/index.php?topic=121349.msg1001227;topicseen#new
Also, UINT_MAX is changed to UINT32_MAX as uint32_t is used, not unsigned
In the past, various bugs have triggered libFLAC to write enormous
coded residuals. While these bugs have been fixed, this check is
added to limit the impact of possible remaining or future bugs
When a bitwriter is grown past the maximum sane size of a frame
(8 channels of 65535 samples with 24 + 4 bits per sample) this
indicates that such a bug was triggered. Instead of a possible
crash or creating unreadable files, bitwriter_grow_ fails as if
it could not allocate more memory.
in set_partitioned_rice, there was a special treatment in case
partition_order == 0. In this case, a rice parameter was passed
as an argument. However, in case of an LPC block, this rice
parameter was calculated from the LPC error, which is based on the
samples after windowing. Quite often, this resulted in a subframe
with two partition with the same rice parameter. Also, in case of
partial_tukey and punchout_tukey windows, the suggested rice
parameter could be quite sub-optimal.
This patch removes the special treatment of partition_order == 0
and the passing of a rice_parameter as an argument
The size of the first frame was displaying including a PADDING
block, as the decoder position wasn't updated after processing
one such block. The location in the code where the decoder
position is updated has been moved, so a PADDING block does not
get included into the size of the first frame anymore
Without this commit, building fails on MinGW because
-D_FORTIFY_SOURCE=2 needs runtime support which MinGW does not
provide. Building was possible with make LDFLAGS='-lssp'
This commit checks whether a symbol used by _D_FORTIFY_SOURCE=2 and
the stack smashing protector are available, and if so, enables these.
Resulting DLLs depend on the libssp DLL.
With autoconf 2.70, the behaviour of AC_C_VARARRAYS has changed,
causing a lot of warnings and as a result a cluttered make output.
Doing some research as to where this comes from, I found an strange
piece of code that seems to rely on a misunderstanding as to VLA's
in C++. As I found, the C++ standard does not have VLA's. The
configure.ac code and some code in libFLAC++ seems to think it does.
This now causes strange behaviour.
This commit removes the code relying on this behaviour and removing
all VLA related autoconf macro's from configure.ac
Autoconf 2.71 warns about obsolete macro's on running ./autogen.sh.
AC_PROG_CC_STDC is replaced by AC_PROG_CC as recommended by autoupdate
AC_HEADER_STDC has been removed. Autoupdate recommended the following:
> The preprocessor macro `STDC_HEADERS' is obsolete. Except in unusual
> embedded environments, you can safely include all ISO C90 headers
> unconditionally.
Starting with autoconf 2.70, obsolescence warnings are output by
default. To keep the script as compatible as possible, I build
autoconf 2.60 and ran the autoupdate that came with it on
configure.ac and all m4 files.
Now that many DACs support up to 768kHz, add support for these
sample rates to the encoder. Files produced with these sample rates
are already decodable by the reference decoder. Update documentation
and tests accordingly.
With this commit, it is possible to run the full test suite on
Windows machines when busybox-w32 is installed. This program is
available through chocolatey with 'choco install busybox'
CMake tests for availability of busybox and use if available. As
chocolatey is the preferred method of fetching software for
Github actions, this commit paves the way for running the full
test suite on Windows for CI
Without this patch, CMake places output binaries and libraries in
the respective source directories, like the autotools build system.
The Visual Studio build system places objects in the objs directory
Because CTest didn't run properly when building shared libs, this
commit changes the CMake behaviour on (NOT UNIX) to that similar
to Visual Studio. That way, DLLs and EXEs are placed in the same
directory and running CTest with the correct DLLs being loaded
is trivial.
Clang throws *a lot* of warnings on alignment requirement increase
where no alignment is required at all. This is a results of the
way intrinsics were implemented long ago. See
https://stackoverflow.com/questions/71279668/why-does-clang-complain-about-alignment-on-sse-intrinsic-unaligned-loads
This commit silences these warnings by first casting the pointer
to (const void*) or (void*) before casting the (const __m128i*),
(__m128i*), (const __m256i*) or (__m256i*)
Compiling with and without this patch returns exactly the same
binary for GCC 9.3 and clang 10.0
printf/fprintf prefer format specifiers rather than variable strings
(despite the const status). No functional change.
Fixes the following compiler reported warning:
warning: format not a string literal and no format arguments [-Wformat-security]
In stream_encoder_new, set_defaults_ was called before setting
encoder->protected_->state to uninitialized. However, this state
was being accessed by set_compression_level in set_defaults_. As
this is undefined behaviour, move the initialization of
encoder->protected_->state up to before calling set_default_
Martijn van Beurden