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 212820 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Yalac - Comparisons

Reply #275 –
Quote from: pest on
Quote

Are you talking about uncompressed audio formats? For windows wave this isn't true. I don't know, if there are more exotic formats which are doing it.

If you are talking about other lossless compressors: If i remember it right, FLAC has this option always enabled and Mpeg4Als too, if the mode -7 has been selected.


a bit of misunderstanding here. i only wanted to know if you manually have to specify
the wasted bits or if yalac searches for them as in other compressors like mpeg4als.

Oh...

Currently it is always switched on and can not be disabled.

The analysis of the samples is beeing performed as part of another necessary anaylsis and shouldn't effect encoding speed. If the analysis has detected some wasted bits, there will be a small slowdown of encoding, but that should be ok for the huge compression advantage.

The only reason why one would want to disable this option could be the small speed penality on the decoding side (only if there are wasted bits). Possibly it could be just a little too much for some weak hardware, but i really don't know.

Yalac - Comparisons

Reply #276 –
Thanks for the update TBeck.  I'm glad to hear that you're still working on things.

Yalac - Comparisons

Reply #277 –
Current progress (V0.11)

Oh yes, i am still working on it...

Most work is going into the preparation of a public release. There is really much to do. Currently i am looking at my whole source code, removing code which was only necessary for evaluations of new compression methods. Then i look at the file structure with the later documentation work in mind. Frequently i am finding inconsistencies or unnecessary complex code parts, which have to be simplified. This work isn't too interesting but needs much concentration.

