>
> 1
> long block huffman coding system is selected between two or three
> candidate. Of cource most efficient one is selected. But short block
> is not.
> see my version of loop.c, new_choose_table_short (line 1642).
> This code will select coding system as same as the long block.
>
Takehiro is being very modest. His huffman table selection & bit
counting routines are entirely re-written. The new routines are much
simpler and much easier to read. If I was the author of any of the
original ISO code, I would be quite embarrased to see Takehiro's code
:-). In addition, the new routines find better Huffman tables for
both short blocks *and* long blocks! I am in the processing of
switching LAME now.
The new code also solves a problem that Leonid had fixed, but I never
quite got all of Leonid's fixes into LAME. With Leonid or Takehiro's
code, the predicted total number of bits needed in loop.c is
equal to the actual number of bits used for the encoding. In the old
code, loop.c would often overestimate the number of bits required.
These extra bits would not even go into the reservoir, they would just be
wasted.
> 2
> when fixed bitrate MPEG1 Layer3, lame will allocate the same bits to
> granula 1 and 2. But my version will divide into 2 granulas on pe.
> See my loop.c, line 814. It use VBR_on_pe to do it.
>
There are good reasons for doing this, but I'm not going to
incorporate it into LAME because it violates my ideas of
symmetry among the granules. The new routine
will alocate bits for granules 0 and 1 based
on the total number of bits available for the frame.
(average bits + reservoir). Granule 0 gets bits based
on its pe, and the pe of the *next* granule. But granule 1 gets
bits based on its pe and the pe of the *pervious* granule, and
thus the granules are treated differently. (MPEG2 avoids the problem
by only using 1 granule per frame).
I can see situations where either algorithm has advantages.
But almost all the time you allocate extra bits to a frame it
is for pre-echo, and for pre-echo I think it is more important
that the first granule gets all the extra bits since an
attack in the first granule will mask pre-echo created by
an attack in the second granule.
> 3
> an original lame sometimes select "not best" scalefac_compress.
> See my loop.c, scale_bitcount (line 259). It examines all
> scalefac_compress, and tries to find the best.
>
(see comments for #1 above)
> 4
> in l3psy.c, it uses optimized algorithm only when 44.1kHz,
> long block data to calculate the spread function(like sprdngf2 routine).
> my version will use all situation(all sampling rate, long/short block).
> Basically, the initial routine will find "none zero" region of the spread
> matrix and use this imformation to calculate the spread function.
>
I added this. It should speedup encoding non 44.1kHz input.
> 5
> ISO psycoacoustic model calculate TMN (Tone Masking Noise),
> in initialization routine of l3psy.c(like l3psy.c, line 353 of lame3.29).
> But main routine doesn't use this and TMN is fixed number
> (like l3psy.c, line 675 of lame3.29). My version will use the calculated
> TMN.
>
> But I don't know whether calculated TMN is right or not :).
Me neither, but I'm going to stick wit the original TMN formula. It
is the one in the ISO standard in the section titled something like
"modifications to psy-model 2 for layer 3".
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
