Hi,
"solved" might be a an overstatement [:)], since the code still needs
tweaking, but lets say I think I located a pain-point _very_
precisely...
In short: something goes terribly wrong with >20kHz signals.
to illustrate:
http://users.belgacom.net/gc247244/extra/ns-386a-funny.png
[wav: http://users.belgacom.net/gc247244/extra/ns.zip (500K) ]
as you can see on the "newsweep" signal, vbr_mt actually outperforms
vbr_rh on just about the whole spectrum _but_ messes terribly up on
the >21kHz range. (strange discrete ath/sfb-jumps btw (?))
I verified my >20kHz assumption by cutting off (@19kHz) the "velvet" signal
,which gives much problems, and behold: the vast majority of the
anomalies (C1 problem=gone) were fixed!
[FACT ENDS HERE]
[Welcome to my fairy fantasy land]
I'm going for an educated guess:
* 22 (0-21) sfb's, each with start and end ath's
* I actually made a visualisation of the ATH's: FFT([320-vbr](sweep))
* Ideally it would be smooth (like vbr_mt reaches by empirics)
* so all Area between smooth graph and "saw-tooth" graph symbolizes an
avg non-optimal (too large) frame-size choice
* ath(sfb(21.end)) is terribly wrong, and could eg. be better
=ath(sfb(21.start)), which would quickly fix bug
* trying to get that saw-tooth smoothened would be a more fundamental
fix?
[Scholar, how much out of 5 did I get? Rate the eternal student
please.]
--
Best regards,
Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
