Takehiro Tominaga schrieb am Fre, 22 Sep 2000:
> M> So lets agree ahead of time as to when and what will be done.
> M> Takehiro: are you volunteering?
>
> No problem :)
>
> R> How about releasing 3.87 beta before starting to rearrange the
> R> source code base?
>
> Oh, that sounds OK, but I want to merge some features(faster quantize,
> more configure things, etc) and debug about -q1 things.
For VBR-old I would say it is safe to use -q1 combined with --raise-smr 1
suggested: lame -v -mj -d -q1 --raise-smr 1 x.wav x.mp3
The problem LAME had are related to the poor SMR output of
our psymodel for sounds like gspi35_2.wav, vbrtest.wav, etc.
Naoki's psy tune fixes it somehow too, maybe he will write some
remarks at his code.
> So, my plan is this
>
> 1 Merging and debugging code, with current file structure
> (in this weekend ?)
>
> 2 check the "new code" (next week ?) and release 3.87
>
> 3 change the directory structure and update configure/Makefile etc.
I would prefer to release 3.87 before doing huge changes,
but that is only my opinion...
> and the new directory structure I am currently planning is
> 1 $LAME_HOME/libmp3/, $LAME_HOME/libmp3/i386/
> libmp3 sources will be moved to here
we have already libmp3lame/
why not using it?
> 2 $LAME_HOME/frontend/
> lame.c, gtk* things will be here.
> we should discuss about parse.c, get_audio.c, and brhist.c
I vote to move them there, they have nothing to do
with the core encoding engine.
> 3 $LAME_HOME/include/, $LAME_HOME/lib/
> libmp3 thing will be here
> 4 $LAME_HOME$/mpglib, $LAME_HOME$/doc
> same as it is.
>
> Any ideas ? I need your idea, especially
> changing API (I think API has not been frozen...)
> parse.c, get_audio and brhist.c (I think these code should not
> be in library)
Well, Mark says the API is frozen! But, if we wanna make
a library out of the core encoding engine, we will have
to change the API.
> ---
> [EMAIL PROTECTED] // may the source be with you!
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
