[MPlayer-dev-eng] Re: [PATCH] don't skip first mp3 frame

Nehal nehalmistry at gmx.net
Wed Mar 31 04:10:57 CEST 2004


On Wed, 24 Mar 2004 23:54:35 +0100
Alban Bedel <albeu at free.fr> wrote:

> Hi D Richard Felker III,
> 
> on Tue, 23 Mar 2004 22:37:22 -0500 you wrote:
> 
> > On Wed, Mar 24, 2004 at 01:26:16AM +0100, Alban Bedel wrote:
> > > Hi Nehal,
> > > 
> > > on Mon, 22 Mar 2004 11:55:03 -0800 you wrote:
> > > 
> > > > Albeu: skipping the first 2 frames is a bad fix either
> > > > way. fixing one bug by adding another is not right. even
> > > > if it doesn't fix mp3lib, the first 2 frames should play,
> > > > otherwise it breaks all other mp3 decoders (ie, ffmp3)
> > > > that work fine. if you wanted a temporary fix, the first 2
> > > > frames should have been skipped from  the mp3lib code
> > > > only.
> > > 
> > > I never claimed that it was a good fix. And when the mp3
> > > demuxer was written ffmp3 was slow as hell so no one used
> > > it.
> > > 
> > > > but it seems everything was fine for me were fixed when i
> > > > removed _both_ 2 frame skips, (my patch + comment out 
> > > > ad_mp3lib.c:49, MP3_DecodeFrame(NULL,-2);  ) if anyone has
> > > > any mp3's that still pop after this, please send to me (at
> > > > least the first couple of seconds)
> > > > 
> > > > so i can fix.
> > > 
> > > I look at this tomorow, but i bet it won't be long before i
> > > find some files wich will be initialized with wrong params.
> > 
> > I'm really curious: how does mpg123 handle such files??? It's
> > the same code as mp3lib, right?
> 
> i don't have mpg123 here. I uploaded a sample
> (broken-first-frame.mp3) if you want to check. xmms (wich use
> mp3lib i think) play it fine, mpg321 too (dunno, what this one
> is using).
> 
> 	Albeu

Hi Albeu,

i downloaded the broken-first-frame.mp3 and tested it, apparently 
the starting position skips the header if it doesn't start at the 
beginning of the file. it then searches for the next header data
(which in this case, it finds what it thinks is a frame header
inside the audio data of first frame which is why it incorrectly
detects it as 48000)

anyways here is a revised patch, plays the mp3 fine now

Nehal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp3skip-revision2.diff
Type: application/octet-stream
Size: 1680 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040330/421fed66/attachment.obj>


More information about the MPlayer-dev-eng mailing list