The last two days went into the hopefully final modification of the preset system (I can't remember, how often i have been talking about final presets...).

I want to thank two members for helping me to build them:

- Joseph Pohm for another great report about possible preset variations.
- Synthetic Soul for always telling me: 'Good work, but i still would like to see Normal to be a bit faster...'.

And what's new?

Earlier presets had been constructed to make each higher preset encoding about two times slower than the previous one. This may be a bit unflexible, especially if someone has particular encoding speed requirements, for instance: I want the maximum compression possible at the speed my grabber can grab audio from CD.

Therefore a finer resolution of the encoding speed was needed. Now there are two new presets, one between old fast and normal and one between old normal and high. Now each higher preset should be about 1.41 (square root of 2) times slower than the previous one.

Now we have presets 0 to 5, called Turbo, Fast, Light, Normal, High and Extra.

- Turbo is very similar to old Turbo of V0.09.
- Fast is nearly identical to old Fast of V0.09.
- Light is basically Fast with 64 instead of 32 predictors. (Hi Neil, i hope, you like it!)
- Normal is nearly identical to old Normal of V0.09.
- High is now using only 128 predictors like Normal, but is using the PreFilter like old high.
- Extra is quite similar to old High, but using 256 predictors.

Now some data for my primary sample set "rw":

(Test system: P3-800. Encoding without output.)
Code: [Select]
         Turbo   Fast    Light   Normal  High    Extra   Max
Compr:    58.03   57.14   56.78   56.49   56.32   56.10   55.96
  Diff:            0.89    0.36    0.29    0.17    0.22    0.14
Speed:    54.71   37.19   26.05   18.04   12.14    8.40    2.57
  Ratio:           1.47    1.43    1.44    1.49    1.45    3.27

"Diff" is the compression advantage over the previous (lower) preset.
"Ratio" is the slowdown compared to the previous (lower) preset.

There is no preset called "Max".

I have kept the good old evaluation levels Extra and Max. They can increase the compression of a preset without making decoding slower. That's especially nice for the presets Turbo, Fast and Light, which are candidates for possible later hardware presets or profiles. (Please look at my earlier posts regarding profiles and evaluation levels for a more detailed explaination.)

Too achieve the maximum compression (at any price) use preset Extra with evaluation level Max. But be warned: That's really insanely slow.

Probably i will soon release a V0.11 for the remaining testers, to evaluate the performance of the (so called) final presets.

  Thomas

P.S.: Hi Skymmer, we had some email problems in the past. If you still want to test Yalac, please send me a mail with your email adress.
 

Yalac - Comparisons

Reply #278 –
It's great to hear that we may have an official release soon.  I'm sure the additional testing and feedback will come in useful.

May I ask whether tagging will be available, and if so what type?

Quote from: TBeck on
- Synthetic Soul for always telling me: 'Good work, but i still would like to see Normal to be a bit faster...'.
Thanks for the mention; I'm not sure if I should be proud or not.  Professional nusiance!

I look forward to having a play with 0.11 and comparing the new presets.  Especiall Light.

Edit: Spelling
I'm on a horse.

Yalac - Comparisons

Reply #279 –
V0.11 is done

Compression algorithms:

- Better compression of the filter coefficients. Can give 0.1 percent better compression for preset NORMAL, a bit less for the other presets. A tiny bit but damn fast.
- New Wasted-Bits-option to remove the least significant bits of the samples, if they are all zero. Especially useful, if 16 bit samples have been converted to 24-bit by simply shifting 8 bits of zero in. To my surprise even some 16-bit files are benefiting from this option. That's strange but nice, because each wasted bit usually improves compression by up to 6 percent (for 16-Bit files).
- Some speed up of the PreFilter. Looses only 0.01 percent compression on my file sets.

Presets:

- Earlier presets had been constructed to make each higher preset encoding about two times slower than the previous one. This may be a bit unflexible, especially if someone has particular encoding speed requirements, for instance: I want the maximum compression possible at the speed my grabber can grab audio from CD. Therefore a finer resolution of the encoding speed was needed. Now there are two new presets, one between old fast and normal and one between old normal and high. Now each higher preset should be about 1.41 (square root of 2) times slower than the previous one.
- Now we have presets 0 to 5, called TURBO, FAST, LIGHT, NORMAL, HIGH and EXTRA.
- TURBO is using 16 instead of 12 predictors and a frame duration of 102 instead of 94 ms.
- FAST is using a frame duration of 102 ms.
- LIGHT is basically Fast with 64 instead of 32 predictors and a frame duration of 125 ms.
- NORMAL is nearly identical to old Normal of V0.09.
- HIGH is basically Normal with PreFilter enabled.
- EXTRA is quite similar to old High, but using 256 predictors. BitCoder-Optimize Choice disabled.

Release:

I hope to send the new version to the following testers within the next hours:

Josef Pohm
Synthetic Soul
(Skymmer, if he sends me an email adress...)

Only reason for this selection: I haven't heard from the other testers within the last 10 days and i don't want to fill their mail box with new versions they possibly currently don't need.

Any of them can sent me an email anytime, and i will sent the current version.

What should be tested:

- Comparison with V0.10: Speed and compression performance of the presets.
- Please put only the basic presets p0 to p5 without the additional evaluation level into your primary comparison. Otherwise it looks a bit confusing to me. Exception: You may try p52 to obtain the current maximum compression.

Plans for V 0.12:

- Futher preparation of a public release.
- Possibly i will try to speed up the PreFilter. I would like it to be so fast, that it could be included into presets NORMAL or even LIGHT.

Yalac - Comparisons

Reply #280 –
Quote from: Synthetic Soul on
It's great to hear that we may have an official release soon.  I'm sure the additional testing and feedback will come in useful.

May I ask whether tagging will be available, and if so what type?

Surely. But sorry if i should have raised wrong expectations: It's still much to do before a public release.

Possibly the first public release will not support tagging, because

- i want a public release as soon as possible.
- the omission of such useful features like tagging could prevent people from doing too serious things with Yalac. This could be a good thing! The first public release may still contain bugs which we couldn't find with our still limited test sets. It would be real horror if some of the first real users would convert their whole collections to (a buggy) Yalac before it has been tested by more people.

Quote from: Synthetic Soul on
Quote from: TBeck on
- Synthetic Soul for always telling me: 'Good work, but i still would like to see Normal to be a bit faster...'.
Thanks for the mention; I'm not sure if I should be proud or not.  Professional nusiance!

I could not translate "nusiance"...

But my statement was only a little bit ironical! It needed some persistance to break up some of my old conceptions about the preset structure!

Quote from: Synthetic Soul on
I look forward to having a play with 0.11 and comparing the new presets.  Especiall Light.


Hopefully you will not be diappointed. The main advantage of Light over Fast is the increased predictor order. But we allready know, that your file set usually will not benefit too much from more predictors.

  Thomas

Yalac - Comparisons

Reply #281 –
Quote from: TBeck on
I could not translate "nusiance"...


"Professional nuisance" würd ich in etwa mit "berufsmäßige Nervensäge" übersetzen . "nusiance" ist wahrscheinlich nur ein Tippfehler.

Yalac - Comparisons

Reply #282 –
Yes, I doubt the typo helped.

I'm sure MedO's German explanation is a lot more useful (thank you), but I would explain a nuisance as being a pest, or someone who is annoying or inconvenient.

Anyway, I hope I have been of some use.

I will try to start my tests running tomorrow morning.
I'm on a horse.

Yalac - Comparisons

Reply #284 –
Synthetic Soul: Considered adding flake to the test?

Yalac - Comparisons

Reply #285 –
Quote from: Synthetic Soul on
Well, it seems so long since I did this that I hope I did it right.  At first glance (I'm out of time now) things appear to be in order.

Yalac vs The Rest Of The World
http://synthetic-soul.co.uk/comparison/lossless/

Yalac 0.11 vs Yalac 0.10
http://synthetic-soul.co.uk/comparison/yalac/

I'll analyse at a later date.


Kinda off topic, but i'm just blown away by these results. YALAC Turbo actually compresses than Flac 0 AND encodes/decodes faster. That's just crazy.

when this thing comes out, it's gonna be my primary lossless format!

Yay for Tbeck.

btw. is YALAC the final name?

Yalac - Comparisons

Reply #286 –
I'm presuming you mean it compresses more, faster, and decodes faster too.

Yalac - Comparisons

Reply #287 –
Quote
' date='Sep 15 2006, 06:34' post='431121']
I'm presuming you mean it compresses more, faster, and decodes faster too.


hehe yeah.

changed the original post.

so is yalac the final name?

Yalac - Comparisons

Reply #288 –
Tom stated in another post that the actual final name was to be TAK.  We'll see, though.

Yalac - Comparisons

Reply #289 –
Quote from: Synthetic Soul on
Well, it seems so long since I did this that I hope I did it right.  At first glance (I'm out of time now) things appear to be in order.

Oh yes! Again, many thanks!

As always i have been very curious. Because the compression performance of lossless compressors always depends so much on the selection of the test files, i can never be sure, if my own evaluations are representative. That's one reason why your work is that important for me! Especially because your test file set is so different from mine, for instance because it does not benefit from the higher predictor orders of the stronger presets.

But the new presets system seems to work fine for your files too:

- Higher presets are compressing at least a bit better than lower ones.
- The speed differences of the presets are as expected.
- New Light compresses nearly as well as Normal of V0.10, while encoding at a similar speed as WavPack default  .
- Fast and Turbo both are stronger now with only a tiny encoding speed penality.

Overall not a breakthrough in peformance, but possibly a nice improvement of the usability, because of the better resolution of the preset speeds. For me it was worth the effort.

And not to forget: Even if the new "Wasted-Bits-Option" could not help your files, i am very happy to have it done now. It has been the last of my list of features, that overall aren't too important, but seem to be requested by users now and then (i have read some posts about it):

- Why is compressor xy performing bad on stereo files with mono content?
- Why isn't it able to handle silence perfectly?
- Why is it performing bad on some 24-Bit files (with wasted bits)?

Now Yalac should have no more weaknesses in this areas (fingers crossed).

BTW: The strongest compression can be achieved by preset EXTRA + evaluation MAX (-p52).  Not too important. I would expect only about 0.07 percent better compression on your file set.

Possibly there will be one last  modification of the presets: I would like to apply the PreFilter to preset Normal.  Because i don't want to slow it down, i have to look for some speed up of the PreFilter.

  Thomas

PS: Thanks to Shade[ST] for answering questions!

Yalac - Comparisons

Reply #290 –
Quote from: Synthetic Soul on
Well, it seems so long since I did this that I hope I did it right.  At first glance (I'm out of time now) things appear to be in order.

Yalac vs The Rest Of The World
http://synthetic-soul.co.uk/comparison/lossless/

Yalac 0.11 vs Yalac 0.10
http://synthetic-soul.co.uk/comparison/yalac/

I'll analyse at a later date.

Nice results. The decoding speed (complexity) is specially impressive.

Yalac - Comparisons

Reply #291 –
Quote
' date='Sep 15 2006, 00:38' post='431179']
Tom stated in another post that the actual final name was to be TAK.  We'll see, though.


Thanks...



   




(anyone get it?)

Yalac - Comparisons

Reply #292 –
Quote from: Madman2003 on
Synthetic Soul: Considered adding flake to the test?
As things stand the table uses official, released, builds only.

However, with the upcoming WavPack 4.4, FLAC 1.1.3, and also Flake, it would be interesting to see how these new encoders compare.

I may run some tests with WavPack 4.4a3, FLAC 1.1.2_CVS (using -A tukey(0.5) and -A tukey(0.5)+flattop) and wisodev's Flake build if I get time, but I am more interested in testing officially released builds, and I have little time at the moment.

Thanks for the idea, anyway.


Quote from: TBeck on
BTW: The strongest compression can be achieved by preset EXTRA + evaluation MAX (-p52).  Not too important. I would expect only about 0.07 percent better compression on your file set.
Yes, I don't know why I didn't just use the additional evaluation levels on all presets to get the full range in the first place.  I will add them in the next day or so.
I'm on a horse.

Yalac - Comparisons

Reply #293 –
Quote from: Synthetic Soul on
Quote from: TBeck on
BTW: The strongest compression can be achieved by preset EXTRA + evaluation MAX (-p52).  Not too important. I would expect only about 0.07 percent better compression on your file set.
Yes, I don't know why I didn't just use the additional evaluation levels on all presets to get the full range in the first place.  I will add them in the next day or so.

Caution: For presets High and Extra the evaluation level Extra is useless, because the basic presets allready are using all the options evaluation Extra could add.

Sorry for not telling earlier.

  Thomas

Yalac - Comparisons

Reply #294 –
Quote from: Synthetic Soul on
Quote from: Madman2003 on
Synthetic Soul: Considered adding flake to the test?
As things stand the table uses official, released, builds only.

However, with the upcoming WavPack 4.4, FLAC 1.1.3, and also Flake, it would be interesting to see how these new encoders compare.

I may run some tests with WavPack 4.4a3, FLAC 1.1.2_CVS (using -A tukey(0.5) and -A tukey(0.5)+flattop) and wisodev's Flake build if I get time, but I am more interested in testing officially released builds, and I have little time at the moment.

Thanks for the idea, anyway.


I'd second the interest in seeing Yalac tested against other 'development build' encoders: it'd be more like comparing state-of-the-art oranges to state-of-the-art oranges. Or apples to apples. you know what I mean. (am I making sense? it's hard to tell sometimes)

Yalac - Comparisons

Reply #295 –
Kinda.

The who point is to compare Yalac/TAK to existing, official encoders though, i.e.: those encoders that 99% of users are using.  Yalac/TAK gets updated with each alpha because it is the reason for the comparison.

I would be more than happy to update the results for FLAC and WavPack when 1.1.3 and 4.4 are released.  Both will warrant new data.  As a WavPack user I have my own motives to test 4.4 against 4.3.

I'm interested to see the results for Flake, but I don't really understand where it fits into the equation.  Justin Ruggles' response in his thread answers some of my questions, but fails to fill me with confidence.  Will Flake end up replacing FLAC.EXE as the FLAC encoder?

FLAC 1.1.3 is my main concern though, as I can test now with 1.1.2_CVS, and use settings that I think will be used in 1.1.3 following Josh's posts #77 and  #79 (-A tukey(0.5), and -8 with -A tukey(0.5)+flattop for the new -9), but I'm not certain whether this will equate to 1.1.3's results or not.  What's the point of posting irrelevant data?

All that said, I am interested as well, so if I find a spare hour or so then you may well see them reported.
I'm on a horse.

Yalac - Comparisons

Reply #296 –
Quote from: Synthetic Soul on
Yalac vs The Rest Of The World
http://synthetic-soul.co.uk/comparison/lossless/

Yalac 0.11 vs Yalac 0.10
http://synthetic-soul.co.uk/comparison/yalac/
Quote from: Synthetic Soul on
Quote from: TBeck on
BTW: The strongest compression can be achieved by preset EXTRA + evaluation MAX (-p52).  Not too important. I would expect only about 0.07 percent better compression on your file set.
Yes, I don't know why I didn't just use the additional evaluation levels on all presets to get the full range in the first place.  I will add them in the next day or so.
Quote from: TBeck on
Caution: For presets High and Extra the evaluation level Extra is useless, because the basic presets allready are using all the options evaluation Extra could add.
I have now added High Max and Extra Max.  Extra Max provides an additional 0.087% compression - not a bad guess.
I'm on a horse.

Yalac - Comparisons

Reply #297 –
You will not be surprised to hear, that i am also very interested into the performance of Flake and the upcoming new Flac release. Here is a comparison i have just performed.

Participiants:

Yalac V0.11a:  slightly improved over V0.11.
FLAC  1.1.2:
Flake 0.10:    file flake-0.10-win32-i686.zip from sourceforge.

Test system:

P3-800 with a (slow) 40 GB HD.

Results

Code: [Select]
          Yalac V0.11a                             |  FLAC  |  Flake               |
          Turbo  Fast   Light  Normal High   Extra |  -8    |  -8     -11    -12   |
---------------------------------------------------+--------+----------------------+
rw                                                 |        |                      |
Ratio:    58.03  57.14  56.78  56.49  56.30  56.09 |  59.54 |  59.06  58.80  58.74 |
EncoTime: 31.46  41.24  52.74  70.45  92.25 127.96 | 280.47 | 133.57 297.68 871.84 |
---------------------------------------------------+--------+----------------------+
songs                                              |        |                      |
Ratio:    49.09  48.37  47.98  47.59  47.41  47.20 |  51.35 |  50.27  49.66  49.59 |
EncoTime: 16.19  22.80  31.42  43.70  59.02  84.50 | 185.51 |  86.14 198.37 591.69 |
---------------------------------------------------+--------+----------------------+

Ratio is the compression ratio in percent, EncoTime the duration of encoding in seconds. Encoding speed of Yalac's presets Turbo and Fast is allready being limited by my slow 40 GB harddisk.

For the test sets:

"rw" contains 46 files from http://www.rarewares.org/test_samples/. Should be the whole dir. I call this my primary test set and prefer to use it for my tuning.

"songs" contains CD-Ripps of the beginning of the following songs:
Code: [Select]
Song_02  Dire Straits "(Forgot the title)", 1:19
Song_04  Bruce Cockburn (Cover) "Red ships take off...", 1:27
Song_06  King Crimson "Lady of the dancing waters", 1:29
Song_08  Peter Gabriel "Mercy Street", 3:10
Song_10  Thin Lizzy "Whisky in the jar",  1:19
Song_12  Tracy Chapman "Mountains o' things",  1:02
Song_14  Bruce Cockburn (Cover) "Silver wheels",  1:20
Song_16  Kunze "Dein ist mein ganzes Herz",  1:12

This set contains many files that are benefiting from higher predictor orders. It may be less representative than set rw, but i keep it because it has been my primary set for many years.

Some remarks

Flake is performing really great compared to FLAC. Much faster and significantly better compression! Congratualations! I am very curious, if a possible combination of the new methods of Flake and the upcoming FLAC will provide even better compression.

While testing Flake, i have been a bit irritated: My tool for the calculation of the compression ratio gave me worse ratios than Flake itself reported. My pocket calculator tells me, that the my tool is right.

Does Flake (and possibly FLAC, i didn't check it) ignore the overhead of metadata and streaminfo when calculating the compression ratio?

Yalac - Comparisons

Reply #298 –
flake has improvements that are also in FLAC CVS.  the next release should provide comparable compression for the same predictor order.  flake will still be faster at encoding.

the compression ratio flac shows is based on the final file size (which includes metadata).

Josh

Yalac - Comparisons

Reply #299 –
Quote from: jcoalson on
flake has improvements that are also in FLAC CVS.  the next release should provide comparable compression for the same predictor order.  flake will still be faster at encoding.

Hi Josh,

great news!

Quote from: jcoalson on
the compression ratio flac shows is based on the final file size (which includes metadata).

Thanks for making it clear. Possibly it's a small bug in Flake. The compression ratio it reported was about 0.25 to 0.30 percent too good for the files i have checked.

  Thomas



I really don't like the boards automatic concatenating of posts. 

This should have been a separate post:

Because i am currently tuning Yalac for high resolution files, here the results of another test:

Code: [Select]
          Yalac V0.11a                                    |  FLAC  |
          Turbo  Fast   Light  Normal High   Extra  Insane|  -8    |
----------------------------------------------------------+--------+
sh_2444                                                   |        |
Ratio:    58.53  58.23  57.98  57.87  57.76  57.64  57.57 |  60.28 |
EncoTime:  6.33   8.48  10.88  15.05  19.65  27.70  86.32 |  96.54 |
----------------------------------------------------------+--------+
sh_2496                                                   |        |
Ratio:    54.58  54.33  54.21  54.18  53.84  53.79  53.76 |  57.92 |
EncoTime: 12.66  17.34  22.04  29.22  38.18  48.59 107.73 | 184.58 |
----------------------------------------------------------+--------+

Test system is the same as before. Looks as if Flake doesn't support 24 Bit yet, therefore no results for it.

For the test sets:

"sh_2444" contains 5 files with 24 bit and 44 or 48 Khz.

"sh_2496" contains 6 files with 24 bit and 96 Khz.

Unfortunately i don't have more real high resolution files.