sample scaling produces clipping after resync on MSVC++
Brought to you by:
sobukus
Menu
▾
▴
#86 sample scaling produces clipping after resync on MSVC++
Somewhere between 1.6.2 and the current trunk a new problem was introduced that only occurs when using a libmpg123 compiled with MSVC++.
It happens while decoding mp3s in feeder mode. If a resync is needed, for example after fuzzy seeking or when decoding a broken mp3 file the decoded audio will sometimes start to clip badly. The decoding itself continues correctly there are no error values returned from libmpg123 calls. Only the decoded audio samples clip. This happens regardless of the output format. When decoding to float, the values are way out of range, often even greater than 32768.
When I compared the debug log output of successfull decoding with 1.6.2 and a clipping decoding with trunk and have not found any differences, everything looks correct.
As said above, the clipping occurs only sometimes, not on every resync.
Attached is a small program and a mp3 that reproduce the problem. The mp3 is broken and during decoding libmpg123 needs to resync. After the resync the audio will clip. The exactly same code will work without problems in 1.6.2 and on trunk on plattforms other than MSVC++. Turn down the volume when testing :-)
Small app that reproduces the clipping problem
broken mp3 that reproduces the clipping problem
File Added: bad.mp3
Observe this recent commit:
r1815 | thor | 2009-02-14 11:06:42 +0100 (Sa, 14. Feb 2009) | 8 lines
Most probably pinned bug 2472726.
I finally have been able to reproduce it with the help of valgrind, which changed the memory management.
After a resync, the frame buffers get (re)allocated, in case of the decwin, that's a free() of the old and immediately malloc() of the new.
With normal glibc memory management that resulted in the same block of memory than before being assigned (when the size did not change).
Thus, the failure to call make_decode_tables on the new memory ws hidden because the old values were still there.
So, the easy fix is to call make_decode_tables everytime after changing the frame buffers. Waiting for confirmation from the Windows folks...
-----
So, I am confident that another test on Windows will work fine.
After a corresponding heads-up, I'd like to think about releasing a 1.7.0 beta.
I confirm that this bug has been fixed with r1815. Thanks a lot!