hi all,
Chris M said,
>> On a sample run on a pentium II 266 (compiled using gcc), quantize() takes
>> 12 sec, while quantize_xrpow() takes 2.56 sec.
yes. very nice :)
>> I'll add some comments to
>> the function to explain the assembly.
Good :) I know zero assembly (except for some c64 stuff )
then Mark T said.
> Dont do any more work on quantize()!
> I've actually already removed it from what will be the next release.
Ah. thought as much.
Idea for quantize_xrpow()
- calculate xrpow_max when initially calculating the xrpow[] array from
xr[]
- in quantize_xrpow[] before doing the 576 calculations, check that
xrpow_max * istep does not exceed 8191 + 14. If it does, exit and choose a new
step size.
- this basically eliminates the maximum value check in count_bits and
saves a chunk of time.
Idea for binsearch_stepsize()
- JHL's binsearch is good. It may be possible to *predict* the
stepsize rather than keep guessing it.
- There is a relationship between the bits needed and the current
stepsize.
bits = (constant) * stepsize^0.3
- The 0.3 is about right but I haven't figured out where it comes from.
- The (constant) is probably different for each particular granule.
- Using a bit of formula manipulation, once we've done one run of
quantize (using stepsize1 and yielding a bitcount of bits1), we can predict the
stepsize (stepsize2) required to generate about the right number of bits (bits2)
step2 = step1 * (bits2/bits1)^(10/3)
- given that we *want* bits2 to be the desired rate
step2 = step1 * (desired_rate/bits1)^(10/3)
No time to implement these for about 2 weeks (due to exams, camp and interstate
holiday) so have a shot if you have time.
speed on
later
mike
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
