Recently I had been playing around with the Visual Basic version of Visual Studio Express and somehow mucked it up real good. It told me it could not create the Visual Basic compiler and I should re-install. I re-installed and it was still mucked up so I completely removed Visual Basic and SQL Server pending an epiphany of sorts.
A couple of days ago I decided to rip a copy of the songs on a CD I got for Christmas for my portable player. I used Windows Media 11 to rip the copy but then I remembered that I preferred using Exact Audio Copy for ripping CDs. EAC makes a persuasive argument that they make a better copy. Since I had re-built my desktop since the last time I ran EAC, I had to re-install EAC. As part of the installation I had to install the LAME MP3 Encoder, too. Although I had a binary version of LAME available I decided this might this might be a good time to work through my Visual Studio Express problems. I would be working with C++ rather than Visual Basic environment but I expected that what I learned from the Visual Studio Express framework under C++ would also apply to Visual Basic environment. I expect that Visual Studio reuses most of the IDE environment. Since I had already downloaded the DVD with all of the Visual Studio 2008 Express packages on it the installation should be relatively painless. So I installed the C++ package.
The big challenge would be to fix the errors and warnings from using the 2008 compiler version. The only error I had to fix was the errors resulting from a missing msacmdrv.h. Since I did not have access to the Window DDK, I decided to use the version included in the ACM\ddk directory. I copied it into the ACM directory.
It took a little research to get rid of the warnings. Someone advised that I compile LAME from the command prompt using the included Makefile for the Microsoft compiler.
To build LAME from the included Makefile I had to:
- Download a copy of NASM. Extract nasm.exe from the file, rename it to nasmw.exe, and copy into the lame-3.97 directory. The makefile we are going to use requires nasmw.exe.
- Open a command prompt from Visual Studio using the “Tools-Visual Studio 2008 Command Prompt” menu item. This opens a command prompt with the environment path variables set properly to use the command line versions of the C++ compiler and linker.
- Change the directory to the project directory, lame-3.97.
- Type “nmake -f Makefile.MSVC COMP=MS” and press Enter.
- A LAME executable was created and the only messages I got were warning messages about invalid /QIof and /QIfdiv compiler parameters.
Okay, that wasn’t too bad! Since I had not been humbled by a compiler in the last thirty seconds I decided to see if I could do the whole process inside Visual Studio.
To build LAME from inside the Visual Studio environment I had to:
- I saw that there was a sln file(probably a VC7 workspace) available so I decided to let Studio try and convert the workspace. I was a little leery since I tried converting a Visual Basic workspace recently and I really made a mess of it. In this case the conversion appeared to create a working environment.
- The first time I built the solution using the converted workspace, I generated a lot of warning messages and the executable seemed large. So I set out to “fix” the problems. Some of the warnings were related to deprecated I/O functions that may be unsafe. In this environment I deemed them safe so I “fixed” the problem by including a compiler parameter, /D “_CRT_SECURE_NO_WARNINGS”, on the command line page for the lame project. I deleted references to /QIof and /QIfdiv on the command line page since these are not valid compiler parameters. I added the compiler parameters, /O2, /Ob2, /Zp8, /GL, and /Zi, to the optimization page since the Makefile used these parameters. I changed these parameters on libmp3lame, mpglib, and lamemp3encdll.
- To build the solutions, you select a Solution Configuration and press F7. There are twelve different configurations but I was interested in the configuration to build the DLL, “dll release”, and the one to build the lame.exe, “LAME release”. When I built these solutions I was only getting 24 warning messages. Almost all of the messages were related to type conversion(e.g. float to double). It would be nice if there were no warning messages but these message looks to be harmless. I am unwilling to mess with other people’s code unless it does not work. If everything compiles without errors(warnings are okay 😉 ), lame.exe and lame_enc.dll should be in the output folder.
I tested LAME by running LAME with the input file, testcase.wav, and comparing its size to the testcase.mp3 file included in the distribution. I got the same size files so it must be working. 😉