Hello,
Tuesday, July 11, 2000, 6:25:46 AM, you wrote:
MT> If you want to try further adjusting the tunings
MT> the real thing you want to play with is the dbQ[] array
MT> in vbrquantize.c:
MT> static const FLOAT8 dbQ[10]=
MT> {-5.5,-4.25,-3.0,-2.50, -1.75, -.75, -.5, -.25, .25, .75};
I've been working on this. Problem is that
- or I loose bitrate on hard pieces (*)
- or I set the hard to encode, and get an overal avg size increase
for the moment, I'd suggest (*)
static const FLOAT8 dbQ[10]={-4.76,-3.9,-3.04,-2.175, -1.31, -0.45, 0.41, 1.28,
2.14, 3.0};
AND
-q1 defaulted (**)
I benched the filesize of 3.85 V1&V9 to match 3.86 V1&V9 using an
averagely difficult piece to encode. V1&V9 are the most important in
the scale (to me), because V1 stands for transparent-vbr and V9 as
smallest avg defined in old vbr(, for the people needing it.)
Then, I simply did a linear interpolation between these. I see no
need to make the gap between V1 and V2 greater than the one between V8
and V9.
(**) I used "Lame -V(1/9) -mj -h -q1" [3.86] to compare to "Lame
-V(1/9) -mj -h" [3.85] because that way the better(***) -q1 can be
used without the risk of a too low bitrate on -V9 -> -V3.
(***) -q1 was just a more extensive search algo to find lowest
possible bitrate to fit quality I think?
(*) The average pieces should somewhat match, but the hard to encode
ones will be under-dealth bits in current state compared to their 3.85
processing. I hope this can be compensated by, for example,
- making the JS mode more picky on when to go for MS because this
happens too often right now (see 'velvet-bug') => larger filesize
{- maybe making the highest sfb's have more importance (? higher
abs(ath)) so that the chance of high freq distortion (which is about
the only important one left at this bitrate imho, besides MS stereo prob)
is lowered significantly? =>larger filesize} (could be totally wrong
comprehension of the psy-coding-thingy, if so, please ingnore :))
I know I'm assuming a lot (lack of knowledge), but I hope my
blabberings are somewhat constructive and useful.
--
Best regards,
Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
