IPB

Welcome Guest ( Log In | Register )

15 Pages V  « < 2 3 4 5 6 > »   
Reply to this topicStart new topic
Yalac - Comparisons, How the evaluation release compares to other compressors
Shade[ST]
post May 13 2006, 02:38
Post #76





Group: Members
Posts: 1189
Joined: 19-May 05
From: Montreal, Canada
Member No.: 22144



Do the rounding errors mean that the encoding may no longer be lossless?
Go to the top of the page
+Quote Post
TBeck
post May 13 2006, 02:46
Post #77


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE
' date='May 13 2006, 03:38' post='391925']
Do the rounding errors mean that the encoding may no longer be lossless?


Definitely no. They only change the predictor coefficients a bit. But this happens, before they are beeing used for the (critical) prediction. Before the prediction you can modify them as much as you like. It will only decrease the compression ratio.

Did you read the post about the optimization of the window function of FLAC? It's the same there: The window modifies the coefficients in a useful way without affecting the data integrity.
Go to the top of the page
+Quote Post
Destroid
post May 13 2006, 02:51
Post #78





Group: Members
Posts: 550
Joined: 4-June 02
Member No.: 2220



A quick comparison between the last two versions using another original un-remastered CD pressing. The GUI version of 0.06 was used to for fairness, MMX always enabled and usage of SSE is indicated.
CODE
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.62x
Yalac 0.06 fast 46.15% 68.11x 82.45x

Yalac 0.05 normal 45.79% 26.95x 80.50x
Yalac 0.06 normal 45.70% 32.89x 84.24x

Yalac 0.05 high 45.41% 10.17x 78.02x
Yalac 0.06 high 45.41% 11.34x 80.83x
Yalac 0.06 high (SSE) 45.41% 11.73x 83.07x

Yalac 0.05 insane 45.34% 4.10x 79.44x
Yalac 0.06 insane 45.34% 4.26x 81.37x
Yalac 0.06 insane (SSE) 45.34% 4.36x 80.63x

I didn't notice any differences when using SSE on my machine, not sure what could cause the output file to be different huh.gif

I wanted to run a different comparison using the command line version but came across this:
QUOTE
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.


Does this mean we are asked to try out -c1, -c2, -c3, -c4 and -c5 on just HIGH modes?

edit: typos; System = A64 3000+ 512DDR Caviar 80GB Win2K

This post has been edited by Destroid: May 13 2006, 03:27


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
TBeck
post May 13 2006, 03:03
Post #79


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Destroid @ May 13 2006, 03:51) *
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.


Many thanks! It's great to see FAST performing as expected: Faster and better than in V0.05.

QUOTE
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?


Sorry, no. This was only a general description or example for the usage of the -c option. The valid argument range will change between different version.

This time you can only specify -c1 to enable SSE. Presets HIGH should be most affected by the use of SSE. If there is any advantage for SSE, then it should show up on HIGH.

Could you please post your CPU type?

This post has been edited by TBeck: May 13 2006, 03:12
Go to the top of the page
+Quote Post
Destroid
post May 13 2006, 03:25
Post #80





Group: Members
Posts: 550
Joined: 4-June 02
Member No.: 2220



Oops, keep forgetting the sustem specs. I fixed that along with a couple of humorous typos tongue.gif


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
TBeck
post May 13 2006, 03:33
Post #81


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Destroid @ May 13 2006, 04:25) *
Oops, keep forgetting the sustem specs. I fixed that along with a couple of humorous typos tongue.gif


Thanks.

I did miss the typos... sad.gif
Go to the top of the page
+Quote Post
Synthetic Soul
post May 13 2006, 08:03
Post #82





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (TBeck @ May 13 2006, 01:33) *
BTW: 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. smile.gif

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... wink.gif


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
TBeck
post May 13 2006, 12:52
Post #83


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Synthetic Soul @ May 13 2006, 09:03) *
QUOTE (TBeck @ May 13 2006, 01:33) *
BTW: 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!).

The protocol function should only have a significant effect on the speed of preset FAST, maybe NORMAL. But this time i am most interested into the performance of FAST, because most work went into it.

It's a bit funny: Before April 1st most of my work went into the optimization of the modes with high predictor orders (256 and up). There was no FAST mode. This preference had been caused by my not representative test corpus which does benefit far more from higher predictor orders than the test sets of you and the other testers. Yes, this reality check did change my priorities...

QUOTE
Sorry, it's morning here and I haven't even seen the email yet. smile.gif

