2.72 Frame count for all CBR MP3s incorrect

[BigD2001]

Well, at least all the MP3s I have tested so far. Anyway, in the MPEG file information shown (Alt-3 from the playlist editor), the calculation for number of frames is not correct.

Example 1 - File Info for a typical MP3:

Size: 2253996 bytes
Header found at: 0 bytes
Length: 112 seconds
MPEG 1.0 layer 3
160kbit, 8636 frames
44100Hz Joint Stereo
CRCs: No
Copyrighted: No
Original: Yes
Emphasis: None

When I examined this file in a hex editor, I found that it really only contained 4,318 MPEG frames!

The way I have seen to calculate the expected number of frames is this:

const SamplesPerFrameLayer3 = 1,152
const BitsPerSample = 8
const FrameByteMultiplier = SamplesPerFrameLayer3 / BitsPerSample (144)

FrameLengthInBytes = FrameByteMultiplier * BitRate / SampleFrequency + PaddingLength

SampleFrequency will normally be 44,100 Hz.
PaddingLength will be either 0 or 1.

So, for the file above, the formula would be:

FrameLengthInBytes = 144 * 160,000 / 44,100 + 0
FrameLengthInBytes = 522 bytes

If you then take:

NumberOfMpegFrames = FileSize / FrameLengthInBytes
NumberOfMpegFrames = 2,253,996 / 522
NumberOfMpegFrames = 4,318 frames

I can't really guess what sort of code WinAmp is using to arrive at a value that is precisely double this number.

I did verify in my hex editor that the MP3 really does contain exactly 4318 frames, so I think my calculation is correct.

Note that my formula does not take into account the case where the MP3 file has 16-bit CRC protection set, or when a bit reservoir is employed. I don't have any files with CRC turned on, so I don't want to guess what the correct formula really is and then have it be incorrect.

If I'm all wrong and WinAmp is defining "frame" differently than I am, and it really is correct, please let me know. I'm always ready to admit when I'm wrong.

Dennis

[BigD2001]

I kind of thought I'd get at least one response to my bug report.

Is this fixed in the upcoming 3.0?