' date='May 13 2006, 03:38' post='391925']Do the rounding errors mean that the encoding may no longer be lossless?
Dire Straits - Brothers in Arms 584,178,044 bytes duration 55:11=====================================================================name/params Ratio EncTime DecTime--------------------- ------ ------ ------Yalac 0.05 fast 46.44% 50.97x 81.62xYalac 0.06 fast 46.15% 68.11x 82.45xYalac 0.05 normal 45.79% 26.95x 80.50xYalac 0.06 normal 45.70% 32.89x 84.24xYalac 0.05 high 45.41% 10.17x 78.02xYalac 0.06 high 45.41% 11.34x 80.83xYalac 0.06 high (SSE) 45.41% 11.73x 83.07xYalac 0.05 insane 45.34% 4.10x 79.44xYalac 0.06 insane 45.34% 4.26x 81.37xYalac 0.06 insane (SSE) 45.34% 4.36x 80.63x
In addition to my latest specification there is a new command line switch:-cx Evaluate test ©ase x.If i will ask the testers to evaluate the effect of internal encoder parameter variations, they can switch between them via this option. For instance: Please try -c1 to -c5.
A quick comparison between the last two versions using another orginal un-remastered CD pressing. The GUI version of 0.06 was used to for fairness, MMX always enabled and usage of SSE is indicated.
I wanted to run a different comparison using the command line version but came across this:"If i will ask the testers to evaluate the effect of internal encoder parameter variations, they can switch between them via this option. For instance: Please try -c1 to -c5."Does this mean we are asked to try out -c1, -c2, -c3, -c4 and -c5 on just HIGH modes?
Oops, keep forgetting the sustem specs. I fixed that along with a couple of humorous typos
BTW: Activation of the protocol function slows encoding down.
Quote from: TBeck on 12 May, 2006, 08:33:52 PMBTW: Activation of the protocol function slows encoding down.Yes, I had considered this. Another reason to use TimeThis to time the commandline executions: to keep the Yalac commandline as clear as possible (same reason you don't tag with other codecs!).
Sorry, it's morning here and I haven't even seen the email yet.
I did have a think about some batch files to distribute last night (to automate as much as possible and to produce reports for use in my database), but it seems they won't be needed.
I'll try to run the first of my own tests today. I may be off looking at dinosaurs though...
Edit: I just realised that the previous tests were on versions of Yalac earlier than 0.05. Therefore to do a comparison I really need to run some 0.05 tests.
I hacked the original comparison table to include only the original Yalac runs and the new 0.06 runs:
Would it be easy for you to generate two tables: One for the comparison of the (two) different versions, one for the comparison of the latest version with other compressors?
Edit: I have actually left the 0.02-0.04 results in the table. As with the other comparison, if you add "all=1" to the URL yo can see them too (although it may get a little confusing!). http://synthetic-soul.co.uk/comparison/yalac/?all=1Edit 2: OK, http://synthetic-soul.co.uk/comparison/lossless/ now uses the 0.06 (commandline) results.
NB: I have relegated High -SSE to the hidden set ("?all=1") for the multi-encoder comparison, to stay in keeping with the table. Basically, only core settings are shown by default, and a few special settings are shown only when "?all=1" is added. I guess this is just me being anal, but it seemed right.
I am quite new to SSE... I would have thought, that it gives the same results as single precision arithmetic performed by the floating point unit (FPU). Mabe it differs in the handling of rounding and underflows (i didn't care for the setting of the right SSE-Flags).
For the regular FPU the computing precision is controlled by the FPU codeword.You can set it with 'fldcw'.It sets the computing precision to single (FP32) and the rounding mode to nearest (this should be the default)
Because the compiler keeps intermediate results of a computation in the FPU registers it preserves the extra computing precision between operations - unlike when SSE is used. This causes different results.It also means that a program compiled with different optimization settings can give different results!!!
Perhaps I should add some fast settings for FLAC and WavPack as a comparison.
Fast mode is quite impressive in ratio and speed, though I do wish that the high and insane modes compressed a little better, to better compete with Monkey's Audio.
Quote from: Firon on 15 May, 2006, 01:53:56 PMFast mode is quite impressive in ratio and speed, though I do wish that the high and insane modes compressed a little better, to better compete with Monkey's Audio.Me to.But you have to take into account, that those test files aren't fully representative. On my test corpus the difference between FAST and HIGH is significantly bigger than here and yalac is performing slightly better than Monkey HIGH. This may be the other extreme. The truth may lie in between.Nevertheless i am working on further improvements, especially for those files, were yalac performs worse than monkey. My current evaluations seem to confirm, that an increase of about 0.50 percent for preset high is realistic. It's not easy to give such an estimate: My latest optimizations are providing up to 1.50 percent better compression than Monkey on selected files, but it's not quite clear now, what the average will be.But one thing is clear: Those new optimizations will not be cheap. They will reduce the encoding speed of HIGH.And it will take much time until they are fully implemented. The new optimizations show strong interactions with any existing processing unit in yalac. It might be necessary to change big parts of my current codec design to get the most out of the new optimizations.
Perhaps a High, Extra High, and Insane like Monkey's? (keep high, optimized high becomes extra high)
BTW: Would it make sense, to reintroduce a FASTEST preset? I could implement one, which would be about 50 precent faster than FAST (i am evaluating encoding speed without output, because my disk is far too slow). It might compress 1 percent worse than FAST.Another option would be a 15 percent speed up of FAST with a compression penality of about 0.1 percent.