Having more than 10 consecutive frames decoded as mp3 should be
considered a clear signal that the sample is mp3 and not mpegps.
Reported-By: Florian Iragne <florian@iragne.fr>
CC: libav-stable@libav.org
The quality scale field is only supposed to be present if the fourth bit
is set. In practice, lame always sets it, but other tools might not.
CC:libav-stable@libav.org
Consider a file created with something like:
cat file1.mp3 file2.mp3 > result.mp3
Then if file2.mp3 has gapless information, result.mp3 would stop playing
something in the middle. This happens because the gapless info directs
the decoder to discard all samples after a certain position. To make
matters worse, the gapless info of file2.mp3 will be used when playing
the file1.mp3 part, because the gapless info is located at the end of
the file.
While handling concatenated gapless files correctly would be insane and
a lot of effort (especially without scanning the whole file on opening),
it's easy to prevent at least early EOF. Playback will happen to work,
even if it's slightly broken.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The code already had skipping of initial padding, but discarding
trailing frame padding was missing.
This is somewhat questionable, because it will make the decoder discard
any data after the declared file size in the LAME header. But note that
skipping full frames at the end of the stream is required. Encoders
actually create such files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When a id3 tag is larger than the amount of space we will probe
give it a score similar to what a .mp3 extension would have given it
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The toc is inexact and not using it can thus make sense.
Using it is faster though, thus the opposite can similarly makes sense
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.
When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.
When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
Signed-off-by: Alexander Kojevnikov <alexander@kojevnikov.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The libav code depends on mp3 startcodes only occuring at the start of
frames. But there is nothing in mp3 that prevents them occuring elsewhere
by chance. Thus the code would fail randomly, the new code searches for 3
consecutive valid frames. If this turns out to be still insufficient the
number can be raised further, or additional checks added.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Manually remove that flag again for formats that read an arbitrary
amount of data and thus truncation is not an error.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Also add missing trailing commas, break long codec_tag lines and
add spaces in codec_tag declarations.
Signed-off-by: Martin Storsjö <martin@martin.st>
The fields "Number of Bytes" and "Number of Frames" are mixed up. "Bytes"
come first, "Frames" behind.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Alex Converse <alex.converse@gmail.com>
The MP3 demuxer split the data in packets of 1024B which are later split
in MP3 frames by the MPEG audio parser. The last read is "truncated",
but this should not raise any error.
Solution-by: Michael Niedermayer
Michael Niedermayer
Luca Barbato
Anton Khirnov
wm4
Carl Eugen Hoyos
Alessandro Ghedini
Vittorio Giovara
Diego Biurrun
Alexander Kojevnikov
Ronald S. Bultje
Reimar Döffinger
Martin Storsjö
Ingo Brückl
Clément Bœsch