decoding, how many chunks of "main info"?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

decoding, how many chunks of "main info"?

Torsten Mohr
Hi,

reading in the ISO 11172-3 i see on page 43, Figure A.7.b. that
the MP3 stream consists of frames (of course) and that a part of
the "main data" can be located in a previous frame.

That is ok so far, but in the example i see also that the "main data"
can span _several_ previous frames.

Is there a limitation to the number of previous frames that i
need to consider for the "main data" of a frame?

For example, i'm decoding frame 345, it is ok that i need to look
back to frame 344 in some cases.  As i understand Figure A.7.b i
also may need to consider frame 343.  How far can this reach back?

Is this something that is just "on paper" but does not happen in
reality?

Is my understanding correct so far?


How does this interfere with resyncing?  If i need to resync to a frame
and i find a valid frame, but its "main data" starts in the 4th previous
frame, then i have to skip this valid frame, is this correct?


Can anybody suggest me a pseudo-algorithm that considers both problems
(resyncing & back-referring of "main data")?


Or did i just misunderstand the spec here?


Thanks for any hints,
Torsten.
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: decoding, how many chunks of "main info"?

Takehiro Tominaga
From: Torsten Mohr <[hidden email]>
Subject: [mp3encoder] decoding, how many chunks of "main info"?
Date: Sun, 4 Feb 2007 18:08:18 +0100

> reading in the ISO 11172-3 i see on page 43, Figure A.7.b. that
> the MP3 stream consists of frames (of course) and that a part of
> the "main data" can be located in a previous frame.
>
> That is ok so far, but in the example i see also that the "main data"
> can span _several_ previous frames.
>
> Is there a limitation to the number of previous frames that i
> need to consider for the "main data" of a frame?
>
> For example, i'm decoding frame 345, it is ok that i need to look
> back to frame 344 in some cases.  As i understand Figure A.7.b i
> also may need to consider frame 343.  How far can this reach back?
>
> Is this something that is just "on paper" but does not happen in
> reality?

Why don't you test by yourself :p ?
It happens every mp3 files.

The max number of buffered frames is 255, IIRC. It can be determined
by some easy calculation. The blow comments are cited from
'libmp3lame/encoder.h' in the LAME source.


    /* mpeg1: buffer=511 bytes  smallest frame: 96-38(sideinfo)=58
     * max number of frames in reservoir:  8
     * mpeg2: buffer=255 bytes.  smallest frame: 24-23bytes=1
     * with VBR, if you are encoding all silence, it is possible to
     * have 8kbs/24khz frames with 1byte of data each, which means we need
     * to buffer up to 255 headers! */
    /* also, max_header_buf has to be a power of two */


> How does this interfere with resyncing?  If i need to resync to a frame
> and i find a valid frame, but its "main data" starts in the 4th previous
> frame, then i have to skip this valid frame, is this correct?

Right. In the worst case, you need to skip 255 frames.


> Can anybody suggest me a pseudo-algorithm that considers both problems
> (resyncing & back-referring of "main data")?

Sorry, I've ever wrote an mp3 decoder and I cannot show you.
--
Takehiro TOMINAGA // may the source be with you!
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder