Re: [MP3 ENCODER] LAME as a shared lib
On 20 Sep, Mark Taylor wrote: 1) use commandline like strings to setup LAME's encoding engine handle = lame_get_handle(); lame_setup_stuff(handle, "output samplerate = 32 kHz"); lame_setup_stuff(handle, "input samplerate = 48 kHz"); lame_setup_stuff(handle, "bitrate = 128 kps"); or in an Amiga TagItem like way (I have an implementation (~2k source, most of it are comments) of struct TagItem and NextTagItem() if you need it), less difficult to use (you didn't need a parser). And how about volunteering to add this to LAME? :-) NextTagItem() (no problem, .gz or .bz2?) or lame_setup_stuff() (sorry, not enough spare time at the moment)? Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame as an embedded library
I'm really happy about all this discussion on making it more library-ish, as i'm trying to make it available inside another product. unfortunately the product is in perl, so i'm trying to work up a full library binding to libmp3lame... so the first thing i did was i made up a perl program, as a tester, that called all the functions that main.c did, and then went through and made sure that the functions it called behaived correctly from perl... i'd like to take this opportunity to point out one of my pet peeves with libmp3lame, and that is the lame_decoder() function takes a FILE* ... and then helpfully closes it for you. so that you helpfully get a SIGSEGV when you try to cleanup the files you open and close them again. blah. but otherwise, it's been going pretty good. Also! there's been some talk of removing the cmd-line parsing code from the library. i think that's a bad idea, at least until there's some documentation on what you're supposed to set in that big bit-structure, you have two choices, just feed it embedded cmd-args, or read the source. while i'm okay reading the source, it shouldn't be that hard just to figure which flag you need to set to get something done. -answer On Wed, 20 Sep 2000, Mark Taylor wrote: Date: Wed, 20 Sep 2000 17:58:03 -0600 From: Mark Taylor [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] Lame as an embedded library I agree this 100%! I think we should make more simple mp3 encoding engine. Compared with vorbis, what a messy code LAME is ! I want to make "example" or "frontend" directory and move lame.c and gtk*, brhist.c and so on into it. Any Ideas ? I like "frontend". And also a "libmp3lame" directory for the library. Moving all this code into subdirectories will be disruptive: all the different makefiles and MSVC project files need to be updated. We will also need a ./configure/make system which will traverse the subdirectores. So lets agree ahead of time as to when and what will be done. Takehiro: are you volunteering? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame as an embedded library
Mark Taylor schrieb am Don, 21 Sep 2000: I like "frontend". And also a "libmp3lame" directory for the library. Moving all this code into subdirectories will be disruptive: all the different makefiles and MSVC project files need to be updated. We will also need a ./configure/make system which will traverse the subdirectores. So lets agree ahead of time as to when and what will be done. Takehiro: are you volunteering? Mark How about releasing 3.87 beta before starting to rearrange the source code base? Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME as a shared lib
or in an Amiga TagItem like way (I have an implementation (~2k source, most of it are comments) of struct TagItem and NextTagItem() if you need it), less difficult to use (you didn't need a parser). And how about volunteering to add this to LAME? :-) NextTagItem() (no problem, .gz or .bz2?) or lame_setup_stuff() (sorry, not enough spare time at the moment)? Actually, I wouldn't mind doing this, as I already have CVS access... ;) (either .gz or .bz2 would do fine) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame as an embedded library
M So lets agree ahead of time as to when and what will be done. M Takehiro: are you volunteering? No problem :) R How about releasing 3.87 beta before starting to rearrange the R source code base? Oh, that sounds OK, but I want to merge some features(faster quantize, more configure things, etc) and debug about -q1 things. So, my plan is this 1 Merging and debugging code, with current file structure (in this weekend ?) 2 check the "new code" (next week ?) and release 3.87 3 change the directory structure and update configure/Makefile etc. and the new directory structure I am currently planning is 1 $LAME_HOME/libmp3/, $LAME_HOME/libmp3/i386/ libmp3 sources will be moved to here 2 $LAME_HOME/frontend/ lame.c, gtk* things will be here. we should discuss about parse.c, get_audio.c, and brhist.c 3 $LAME_HOME/include/, $LAME_HOME/lib/ libmp3 thing will be here 4 $LAME_HOME$/mpglib, $LAME_HOME$/doc same as it is. Any ideas ? I need your idea, especially changing API (I think API has not been frozen...) parse.c, get_audio and brhist.c (I think these code should not be in library) --- [EMAIL PROTECTED] // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Some suggestions for LAME - please review
Hi, I got some suggestions for LAME. They're not too complicated (probably are to implement, though), so here goes: - LAME VBR doesn't encode the LSB (Least Significant Bit) correctly (as described on http://privatewww.essex.ac.uk/~djmrob/mp3decoders/lsb.html) - what exactly is causing this and how could it be fixed? - A good suggestion, IMHO: freeformat VBR encoding up to 640 kbs - this feature could be implemented through the -B switch (with additional values of 384/448/512/640), which would default to 320, but could be set higher to give a freeformat VBR. This would have the advantage that some parts which are too difficult to compress even with 320 kbs could use even higher bitrates which would improve the quality of those frames. I'm sure not many people would mind a freeformat VBR MP3 if it would mean a nice improvement in quality without having the file bloated like with freeformat CBR. - An engine which would analyze the source data and find out which mode for -X would be best to use for compression (I have to admit though, that I am not too familiar with the -Xx settings - if someone could please explain these modes (or point me to a document which explains them), I'd be very grateful) That's all for now. LAME is the best MP3 encoder out there - better than FhG even - and I am certain it will improve much more, considering the great people that are working on it right now. Keep up the good work! Thanks! -Youri -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
