Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Yalac - Comparisons (Read 206374 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Yalac - Comparisons

Reply #75
Do the rounding errors mean that the encoding may no longer be lossless?

Yalac - Comparisons

Reply #76
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.

Yalac - Comparisons

Reply #77
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: [Select]
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 

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
"Something bothering you, Mister Spock?"

Yalac - Comparisons

Reply #78
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?

Yalac - Comparisons

Reply #79
Oops, keep forgetting the sustem specs. I fixed that along with a couple of humorous typos
"Something bothering you, Mister Spock?"


 

Yalac - Comparisons

Reply #81
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.

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...
I'm on a horse.

Yalac - Comparisons

Reply #82
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.

You poor man!   

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

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!

Yalac - Comparisons

Reply #83
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. 

I'll reinstate the link when I have done so.
I'm on a horse.

Yalac - Comparisons

Reply #84
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 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.

Yalac - Comparisons

Reply #85
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.

Yalac - Comparisons

Reply #86
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.
I'm on a horse.

Yalac - Comparisons

Reply #87
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.

Yalac - Comparisons

Reply #88
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.

Yalac - Comparisons

Reply #89
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.

Yalac - Comparisons

Reply #90
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!!!

Yalac - Comparisons

Reply #91
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!).

Yalac - Comparisons

Reply #92
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 ), 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.
I'm on a horse.

Yalac - Comparisons

Reply #93
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.

Yalac - Comparisons

Reply #94
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.

Yalac - Comparisons

Reply #95
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.

Yalac - Comparisons

Reply #96

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)

Yalac - Comparisons

Reply #97
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

Yalac - Comparisons

Reply #98
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.



Thanks for all the hard work,

Don't forget to get some sleep,
Tristan.

Yalac - Comparisons

Reply #99
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?"