Yalac – Evaluation and optimization Reply #25 – 2006-06-09 13:22:56 Quote from: TBeck on 2006-06-08 20:44:42I had to come to a deceision: Use parcor coefficients or not. I have deceided against it. I didn't see that coming. I think I'm pleased; although I too find it difficult to say no to the benefits of parcor coefficients.Quote from: TBeck on 2006-06-08 20:44:42And the PreFilter can be turned off (for higher speeds), which would not have been possible for the parcor coefficients.I think this is a huge factor. It allows you more flexibility for each preset.Quote from: TBeck on 2006-06-08 20:44:42It seems, as if we will see HIGH become about 25 percent faster without a significant compression penality! And the method i used for the speed up can be applied to other optimizations of the compression efficiency, which i actually did not want to implement, because they would have been too slow!That all sounds like very good news indeed. Quote from: TBeck on 2006-06-08 20:44:42BTW: Preset FASTEST is back. Not too important for me, but why not provide both extremes: INSANE for the upper, FASTEST for the lower end.Exactly, why not? I think the bigger the range the better. Even users who normally use Extra may want Fastest occasionally if they are in a hurry to transport a file. I also suspect Fastest will still have ridiculously competative compression rates...[quote author=Shade[ST link=msg=400876 date=1149796907]Sounds good, though I wonder how large the difference between fast and fastest will be -- will there not be throttling of the processor / ram / hard drive?[/quote]This is definately a factor. However, with the idea that IO issues will decrease over the coming years it is well worth ensuring that Yalac doesn't fall foul of merely attaining current IO speeds. There's also decoding to RAM to consider.Well, I'm really looking forward to taking a look at 0.09. A new Fastest preset, and faster encoding for Normal, sound great to me.