How Using "Beesweet1.3b8.dll" with Delphi Prog ?

[Dark-Cracker]

i hope DspGuru could help me. i try to integrate the beesweet dll with an GUI in Delphi someone could help me because i can't translate in delphi how i must call the fonction of this dll.

Thank u for helping me :-)

PS: sorry for my crap english, i am a little frenchy

[DSPguru]

@Dark-Cracker
you're english is okay :)

i'm not a delphi programmer, so i can't help you much.
please check "example2.c" that included in the package, you'll see the main idea of usage.


EDIT : LigH is known to be a very good delphi programmer, mayB he could help you.

[Dark-Cracker]

Ok i will try to see in you file exemple2.c i have also the vstripGUi source (an delphi GUI who use Vstrip.dll, this will surely help me)
But if someone have an idear on how to use the beesweet dll in a Delphi prog, he can mail me an exemple :-)

thank dspguru for your quick answer and very nice work with "beesweet", good luck for the next release.

PS: if LIGH have an idear he can contact me. :)

[Swede]

I thought I could give Dark-Cracker a hand but..

Is there *any* more docs about using besweet.dll than the 2 short examples? (For instance: Why is there a deinit as the first command in example2? I think I've looked everywhere)

I was just going to check that i sent the pascal-params correctly but I don't seem to get anything working, perhaps I'm just stupid :)

If I trace the code I can see that the first command in the array (the deinit) seems to trigger something in the MVCRT.dll but anything else just dies, somewhere in the mvcrt.dll, perhaps there something wrong with the version of that .dll in my machine? Even though besweet.exe does the job perfect?

[Nic]

Hi ya Swede,

My changes to DVD2AVI kind of prompted DG to make the recent changes to BeSweet.DLL. So DG, (with a little input from me) invented the current interface for the DLL.

So if you need a hand then shout me, (but I know nothing about pascal/delphi so im not sure how much use ill be :( )

Cheers,
-Nic

[Swede]

Thnx, I've sent a mail to you. It's easier for me (at least) to move this discussion. :D

[Dark-Cracker]

I you try to use this dll with a frontend in Delphi think to mail me an exemple too :-)

Bye

[Swede]

I'm not trying to keep this secret, I assure you all... It's just that I don't like to be the one standing 'caught with you're pants down'. (AC/DC anyone?)

Right, I've been trying to get the besweet.dll to work in Delphi. I've got so far that I can make an .mp3 out of a .ac3 but not without the whole thing to crash on me with 'Floating point error' right at the end.

This is an part of the Delphi/Pascal-code:

const
argc = 18;
argv: Array [1..argc] of String = ('Project1','-core(','-input','Test.ac3','-output',
'Test.mp3','-logfile','besweet.txt',')','-azid(','-z1','-b1',')','-lame(','-b','128',')',#0#0);
type
BSfarproc = procedure (argc: Integer; arcv: pointer); cdecl;
var
BeSweet: BSfarproc;
hDLL: HMODULE;
begin
hDLL:=LoadLibrary('BeSweet.dll');
if hDLL<>0 then begin
ListBox.Items.Add('dll found!');
BeSweet:=GetProcAddress(hDLL,'BeSweet');
if Assigned(BeSweet) then begin
BeSweet(argc,@argv);
argv[1]:='deinit';
BeSweet(argc,@argv);
if not FreeLibrary(hDLL) then
ListBox.Items.Add('Not Free''d!');
end;
end
else
ListBox.Items.Add('dll not Found!');
end;

The problem seems to be that somewhere inside the first BeSweet-call something goes wrong, this might be 'cause I've misunderstood something, but trace'ing the code doesn't help me. The procedure BeSweet is executed but doesn't return, at asm-level, but makes an Floating point error-fault, which is captured but Delhpi.

It doesn't matter if I include the last #0#0 or not, there has to be something else that I don't see... :(

Well, if anyone has an idea, feel free to speak up.

[DSPguru]

1. shouldn't agrc be 14 in your case ?
2. please post logfile.

[Swede]

#1. 14? This is one of the things, how should I count?
--
'Project1','-core(','-input','Test.ac3','-output',
'Test.mp3','-logfile','besweet.txt',')','-azid(','-z1','-b1',')','-lame(','-b','128',')',#0#0
--
What counts?

--
#2. That's another prob. Since it crashes on me I don't get the log-file. It seems that it does'n get written until the 'deinit'-cmd..?
--

[DSPguru]

1)
1) 'Project1',
2) '-core(',
3) '-input',
4) 'Test.ac3',
5) '-output',
6) 'Test.mp3',
7) '-logfile',
8) 'besweet.txt',
9) ')',
10) '-azid(',
11) '-z1',
12) '-b1',
13) ')',
14) '-lame(',
15) '-b',
16) '128'
17) ,')'

