From: Bluechip <csbluechip_at_gmail.com>
Date: Sun, 15 Jan 2006 22:21:59 +0000

Thanks for all that - I'm pretty sure I understand everything you said - I
could be wrong, but the construct I now have in my head makes sense ...the
magic words of understanding for me were "bit reservoir" :)

BC

>On Sun, Jan 15, 2006 at 03:03:15AM +0000, Bluechip wrote:
> >
> > >> >>Am I ever likely to encounter an MPEG Audio file which will contain
> > >AUDIO
> > >> >>frames which differ in VERSION, LAYER, SAMPLERATE and/or
> CHANNELS? Eg.
> > >> >>Some frames are 48KHz and other frames are 44.1KHz ...or some
> frames in
> > >> >>Stereo, some in Joint-Stereo?
> > >
> > >a change of LAYER or SAMPLERATE requires a restart of the decoder.
> >
> > Excellent information.
> >
> > I notice you did not mention VERSION or CHANNELS ...Given a LAYER change
> > will trigger a restart it seems logical to presume a VERSION change would
> > also trigger a restart even if the change was Ver1/Lyr1 -> Ver2/Lyr1
> >
> > Would you care to comment on CHANNEL changes ...even if your answer is
> > "don't know" I would consider that to be helpful feedback.
>
>I don't know ;)
>
> >
> > >> Thanks, I too use razorlame, and also have no idea what short or long
> > >> blocks are - and google isn't helping much either. LOL
> > >
> > >IIRC, the audio data that belongs to each MPEG-1 layer III audio header
> > >(in fact, the frame header can be located just in the middle of the
> > >audio data it belongs to)
> >
> > :O
> > A frame header can exist in the middle of an [a pair of] audio frame[s]??
>
>No, each frame starts with a frame header optionally followed by a CRC
>checksum. Then it get's layer specific, in MPEG 1 layer 3 this is
>followed by a section named 'side information'. The remaining rest of
>the frame is being used for so-called 'main data', but (now it's going
>voodoo) the main data that belongs to a given frame may begin up to 511
>bits of main data space (this is without headers and side info) before
>this frame. It's even possible that it starts in frame N-2 and/or that
>it ends in frame N-1 (given that we are looking for the main data that
>belongs to frame N). This is the 'bit reservoir' thing that is only
>being used for constant bitrate streams (it doesn't make much sense for
>VBR streams).
>
>For further investigations have a look into layer3.c of libmad,
>especially the mad_layer_III function around
>/* find main_data of this frame */ and search the web for
>'"main_data_begin" frame'
>
>Helpful discussion of this topic:
>http://www.mars.org/mailman/public/mad-dev/2002-July/000702.html
>
>Nice chart:
>http://www.neumahr.de/study/mpeg_audio.pdf
>(it's in german, go to page 17)
>
> >
> > Could you explain a little more on that - it seems very important to my
> > util.
> >
> > If my file has only TWO [a pair of] audio frames (unlikely, but valid)
> > ...the file can/will look like "AUDIO_DATA -- HEADER -- AUDIO_DATA"
> > ...surely lack of a header at the start of the file will mean the first
> > block of audio data cannot be found by the decoder?
>
>The first frame is an exception, it requires the main data block to
>begin immediately after the side info.
>
> >
> > Or do you mean that there would be two [a pair of] audio frames which each
> > contained half of the data required to recreate the original sound?
>
>For instance, yes.
>
> >
> > Do you have a test file which I can throw at my util for testing please?
>
>No, sorry.
>
> > (or instructions for making one)
>
>Depends, on what you want to test, doesn't it? Play with lame's options
>and break the files with your favourite hex editor, I do not have a more
>sophisticated idea at the moment.
>
>Jacob
Received on 2006-01-15