Control: tags -1 + patch
Am Mittwoch, den 18.02.2015, 10:53 +0100 schrieb Fabian Greffrath:
But this is still not the cause of the crash, sigh! Patching the sample
to report 1 channel, it still crashes at the same location.
Phew, got it.
This time, it was a simple logical error in the lame
Am Dienstag, den 17.02.2015, 11:19 +0100 schrieb Fabian Greffrath:
But, the sample at hand reports -251 channels. Adding ... ||
gfp-num_channels 0) to Maks' patch actually fixes the crash.
But this is still not the cause of the crash, sigh! Patching the sample
to report 1 channel, it still
On Wed, Feb 18, 2015 at 12:11:35PM +0100, Fabian Greffrath wrote:
Phew, got it.
Thank you for your comprehensive analysis. I have verified that the patch fixes
this issue. Should I report this to upstream bug tracker or does package
maintainer handle that? Bug tracker in sourceforge.net does not
Am Mittwoch, den 18.02.2015, 12:11 +0100 schrieb Fabian Greffrath:
This time, it was a simple logical error in the lame sources: The fake
sample rate of the fuzzed input file is 1631 kHz which lame tries to
sample down to 48 kHz in the process of encoding. The ratio between
input and
Am Dienstag, den 17.02.2015, 09:11 +0100 schrieb Fabian Greffrath:
Does anyone know the highest reasonable input samplerate supported by
lame?
Na, this was a red herring. I just patched a (valid) WAV file to report
a samplerate of some 10^6kHz and lame still successfully processed on
it.
But,
Hi Henri,
thank you for submitting this bug report!
Am Montag, den 16.02.2015, 12:45 +0200 schrieb Henri Salo:
Error reading input file
lame: util.c:595: fill_buffer_resample: Assertion `fabs(offset) = .501'
failed.
This seems to be the inverse problem this time: The samplerate in the
6 matches
Mail list logo
