>
> 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
> --
My guess is that it is a feature like sparsing the side channel
and the mixed long & short block windows. It
went into the standard but was later found not to work very well. but
I dont have any real proof of this. The main reasons I have been
slowly removing that code is laziness (How much work was it for you to
get it working?) and because FhG didn't use it, at least in the
samples I looked at, encoded at 128kbs. FhG also doesn't seem
to use mixed blocks either. They could have the same
bugs, but I think that is unlikely.
Good point about MPEG2 LSF. There they dropped the whole 2 granules per
frame concept (and thus no scfsi), which I'll take as more evidence
that scfsi doesn't work very well?
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
