|
Rockbox mail archiveSubject: Re: MPEG Audio formatRe: 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 |