On 7 Aug, Lorenz Klaus wrote:
> Hi,
>
> in FreeAmp 1.3.0, inf file xinglmc.cpp line 358 and line 371
The code you list does not exits at these lines. Are you sure you're
looking at an unmodified version of xinglmc.cpp version 1.97?
> (m_sMpegHead.option == 1) it seems that MP1 (m_sMpegHead.option == 3) and
> MP2 (m_sMpegHead.option == 2) are disabled.
xinglmc.cpp version 1.97 of freeamp 1.3.0, line 232:
(m_sMpegHead.option == 1 || m_sMpegHead.option == 2)
Given this, MPEG-1 and MPEG-2 layers 2 and layers 3 are enabled and
layer 1 is not. There aren't too many layer 1 files out in the world,
since they are almost identical algorithms (as far as difficulty to
implement is concerned), with layer 2 yielding better compression. Most
people never bothered with layer 1. Quite frankly I am suprised that
people still want to deal with layer 2.
The MPEG audio streaming synching is a mess, and our friends over at
SHOUTcast made a couple of screw-ups when they created SHOUTcast. Here
is the scoop: An audio frame in MPEG begins with the bits 0xFFF*, after
that you will find the all the juicy details for the frame like the bit
rate, sample rate and all that happy stuff. The MPEG group decided to
not impose the restriction that the audio frame synch marker could not
ever appear in the body of an MPEG frame.
SHOUTcast does not require each packet that it sends (unlike a properly
designed streaming protocol like RTP) contains an integral number of
MPEG frames. This means that a SHOUTcast client needs to search for the
next synch marker and start playing that stream. Well, most of the bits
in the MPEG frame header are used, which means that if you jump into
the middle of a SHOUTcast stream, find the next sync marker you may not
actually have found a correct stream marker. And you cannot tell from
the header itself if you've found a valid sync marker, since most of
the bits in the audio header are used. This means that you can jump
into the middle of a 128k layer 3 stream and think that you're actually
getting a 256k layer 1 stream.
So, I thought I'd be clever and given the current header go to the next
header and compare the headers to make sure that this was a valid
stream. Well, that is also not foolproof since there are some MP3 files
that have nothing but FFs as the contents of the first dozen audio
frames. So, its hard to distinguish if you're jumping from trash to
trash header or from an actual to an actual header.
So, finally I can make my point to answer your question. If I remove a
rarely used layer and I toss out frames layer types '00' and '11' then
I've removed half of the possible bad frames that my sync scheme might
get tripped up on. Besides, most of the time when the sync scheme got
confused, it thought it was decoding a layer 1 file.
Well, you asked. :-)
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
