Hello,

i'm using Lame dll for 2 years without any compliance, until now!

I tried to update to Lame 3.95.1 dll and i get Access Violation Error (in beEncodeChunk call). I tried Mitiok's, John33's and Gabriel Bouvigne's compile,
everytime same action. When i replace dll with 3.93.1 version, everything work GREAT!

Thank you very much for any help or hint.

Byvaly.

we need to know several things:
*which application are you using
*what parameters are you using
*does the problem happen with every tracks or just some specific tracks
*if the problem is only happening on some specific tracks, we would need access to one of those tracks

edit: a test version of the dll is here:
http://gabriel.mp3-tech.org/lame

Hello Gabriel,

>*which application are you using
it's mine...

>*what parameters are you using
with BE_CONFIG.Format.LHV1 do
begin
dwStructVersion := 1;
dwStructSize := SizeOf(BE_CONFIG);
dwSampleRate := 8000;
dwReSampleRate := 0;
nMode := 3;
dwBitrate := 16;
dwMaxBitrate := 16;
nPreset := -1;
dwMpegVersion := 0;
dwPsyModel := 0;
dwEmphasis := 0;
bPrivate := True;
bCRC := True;
bCopyright := True;
bOriginal := True;
bWriteVBRHeader := False;
bEnableVBR := False;
nVBRQuality := 0;
dwVbrAbr_bps := 0;
nVbrMethod := -1;
bNoRes := True;
bStrictIso := False;
nQuality := 0;
end;


>*does the problem happen with every tracks or just some specific tracks
every track

Thank you for your help! Byvaly.

Isn't the dll working when used with other programs?

It works fine with CDex 1.51.

One possible gotcha: you're probably not filling the struct with zeroes before passing parameters.

Second: If I were you, I'd check BE_CONFIG, where are you getting it from?

>Second: If I were you, I'd check BE_CONFIG, where are you getting it from?

I do not understand meaning, could you be more specific, please?

Thank you.

Are you getting it from LAME headers, or some intermediate Pascal unit?

i get it from this archive

http://cesnet.dl.sourceforge.net/sourcefor...e-3.95.1.tar.gz

and header file

\Dll\BladeMP3EncDLL.h

Hello Gabriel,

today i've tried the same encoding in different app - CDEx 1.51, with new 3.95.1 dll
and is NOT W O R K I N G!!! CDEx crashed the same way as in my own app. So it seems to be dll bug, not the application one!

I'm sending you CDex setting:
Options, Settings, Encoder -->

Version: 2.5
Bitrate: 16
Mode: mono
all flags set
Quality: 0
On the fly: yes
VBR: disabled
Output: Auto

Also i've enabled WriteLogFile and this's log content:

Lame_enc configuration options:
==========================================================
version =0
Layer =3
mode =Mono
Input sample rate =8.0 kHz
Output sample rate =8.0 kHz
bitrate =16 kbps
Quality Setting =0
Low pass frequency =4000
Low pass width =-1
High pass frequency =0
High pass width =-1
No short blocks =0
Force short blocks =0
de-emphasis =0
private flag =1
copyright flag =1
original flag =1
CRC =on
Fast mode =disabled
Force mid/side stereo =disabled
Padding Type =2
Disable Reservoir =0
Allow diff-short =0
Interchannel masking =0.001000
Strict ISO Encoding =No
Scale = 0.95
VBR =disabled, VBR_q =4, VBR method =vbr_off
Vbr Min bitrate =16 kbps
Vbr Max bitrate =16 kbps
Write VBR Header =No
VBR Hard min =0
ATH Only =0
ATH short =0
ATH no =0
ATH type =4
ATH lower =0.000000
ATH aa =-1
ATH aa loudapprox =2
ATH aa sensitivity =0.000000
Experimental nspsytune =1
Experimental X =1
Experimental Y =0
Experimental Z =0

Thank you for any help! Byvaly.

