http://bugs.winehq.org/show_bug.cgi?id=11659
Summary: acmStreamConvert inconsistencies (Windows Vs Wine for mp3 -> pcm) Product: Wine Version: 0.9.55. Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: msacm32 AssignedTo: wine-bugs@winehq.org ReportedBy: lightning_uk@imgburn.com
When attempting to convert MP3 to PCM (Stereo, 44100Hz, 16bit - for burning to a disc) the acmStreamConvert function (working synchronously) does not work as expected (doesn't do what Windows does).
The 'cbSrcLengthUsed' value within the ACMSTREAMHEADER structure is not updated with the correct value (or the wrong amount of data is actually used).
When 'cbSrcLength' and 'cbDestLength' are set to the same value (in my case, 75264), after conversion 'cbSrcLengthUsed' is always being set to the entire size of the source buffer (75264) rather than the amount of the source buffer that was actually used to create the content in the destination buffer.
Windows behaviour on first two calls to acmStreamConvert...
D 10:41:06 FileSize: 5339011 D 10:41:06 CurrentFileBytesRead: 75264 D 10:41:06 cbSrcLength: 75264 D 10:41:06 cbSrcLengthUsed: 16343 D 10:41:06 cbDstLength: 75264 D 10:41:06 cbDstLengthUsed: 73728
D 10:41:06 FileSize: 5339011 D 10:41:06 CurrentFileBytesRead: 91607 D 10:41:06 cbSrcLength: 75264 D 10:41:06 cbSrcLengthUsed: 10031 D 10:41:06 cbDstLength: 75264 D 10:41:06 cbDstLengthUsed: 73728
Wine behaviour on first two calls to acmStreamConvert...
D 10:33:22 FileSize: 5339011 D 10:33:22 CurrentFileBytesRead: 75264 D 10:33:22 cbSrcLength: 75264 D 10:33:22 cbSrcLengthUsed: 75264 D 10:33:22 cbDstLength: 75264 D 10:33:22 cbDstLengthUsed: 73728
D 10:33:22 FileSize: 5339011 D 10:33:22 CurrentFileBytesRead: 150528 D 10:33:22 cbSrcLength: 75264 D 10:33:22 cbSrcLengthUsed: 75264 D 10:33:22 cbDstLength: 75264 D 10:33:22 cbDstLengthUsed: 73728
Applications are supposed to move the source buffer on by 'cbSrcLengthUsed' bytes after each call to acmStreamConvert.
The source buffer is therefore being used up far too quickly and the conversion is considered complete long before it actually is.
http://bugs.winehq.org/show_bug.cgi?id=11659
Chris chris.kcat@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chris.kcat@gmail.com
--- Comment #1 from Chris chris.kcat@gmail.com 2008-02-20 06:08:45 --- Actually what Wine's doing is buffering all src data, then decoding however much it can from that buffer, and leaves the rest until the next call. So you do increment the source data by the amount "used". The difference is that Wine leaves the extra source data buffered for the next call, whereas Windows leaves it unbuffered and reports it unused.
Of course, Wine's method can cause some problems to unsuspecting apps. Namely that the buffered input will continue to grow as long as there's not enough output to decode it all. If you attempt to continue buffering 0 src bytes until you get 0 dst bytes, you'll get everything.. but I suppose this should be fixed to match Windows' behavior.
http://bugs.winehq.org/show_bug.cgi?id=11659
--- Comment #2 from lightning_uk@imgburn.com 2008-02-20 06:33:30 --- Thanks for the info, it's nice to know how these things work :-)
Knowing what I know now, I can work around the problem - but as you say, it really should be emulating how Windows does it.
http://bugs.winehq.org/show_bug.cgi?id=11659
--- Comment #3 from Austin English austinenglish@gmail.com 2008-06-03 13:09:17 --- Is this still an issue in 1.0-rc3?
http://bugs.winehq.org/show_bug.cgi?id=11659
--- Comment #4 from Chris chris.kcat@gmail.com 2008-06-03 14:01:30 --- The original issue seems to be patched (it doesn't keep the extra data buffered anymore), but it seems there's another related issue (not buffering on very small data lengths, such that 0 source bytes are used, causes some apps to try and resend it without adding more data). It doesn't seem to be a major issue, and is probably something to look into later after 1.0. I'm not sure if it's because the small data chunks should be buffered, or if an error isn't being properly propagated back to the app.
http://bugs.winehq.org/show_bug.cgi?id=11659
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #5 from Austin English austinenglish@gmail.com 2008-06-03 15:00:05 --- Let's resolve this one fixed then. Please open a new bug for the other issue.
http://bugs.winehq.org/show_bug.cgi?id=11659
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2008-06-06 10:39:05 --- Closing bugs fixed in 1.0-rc4.
-
wine-bugs＠winehq.org