> What about the proposal to design and discuss a well designed lame API now
> without implementation? AFAICS this takes at least 3 months, if you want to
> have a durable and neat API, Mark don't want to change the API until summer
> 2001. May be should use this time to design all the structures are needed
> and the lame.h file needed. This interface should be designed in a way, so
>
> * no arbitrary constants are in it
> * also Layer I, Layer II and AAC can added to this interface
> * also multiple channels are possible
> * feed count be int16, int32, float, double
> * Support of huge arrays (open file, memmap, run encoder once, save result)
> * solving 'Gap' problem
> * solving compatibility problem with LAME 3.xx interface
>
> I propose a file 'NewAPI.h', were all this is written down (prototypes and
> rationale). This is better than only discussing and later forgetting the
> results.
>
This is a good idea. Some comments (Frank: not all of these are serious:-)
1. file I/O has been removed from the library, so we only have to deal
with encoding buffers.
2. I dont think declaring the sample rate as 'long double' is enough. We
need to add a portable, object oriented arbritrary precision floating
point library to LAME. The sample rate should be a default of
128 digits, but the user can increase this with suitable
options.
3. Creating a dozen or so odd types, all synonymous with 'int'
is a great idea. But I saw a few 'int's left. I think
we need to replace these with more new types.
4. LAME should be converted to C++ or Java. C just is not up to
the task of distinguishing between 30 different types of integers.
5. All developers should be required to take 200 hours of UML training
before working on any more code.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