You poor man! sad.gif

QUOTE
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.

The next version may need them. It will probably provide more test cases (-cx).

QUOTE
I'll try to run the first of my own tests today. I may be off looking at dinosaurs though... wink.gif

Hey family man! No chance to fill your children with enthusiasm for encoder evaluations? But no, that's not what children really need. Have fun!
Go to the top of the page
+Quote Post
Synthetic Soul
post May 15 2006, 11:09
Post #84





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



I hacked the original comparison table to include only the original Yalac runs and the new 0.06 runs:

<link removed> Edit: now back: http://synthetic-soul.co.uk/comparison/yalac/

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. sad.gif

I'll reinstate the link when I have done so.

This post has been edited by Synthetic Soul: May 15 2006, 15:46


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
TBeck
post May 15 2006, 12:52
Post #85


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Synthetic Soul @ May 15 2006, 12:09) *
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. sad.gif


I hope, it's not to late: For me the comparison of Preset FAST with V0.05 is the most important! Hence there is no urgent need to test the other presets of V0.05.
Go to the top of the page
+Quote Post
TBeck
post May 15 2006, 13:41
Post #86


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Synthetic Soul @ May 15 2006, 12:09) *
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?

Not too important, but if you could generate them automatically with your scripts, it would be nice.
Go to the top of the page
+Quote Post
Synthetic Soul
post May 15 2006, 15:26
Post #87





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (TBeck @ May 15 2006, 13:41) *
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?
OK, well the comparison of 0.05 and 0.06 is back at http://synthetic-soul.co.uk/comparison/yalac/.

I will remove previous versions of Yalac from the multi-encoder comparison and replace them with the 0.06 results. There's little point in comparing old versions of Yalac against other codecs, so I don't see a problem with this. That comparison may as well hold the latest version of Yalac against the others.

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=1

Edit 2: OK, http://synthetic-soul.co.uk/comparison/lossless/ now uses the 0.06 (commandline) results.

This post has been edited by Synthetic Soul: May 15 2006, 15:42


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
TBeck
post May 15 2006, 15:57
Post #88


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Synthetic Soul @ May 15 2006, 16:26) *
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=1

Edit 2: OK, http://synthetic-soul.co.uk/comparison/lossless/ now uses the 0.06 (commandline) results.

Perfect! Many thanks!

I am really glad to see, that the last two weeks of hard work on preset FAST were not a waste of time. But don't expect me to make FAST significantly faster! No chance... Ok, a multi core version is possible...

Very happy

Thomas

P.S.: Good, that there is no significant difference between GUI and command line version. One thing less to test for further comparisons.
Go to the top of the page
+Quote Post
Synthetic Soul
post May 15 2006, 16:09
Post #89





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Yes, Fast is truely impressive. In the encoder settings I tested it now has the fastest compression and decompression speed, while being around mid-table for compression. Bear in mind I 'm not including some encoders fastest settings, but the table is currently geared at compression rate, rather than speed. Perhaps I should add some fast settings for FLAC and WavPack as a comparison.

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'm on a horse.
Go to the top of the page
+Quote Post
TBeck
post May 15 2006, 16:17
Post #90


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Synthetic Soul @ May 15 2006, 17:09) *
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.

Hm, i think compression technology is a good place to be a bit anal... Here it really helps. rolleyes.gif
Go to the top of the page
+Quote Post
Hyp-X
post May 15 2006, 16:21
Post #91





Group: Members
Posts: 5
Joined: 15-March 06
Member No.: 28484



QUOTE (TBeck @ May 13 2006, 02:29) *
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).


Rounding and underflows should be the same as long as the right flags are set.

For the regular FPU the computing precision is controlled by the FPU codeword.
You can set it with 'fldcw'.
Example (C++):

unsigned short cw_single_round = 0x07F;
__asm fldcw cw_single_round;

It sets the computing precision to single (FP32) and the rounding mode to nearest (this should be the default)

I don't know about Delphi, but in VC++ double precision is the default (FP64).

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!!!
Go to the top of the page
+Quote Post
TBeck
post May 15 2006, 16:33
Post #92


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Hyp-X @ May 15 2006, 17:21) *
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)

Thanks for the hint. I know, how i have to do it when using the FPU. But i didn't take a deeper look into SSE. My SSE-Implementation is only a first quick and dirty approach for the evaluation, if it is of any advantage for me.

QUOTE
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!!!

