Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: LAME_ENC.DLL programming (Read 11528 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME_ENC.DLL programming

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.

LAME_ENC.DLL programming

Reply #1 –
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?

LAME_ENC.DLL programming

Reply #2 –
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.

LAME_ENC.DLL programming

Reply #3 –
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.

LAME_ENC.DLL programming

Reply #4 –
Quote
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.

LAME_ENC.DLL programming

Reply #5 –
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.

LAME_ENC.DLL programming

Reply #6 –
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.

LAME_ENC.DLL programming

Reply #7 –
Quote
The declaration should be cdecl, not stdcall.

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

LAME_ENC.DLL programming

Reply #8 –
Quote
I guess the mapping of the normal/extreme/insane presets to the BE_CONFIG struct are a well kept secret?


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.

LAME_ENC.DLL programming

Reply #9 –
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.

LAME_ENC.DLL programming

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

dev0
"To understand me, you'll have to swallow a world." Or maybe your words.

LAME_ENC.DLL programming

Reply #11 –
Quote
etree users would also appretiate FLAC support (using libFLAC).

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

LAME_ENC.DLL programming

Reply #12 –
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...