Re: [MP3 ENCODER] new VBR code
I forget why the -B option was added, but it should not be used under normal circumstances. It was added because there are some decoder chips wich can't handle more than 192k frames. For (strange) cases like -b128 -B 128, why not made lame using cbr instead of vbr? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new VBR code
There is so much stuff constantly changing with lamenew options, VBR, CBR, etc.. At this point I have totally lost touch with what mode is what and which flags I should use. I sure hope you guys will start thinking more about usability at some point -steve We do think about usability: That is why the best, and reccommended options (described in the USAGE file), has NEVER changed! It will always be: lame -h input.wav output.mp3 (add -b bitrate for other than 128kbs). Everything else is under constant development and has never been reccommended except for people willing to do (repeatedly) their own testing and evaluation. Whenever something is proven proven to give consistently better results, that feature will be enabled by default with the above options. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new VBR code
You're saying that variable bitrate encoding (old or new) isn't recommended or proven to give consistently better results? (but you know it probably will) We do think about usability: That is why the best, and reccommended options (described in the USAGE file), has NEVER changed! It will always be: lame -h input.wav output.mp3 (add -b bitrate for other than 128kbs). Everything else is under constant development and has never been reccommended except for people willing to do (repeatedly) their own testing and evaluation. Whenever something is proven proven to give consistently better results, that feature will be enabled by default with the above options. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Makefile.djgpp
Ar is part of the GNU binutils package. DJ Delorie has updated the binary version of binutils to the 2.10 (the latest) the file name is bnu210b.zip. This is from the manual page for ar. "The GNU ar program creates, modifies, and extracts from archives. An archive is a single file holding a collection of other files in a structure that makes it possible to retrieve the original individual files (called members of the archive). The original files' contents, mode (permissions), timestamp, owner, and group are preserved in the archive, and may be reconstituted on extraction. GNU ar can maintain archives whose members have names of any length; however, depending on how ar is configured on your system, a limit on member-name length may be imposed (for compatibility with archive formats maintained with other tools). If it exists, the limit is often 15 characters (typical of formats related to a.out) or 16 characters (typical of formats related to coff)." Using bash instead of the DOS command.com as your shell makes things with make MUCH easier. I attached a copy of the makefile I use, I haven't made many changes, accept basically optimizations. I have a majority of the GNU utilities that are available for download for DJGPP installed, I'm just trying to give some suggestions on making things a little easier for anyone using DJGPP. I'm sure you could remove libmp3lame.a, and just use something like 'gcc -static $(CC_OPTS) $(CPP_OPTS) $(OBJS) -o lame.exe' or something like that, that's just off the top of my head, but something like that should work just fine. Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Taylor Sent: Friday, July 07, 2000 4:12 PM To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] Makefile.djgpp Last night I hacked the lame makefile for DJGPP. It's attached to this email I have tested it with DJGPP 2.03, GCC 2.95 (19990728 release), the DJGPP port of GNU make 3.78.1 and lame 3.85 beta. Thanks! I just added Makefile.DJGPP to the project. One question: it looks like you also need "ar.exe"? Does this come with DJGPP? The Makefile you sent follows the linux version and first builds libmp3lame.a (using ar) and then compiles LAME.EXE against this library. For the Makefile.DJGPP, we could skip this step and compile LAME.EXE directly, just to remove the need to have ar.exe? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) Makefile
Re: [MP3 ENCODER] Makefile.djgpp
On Fri, 7 Jul 2000, Mark Taylor wrote: I just added Makefile.DJGPP to the project. One question: it looks like you also need "ar.exe"? Does this come with DJGPP? Yes, ar.exe is part of the DJGPP gnu binutils package which part of a basic DJGPP install. You can assume that anyone who has a working DJGPP will have ar.exe. Chris Wise -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: vorbis comment header patch
OK, the patch (with several modifications) is in the CVS tree. On Thu, Jul 06, 2000 at 08:26:22PM -0700, Ralph Giles wrote: On Thu, 6 Jul 2000, Don Melton wrote: Cool! I didn't even think to add vorbis support when I landed the id3v2 stuff this week. Nice idea, Ralph! Thanks. :-) This is probably a stupid question, but are there docs online about the comment header (he asks without even looking at the vorbis site first)? Unfortunately, it isn't on the website, but you can get it from cvs: vstream.html in the vorbis/docs directory. Doesn't support track number of genre. The second is easy to add; the first requires that the vorbis people settle on a standard form for it. Let me see if I can contact them about their plans for this. If you find out anything, let us all know. Maybe I can hack in the genre. :-) There's been some discussion on the (vorbis@) list; check the archives. Basically, we just need to pick something and have Monty bless it. I'd vote for "TRACKNUMBER", or maybe "INDEX", but whatever. Genre is easy. Just lookup the code in the table and write the text out as "GENRE=%s" I was just lazy. :) I'm re-doing the "id3tag" API (to use bitstreams) now, so I'll expose the genre number to name conversion utility to make this clean. -- Don Melton mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
