MPEG 2 and 2.5 - problems calculating frame sizes in bytes
-
I have a console program which I have used for years, for (among other things) displaying info about certain audio-file formats, including mp3. I used data from the mpeghdr site to calculate the frame sizes, in order to further calculate playing time for the tracks. The equation that I got from mpeghdr was:
// Read the BitRate, SampleRate and Padding of the frame header.
// For Layer I files use this formula:
//
// FrameLengthInBytes = (12 * BitRate / SampleRate + Padding) * 4
//
// For Layer II & III files use this formula:
//
// FrameLengthInBytes = 144 * BitRate / SampleRate + PaddingThis works well for most mp3 files, but there have always been a small subset for whom this equation failed. Recently, I've been looking at a set of very small mp3 files, and have found that for these files this formula fails *much* more often, so I'm trying to finally nail down what is going on. In all cases, I can successfully find the first frame header, but when I used the above formula to calculate the offset to the *next* frame header, it is sometimes not correct. As an example, I have a file 'wolf howl.mp3'; analytical files such as MPEG Audio Info show frame size as 288 bytes. When I run my program, though, it shows length of first frame as 576 bytes (2 * 288). When I look at the mp3 file in a hex editor, with first frame at 0x154, I can see that the next frame is at 0x154 + 208 bytes, but this calculation *does* in fact result in 576 bytes...
File info:
mpegV2.5, layer III
bitrate=variablebitrate=32, sample_rate=8000, pad=0, bytes=576
mtemp->frame_length_in_bytes =
(144 * (mtemp->bitrate * 1000) / mtemp->sample_rate) + mtemp->padding_bit;
which equals 576So what am I missing here?? I've looked at numerous other references, and they all show this equation... At first I thought is was an issue with MPEG 2.5, which is an unofficial standard, but I have also seen this with MPEG2 files as well. Does anyone have any insights on what I am missing here?? //************************************** Later notes: I thought maybe audio format would be relevant to this issue, so I dumped channel_mode and mode_extension for each of my test files (3 calculate properly, 2 don't). Sadly, all of them are cmode=3, mode_ext=0 (i.e., last byte of the header is 0xC4)... so that doesn't help...