> How to not reproduce this behaviour (not a bug) > > 1. Read the lame documentation. > > 2. Note the section on --mp3input switch: > --- > "* --mp3input MPEG Layer III input file > Assume the input file is a MP3 file. Usefull for downsampling from one mp3 > to another. As an example, it can be usefull for streaming through an > IceCast server. > If the filename ends in ".mp3" LAME will assume it is an MP3 file. For stdin > or MP3 files which do not end in .mp3 you need to use this switch."
So, let me get this straight.... You guys don't have an stream identifier (thats fine), so you allow the user to explicitly state that the source is an MP3 by using a flag, --mp3input. Then, you undermine the whole reason the flag is there in the first place, by looking at the friggin suffix of the filename anyway! Doesn't that strike you as being a little...oh, I dunno......retarded? If you're not going to enforce the flag, then why is it there? If writing a stream identifier is too much work, I suggest you build a generic --type flag to help the encoder deal with the input, i.e. --type wav, --type mp3, etc. and make it manditory. The bottom line here is that the suffix should _never_ matter in the processing of a file. Use it as a hint, sure, but bet the house on it? No. Cheers, Bowie > --- > > 3. Follow the instructions. > > LAME works the way you were told it would work, so where is the bug? > > Chris > > _______________________________________________ > mp3encoder mailing list > [EMAIL PROTECTED] > http://minnie.tuhs.org/mailman/listinfo/mp3encoder _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
