Hello,
I've been experimenting all day with the "vbr_mt" mode, because of the
great speed advantage over "vbr_rh" in it's current form.
No need to tell anyone the vbr_mt generates very large files, and I
found -V3 (mt) to be somewhat the filesize-equivalent of -V1 (rh).
What bothered me was the lowpass filter used by -V3, and after
analysis knowing that "V1" should give better Q than "V3" (ATHs of
sfbs are different anyhow, so I assume...)
After 8-9 hours of trying to grasp a fraction of the source (no
programmer, no psy-coding background, plain dumb :)) (in a futile attempt to find the
reason why
"-b" is misinterpreted (?)) this catched my eye:
qadjust=-2.5; /* start with -1 db quality improvement over quantize.c VBR */
in Mark's vbrquantize.c. Why this "-2.5"?
Anyways, I changed the thing to some other values and
"qadjust=-.5;" combined with "-q1" gives filesizes/bitrate
distributions very much like the --old-vbr. (meaning: V1,JS=transparent
for most, at 170-180kbit/s average)
Checked with "-V1 -mj -h -b128 -F -q1" (on loads of files) and extra is that -V4 files
with -q1 give relatively bigger files now, so maybe q1 can be
defaulted on vbr_mt?
Positive:
+ now 3x faster VBR
+ compareable V0-V9 scale
Negative:
- some nasty artifacts in a file I encoded (every vbr_mt does
worse than vbr_rh on this file), I'll address this in another
thread. (*, if desired)
- "-b128" still gives me 40,112 kbit frames. I thought "/* disable
analog_silence if *any* of the granules != silence */" was sufficient
to discriminate analog silence, but I am missing a point I think :(
btw: are these kinds of comments useful? (*)
and how about: I found some nasty artifact @vbr_mt/V1 (which should be transparent
imho), but
cannot fix myself...?
.
While going through the source-code, I felt what Pathfinder must have
felt like on Mars (..., the third week after landing there)
--
Best regards,
Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