2)
'deinit', found in 'example2', is only relevant when using "-input ac3input". (meaning - there is NO input file, input is delievered thru AC3_Bursts.
but that's not your case. what you're implementing is what appears in 'example'.

[Swede]

Ok, so 17 seems to be correct. Tried that.

And, yes I've been trying just to get this to work, just as fluent and simple as besweet.exe with the same cmd-line, but to no avail... It just crashes with a Floating point err.
I'm quite sure that I'm doing something wrong here in my Pascal-interpretation but I've *really* tried to step through in the debugger and can't find the reason...
What's the first parameter? Do you try to grab the win-handle to output anything? Or why is it there?
Should I 'init' it in any way?

And can I get something useful out of a SS since I don't get a return no matter how I try?

[DSPguru]

Originally posted by Swede
Should I 'init' it in any way?in mode one - no.

And can I get something useful out of a SS since I don't get a return no matter how I try? what's SS ?

maybe there's a problem with the calling convention..
can't help you with delphi.

[Swede]

Ok, no init. But still, what's the first param? deinit or anything else?

SS = Single Step, I've been stepping though the code to no avail.
I've written a few dll's and since you all say this works, and I doubt not!, it *has* to mean that I'm doing something wrong. I just have to find out what!

There are a few ways to call a C-function from a Pascal-proc but most of the errors comes from pop'ing/not pop'ing bytes from the stack. Either way the call *should* return and the err *should* emerge afterwards which is not the case here.
Maybe it's got something to do with MSVCRT.DLL, which if I understand correct is a C Runtime-lib, and I might not initiate correct?

[LigH]

There is at least one more mistake: The C construct "char **" is incorrectly translated into "array[..] of String" - instead, it must be an "array[..] of PChar", because C applications are expecting ASCIIZ strings (Char arrays closed with a trailing #0), not PASCAL strings (which have a length prefix). Exactly, "argv" is an array of Pointers to arrays of chars; because the argument count is submitted via "argc", the last 'argv member' does not need to be #0#0.

Besides that, the "cdecl" calling convention is essential, of course.

(No promise, but I might try this today and post my results. Depends on my time.)

[Swede]

Strictly Pascal you're correct, but Delphi's String is (since ver 3 I think) the same as a Pchar. (You can get the Pascal-string is you excplicitly declares a String[len] or ShortString). Hence the argv: Array [1..argc] of String; is exactly the same as char ** since I deference it in the call @argv.

(And the #0#0 was just a test to see if the reason it crashes *right* at the end had something to do with #of argc.)

I *do* get the mp3 but before the log-file gets flushed to disk the whole thing crashes, somewhere inside but before it returns.?.

[LigH]

Of course, you shall try to surround the BeSweet function calls by "try...except" or "try...finally" blocks and hope to catch the exception, so that the application at least does not crash anymore. But as you are writing that the function does not really return, I'm starting to doubt it being the one and only solution...

And maybe you can try to add "argc:=1" before calling BeSweet with the "deinit" parameter. - I think I'll definitely have to try for myself; so 'til later.

-

(P.S.: It's a really new information to me that PChar shall be the standard for strings in Delphi - I always thought that the default for 16-bit Delphi is ShortString, the same as Turbo Pascal strings with 1 byte length prefix, and for 32-bit Delphi it's WideString - or depending on the project options; but PChar... I read the documentation so many times, I thought I would know if it was so...)

[Swede]

If I SS I can see that the params are pushed to the stack as they should, the besweet.besweet is called and tracing that show that is just a 'wrapper' with then calls another func, and if I set a breakpt here it never returns, it just crashes, which I can try..except but it to late anyway :)

So the next call using deinit is never done and as DSPguru said it shouldn't be there anyway, so I deleted that part.

And about the strings your'e almost :D correct but:
In the default {$H+} state, the compiler interprets string (when it appears without a bracketed number after it) as AnsiString.
And AnsiString is a null-term array of chars. Voila!

[LigH]

I just tried the same (almost - for debugging purposes, it became a bit bigger than Swede's example; especially Params2ArgVect is very "schoolish"). To my surprise, it simply returned the usual error message, as if no or a wrong parameter was submitted. Finally, the DLL simply stopped the whole application instead of returning to the function call.

Although searching for many minutes, I couldn't find substancial differences to Swede's example. So if anyone would like to look at it, here is my source (I hope you don't mind the quite huge printout too much):


program BS_CLI;
{$APPTYPE CONSOLE}
uses
Windows, SysUtils;

const
BeSweetFuncName = 'BeSweet';
BeSweetLibName = 'BeSweet.dll';

type
TArgVect = array[Byte] of PChar;
TBeSweetProc = procedure(ArgCount: Integer; ArgVPtr: Pointer); cdecl;

var
BeSweetProc: TBeSweetProc;
GArgCount: Integer;
GArgVect: TArgVect;
hDLL: THandle;

procedure Params2ArgVect(var ArgCount: Integer; var ArgVect: TArgVect);
var
ParamIdx, ArgLen: Word;
ArgStr: String;
ArgPC: PChar;
begin
ArgCount := 0;
if ParamCount > 0 then begin
Write(ParamCount, ' arguments: "');
for ParamIdx := 0 to Pred(ParamCount) do begin
ArgStr := ParamStr(Succ(ParamIdx));
ArgLen := Length(ArgStr);
ArgPC := StrAlloc(Succ(ArgLen));
ArgVect[ParamIdx] := StrPCopy(ArgPC, ArgStr);
Write(ArgPC, ' ')
end;
WriteLn(^H'"');
ArgCount := ParamCount
end
end;

begin
WriteLn('BeSweet - Delphi CLI wrapper');
FillChar(GArgVect, SizeOf(GArgVect), 0);
Params2ArgVect(GArgCount, GArgVect);
hDLL := LoadLibrary(BeSweetLibName);
if hDLL = 0
then WriteLn('Could not load module "'+BeSweetLibName+'"')
else begin
BeSweetProc := TBeSweetProc(GetProcAddress(hDLL, BeSweetFuncName));
if Assigned(BeSweetProc)
then try
try
BeSweetProc(GArgCount, @GArgVect);
WriteLn('OK')
except
on E:Exception do begin
WriteLn(E.Message)
end
end
finally
if not FreeLibrary(hDLL)
then WriteLn('Library "'+BeSweetLibName+'" could not be released.')
end
else WriteLn('Could not locate function "'+BeSweetFuncName
+' in module "'+BeSweetLibName+'"')
end
end.


My calling command line was:

BS_CLI.exe -core( -input H:\Programme\BeSweet\AC3TEST.AC3 -output I:\AC3TEST.MP3 -logfile I:\AC3TEST.LOG ) -ota( -g max ) -azid( -f1 -n1 ) -lame( -b 160 )

[LigH]

I forgot: When the package of all the required DLLs is not present, calling the BeSweet DLL resulted in an Access Violation in MSVCRT.DLL - not my preferred solution, I must say...

[Swede]

Although searching for many minutes, I couldn't find substancial differences to Swede's example.
I think you've missed the same thing that I missed... The first 'magic' parameter... From what I found out the first one has to be, either deinit, or something else. I haven't got a reply yet to why or what but just pass anything (Besweet, swede, LigH or whatever)...

[LigH]

ParamStr(0) is the name of the application. It's logical - arrays are counted from 0, therefore simply passing the "argv" array includes this one, too.

My new results now:

BeSweet seems to work in general, it starts to calculate the optimal gain (which is reported on the console), it writes the MP3 file (which is *NOT SHOWN*!), then a few seconds later the program crashes (blue screen, Exception 0E); to avoid this, it is possible to reset the application (or, kill the running task from within the IDE) - the MP3 file is then partly written.

Anyway, the DLL call does not return to the calling application, it crashes at its end.

Issue confirmed. DSPguru, any comments?

[Swede]

ParamStr(0) is the name of the application. It's logical - arrays are counted from 0
Arghh.. You got me there :)

And, you did a console app (which I didn't) and you say that you get output there? If that's the case then perhaps it's somehting with the interaction between MSVCRT and BeSweet.dll... Does it try to hook up to a certain window to produce output? And do you get a correct MP3, like I do?

[DSPguru]

i'm affraid the calling convention isn't cdecl..

i'm using declspec(dllexport)..

[LigH]

"declspec(dllexport)"??? That's nothing I know about. But I guess that it could be related to what is called "stdcall" in Delphi - it's the caling convention which is used by most of the Windows API functions, as the Delphi help reports.

To get in detail - the following calling conventions are possible in Delphi:

"register" - parameters from left to right, submitted in registers, routine cleans (most efficient way, default)
"pascal" - parameters from left to right, submitted in stack, routine cleans (backwards compatible)
"cdecl" - parameters from right to left, submitted in stack, caller cleans (as used by most C compilers per default)
"stdcall" - parameters from right to left, submitted in stack, routine cleans (as used by most Windows API calls)
"safecall" - parameters from right to left, submitted in stack, routine cleans (as used in Windows APIs with dual interfaces, COM Exception handling)

("left to right" means that the first parameter in the function parameter list is pushed at first onto the stack {or loaded into EAX} - "right to left" on the opposite stores the last parameter at first)


But no matter if calling BeSweet DLL by either cdecl or stdcall (which are very closely related, except for the end) - both ways crash before returning with bluescreen and Exception 0E - the MP3 file is complete and sounds well, though. And the DLL output is written into that console window (a)from/(b)with which the CLI application was started (a)from the command line/(b)in the IDE.

[LigH]

Oops - did I say "complete"? Well, at least it's playing well, but I'm missing something valid in the first hundreds bytes: They are all 00, instead I'd expect some header here (ID3Tag V2, Xing VBR...)?

[Swede]

Ok, sober again :) and I did some serious debugging this morning.

It crashes *after* the message Finalizing but *before* it says Conversion completed.
The error is Floating point division by zero.
The offending instruction is a fmul qword ptr [address], that comes just before some call that ends up in MSVCRT._ftol
If I just ignore that error I *do* get the mp3 and the logfile.

This is about as much as I can do without the dll-source.

[LigH]

"The advantage of standards is that you may chose one of so many..."

@DSPguru: If it helps you debugging, I could send you my CLI wrapper with different calling-convention flavours. Then you can try to debug your DLL by using one of these applications as host for your DLL (at least this kind of DLL debugging works in Delphi, I hope you can do the same with your favourite C compiler).


*UPDATE* - Here they are:

http://www.ligh.de/software/BS_CLI.ace (ACE2) or http://www.ligh.de/software/BS_CLI.rar (RAR3), as you like.

PLEASE NOTE: "register" and "pascal" are NOT expected to work, they shall abort with an access violation - just to demonstrate that these conventions are very different. If either "cdecl" or "stdcall/(safecall)" are working well can only be seen when BeSweet.DLL returns to the calling application.

[DSPguru]

sorry guys,
i won't have time to check it out before sunday.

[TheWEF]

why not run BeSweet.exe instead? you can do it like this:


uses Windows,SysUtils;
...

ExecuteAndWait('C:\BeSweet.exe -myCommandline',False,True);

...
function ExecuteAndWait(const aCmdLine: String; Hidden, doWait: Boolean): Boolean;
var
StartupInfo : TStartupInfo;
ProcessInfo : TProcessInformation;
CreationFlag: DWORD;
begin
{setup the startup information for the application }
FillChar(StartupInfo, SizeOf(TStartupInfo), 0);
with StartupInfo do
begin
cb:= SizeOf(TStartupInfo);
dwFlags:= STARTF_USESHOWWINDOW or STARTF_FORCEONFEEDBACK;
if Hidden
then
begin
wShowWindow:= SW_SHOWMINNOACTIVE;
CreationFlag:= IDLE_PRIORITY_CLASS;
end
else
begin
wShowWindow:= SW_SHOWNORMAL;
CreationFlag:=NORMAL_PRIORITY_CLASS;
end;
end;

Result := CreateProcess(nil,PChar(aCmdLine), nil, nil, False,
CreationFlag, nil, nil, StartupInfo, ProcessInfo);
if doWait then
if Result then
begin
WaitForInputIdle(ProcessInfo.hProcess,INFINITE);
WaitForSingleObject(ProcessInfo.hProcess, INFINITE);
end;
end;


put it into a thread object (TThread) if you want to wait for return in the background:

with TMyThread.Create(False) do OnTerminate :=Main.AudioEncodingDone;


procedure AudioEncodingDone(AOwner:TObject) will be executed when audioencoding is finished.

wef.

[DSPguru]

wef is right :
if your code doesn't look like example2.c, there's no reason to work with the dll.

anyway, i'll look for the bugs whenever free (not before sunday).

[LigH]

Originally posted by TheWEF
why not run BeSweet.exe instead?

Oh well, tastes are so different... Some people kept asking for DLL versions of tools, others recommend calling the EXE :D

Why calling DLLs? Just a few thoughts:

* Some people don't like consoles or CLI apps (they are so un-fancy).
* Some DLLs provide interfaces to internal data, which can be displayed e.g. graphically; this won't work when calling the EXE.

_


Just while you are here (sorry for kicking your ass again, but I'm just curious): Is GKnot still in development, regarding the new situation e.g. with XviD and Ogg? No news for a long time makes me nervous, somehow... :rolleyes:

[Swede]

why not run BeSweet.exe instead?
My only reason was to help Dark-Cracker, he said he wanted to use it in Delphi and since I know my way around I thought I could give him a hand.
But of course, if his reason is just to control BeSweet he could just use the exe.

[DidzisK]

Originally posted by LigH
(P.S.: It's a really new information to me that PChar shall be the standard for strings in Delphi - I always thought that the default for 16-bit Delphi is ShortString, the same as Turbo Pascal strings with 1 byte length prefix, and for 32-bit Delphi it's WideString - or depending on the project options; but PChar... I read the documentation so many times, I thought I would know if it was so...) [/B]

Default for 32-bit Delphi is AnsiString (in default {$H+} state). AnsiString and PChar are closely related - they both are dynamically allocated and can contain up to 2G characters. You can also cast string (AnsiString) to PChar in many cases but not all - in some cases you will need to explicitly allocate memory for PChar variable before calling a routine which uses PChar as parameter.

WideString uses 2 bytes for each caracter and is used for storing Unicode strings. It is not a default string type in Delphi.

[LigH]

Originally posted by DidzisK
...
AnsiString and PChar are closely related - they both are dynamically allocated and can contain up to 2G characters

Yeah... I read again in the documentation: Both are an array of Char with trailing #0 from their address forward; AnsiString has an additional length LongInt stored in the 4 bytes before the first character. So up from the first character, they are indeed equal.

[DSPguru]

what i meant to say is :
if you're planning to use BeSweet.dll, you should implement an example2-like application. if you're implementing the first example, it's as good as running the exe.

[Dark-Cracker]

Thank u very much for all the answer to my question.I try to use the besweet dll in a rippack i prefer using the dll because i want somethink graphical and DSpguru has made a besweetdll it for it.
I hope a working solution will be find because a lot of programmer use delphi and besweet is the best tool for Audio.

Best regard to Sweed, Light, TheWEF, Dspguru for there helpfull answer.

Ps: sorry for my poor english , i hope u have understand what i try to explain.

[DSPguru]

Originally posted by Dark-Cracker
Ps: sorry for my poor english , i hope u have understand what i try to explain. your english is fine !!

[Dark-Cracker]

Hi DSPguru hi hope i will don't boring you but have u try to debug the besweet DLL ? :)

A big greet to SWEDE ang LIGH for helping me for this task.
I hope with the *futur* debugging besweet dll the BS_CLI prog will work fine.

Bye. Thank u all for helping me.

PS: Sorry my english is *a little* crap :-)

[DSPguru]

i won't debug it until you try to implement the second example.

[LigH]

Originally posted by DSPguru
i won't debug it until you try to implement the second example.

I'm just about to do that; but unfortunately, my C reading experience is limited: There is a rather complex replacement code for the command line parameters - 'switch(argc) { case ...' - but it seems to be completely useless because there is a line


// init BeSweet
*ARGV=*argv; // <===
BeSweet(ARGC,ARGV);


following after ARGV is changed. :confused:

As far as I understand, the new argument vector "ARGV" (submitted by the application to the DLL) is exchanged by the whole original argument vector "argv" (submitted from the command line to the application's main function) after the argument processing. Or did I misunderstand that command?

[DSPguru]

argv is char** !
anyway, ignore this Switch case. it is only used to set parameters thru the cli.
read my comments.

[LigH]

Sometimes I wish you would describe problems and solutions more explicitly :mad:... Delphi programmers are not used to the C format of pointer (de-)referencing - therefore it took me a few minutes to understand what you wanted to tell me with this reply.

The expected result is to copy the first component of the argument vector from the "command line" to the DLL. The first, not all. That means that the first argument (with index 0) then contains the filename of the calling application. Or to be a bit more verbose:

C: "*ARGV = *argv;"
Delphi: "ARGV[0] := ParamStr(0);"

Now I can continue! :p

[Swede]

@DSPguru: I was a bit bored this morning so I implemented your example2, with the only difference beeing the program feeding the AC3-stream to the dll and got the exact same error, at the same line that I reported earlier. As you can see I didn't copy the exact same parameters but they shouldn't make any difference, right?
Reading your comments I'm a bit worried about // BeSweet.dll will close the file, and assert maximum gain The dll can't close the input-file since it doesn't have the correct handle...

If anyone need the source:
---

program Project1;
{$APPTYPE CONSOLE}
uses Windows, SysUtils, Classes;
const
argc = 17;
argv: Array [1..argc] of String = ('Project1','-core(','-input','ac3input','-output',
'Test.mp3','-logfile','besweet.txt',')','-azid(','-z1','-b1',')','-lame(','-b','128',')');
type
BS_Record = record
hours, minutes, seconds, millis: Short;
peak: Single;
err: Integer;
end;
BS_Ptr = ^BS_record;
BSfarproc = procedure (argc: Integer; arcv: pointer); cdecl;
AC3proc = function (size: Integer; var buf): BS_Ptr; cdecl;
var
BeSweet: BSfarproc;
AC3_Bursts: AC3proc;
hDLL: HMODULE;
s: String;
info: BS_Ptr;
buff: Packed Array [0..2047] of Byte;
ac3File: TFileStream;
count: Integer;
begin
hDLL:=LoadLibrary('BeSweet.dll');
if hDLL<>0 then begin
Writeln('DLL found');
BeSweet:=GetProcAddress(hDLL,'BeSweet');
AC3_Bursts:=GetProcAddress(hDLL,'AC3_Bursts');
if (Assigned(BeSweet) and Assigned(AC3_Bursts)) then begin
ac3File:=TFileStream.Create('Test.ac3',fmOpenRead);
BeSweet(argc,@argv);
count:=2048;
while count=2048 do begin
count:=ac3file.Read(buff,2048);
info:=AC3_Bursts(count, buff);
with info^ do
write(IntToStr(hours)+':'+IntToStr(minutes)+':'+IntToStr(info^.seconds)+':'+IntToStr(millis)+' err '+IntToStr(info^.err),#13);
end;
ac3File.Free;
argv[1]:='deinit';
BeSweet(1,@argv);
if not FreeLibrary(hDLL) then
Writeln('Not Free''d!');
end;
end;
end.

[LigH]

"He, alter Schwede!" :p Here you've been faster than me.

TFileStream is something I shall remember in the future - I was about to use the Win32 functions directly, but now that I know there is an object for it, it might become easier in the future to "transpile" C sources.

I also would like to ask DSPguru in general to provide more (by count), more actual and more verbose documentation of his tools. From my experience, I sometimes found weaknesses and bugs while thinking about how to describe interfaces in a documentation...

[Swede]

"He, alter Schwede!" Here you've been faster than me. Well, I hope you don't think I'm taking this as a race, 'cause that's absolutely not my intention. :)
It was just that I had to do something else for a while. Well, else as in not programming in the other Delphi-apps that I'm doing... Come to think of it, I don't do anything else than Delphi... Almost...

[Swede]

Well, duh! I was kinda wrong when I assumed the parameters had nothing to do with this... Changing from the azid to ota did the trick.. Try my last code but using this params:
argc = 21;
argv: Array [1..argc] of String = ('Project1','-core(','-input','ac3input','-output',
'Test.mp3','-logfile','besweet.txt',')','-ota(','-d','0','-G','max',')','-lame(','--alt-preset','128','--scale','1',')');

[DSPguru]

compile and attach in here.

[Swede]

compile and attach in here.
Here it is, but since everything is hardcoded it must be the most useless program I've ever done :D

(Instead of waiting for the attach, you can d/l it here (http://leffe.dnsalias.com/project2.zip) )

[Nic]

@DSPGuru:

Hiya :)

Forgot to mention, exception faults in the BeSweet.DLL can occur if very small buffer sizes (<1000) are sent to AC3Burst...This isn't a problem because ive made it so DVD2AVI will always buffer & send 8000 bytes. But I thought id mention it just in case you hear similar reports :)

Thanks again for all your help :) (I see movmasty guessed your avatar :) (btw i guessed wrong myself :( :) )

Cheers,
-Nic