[Replying to me own e-mail -- what's wrong with this picture]

> >    You are not using 'sHead' anywhere. Could you clarify?
> You just spotted a bug! The following two lines should be using sHead and
> not m_sMpegHead. I will make the necessary changes. Thanks for pointing
> out.
>      if (m_frameBytes > 0 && m_frameBytes < iMaxFrameSize &&
>      (m_sMpegHead.option == 1 || m_sMpegHead.option == 2))

Let me correct myself here -- you spotted a bug in the *old* code. The
lengthy diatribe from below actually pertains to the latest version of the
code. Please download 2.0 source code from our site. My comments below are
not accurate for the code you're currently looking at. Sorry.

--ruaok         Freezerburn! All else is only icing. -- Soul Coughing

Robert Kaye -- [EMAIL PROTECTED]  http://moon.eorbit.net/~robert
----- Original Message -----
From: Mayhem & Chaos Coordinator <[EMAIL PROTECTED]>
Sent: Monday, December 20, 1999 12:38 PM
Subject: Re: Xing Decoder

> > Hi Sir,
> Please, call me Dude. Not sir. :-)
> >      Thanks for giving me the right direction..
> Sorry for not getting back to you sooner -- the FreeAmp 2.0 release was
> since our server started going on the fritz.
> >      I got struck with GetHeadInfo() function.
> This function is MP3 specific -- it may not be much use to you. This
> function is also a *royal* pain the in butt -- I don't know how many times
> I've had to tweak it. No wonder its not obvious what's going on.
> >      I really dont understand why you are calling
> >      head_info3() two times. The second time you are filling the
> >      MPEG Header variable(local), sHead.
> >
> >      MPEG_HEAD sHead;
> >      int iFrameBytes, iBitRate;
> >
> >      iFrameBytes = head_info3(((unsigned char *)pBuffer) +
> >      m_frameBytes + iForward + m_sMpegHead.pad,
> >      iMaxFrameSize - (m_frameBytes + iForward),
> >      &sHead, &iBitRate, &iForward);
> The basic idea behind this function is to seek to the first MP3 frame.
> Typically a proper MP3 file will not need this function, but a file that
> corrupted a the beginning or an HTTP stream where you might get tossed
> the middle of a frame requires it.
> The difficulty of this function is derived from the fact that MP3 frames
> start with 0xFF 0xF*. This marks the start of a frame -- however, MP3
> no precautions to not have 0xFF 0xF* appear anywhere else in the
> So, if the MP3 decoder simply advances the stream to the first 0xFF 0xF*
> may end up in the middle of a frame instead of at the beginning of a
> So, when I find a 0xFF 0xF* I call head_info3() to get the stats about
> frame. Then I seek exactly one frame ahead and call head_info3() again to
> make sure that the data I got from the first frame matches the second
> The sampling rate, MPEG-1 vs MPEG-2 and audio layer need to be same in
> for me to consider these frames valid. (Note: You cannot compare bitrate,
> because of VBR streams) If the data does not jive, I assume that I landed
> the middle of an audio frame and seek to the next frame and repeat the
> process. If the second frame does match, I go one further and look a the
> frame to make sure it matches as well. If I get the third match, I exit
> function with the input stream positioned at the first valid frame.

> --ruaok         Freezerburn! All else is only icing. -- Soul Coughing
> Robert Kaye -- [EMAIL PROTECTED]  http://moon.eorbit.net/~robert
> _______________________________________________
> http://www.freeamp.org/mailman/listinfo/freeamp-dev


Reply via email to