Thanks for the suggestions Gabriel. Here's what I've done:
>
> *fast mode must be forbidden with vbr
>
done!
> *only accept 320k with higher settings, ie -V 0, like Xing
>
done!
> *use no lower limit in 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.
> *choosing bitrate like this:
>
> if (frame.blocktype==short)
> bitrate=previous_frame.bitrate;
> else
> bitrate=(previous_frame.bitrate)-1;
>
done! although for shortblocks I still impose a minimum bit rate.
I think pre-echo is one of the most noticable flaws, and I want
to make sure it is reduced as much as possible.
> {
> try encoding;
> 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?
Right now LAME requires "over" for all granules to be <= over_limit.
Another possibility would be the average over <= over_limit.
(over = number of scalefactor bands with distortion > allowed distortion,
where allowed distortion is given by the psycho-acoustic model.)
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
