MSACM: winemp3 codec crashes on seek, reimplement with libmad?

[Eric Pouech]

Alex Villací­s Lasso wrote:
> Eric Pouech wrote:
> 
>> > Are there any issues
>>
>>> I should take into account before trying this?
>>
>> first of all, are we sure that the issue comes from the decoder itself 
>> (and not some wine wrapper around it) ?
> 
> I performed the following test: with the sample VB application, I 
> modified the winemp3 code to write the input buffer (mp3) and the 
> decoded output buffer (PCM) at the end of separate files. Then I played 
> the mp3 samples file. This one plays correctly (rules out mangling of 
> input buffers). The output file has quirks, but plays a little better 
> than the output from the VB application (no delays), which suggest that 
> there are some timing issues with the winemp3 code, or that the output 
> duration, as reported by winemp3, is slightly incorrect.
or simply, that the sequence of:
- getting mp3 encoded data
- pushing them to the decoder for decoding
- pushing the decoded data to the speaker
runs slower than the expected pace...
which doesn't blame only step2, or the decoder itself. for example, 
putting the decoder in a separate thread would greatly improve, or using 
smaller packets in step 1.

>> the second issue is that MAD is GPL... hence we cannot use it
>> A+
>>
> Too bad. I was thinking about adding a configure check for libmad and 
> linking to it, but then this would still disallow mixing the code. BTW, 
> when was the winemp3 code forked form mpg123? Maybe it is high time for 
> somebody (me?) to do a resync with the latest version of mpglib.
it's a couple of years old. at the time I looked for it, it was the only 
  LGPL mp3 decoder that I found.
A+

-- 
Eric Pouech