Hi Gabriel,

I just wonder why no one complain about this ...

The ACM also affect EAC from starting, when I switch to 3.92 everything back to normal.

Also VirtualDub will crash sometimes, depends on the bitrate I choose.

I just tryed your settings in CDEx, with 3.95.1 from Mitiok and 3.96 (fresh compile). Both worked fine.

Perhaps the problem happens only with some of your files? Did you tryed to encode other files?

http://gabriel.mp3-tech.org/lame/
Does it also crash with this ACM codec ?

The latest compiles of 3.95.1 and 3.96 alpha are fine here with CDex, EAC.

I think that I found the problem. It could happen when using mpeg 2.5, but not always, so it was hard to spot.
Please try with some 3.96a2 compiles when they will be available.

The DLL also crashes (at any setting) when the source input is 22kHz mono. Converting it to stereo or to 44100 makes it run OK again. Commandline doesn't do this.

Works for me. You will have to be a little more specific: provide settings and eventually a sample.

Hello Gabriel,

i tried several files and ALL crashed!

I can try some other test files, if you provide ones...

Is there any newer build, please?

Thank you for GREAT job!

Hello John33,

did you tried my "crash" setting in EAC or CDex, please?

Version: 2.5
Bitrate: 16
Mode: mono
all flags set
Quality: 0
On the fly: yes
VBR: disabled
Output: Auto

Yep, I tried your settings with CDex 1.51 with 3.95.1 and 3.96alpha and both worked flawlessly. I also tried using the ACMs with EAC and, although the setting options are much more limited, they both worked fine.

Hello John33,

could you share your test files, please?

So i can try it too...

Thank you.

Do you mean the dlls? Or the music? The music sample is 40Mb, but I don't think that is a relevant factor. I just tried 3.95.1 with several samples, including the famous 'applause.wav', and it was fine with all of them. If you want the binaries, they're the ones at Rarewares.

Hello Gabriel,

Is there any newer build - i can test, please?

Thank you for GREAT job!

http://mitiok.free.fr

You will find there 3.96a2

What might make a difference is how you allocate the buffers. If you allocate using some language's internal malloc or getmem call, chances are that you're allocating from the program's pool of memory. Reading/writing outside the memory block will usually not cause an AV because there's nothing protected around it (you'll just be poking into other objects' data).

If you allocate using Window's GlobalAlloc(...) routines, the block will be protected and any buffer over- or underflow (well, rounded to 16 bytes) will cause an AV error. Coming from the Windows 3.x programming environments, I still have the habit of allocating memory buffers to be passed to DLL functions using GlobalAlloc (you had to in those days...). So I'd have to check if this appears to fix the problem. If it does, the new LAME is probably reading a few bytes outside of the allocated buffers which triggers the CPU exception.

Does that mean that you still have a problem with 3.96a2?

I didn't find any compiled version 3.96.

I tried the one I could find (4.0a10) from http://mitiok.free.fr

The DLL reports version 1.1 and a build date of 17 jan 2004.

It crashes on any VBR rate, including "old" presets (VOICE, TAPE, etc) when input file is 22050Hz Mono 16-bit.

It crashes on 64kbps VBR/ABR on 44100/16 input.

In all cases, it's a NULL pointer exception, it tries to access address 0.

Still have to gather the BE_CONFIG stuff I use (it's kinda scattered). Anyway, if you want to reproduce, get CD Wave 1.93 from http://cdwave.com/download.html and select "Variable bitrate" and 64kbps on any file.

Hello Milosoftware!

you're absolutely RIGHT!

It crashes everytime!

Thank you for your post.

New compiles are available from http://rarewares.hydrogenaudio.org/

Hello Gabriel,

i tried dll 3.96a from http://rarewares.hydrogenaudio.org/ as you posted...

... and it works GREAT! NO CRASH!

Great JOB. When it's supposed to release a final build, please?

Thank you.