> From: Takehiro Tominaga <[EMAIL PROTECTED]>
> Date: Sun, 09 Jan 2000 19:55:41 +0900
>
> Takehiro TOMINAGA(me)>
> >> and dividing region0/1/2 is determined by looking up the
> >> subdv_table[]. However, I am afraid this method is not the
> >> best.
>
> Segher Boessenkool <[EMAIL PROTECTED]>>>
> S> It is indeed not best.
>
> S> It's not in the standard at all; it's in the example
> S> implementation.
>
> Leonid A Kulakov <[EMAIL PROTECTED]>>
> L> The current is not a best method really, but it is simplest
> L> (fastest).
>
> Ross Levis <[EMAIL PROTECTED]>>
> R> I hope the "best" method will always be added to LAME no matter
> R> how small.
> :
> R> If there is a speed problem then the better method should be
> R> added to the -h option.
>
> Ok, now I made a "ALL Huffman searching" mechanism current CVS
> version. This mechanism enables when you use -h option.
>
> With this mechanism, about 10-20% slower, but 2-10% better Huffman
> coding efficiency we got.
>
> please test and comment this.
> ---
> Takehiro TOMINAGA // may the source be with you!
Looks good! I also added it to the VBR routines.
As implemented, after the quantization is computed it will
then find more efficient huffman encoding. The extra bits will
then be added to the reservoir.
I ran my usual test that I run when the huffman encoding is
made more efficient:
old.mp3: original code with --nores
new.mp3: new code, with new huffman encoding but all saved bits wasted.
new.mp3 and old.mp3 of course differ in almost every frame, but:
mpg123 -w new.wav new.mp3
mpg123 -w old.wav old.mp3
and new.wav and old.wav are bit-for-bit identical.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
