Hi everyone,
I'd like to use MAD as a library (a DLL would be better) to read from MP3 buffers. The idea is to create a Windows codec (coding-decoding) with a complete free software solution.
I'm currently working on having lame (as a DLL, since my project has the BSD license and not GPL) to do the encoding part, and I'd like to use MAD to do the decoding.
Is that possible ? Any way of building a DLL without using cygwin (because I'm don't want to be obliged to use Cygwin on the user PC) ?
On Wed, 30 May 2001 15:23:47 +0200 (MEST), steve.lhomme@free.fr wrote:
Hi Steve,
Hi everyone,
I'd like to use MAD as a library (a DLL would be better) to read from MP3 buffers. The idea is to create a Windows codec (coding-decoding) with a complete free software solution.
I'm currently working on having lame (as a DLL, since my project has the BSD license and not GPL) to do the encoding part, and I'd like to use MAD to do the decoding.
Is that possible ? Any way of building a DLL without using cygwin (because I'm don't want to be obliged to use Cygwin on the user PC) ?
with what compiler do you usually work? don't even try MSVC, because Rob has used some gnu extensions (in libmad/huffman.c) that doesn't work in Visual C.
I recently got to compile libmad using mingw, and after minor modifications (interested in them, Rob?) the linker produced a DLL and a linker .lib; my only problem is now that the .lib file seems to not being compatible to MSVC (which my main program is written in), and calls to libmad functions crash.
You could tell me when you got that thing to work under win32 :-)
bye Michael
En réponse à Michael Fink michael.fink@asamnet.de:
On Wed, 30 May 2001 15:23:47 +0200 (MEST), steve.lhomme@free.fr wrote:
Hi Steve,
Hi everyone,
I'd like to use MAD as a library (a DLL would be better) to read from
MP3
buffers. The idea is to create a Windows codec (coding-decoding) with a complete
free
software solution.
I'm currently working on having lame (as a DLL, since my project has
the BSD
license and not GPL) to do the encoding part, and I'd like to use MAD
to do the
decoding.
Is that possible ? Any way of building a DLL without using cygwin (because I'm don't want
to be
obliged to use Cygwin on the user PC) ?
with what compiler do you usually work? don't even try MSVC, because Rob has used some gnu extensions (in libmad/huffman.c) that doesn't work in Visual C.
Bingo ! I use MSVC++ 5 and 6. Sometimes Borland C++ 5.5 (the free one) and sometimes MinGW.
I recently got to compile libmad using mingw, and after minor modifications (interested in them, Rob?) the linker produced a DLL and a linker .lib; my only problem is now that the .lib file seems to not being compatible to MSVC (which my main program is written in), and calls to libmad functions crash.
Well if it could work with MinGW that would already help me a lot !
You could tell me when you got that thing to work under win32 :-)
Mine ? Sure ! But I guess it's going to take a while. First I'll make a sync codec with CBR, then I'll try ABR with an async codec and finally if everything is fine a VBR one.
Ummm, I was going to wait a couple days to announce this, but I'm working on a high-level audio API that uses MAD for MP3 decoding, and I got MAD to compile and work in VC++. However, you can't safely put the MAD API itself in a DLL as it uses structs for a few things (rather than getters and setters).
You can see my web page here: http://aegisknight.org/acoustique.html
I'll have the source code in anonymous CVS before too long, and I'll post it up here for everyone to see. :)
Hi everyone,
I'd like to use MAD as a library (a DLL would be better) to read from MP3 buffers. The idea is to create a Windows codec (coding-decoding) with a complete free software solution.
I'm currently working on having lame (as a DLL, since my project has the BSD license and not GPL) to do the encoding part, and I'd like to use MAD to do the decoding.
Is that possible ? Any way of building a DLL without using cygwin (because I'm don't want to be obliged to use Cygwin on the user PC) ?
Well if it's already in VC++ I can work it out to make a DLL !
DLL can use structs too (the ACM uses them a LOT) !
You can also share meamory if you really need it.
But what I need is to be able to decode a MP3 data table, for the rest anything is possible/welcome.
Otherwise I was considering using the Winamp plugin ! (which already have lots usefull functions coded)
----- Original Message ----- From: "Chad Austin" aegis@aegisknight.org To: steve.lhomme@free.fr; mad-dev@lists.mars.org Sent: Wednesday, May 30, 2001 9:28 PM Subject: Re: [mad-dev] WIn32 library
| Ummm, I was going to wait a couple days to announce this, but I'm working on a high-level audio API | that uses MAD for MP3 decoding, and I got MAD to compile and work in VC++. However, you can't | safely put the MAD API itself in a DLL as it uses structs for a few things (rather than getters and | setters). | | You can see my web page here: http://aegisknight.org/acoustique.html | | I'll have the source code in anonymous CVS before too long, and I'll post it up here for everyone to | see. :) | | > Hi everyone, | > | > I'd like to use MAD as a library (a DLL would be better) to read from MP3 | > buffers. | > The idea is to create a Windows codec (coding-decoding) with a complete free | > software solution. | > | > I'm currently working on having lame (as a DLL, since my project has the BSD | > license and not GPL) to do the encoding part, and I'd like to use MAD to do the | > decoding. | > | > Is that possible ? | > Any way of building a DLL without using cygwin (because I'm don't want to be | > obliged to use Cygwin on the user PC) ? | | -- | Chad Austin | http://aegisknight.org/ |
The reason you want to avoid using structs in a DLL interface is because certain compilers (and options within a single compiler) let you pack DLLs in different ways. Therefore, there is no way to *guarantee* that a DLL will have a certain layout in memory. You can use #pragma pack() and all that fun stuff, but that seems kinda hack to me. :) For example, libpng has structs for the various things, but they recommend you use getters and setters to modify them.
png_set_whatever(blah, 2); // stuff like this
Well if it's already in VC++ I can work it out to make a DLL !
DLL can use structs too (the ACM uses them a LOT) !
You can also share meamory if you really need it.
But what I need is to be able to decode a MP3 data table, for the rest anything is possible/welcome.
Otherwise I was considering using the Winamp plugin ! (which already have lots usefull functions coded)
Since DLL are made to be used in Windows, and that lots of MS DLL uses structs, I guess that ANY compiler which uses DLL can use at least the same format as the MS ones. So I don't think it's such a problem.
En réponse à Chad Austin aegis@aegisknight.org:
The reason you want to avoid using structs in a DLL interface is because certain compilers (and options within a single compiler) let you pack DLLs in different ways. Therefore, there is no way to *guarantee* that a DLL will have a certain layout in memory. You can use #pragma pack() and all that fun stuff, but that seems kinda hack to me. :) For example, libpng has structs for the various things, but they recommend you use getters and setters to modify them.
png_set_whatever(blah, 2); // stuff like this
I suppose that's true. But then you'll have to modify MAD so it does byte packing on the structs (as all Windows structs are), and that might be a performance hit.
Either way, if MAD is to be built as a standard DLL, a binary interface must be specified.
Since DLL are made to be used in Windows, and that lots of MS DLL uses structs, I guess that ANY compiler which uses DLL can use at least the same format as the MS ones. So I don't think it's such a problem.
On Thu, 31 May 2001 11:45:51 -0800, Chad Austin aegis@aegisknight.org wrote:
I suppose that's true. But then you'll have to modify MAD so it does byte packing on the structs (as all Windows structs are), and that might be a performance hit.
Either way, if MAD is to be built as a standard DLL, a binary interface must be specified.
Hmm, how about COM? when I get that DLL to work under win32 I could make a COM object to access the mad lib, and no one have to worry anymore about building a DLL.
bye Michael
Hmm, how about COM? when I get that DLL to work under win32 I could make a COM object to access the mad lib, and no one have to worry anymore about building a DLL.
That would be very cool... IAudioStreamDecoder... :)
-
Chad Austin -
Michael Fink -
Steve Lhomme -
steve.lhomme＠free.fr