Yeah, but in my case it will only affect the compression rate a tiny bit (maybe 0.01 - 0.02 precent). Any calculation, which affects the data integrity, is beeing performed in integer fixed-point-arithmetic.

No need to worry about YALAC beeing not really lossless!

Thomas

P.S.: Forgot about the intermediate results on the FPU stack! Thanks. (Again, it doesn't affect data integrity!).

This post has been edited by TBeck: May 15 2006, 16:38
Go to the top of the page
+Quote Post
Synthetic Soul
post May 15 2006, 18:35
Post #93





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (Synthetic Soul @ May 15 2006, 16:09) *
Perhaps I should add some fast settings for FLAC and WavPack as a comparison.
Added.

FLAC -0 is now tops for encoding speed, with Yalac Fast in second place.

However, Yalac Fast is still tops for decoding speed (with FLAC -0 in second place ohmy.gif), although they differ by a negligable amount. The compression is far better though (64.2% compared to 70.7%).

Wowsers.

Edit: changed "although admittedly it is possibly a negligable amount" to "although they differ by a negligable amount", to be more precise.

This post has been edited by Synthetic Soul: May 15 2006, 19:07


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
Firon
post May 15 2006, 18:53
Post #94





Group: Members
Posts: 830
Joined: 3-November 05
Member No.: 25526



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.
Go to the top of the page
+Quote Post
TBeck
post May 15 2006, 19:45
Post #95


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Firon @ May 15 2006, 19:53) *
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.

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.
Go to the top of the page
+Quote Post
Synthetic Soul
post May 15 2006, 22:20
Post #96





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



I have just checked the MD5 hash of all decoded files and all match the source files exactly.

I think that's me done for now.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
audiofreak
post May 16 2006, 03:14
Post #97





Group: Members
Posts: 13
Joined: 29-December 05
Member No.: 26723



QUOTE (TBeck @ May 15 2006, 14:45) *
QUOTE (Firon @ May 15 2006, 19:53) *

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.

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)
Go to the top of the page
+Quote Post
TBeck
post May 17 2006, 02:57
Post #98


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (audiofreak @ May 16 2006, 04:14) *
Perhaps a High, Extra High, and Insane like Monkey's? (keep high, optimized high becomes extra high)

Yes, i allready thought about an EXTRA preset...

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.

Possibly not too important, but i am really into speed.

Thomas
Go to the top of the page
+Quote Post
Shade[ST]
post May 17 2006, 05:58
Post #99





Group: Members
Posts: 1189
Joined: 19-May 05
From: Montreal, Canada
Member No.: 22144



QUOTE (TBeck @ May 16 2006, 21:57) *
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.

I think people looking at this codec are looking at speed also.

For those who can afford to _not_ have speed, the best option is to use optimfrog extranew. In your case, however, a speed-optimized lossless codec with good compression would be ideal for portable players (rockbox, etc.), since it's integer-based and very fast.

As such, I would make both modifications. Make fast faster by 15%, and make a (new) fastest preset, faster than what we currently have.

smile.gif

Thanks for all the hard work,

Don't forget to get some sleep,
Tristan.
Go to the top of the page
+Quote Post
Destroid
post May 17 2006, 20:21
Post #100





Group: Members
Posts: 550
Joined: 4-June 02
Member No.: 2220



I agree the speed aspect is a Yalac specialty.

Since I continue using an older lossless encoder for archival uniformity, I'm interested in compression efficiency -- there's much more to do than wait around encoding! Obviously, when using a "symmetrical" codec such as the one I use, I lose in the long-run with decode speeds that are actually slower than the encoding speed. The reason is more data is being written to disk during a decoding than encoding.

So, in regards to speed:

- Machines like mine using ATA100 I usually max-out at about 82x decoding speed for 16bit 44KHz stereo
- The fastest encoding speed I clocked was about 98x with my outdated codec
- Yalac decodes from all modes at about the maximum ATA performance
- newer SATA drives have no distinguishable advantage over ATA, unless it's the 500+GB 10,000 RPM variety
- any speed enhancements for YALAC Fast(est) encoding should take into account the limitations of average HDD performance, otherwise the performance boost will not be noticed

Given that, I'd love to see the speed increase or a new fastest preset.

For your information, Thomas, the archival encoder I use achieved a speed of 97.83x with a ratio 47.94%, while Yalac 0.06 Fast clocked at 68.11x with an impressive 46.14% ratio with "free" super-fast decompression speed. Good work!


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post

15 Pages V  « < 2 3 4 5 6 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th September 2014 - 01:01