Been attempting to build LAME_ENC.DLL support into CD Wave. After re-factoring the whole output logistics to support other-than-WAV files, I couldn't get it to work.

I peeked around, noticing the OGG Vorbis codec offers a very similar interface, and that worked on the first attempt. If you want proof, download the (very) beta http://www.cdwave.com/cdwav192.exe (vorbis.dll is included in the package).

The lame_enc.dll will crash with an access violation error when calling the encode chunk function. I translated most of the stuff from C(++) to Delphi.
On one occasion, it really did encode the file, but crashed close to the end. The MP3 was playable though, and sounded just fine. I never managed to reproduce this.

Forgot to bring a few code snippets, but are there any LAME programmers who know what to look for? Is there some undocumented 'feature' in the DLL interface that makes it crash....

I tried with the rarewares distribution, using v 1.90.3, 1.92.something and the 1.93 alpha version, but they all behaved identically.

There was a fix in 3.94 regarding delphi. The problem was that the declaration of calling convention in the .pas file was wrong. Perhaps this is your case?

If the declaration (stdcall?) is wrong, yeah, but most of the functions appear to work just fine. I'll try with the latest 1.94 DLL...

What usually happens is that after calling 'encodeChunk', it returns 0 (success) and sets (or leaves) dwWrite (number of output bytes) to zero.
But in the mean time, some of my local variables have been destroyed, leading to the AV crash. Sometimes the crash takes place inside the DLL.

I also tried 'fixing' for buffer overruns by allocating 4x the memory that LAME wanted, and supplying a pointer in the middle of that memory, so that it could read/write way outside that buffer. Didn't help, the problem seems to be with the stack.

The declaration should be cdecl, not stdcall.

It is perfectly normal for Lame to sometimes return 0 output bytes. It just means that it needs more data before returning any compressed data.

But your local variables beeing destroyed is not normal.

Hmm, cdecl (guess that makes it use the C calling model) would not cleanup the stack afterwards, which would explain the stack corruption i saw (not corruption, just not moving the SP back to where it was upon call). I'm surprised that it got as far as it did (I built an OO shell around it)...

Have to check (am at work now) if that's the case...

I'd expect the vorbis.dll to use something similar, have to check that one out...

The dwWrite being zero is no problem, but it's just one of the symptoms just before the thing goes down...

M.

Gabriel, do you know if it is possible to use the LAME DLL with Visual Basic? I searched the net but couldn't find anything. The only example for VB used another wrapper DLL written in C, but it supported only setting the bit rate.

Of course you can use the Lame dll from VB. VB is able to call C functions from dll. Using Lame with VB should not be different than using any other C dll.

Well, that did the trick. (ESP register not restored correctly on function return...)

Got it working correctly now. Now for setting some good defaults...

I guess the mapping of the normal/extreme/insane presets to the BE_CONFIG struct are a well kept secret? I tried to figure things out by looking at the source (presets.c) but couldn't make much of that...

Think i'll set some low end for portable players (64kbps, or would that be a bad idea), medium for home/car use (128), good for home (VBR around 160) and "archive" something like 256kbps VBR.

Currently, it's only doing 128kbps (in "high" or "very high" quality mode)...

http://www.cdwave.com/cdwav192.exe

Mike

Not really. Have a look at LAME_QUALITY_PRESET in blademp3encdll.h, you will find the values you are searching for.

Btw, with 3.94 it should be easier as there will be no need anymore to set preset values.

Gabriel, did anyone ever tell you you're an angel?


This is gonna be a busy Xmas holiday...

Now if only there was a shorten (shn) DLL, I could make some etree.org users very happy. Ah well, I can always include an 'external program' compressor.. 'nuf to do for the holidays.

etree users would also appretiate FLAC support (using libFLAC). Thanks for your work on this simple but great tool.

dev0

libFLAC's on my disk since yesterday... No promises but I usually have quite some time on my side during the Xmas holidayz...

e-Tree users rejoice then - CD Wave 1.92 (beta) can now write FLAC files directly. (Using libFLAC.dll)

Now I guess what I need to do next is to write 5 pages of acknowledgements and stuff for all the libraries and source code I used to get this going...