The code of fixed_compute_best_predictor was presumable once optimized,
but it appears a much more readable form is now equally fast or even faster,
see https://github.com/xiph/flac/pull/337 for details.
This fixes the 'false positive' oss-fuzz bug filed under
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47264
The fuzzer was timing out because of an enormous input (932kB)
combined with very slow settings. The commit disables certain
slow settings on inputs larger than 2^18 byte.
In 95e2c52 the autotools build worked fine, but CMake missed a few
defines. Activition of the lpc_compute_residual_from_qlp_coefficients
depended on encoder->private_->cpuinfo.use_asm for no reason, so
this dependency is removed
Quite a lot of decoders have trouble streaming or seeking in a
file with frames that only consist of constant subframes because
of the large difference between the largest and smallest subframe.
To remedy this, this commit makes it possible to disable the use
of constant subframes for the last subframe in case all others are
constant with a new API function. This means the minimum bitrate
for a FLAC file encoded with this function used is raised to
1bit/sample (i.e. 48kbit/s for 48kHz material). This commit also
adds tests to the test suite
Add additional fuzzer for the encoder, aiming to reach more coverage
than the current encoder fuzzer. This is done by incorporating
metadata handling and fixing a problem with different settings in
the current fuzzer
Commit 4fbb6d4f2e reverted commit
44036c9a9b and so broke again the build on
uclibc
So put back the sys/auxv.h check as well as a getauxval check in a way
that doesn't break iOS
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
New intrinsic routines are added to compute the best fixed
predictor. According to my testing, the new routine is about
3 times as fast as the existing routine. This means an
overall speedup for preset -2 of about 30% and for preset
-0 of about 15% for CDDA
This commit reworks the code decoding a frame, to add silence when
frames are missing and output silence when something other than the
frame header seems corrupted. Tests are added to the test suite for
this functionality. Also, decoded values are checked to be within bps
Commit 159cd6c introduced a bug that only triggered upon seeking
from the start of a headerless FLAC file to the first frame (so
really not a seek at all). Furthermore that commit did nothing
else in any other circumstance. This commit fixes that, by both
fixing the problem and the behaviour the commit mentioned earlier
meant to introduce.
Co-authored-by: Robert Kausch <robert.kausch@freac.org>
This commit fixed problems with two files mentioned here:
https://hydrogenaud.io/index.php?topic=121478.msg1004022#msg1004022
The first file was truncated and had no MD5. flac didn't warn
about the number of samples not being correct. The second file
had corrupted metadata in which flac detected two STREAMINFO
blocks, triggering quite odd behaviour.
This commit adds checks for the number of samples and skips
a STREAMINFO block if it has already received one
As described in github issue #236, the description of compression
presets in flac.sgml wasn't updated. Also, the description of which
blocksizes are considered subset has been lagging behind in the
manpages as well as the build-in help of FLAC for years, as this
was changed back in 2007. This commit fixes those issues
Currently github actions only runs CI on x86. Travis has 'partner
queues' which do not use credits. By changing .travis.yml to only
use these, forks can use Travis to test on arm64 and ppc64le. I
intend to use this to run travis every now and then on my own
clone of xiph/flac
The partition order was forced to 0 on the last block of a stream.
This limitation is not necessary, as further down in the code more
generic limits are already in place. This improved compression on
the last block, so especially very short files benefit
If on encoding a different format header is detected than is guessed
from file extension, format_mistake in invoked. On merging wave64
support (commit d7f5344), updating the printable names in
format_mistake was missed
According to elf_aux_info() manpage, AT_HWCAP2 is of u_long type.
Feature detection works anyway in this case, but u_long is more correct.
While here, also remove FreeBSD 11 support, it's EOL.
In some circles (Hydrogenaud.io for example) people share binaries
compiled from git, i.e. inbetween official releases. Files created
with these binaries cannot be discerned from others. To improve
troubleshooting, compiles from a git repository are marked with
the commit hash and date when configured with autotools or CMake
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
