> From: Takehiro Tominaga <[EMAIL PROTECTED]>
> Date: Thu, 06 Apr 2000 20:50:25 +0900
>
> Hi all.
>
> I'm planning these features to merge the current LAME from my snapshot...
>
> 0 new bitstream handling code
> (this is almost done by Mark)
>
This is almost done. The new code works great except for a bug in the
framesize for VBR streams. I hope to test a little more and check it
in today. In the process I found (one of) the MPEG2.5 8khz bug:
region1Start = 12 for short blocks is used throughout the code, but it
should be region1Start=scalefac_band.s[3], which is not always 12!
The new code (except for a few variables which still need to be
changed) is also "thread" safe, so it looks a little different. All
the global variables have ugly "gfc->"'s in front of them.
> 1 new short block lossless compression and bit allocation
I actually put this in yesterday, but didn't re-order ix, which
of course didn't work but at least I got far enough to understand
why ix has to be re-ordered! I will stop working on it, but
let me use this as an example of how I think we need to proceed:
I tend to be *very* conservative on changes like this. I would
prefer to first implement the following way:
1. new short block compression code, which re-orders ix on-the-fly.
option to use old values of bigvalues, count1.
2 Run through my test suite: make sure new code
with bigvalues=count1=576 still works. (check that results identical)
3. Run code with new bigvalues and count1 region, but with --nores.
Results should be identical *except* for short blocks. check this.
4. Run new code, create new test cases.
5. re-order ix, chance calc_noise, calc_xmin, retest.
should produce identical results, but may not because the order
of operations has changed. If not, test with --nores and
expect < 1% differences. Regenerate test cases.
>
> 2 fast VBR code
> new algorithm. it is faster than CBR!
I just have one favor to ask related to this: I would like
to use the noise shapping routines (choice of scalefactors)
in vbrquantize. This code should be done in another day or two.
I know you had this in your version a long time ago,
but vbrquantize.c is my "pet project". Also, your code is so
efficient it was hard to understant :-). I have to first put
something in that I fully understand, and then we can start
optimizing.
>From a mathematical point of view this algorithm is much better in
that it does noise shapping as close as possible to the psycho
acousticts. The ISO code appears to be a very ad-hoc algorithm which
seems to give good results. It chooses scalefactors in an slow,
gradual amplification process, but this may somehow be magically tuned
for the ISO masking data. I doubt it, but it is possible that the ISO
algorithm will give better results. Comparing the two codes will also
be hard, since these effects are subtle and require lots of listening.
I am assuming the new code is going to be better, and in that case it
will also be used for CBR, where we adjust the maskings (a la Robert's
VBR work) not to obtain a desired quality but to obtain a desired
bitrate.
Anyway, because of all this, it is very important to me that I feel I
know exactly what is going on in the choice of every single
scalefactor in vbrquauntize.c!
>
> 5 mixed_block support
Funny you should mention that. When I was getting bitstream.c
to work in LAME, i saw that old #ifdef ALLOW_MIXED and thought
this code is never going to be used and deleted it :-)
Anyway, it is still in CVS. I dont recall evern seeing *any* encoder
make use of this: the frame analyzer will display "short (mixed)"
if the short block is of mixed type.
Of course the fact that I've never seen this may be that the
frame analizer has a bug in it :-) Does anyone have a mp3
that they know uses mixed blocks?
Some comments: short blocks are used < 10% of the time, and if
mixed_blocks were used in 10% of those, we are down to a 1%
effect. If you just allocated more bits these 1% of the cases,
you would probably get better results and only increase the filesize
by a tiny ammount.
Other problem: what is the algorithm to determine when to use
a short block instead of a mixed block?
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
