[MPlayer-dev-eng] mp3 recognize bugfix for MPlayer-1.0pre7::libmpdemux/demux_audio.c

Stefan Bambach sbambach at gmx.net
Tue Sep 6 13:50:25 CEST 2005


Hi,

> > My Algorithm:
> > check each byte position in stream und store possibly correct headers in
> > a list until 30000 bytes checked. (same as old one)
> > return with mp3_found=true, if 5 correct headers were found in the
> > decoding means.
> 
> I am not entirely certain, but I think that is how it should have worked
> (and how it works in CVS), I just had a little bug there. Can you check
> this problem exists in clean CVS and if yes send us a sample?


No your code doesn't do it "my" way. (Can only look at the code, because
the CVS version doesn't compile under gentoo linux :-( Problem with
libav... stuff. static version is not included in mplayer and gentoo
ffmpeg version is not compatible...). Except for mpa_layer check, it's
the same code, as in pre7.

You remove each list item, when you call it "invalid". Invalid your way
means e.g. "next_frame_pos < st_pos". That can always happen, because of
random mp3 data is sometimes a possible mp3 header. 

Let's say at these positions are "possible" headers (again framesize
0x100 for simple calculation)...
0x0
0x100
0x110 ===> you delete list element
0x130
0x200 ===> you delete list element
0x300
0x400
0x420 ===> you delete list element
0x500

So if every 4th element is a mp3 random data header, you delete the
"correct" element. And will never get 5 valid elements...



My algorithm:
0x0 -> store 0x0 element (start: 0x0; next_frame_pos: 0x100)
0x100 -> change 0x0 (start: 0x0; next_frame_pos: 0x200)
0x110 -> store 0x110 element
0x130 -> store 0x130 element
0x200 -> change 0x0 (start: 0x0; next_frame_pos: 0x300)
0x300 -> change 0x0 (start: 0x0; next_frame_pos: 0x400)
0x400 -> change 0x0 (start: 0x0; next_frame_pos: 0x500)
0x420 -> store 0x420 element
0x500 -> change 0x0 (start: 0x0; next_frame_pos: 0x600)

So I collect and count all elements, that are in a row in decoding means
(nextframe = pos+framesize) and delete nothing and break, if a list
elements reaches the counter.


sample mp3 file is attached (check it with 
"mplayer -v -v -v sample.mp3 | grep -v head_check"). Although xmms
plugin will play it later... without xmms it doesn't play anything.


Question:
Why checking layer, channels, freq, ... to get correct header sequence ?
What about VBR mp3s ? Some parameters can change each frame !


ciao. Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.mp3
Type: audio/mpeg
Size: 50000 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050906/6b690c62/attachment.mp3>


More information about the MPlayer-dev-eng mailing list