The problem:
Some users are reporting crashes when using the Lame ACM codec, mainly in VirtualDub.
I strongly believe that this is a compilation issue, but we need your help in identifying the problem.
A test version is there: http://gabriel.mp3-tech.org/lame (This one is VC6 compile)
Please report your crashes or success (do not forget to specify where did you get the ACM)
Full Version: Lame ACM codec problems - please help
The lame acm from RareWares crashes Windows Audio Codecs Properties page ( the one accessible from Control Center ) . Your version ( the one from gabriel.mp3-tech.org ) installs fine and does not crash codec properties page but encoding to mp3 with Windows Media Player produces garbage mp3 though I do not know if encoding with Windows Media Player supported with lame acm.
Btw I use Windows XP SP1 and Windows Media Player 9
Btw I use Windows XP SP1 and Windows Media Player 9
My compile is VC++6 with SP5, compiled without DDK (using the alternative msacmdrv.h)
I've recompiled the ACM and I believe that it is now OK. The new download at Rarewares is only actually 'new' in relation to the ACM, the .exe and .dll are the same compiles as before.
If there is still a problem, please advise soonest!!
EDIT:
@Gabriel: How did you manage to compile under MSVC6, all I get is errors in ACM.cpp? Intel passes them as warnings, BTW.
If there is still a problem, please advise soonest!!
EDIT:
@Gabriel: How did you manage to compile under MSVC6, all I get is errors in ACM.cpp? Intel passes them as warnings, BTW.
QUOTE
I've recompiled the ACM and I believe that it is now OK
If you identify what was the problem, please mention it.
QUOTE
How did you manage to compile under MSVC6, all I get is errors in ACM.cpp?
I did nothing special:
*open lame_vc6.dsw
*select the ACM as active project
*compile
My VC6 is patched with sp5, and I am using the msacmdrv.h provided with Lame as I do not have any DDK.
QUOTE (Gabriel @ Jan 14 2004, 03:02 PM)
QUOTE
I've recompiled the ACM and I believe that it is now OK
If you identify what was the problem, please mention it.
I basically removed the limited machine specific optimisations and also removed the optimisations that Dibrom used for 3.90.2.
QUOTE (Gabriel @ Jan 14 2004, 03:02 PM)
QUOTE
How did you manage to compile under MSVC6, all I get is errors in ACM.cpp?
I did nothing special:
*open lame_vc6.dsw
*select the ACM as active project
*compile
My VC6 is patched with sp5, and I am using the msacmdrv.h provided with Lame as I do not have any DDK.
The following error messages are the output I get from VC6 + SP5:
QUOTE
E:\lame-3.95.1\ACM\ACM.cpp(523) : error C2664: 'GetMP3FormatForIndex' : cannot convert parameter 3 from 'char [128]' to 'unsigned short []'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(540) : error C2664: 'GetPCMFormatForIndex' : cannot convert parameter 3 from 'char [128]' to 'unsigned short []'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(656) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [48]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(700) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [32]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(703) : error C2664: 'MultiByteToWideChar' : cannot convert parameter 5 from 'char [128]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(704) : error C2664: 'MultiByteToWideChar' : cannot convert parameter 5 from 'char [128]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(705) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [80]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(706) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [128]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(708) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [512]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(540) : error C2664: 'GetPCMFormatForIndex' : cannot convert parameter 3 from 'char [128]' to 'unsigned short []'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(656) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [48]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(700) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [32]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(703) : error C2664: 'MultiByteToWideChar' : cannot convert parameter 5 from 'char [128]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(704) : error C2664: 'MultiByteToWideChar' : cannot convert parameter 5 from 'char [128]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(705) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [80]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(706) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [128]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
E:\lame-3.95.1\ACM\ACM.cpp(708) : error C2664: 'lstrcpyW' : cannot convert parameter 1 from 'char [512]' to 'unsigned short *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
I am using the DDK, but I don't see that as the problem.
QUOTE
I basically removed the limited machine specific optimisations and also removed the optimisations that Dibrom used for 3.90.2.
Does this mean that for 3.95 you are still using this non C-compliant rounding mode?
QUOTE
I am using the DDK, but I don't see that as the problem.
It seems that your DDK is forcing you to use the wide char win32 APIs (btw this would break compatibility with win95).
Try without the DDK: simply copy the alternative msacmdrv.h into Lame's ACM directory, this should disable the use of your DDK. (at least I hope)
QUOTE (Gabriel @ Jan 14 2004, 03:48 PM)
QUOTE
I basically removed the limited machine specific optimisations and also removed the optimisations that Dibrom used for 3.90.2.
Does this mean that for 3.95 you are still using this non C-compliant rounding mode?
For the .exe and the .dll, yes. Would you prefer that I break with that now?
QUOTE (Gabriel @ Jan 14 2004, 03:48 PM)
QUOTE
I am using the DDK, but I don't see that as the problem.
It seems that your DDK is forcing you to use the wide char win32 APIs (btw this would break compatibility with win95).
Try without the DDK: simply copy the alternative msacmdrv.h into Lame's ACM directory, this should disable the use of your DDK. (at least I hope)
OK, I've done this, recompiled and uploaded again.
Ok anyone has an idea why with lame acm WMP9 encoded mp3s are sound garbage? Known problem? 
QUOTE
For the .exe and the .dll, yes. Would you prefer that I break with that now?
I would definitively prefer C compliance.
QUOTE (Gabriel @ Jan 14 2004, 06:28 PM)
QUOTE
For the .exe and the .dll, yes. Would you prefer that I break with that now?
I would definitively prefer C compliance.
OK, I'll make that effective with all future encodes of 3.95.1 and later.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.