> > if (over always>over_limit)
> > bitrate++;
> >
> > if (there are 2 over <=over_limit)
> > bitrate--;
> >
>
> So are you saying we should only require the "over" value for 2
> out of the 4 granules <= over_limit? Can you explain the thinking
> behind this?
I made a mistake here (I forget the 2 granules for each channel)
so replace it by:
if (4over<over_limit)
bitrate--;
> For now I am going to leave the default 112kbs (changeabel with -b) My
> feeling is the VBR should be used to make higher quality files that
> are slightly larger. So the default will be to encode at 112kbs
> unless it needs more bits. Maybe more people are intested in
> VBR to get as much compression as possible? Then the default should
> probably be no minimum bitrate.
I'm personnaly interested in using VBR to get as much compression as
possible, but always keeping the quality level I choosed with -V. Using no
lower limit won't reduce the quality as over is always under control by -V.
So I use lame -b 32 -V 0, but it's awfully slow because the current VBR
implementation always start at the lower bitrate (32 in my case) and goes up
until over is correct. Hopefully it can be changed to make it much faster.
Xing speed is still a mystery. It's obvious that mmx asm is not the only key
of their speed...
Gabriel Bouvigne - France
[EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3tech.org
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
