2.72 File info for large MP3s incorrect

[BigD2001]

I have recorded many very long MP3's using MusicMatch 5.0 and 6.0 over the past couple years.

I recently noticed that on the file info screen (Alt-3 from the playlist editor), these large files never show a correct duration. More precisely, any file larger than 268,435,455 bytes is always incorrectly displayed. This number is (2^31 / 8) - 1.

All of my large files are CBR and are recorded at various bit rates (from 96k to 256k). Some are Joint Stereo, some are just Stereo, etc. (these details don't matter).

I did some research over the past few days and found the reason why. WinAmp must be using code like the following to calculate the MP3 duration:

Length = FileSize * 8 / BitRate

Here is the info from one example recording:

Size: 707288503 bytes
Header found at: 0 bytes
Length: 6086 seconds
MPEG 1.0 layer 3
224kbit, 1937776 frames
44100Hz Stereo
CRCs: No
Copyrighted: No
Original: No
Emphasis: None

WinAmp calculates the length as 6086 seconds, even though the true length is 25260 seconds. This error is due to 32-bit signed integer overflow when multiplying by 8.

Length = 707,288,503 * 8 / 224,000
Length = 1,363,340,728 / 224,000
Length = 6,086.343 seconds (wrong!)

Actually, 707,288,503 * 8 is 5,658,308,024, which is too big for 32 bits, so the extra bit is lost. A better formula to use would be:

Length = FileSize / (BitRate / 8)

Length = 707,288,503 / (224,000 / 8)
Length = 707,288,503 / 28,000
Length = 25,260.304 seconds (correct!)

Next, using the first calculation can lead to lengths that are negative. For example, here is another set of statistics:

Size: 416432128 bytes
Header found at: 1712 bytes
Length: -10036 seconds
MPEG 1.0 layer 3
96kbit, 2669425 frames
44100Hz Joint Stereo
CRCs: No
Copyrighted: No
Original: Yes
Emphasis: None

As you can see, 416,432,128 * 8 results in a signed result of -963,510,272, and dividing by 96,000 results in
-10,036.565 seconds, exactly what WinAmp displays.

I think you really should be using an "unsigned long int" 32-bit integer to represent your file size to begin with, since a file size can't ever possibly be negative, at least not in my universe. I am a lead programming supervisor at my company, and I'm always getting on to my developers for details like this that result in erroneous behavior near boundary conditions.

But, even if you don't change that datatype, if you alter your calculation to Length = FileSize / (BitRate / 8), you will still result in a correct Length for FileSizes up to 2 gigs. I haven't recorded any 2 gig MP3s yet, but you never know. If you change to using unsigned integers, you'll be able to correctly handle an MP3 up to 4,294,967,295 bytes.

Length should be unsigned too, by the way.

When files like this are queued into the playlist (not actually playing yet), the time displayed is either the shorter, incorrect time when the Length is positive, or just blank when the Length is negative.

Finally, when WinAmp begins actually playing these files, it must change to using the correct Length calculation, because the time updates on the playlist editor to the correct time and correctly plays all the way to the end. But, the Length shown in the file info screen continues to be incorrect.

I hope the information I have provided is sufficient for you to correct your code. If you need further details, I'll be glad to try to provide them. Thanks for a great product!

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? It sure is a pretty simple fix.