Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: Re: MPEG Audio format

Re: MPEG Audio format

From: Jacob Erlbeck <jacob01_at_gmx.net>
Date: Sun, 15 Jan 2006 14:53:38 +0100

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

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy