5

I know there are already a few questions like this here on SO, however they do not fully explain the formulas presented in the answers.

Im writing a parser that should be able to process MPEG-1,2,2.5 Audio Layer I,II,III frame headers. The goal is to calculate the exact size of the frame, including header, CRC (if present) and any data or metadata of this frame (basically the number of bytes between the start of one header and the beginning of the next one).

One of the code snippets/formulas commonly seen on the internet to achieve this is (in no specific programming language):

padding = doesThisFramehavePadding ? 1 : 0;
coefficient = sampleCount / 8;

// makes sense to me. the slot size seems to be the smallest addressable space in an mp3 frame 
// and is thus important for padding.
slotSize = mpegLayer == Layer1 ? 4 : 1;

// all fine here. bitRate / sampleRate yields bits per sample, multiplied by that weird 
// coefficient from earlier probably gives us <total bytes> per <all samples in this frame>.
// then add padding times slotSize.
frameSizeInBytes = ((coefficient * bitRate / sampleRate) + padding) * slotSize;

I have multiple questions regarding above code snippet:

  1. What exactly would this "coefficient" even represent? As it's just sampleCount / 8 it's probably just something used to convert the units from bits to bytes in the final calculation, right?
  2. If my assumption from 1. is correct: if (coefficient * bitRate / sampleRate) already yields something in bytes what would multiplying it with the slot size achieve for Audio Layer I specifically? Wouldn't this imply that the unit of (coefficient * bitRate / sampleRate) should have been "slots" earlier, not "bytes"? If so, then what does the coefficient do, like why divide by 8, even for audio layer 1 frames? Is this even correct?
  3. Questions 1. and 2. lead me to believe that the code snippet above may not even be correct. If so what would the correct calculation for MPEG versions 1,2,3.5 and layers I,II and III look like?
  4. Does above calculation still yield the correct result if the CRC protection bit is set in the frame header (i.e. 16 additional CRC bytes are appended to the header)?
  5. Speaking of the header: are the 4 header bytes included in the resulting frameSizeInBytes or does the result indicate the length of the frame data/body?

Basically all these sub-questions can be summarized to:

What is the formula to calculate the total and exact length of the current frame in bytes, including the header, and stuff like CRC, or Xing and LAME meta data frames and other eventualities?

Frederik Hoeft
  • 1,177
  • 1
  • 13
  • 37
  • 1
    Not sure why you got no Answer here but see if [this one is useful](https://stackoverflow.com/questions/57103676/formula-from-mp3-frame-length/57123251#57123251) to you. I'm not sure where you're getting this `slotSize` from? If you ignore it, for now, then your remaining formula for `frameSizeInBytes` is correct. The `coeffecient` is the **sample count per MP3 frame** which is a specific/set amount, depending on the layer version. Where `layer I = 384 samples` and also `layer II or III = 1152 samples` so **1152 samples / 8 bits** gives **coefficient** as **144**. Ask anything for clarity. – VC.One Jun 09 '22 at 08:21
  • @VC.One Thanks for your comment :) Your explanation of the coefficient did help clarify things a lot. I assume substituting the coefficient with 144, would yield the same (or a similar) formula as presented in [http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm](http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm). The same site also explains the `slotSize` in further detail under section "Padding Bit": `Frame length is length of a frame when compressed. It is calculated in slots. One slot is 4 bytes long for Layer I, and one byte long for Layer II and Layer III.` – Frederik Hoeft Jun 09 '22 at 08:42
  • This makes me believe the formula is mostly correct then. Still I was unable to find any information if the CRC would be included in the length, or whether it should be stripped from the calculation and it's length added separately. – Frederik Hoeft Jun 09 '22 at 08:44
  • Do you have an MP3 with a CRC check? It's a quick test (on the bytes) to confirm if `frameLength` versus `frameLength+2` is the one that gets you to a new MP3 header's beginning. I don't remember processing MP3 of Layer 1, mostly layer 3. My understanding is if Layer 1 then `framebytes = frameLength * 4` else if Layer 2/3 then `framebytes = frameLength * 1` – VC.One Jun 09 '22 at 09:45
  • A couple months later I still was unable to find an audio sample with CRC protected frames in our data set, so I guess at least for this project that whole CRC thing has lost it's relevance. It would still be interesting to know. I was able to verify with a hex editor that the 4 byte header size IS included in the result. I would then assume that the CRC would be included as well. However I could not verify this. – Frederik Hoeft Dec 06 '22 at 14:47

0 Answers0