> >
> > It's a part of preemphasis() (loop.c)
> >
> > > if ( gr == 1 )
> > > {
> > > /*
> > > If the second granule is being coded and scfsi is active in
> > > at least one scfsi_band, the preemphasis in the second granule
> > > is set equal to the setting in the first granule
> > > */
> > > for ( scfsi_band = 0; scfsi_band < 4; scfsi_band++ )
> > > if ( l3_side->scfsi[ch][scfsi_band] )
> > > {
> > > cod_info->preflag = l3_side->gr[0].ch[ch].tt.preflag;
> > > return 0;
> > > }
> > >
> > > }
> > >
> >
> > It seems to me that we have to emphasise spectrum of that second
> > granule here before "return 0" in the case when preflag is set for the
> > first granule, and then return 1. I.e. to do the same as under
> > "if (over == 4 )" condition (see preemphasis() below).
> > Otherwise it will be decoded the wrong way - HF will be too loud.
> > Is it right?
>
> I think all that code should just be deleted, since in LAME it will
> never be activated. in LAME, scfsi[ch][] should always be 0. When it
> is non-zero, some of the side information for gr=1 is not encoded and
> the information for gr=0 is used instead. The ISO code never
> activated this feature, although a lot of the code seems to be there.
>
> In the 128kbs FhG samples I've looked at, I've never seen them use
> scfsi. At low bitrates, there is only 1 granule per frame, and
> thus I dont think MPEG2 uses it either, but I'm not sure.
>
> Mark
>
I see that calc_scfsi() is not in lame at all.
I've missed that code is under #if(0).
So encoder even never try to use scfsi.
Why? Using it can save up to 74 bit for huffman part in second granule.
calc_scfsi() in ISO code is buggy - it never sets it to 1,
but I know how to fix it.
May be FhG has the same bugs.
MPEG2 (LSF) doesn't use in at all.
If it is interesting to recover this feature, we can try.
It is easy to fix dist10, but I'm worrying that
there can be a lot of code in lame to modify if it
was written with assumption that scfsi is always 0.
Leonid
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
