> just wanted to spark a bit of thought on some of the future direction
> of lame. This occured to me after I read that for the update to lame3.30 we
> can now do ID3 tags
>
> Consider the following ideas related to mp3 encoding
> - CD-ripping (CD paranoia)
my understanding is that both paranoia and lame are tending toward
libraries (vs applications). when both are sufficiently modularized,
perhaps a third project should use them.
> - resampling (sox)
if this would just be added as a pipeline stage, ie part of reading the
input file, i dont see a lot of point in integrating it. on the other
hand, if the only change would be some array sizes and floating point
constants, why not? it might even yield a small quality improvement
over the preprocessing approach.
(what im thinking here is that the first stage of analysis mostly
involves pcm -> frequency spectrum, and that changing the speed or
resolution of the samples has very simple effects on the output of
that. comments?)
> - ID3 tags
blah. i hate them. their implementation is a horrible blemish, and
half the time the info in them is wrong anyway. i prefer to just give
my mp3 files descriptive names.
the only program i have ever written that manipulated id3 tags had one
purpose: removing them.
> - CDDB lookups
if i remember how cddb works, you can get all the functionality you
might want here with a shell script and a command line http tool,
assuming that you can get some info about the cdroms table of contents
from the ripper.
none of this has anything to do with lame as it stands.
> - mp3 databases
not sure what you mean by this.
> Should these features be part of LAME? Or should these be considered "support
> materials" and use some other program (like GRIP) to combine all these
> functions?
>
> I remember somebody saying about unix programs that each program only does one
> thing, but does it well.
i prefer vi to emacs. what does that tell you? (aside from the fact
that im a complete idiot :) (although, if the "one thing" i want is a
lisp interpreter, emacs might win.) the unix approach of gluing
together simple, dedicated programs to solve complex problems is a
design paradigm that has my full support.
i think that we should concentrate on quality (error-free operation,
minimal distortion in output), compatibility (flexibility, support for
various formats), and speed, in that order. just my opinion, of course
(until i back it up with patches :). features beyond mpeg audio
encoding/analysis are secondary.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
