>
> First, It appears that it starts at the max bitrate and work our ways down
> to the min bitrate, calling outer_loop each time and comparing the noise
> values to see what rate is the best. I put in some output to print the
> variable 'better' for each loop and observed that, for most of the cases,
> once better was 0 (false), it usually stayed false for the remaining
> attempts. I put a break into the better test,
>
The loop is doing a standard power of 2 search to find the
minimum number of bits possible which still gives the requested
quality. (the defination of 'quality' is a current
topic of research :-)
In your case it is probably something like:
try 2000 bits better = 1 (good enough, see if we can use less bits)
try 1000 bits. better = 1
try 500 bits better = 0 (not good enough, need more bits)
try 750 bits better = 0
try 875 bits better = 0
try 938 bits better = 0
try 969 bits better = 0
try 985 bits better = 0
It stops when the change in the number of bits is less
than some number (like 20). In this case, it would have concluded
that 1000 bits is the smallest number that would give accepable
quality. But you have to do the full search to make sure.
I'm sure you can think of something better, like what Juha did in
bin_search_stepsize(), but it might not be worth the effort - I would
like to put in a new VBR algorithm that will not use outerloop() at all, but
directly choose each scalefactor so that the associated critical band
has an acceptable amount of distortion. I think this will be even
faster than CBR. It is conceptually simpler too, but harder to code
up in the current framework.
>
> I would also like to see a max_bitrate command line option for more complete
> encoding control. For my ears, and the jazz I encode, 160kbps sounds real
> perty. There are some passages, however, that obviously benifit from
> 192kbps, but I can't hear any difference at even higher bitrates. I grunged
> the code in order to encode my music at 160 - 192 VBR, most songs averaging
> 176kbps. I kept the vbr quality at 5, not sure how this effects the
> process. Locking the encoder down to 2 bitrates does speed the encoding
> process, and if the above observations are correct, I can see how it could
> be made even faster.
>
Okay, I'll add a -B option. Some others have requested this too.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
