Section: `Apodization functions`
From:
> For partial_tukey(n) and punchout_tukey(n), […] The use of this is
> that different parts of a block are ignored as the might contain
> transients which are hard to predict anyway. […]
to (emphasis added only in this summary, not in the source):
> For partial_tukey(n) and punchout_tukey(n), […] The use of this is
> that different parts of a block are ignored as the**y** might contain
> transients which are hard to predict anyway. […]
The overhead of calling clock() when encoding/decoding very small
frames turned out to be very large, for framesize 16 these syscalls
took over half the execution time. This commit only calls clock()
when at least 10.000 samples have been encoded or 25.000 samples
have been decoded since the last call to clock()
During application of replaygain, bps is checked to be > 0. This
should never happen in a valid file. This check is specific for
replaygain application instead of more generic (at streaminfo)
because we still want to be able to recover files in which
streaminfo is invalid or missing.
Previously, too large chunks of foreign metadata (> 16MiB) were
signalled by libFLAC, throwing an error upon adding the metadata,
so flac gave a rather vague error back to the user. This commit
adds detection to the foreign metadata handling, so the user gets
a much clearer error.
Credit: Oss-Fuzz
Issue: N/A
This fixes https://github.com/xiph/flac/issues/580
The problem was that after encountering a problem in a first
subframe, the state was changed from READ_FRAME to
SEARCH_FOR_FRAME_SYNC, which meant a problem in the second
subframe was interpreted as a read error instead of invalid data.
With this patch, processing of subframes is stopped after setting
SEARCH_FOR_FRAME_SYNC
After seeking, a partial frame is passed to the write callback.
The FLAC__Frame passed there only has its blocksize and sample
number changed to accomodate. This results in several 'rules'
being violated. For example, the predictor order can be larger
than the blocksize. This caused integer underflow in the analysis
output of the flac command line program, causing heap overflow.
Also, the output analysis data is junk, because the residual and
rice parameters are not changed accordingly, as this would
violate other things that are otherwise given, like the number
of rice partitions being a power of 2.
To remedy this, a FLAC__Frame is now output stating that all
subframes are of the verbatim type, which has no restrictions
like fixed and lpc subframes have.
A better remedy will have to wait to the next API change, to
introduce a few new subframe types for this case and the case
of conveying an unreadable frame.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58481
Martijn van Beurden