[MPlayer-dev-eng] [PATCH] improving MP3 detection
Reimar Döffinger
Reimar.Doeffinger at stud.uni-karlsruhe.de
Tue Sep 21 18:01:41 CEST 2004
Hi,
>>As far as I can tell, the old code did the same checks, but _after_ the
>>detection itself, this should just move this check to a point where we
>>can still search for a better alternative (i.e. another mp3 header that
>>has 5 consecutive good frames). What might be worth discussing is that
>>it changes the detection to always search at most the first 30000 bytes
>>of any file...
>
> Let me rephrase my concern: is it possible that this patch misdetects
> a broken mpeg file as mp3 ?
Possible with a (I would think very slightly) higher probability than
before. Misdetection is only possible when in the first 30k of the file
there is:
1) A valid mp3 header
2) a second valid mp3 header, exactly one framesize apart from the first
one (framesize is specified in the first header) with the same
samplerate and frequency specification.
3) a third valid mp3 header, exactly one framesize apart from the second
one (framesize is specified in the second header) with the same
samplerate and frequency specification.
4) a fourth valid mp3 header, exactly one framesize apart from the third
one (framesize is specified in the third header) with the same
samplerate and frequency specification.
5) a fifth valid mp3 header, exactly one framesize apart from the fourth
one (framesize is specified in the fourth header) with the same
samplerate and frequency specification.
;-)
My guess is that the probability that this happens by chance is really
small, but I don't have numbers...
Difference between before and after my patch is, that before the header
in 1) had to be the first appearance of two bytes that _could_ represent
an mp3 header.
My latest version can also be fine-tuned by modifiying "#define
MIN_MP3_HDRS 5".
Greetings,
Reimar Döffinger
More information about the MPlayer-dev-eng
mailing list