Parts of the code use realloc like
x = safe_realloc(x, somesize);
when this is the case, the safe_realloc variant used must free the
old memory block in case it fails, otherwise it will leak. However,
there are also instances in the code where handling is different:
if (0 == (x = safe_realloc(y, somesize)))
return false
in this case, y should not be freed, as y is not set to NULL we
could encounter double frees. Here the safe_realloc_nofree
functions are used.
Subdivide_tukey is intended to replace partial_tukey and
punchout_tukey. It works in rougly the same way, but uses a more
efficient algorithm, recyling more data.
subdivide_tukey has 2 arguments, of which 1 is optional. The
first states the maximum number of parts the signal has to be
split up in, the second is the tukey parameter, divided by the
max num of parts.
subdivide_tukey(3) analyses audio with an unsplit block, with the
block split in 2 and split in 3. Here the default p of 0.5 applies
to the smallest parts, so the unsplit block effectively has a p of
0.5/3. subdivide_tukey(3/2e-1) does the same but with p of 0.2.
There was some help text in `flac --explain` which hasn't been
correct for about 20 years already. This is removed, the rest of
the text is reflowed to fit 80 chars standard terminal width
Currently, the man pages are converted from a docbook document, but
the conversion doesn't seem very reliable. Also, the man page is
more-or-less duplicated by the html documentation.
This commit moves all tool documentation to a markdown document which
is readable by itself and can be converted by pandoc to a man page
and can be used by Jekyll to populate the website.
This might fix https://github.com/xiph/flac/issues/48 I cannot
check as I don't have a file to test with. Besides returning an
empty string upon reading, also allocate empty strings when growing
vorbiscomments
See https://github.com/xiph/flac/issues/76 for details
Also, move include of stddef.h and stdarg.h up to top of file to
make clear that they are included unconditionally
In 2003, in commit 94f81b0, a check was added for the block align
field in WAVE. If it contradicts other parts of the header, an error
was raised. This was (probably erroneously) made inactive with #if 0
in commit 13c63e4. This commit reactivates the check and removes the
rest of the inactivated code.
In simple_iterator_prime_input_ there was no check whether the first
metadata block is a streaminfo block. As the rest of the functions
operate under the assumption the first block is a streaminfo block,
for example to prevent the functions from deleting the last block
and being left with an iterator pointing nowhere, this check is
added.
When a metadata chain was read from an Ogg FLAC file containing no
metadata (but otherwise valid), an empty chain could be returned,
leading to null derefencing on trying to manipulate it. This commit
adds a check for the chain length
In commit 0077d3b checks were added for metadata reading in the
stream decoder. However, the metadata interface suffers from the
same problems. Similar to the mentioned commit, checks are added.
As abs(INT32_MIN) is undefined, it took some extra work to enable
the encoder to do this. While expected gains are zero, this is
done to ensure full spec coverage in this regard
* Change replaygain analysis so it is able to handle 32-bit PCM
* Increase FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE to 32
* Fix switch-case fallthrough
FLAC seekpoints are coded in unsigned 64-bit ints, but the code
handling them uses signed 64-bit ints. Since users are unlikely
to run into this limit anyway, do not use seekpoints larger than
INT64_MAX
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48112
Commit 3fc5ba4 replaced a seeking error with specific handling.
This handling consisted of lowering the upper seek bound.
However, this handling was both slow and wrong. Because it is slow
it causes fuzzing timeouts. It was wrong in that if there was
another valid frame in the boguss frame being read, it would no
longer be reachable.
This commit replaces the handling with another approach: instead of
lowering the upper bound, the lower bound is raised. With this, the
calculation of pos for the next seek is changed and the seeking code
hopefully ends up somewhere not decoding the bogus frame.
If in decoding the frame at lower bound eof is still reached,
a seek error is thrown. This is reasonable, as lower bound should
be after the end of the last frame (not somewhere halfway a frame)
and if a corrupt frame is encountered, proper seeking cannot be
reasonably expected. It could be argued that it is still possible
to try and lower the upper bound by trying to decode a frame by
moving one byte backward at a time, looking for a frame, but this
will probably cause fuzzer timeouts and as said, proper seeking
in such a stream cannot be reaonably expected.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48077
Without this patch, the order of the arguments matter, with it
it does not: specific compression settings now always override
the more generic compression levels. This fixes issue
https://github.com/xiph/flac/issues/20
On fuzzing the assertion
'decoder->private_->last_frame.header.number_type ==
FLAC__FRAME_NUMBER_TYPE_SAMPLE_NUMBER' failed. This was because it
was possible to get there without having decoded a valid frame yet.
The checks are rearranged such that the code past this assertion is
only reached after it is made sure a valid frame has been decoded.
When a call to read_callback failed in bitreader_read_from_client_
it left the bitreader buffer in a state where the last word was swapped
for endianness. While this wasn't ever a problem, recently code was
merged that rewound the bitreader in case a bogus frame was found.
If this happened, the bitreader buffer would be used in the state
where the last word in the buffer was still swapped. This commit
restores the last word of the buffer in case the call to the
read callback fails
