[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