On Sat, Apr 18, 2015 at 01:59:53PM +0200, Andreas Cadhalpun wrote: > On 18.04.2015 04:40, Michael Niedermayer wrote: > > On Sat, Apr 18, 2015 at 12:55:08AM +0200, Andreas Cadhalpun wrote: > >> The problem is that minath is not the minimum, only close: > >> minath = ath(3410, ATH_ADD) = -5.24237967 > >> ath(3407, ATH_ADD) = -5.24241638 > > > > the exact location of the minimum depends on teh "add" value > > its around 3410 for add=0 and around 3407 for add=4 > > True. > > > for fun, 3407.080774800152 is even closer than 3407 for add=4 > > Yes, but the ath function calculates with floats and thus is > inaccurate enough that it doesn't matter if the input is 3407 > or 3407.1. > > > but the "add" parameter should probably be user selectable > > Currently ATH_ADD is a #define, but if that was made user selectable, > one could approximate the position of the minimum: > minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD) > > > also if you want to prevent coeffs[].ath from becoming negative then > > That isn't strictly required, because 0 is a valid value and is just > as bad as a negative one.
> But I assume the model works better, if it uses something closer to the > minimum of the ath function. thats more a question for claudio than me id say [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
