[MPlayer-dev-eng] Re: [Patch] Trying harder to detect MP3

[Alban Bedel]

Hi Michael Behrisch,

on Sat, 27 Dec 2003 21:14:32 +0100 you wrote:

> Hello,
> 
> this one incorporates code from mp3check in order
> to recognize mp3's with (at most 100 bytes of) junk at start.
> It works only with files (seekable streams).

The main idea is ok to me, but it's not implemented at the right place.
The function is cut into 2 parts. The first try to findout the file
type. The second one setup the demuxer stream, etc.
In the case of mp3 it's not so clear bcs the second part also perform some
extra test to ensure that the file is really an mp3.
So imho your extra check should go into the first part where it currently
only set frmt to MP3.

> Maybe the resulting demuxer->movi_start is wrong, but I
> don't know whether it is right at the moment. (Why does it
> point to a place 4 bytes in front of the second header?)

With your patch the value is definitly wrong. You assign a new value to n
wich then have a value completly unreleated to the other operands of the
operation on the next line.

As you'r pointing out the current demuxer->movi_start is wrong :(
The current value work bcs later the demuxer will just skip the 4 bytes of
junk but we'll better fix it.
It should point to the start of the second mp3 frame. This may sound silly
but way too much mp3 have the first frame broken wich then lead to bad init
of mp3lib :((
IIRC ad_mp3lib skip the first frame too now, so it may not be needed anymore.
Anyway i highly recommend that you checks your patch with LOTS of mp3. (And
with LOTS i really mean at least some 1000's including old stuff ;)

Also check -audiofile. To do this extract the soundtrack from an avi and
when playing with -audiofile it should have perfect sync (even after
seeking).

Good luck ;)
	Albeu
-- 

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.