On 18-Oct-99 Patrick De Smet wrote:
> is anyone doing/considering documenting the code (outside the C-src);
I did this for the MDCT code - should probably be updated. I had spent a lot of
time online, hoping that someone else had already written it.
I see documenting as a good idea - sort of elaborating on the CHANGES/HISTORY
files.
How would we separate:
- code cleanups & added functionality
- speed optimizations
- sound improvments
> 2) how can/could this be put down in source code efficiently
How about a tree-structure html document which links to the relevant document.
Indexed by source file and function. e.g
subs.c/fft
encode.c/filter_subband
encode.c/window_subband
> 3) what alternatives were examined/compiled and compared
Usually, when someone comes up with a better implementation, it replaces the
one that was there. It is a "serial" rather than a "parallel" process. I
don't think anyone has lined up the various quantize() functions LAME has had -
when a better one comes along it wins. Natural selection in the coding world.
> I think this could save some efforts (re-inventing the wheel,
> like my optims (will report later) seem to be compared to Takehiro's);
Takehiro's and your efforts are only very recent. You're not both re-inventing
the wheel, you're presenting two different wheel designs :)
later
mike
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
