Content

In this thread the testers should post results for specific variations of individual encoder options of Yalac (Working name for "Yet another lossless audio compressor"), which will be helpful for debugging and optimization purposes.

General comparisions of the preset modes with other compressors should go into the thread "Yalac - Comparisons".

What happened

Bad timing of my introduction (April 1.) forced an early publication of an evaluation release of Yalac, to prove, that it really works. This are results of 8 forum members, who where so kind to test the experimental release for me.

Many thanks!

Ok, this test uses the command-line Yalac encoder (YALACC) version 0.06 to test the -c1 switch (SSE). Once again I used the original 1985 pressing (DDD), and I timed using Igor Pavlov's TIMER.EXE (mentioned in another dicussion) which indicates where the hard disk can bottle-neck encoding/decoding speed(s).

I found using YALACC with the -c1 switch had an impact on encoding for all profiles, but most interesting was using the -c1 switch on the command-line for decoding usually had a positive effect. I'm not sure if using -c1 for decoding is valid but I re-ran the decoding process twice and the differences are measurable.

System = A64 3000+, 512MB, Caviar 80GB, Win2K

edit: Simplified the table, added specs

It's my understanding that Process = Kernel + User, and Global is what TimeThis would report. I was intending to just look at Process (CPU only) and Global (CPU + IO) values.

Would the 99% Process Time (suggesting a 1% IO time) in the High/Insane encodes be due to disk caching or something?

Edit: Sorry, just realised. I suppose the increased encoding time just means that the time required accessing the file becomes negligable compared to the raw processing of the data, i.e.: the more work goes into compressing the data the more negligable to actual IO time becomes.

Sounds good to me.

Drat, I forgot my specs again! Also fixed

Thanks for this evaluation. I find it absolutely interesting! Especially the low cpu usage when decoding.

For the effect of SSE: It can't be the reason for the speed difference between the two fast encoding passes:

Look at the CPU usage: It's higher in the second pass. That means, that less time has been spent for Disk-IO: 100 - 66 = 34 vs. 100 - 62 = 38 percent. If encoding with SSE was faster, than the portion of the processing time should be reduced (less than the 62 % without SSE) if disk io time was constant.

I am quite sure, that the speed difference has been caused by some caching or other drive issues.

And to reveal a secret: The effect of SSE on preset fast should be absolutely minimal, maybe a tenth of the effect on high, which is allready very small. And decoding does not use SSE at all...

Deceisions for V0.09

This time i need some advice, because i am not sure what would be the best for the next version.

V0.08 has brought the prefilter:

- Activated on presets HIGH and EXTRA.
- Gives on average about 0.20 to 0.25 percent better compression, up to 4 percent on specific files.
- Slows down encoding a bit and decoding on average by 10 to 15 percent, up to 35 percent on specific files.

Within my previous post i allready wrote, that the advantage of the PreFilter probably is beeing caused by at least two seperate effects on the signal.

The first effect produces the huge advantage (up to 4 percent) on some specific files.

The second effect is mostly responsible for the average advantage (0.20 to 0.25), that the PreFilter achieves on most file sets. It helps here, because it reduces the precision required for the accurate storage of the predictor coefficients, which need less space within the file stream when the PreFilter is applied.

To verify this, i implemented another usually more efficient way to store the predictor coefficients and tried it with the PreFilter turned off. And indeed i achieved about the same average compression advantage as with the PreFilter.

Details: Previous versions directly stored the predictor coefficients while the current implementation stores the parcor coefficients. Usually one would expect a bigger advantage for the parcor representation, but because of an initial transformation, that my codec performs on the signal, the storage requirement for the direct coefficients is only slightly bigger.

Advantages of the parcor representation over the PreFilter:

- While it doesn't encode faster than the PreFilter on the higher presets, it is much faster with lower predictor orders and therefore can be used for presets FAST and NORMAL and increase their compression.
- HIGH performs very well without the Optimize Quantization option and therefore is about 20 percent faster,

General disadvantages:

- The decoding speed of NORMAL, HIGH and EXTRA is beeing reduced by about the same amount as with the PreFilter.

Time for some data of my two main test file sets:

The table compares the current implementation of V0.09 with V0.07 (which has no PreFilter). Compression is the improvement of the compression ratio, Encode and decode show the change in encoding and decoding speed. Decoding has been performed without file output.

Short summary for V0.08 with PreFilter (was to lazy to build another table): No difference (fields would contain 0.00) to V0.07 for presets FAST and NORMAL, HIGH would compress only 0.03 percent better than V0.09 but with 30 percent less encoding speed. Decoding speed on HIGH identical to V0.09.

Preset HIGH of V0.09 uses neither the PreFilter nor the Optimize Quantization option. Both options have been moved to EXTRA.

What i like:

- The compression advantage for FAST and especially NORMAL.
- The 20 percent higher encoding speed for HIGH (30 percent better compared to V0.08).

Current preference for V0.09:

Use the configuration described above: New way to store the coefficients, PreFilter moved to preset EXTRA. I don't want to remove it, because it has such a huge effect on some (for instance Joseph Pohm's files).

Question:

The main advantage of Yalac is the high decoding performance. But V0.08 and V0.09 both reduce the decoding speed. Is the compression advantage worth the speed penality? Contrary to the PreFilter, there will be no option to disable the new way to store the prdictor coefficients.

Things to remember:

- The decoding performance has been measured without file output. With output turned on the speed difference would be smaller on most systems.
- The reduction of the decoding performance is directly related to the predictor order the encoder has choosen. If you want better decoding performance, you can always reduce the maximum predictor order the encoder is allowed to use.

I would change the way the coefficients are stored only for fast and normal. For high, extra and insane, I would activate the prefilter.

These would be my choices because in my experience, the prefilter hurt with my files @normal compression.

Why? The new way to store the coefficients (parcor) helps any preset and the PreFilter can always be applied additionally. And with the usage of the parcor coefficients the PreFilter is only advantegous on very special and rare files, therefore it seems well placed in preset EXTRA. Most important: It would make my code far more complex, if i would use both representations of the predictor coefficients.

Ah! I didn't think about the more complex code issue; in that case, maybe you could forget the prefilter altogether? Or put it only in extra and insane, yes. Or, in any case, make it toggleable in the other modes (if ever you need to restrict certain options..)

I'm sure you will find the right solution -- you seem to be so dedicated and well-thought-through.

Good luck,
Tristan.

Thanks!

That's the way i tried to describe above: PreFilter toggleable and activated by default only for preset EXTRA and INSANE.

I've written numerous responses to this now Thomas, but keep contradicting myself and going around in circles.

In my understanding the pre-filter was providing enough benefit to warrant its inclusion. It seems, on first impression, that the parcor method has benefits over using the pre-filter, but little to no disadvantage. With these two points in mind it would make sense to remove the pre-filter and implement the parcor method.

My main concern is the drop in speed for Fast, and Normal, especially encoding. As it stands Yalac is in the top league for decompression and encoding speed, while providing better compression than its competitors. However, Yalac cannot compete with the codecs for whom compression is utmost, e.g.: Monkey's Audio and OptimFROG.

By my results (although I am all too aware that they are affected by IO issues) 0.08 Fast decompressed significantly better than 0.07, but it seems 0.09 would now be slower than 0.07. I would like to see some more non-IO affected figures on this.

There is a compression difference of 0.728% between Yalac 0.08 Insane and Fast (less than 15MiB on my 2GiB corpus). The difference between FLAC -0 and -8 is 4.706%; Wavpack -hx to -f is 2.758%. I haven't yet worked out my point here, but it seems to lead me to the fact that there seems less reason for Yalac users to opt for a slower compression rate, knowing that they may only achieve a little saving. It's the same reason that I stick with Wavpack -h and don't use -x (a difference of 0.657% for my corpus). That said, many people seem to...

Without all this tweaking even 0.03's Fastest (64.690%) was getting much better compression than FLAC -8 (66.028%), and was even better than WavPack default (65.750%). The way I see it you've already achieved what you need to with regard to compression.

I think it is great to squeeze out some more MB for High to Insane, but I think Yalac could begin to lose some of the appeal of Fast, and perhaps Normal. The fact that Fast could potentially decode and encode faster then FLAC -0 (it's main "competitor" in this realm), while providing noticeably better compression, is very tempting.

I don't know, it's so difficult to call, but I guess my point is that I wouldn't want to see Fast or Normal losing any more speed.

As it stands I think the faster presets (Fast, Normal, maybe High) are Yalac's best selling points. I'm not sure if 0.2-03% better compression is as much concern to the target audience as the fact that it is the fastest, with considerably better compression.

I guess the benefit of the pre-filter is that it can be applied to some presets only, whereas a switch to parcor, one assumes, would have to be implemented for all presets. I think, if I could have a Fastest preset that just used Yalac's core/fastest techniques to compress (no doubt still compressing better than its direct competitors) I would be happiest.

I'm not overly happy with this response either (I see I'm still contradicting myself), but I'll leave it here at least as a starting point for further discussion.

Argh! I've just remembered the 20-25% improvement in encoding speed with High, which can't really be ignored; that is very impressive and extremely tempting... way too tempting. I'm also still trying to work out how bad a 6% reduction in encoding speed is for Fast...

Edit: OK, after re-reading the text above I suppose I would have to conclude that I would prefer the pre-filter was kept (if my understanding is correct). I would also like to see Normal worrying more about encoding and decoding speed than squeezing out more compression, even if it means making it compress slightly less well than currently... now there' a statement that should promote some discussion.

Yes, very much so, although I assumed "lightens" to mean that it took a weight off you, as in "Phew! That's a weight off my mind".

This seems to reflect my own trouble with this deceision...

But your and ShadeST's post allready enlightened me a bit!

I have to collect some more and more accurate data before i will answer to your post.

Here the updated data i promised:

- Encoding speed measured without file output.
- Corrected some errors in V0.09 data (especially preset HIGH).
- Only test set rw, because it seems more representative.
- More comparisons.



I will be back for some comments soon...


Edit: I forgot: Test system is a Pentium III with 800 MHz...

Somehow, I feel the speed loss is great compared to the compression gain; efficiency might not be an issue, here.

Could you also post results with IO speeds taken in account? (antivirus disabled, if you have one)

I think IO results will be necessary before we are able to judge the validity of the modifications and decide whether they are worth it or not...

Keep up the great work,
Tristan.

In general i would not agree!

Here my short comments:

- The difference for encoding and decoding speed on FAST between V0.09 and the other versions is not significant.
- Encoding and decoding on HIGH is faster for V0.09 than for V0.08! Since both decode slower than V0.07, it would be more appropriate to ask ourselfes, if we want to go back to V0.07: Remove parcor coefficients and the PreFilter!
- The most important disadvantage for V0.09 may be the 8.39 percent penality for decoding on NORMAL.
- Presset EXTRA seems not too important for me.


With IO turned on, the differences would be far smaller for FAST, a bit smaller for NORMAL and equal for HIGH and EXTRA. I don't think that this would help us...

Agreed.

Your figures are very persuasive.

My main concerns at the moment are Fast and Normal - especially Normal, considering that it should strive to be the best balance of speed and compression that Yalac can offer, IM(H)O .

I don't have an issue with the changes in Fast since 0.07, as you say they are negligable. Normal's drop in decoding speed is a slight concern.

I guess all I can do is reiterate that I would gladly see Normal and Fast lose some compression in order to speed up encoding and decoding (well, depending on the benefit gained. ).

It seems moving to parcor has too many benefits to ignore, but it is possible that you could now make other changes that would create a better spread between Fast and Insane.

I would be very interested to know what you could do, if given license to drop Normal's compression ratio by 0.2-0.3%, and Fast's by 0.5-0.7%. I don't know whether you have enough variables to achieve this, i.e.: whether past improvements have been code improvements that simply can't be undone for speed gains. If you did have some switches that you could simply turn off to favour speed over compression I would be interested to hear your thoughts on the possibilities though.

I would be very interested to hear your opinions, and Josef's. Anyone, in fact!

NB: Thomas, if you would like any of this split to a new thread just let me know. This thread does seem to sway off-topic, and some of this is more relevant to the thread "Yalac – Evaluation and optimization", which is sadly neglected... (poor thing).

Edit: Made text amendment as below...

I will need a bit time to answer, but i am not sure, if i understand this right: Shouldn't this be "if given license to drop Normal's compression ratio by 0.2-0.3%, and Fast's by 0.5-0.7%"?

Yes, sorry.

Please don't spend time on it if you think it is futile.

However, if you think the excercise may enlighten either/any of us, I would be very interested to hear your thoughts.

Yes. And it probably makes the first impression for new users. And some users will possibly never try any other preset. Therefore it should clearly show Yalac's strength (speed) and compare well to the default mode of other compressors.

In this context i am not too happy, that Yalac's NORMAL often compresses a bit worse than Monkey's NORMAL. Therefore i would like the 0.20 percent improvement provided by the parcor coefficients. Possibly this is the most important (psychological) advantage of the parcor coefficients for me...



There is not much that can be done to speed up FAST (at least not without big changes of my code): A decrease of the predictor order from 32 to 8 reduces compression by about 0.80 percent and provides about 25 percent faster encoding.

But a quick check for NORMAL looks more promising: Setting partition serch level from normal to fast reduces compression by about 0.06 percent and provides about 25 percent faster encoding. This looks promising. But don't forget my statements above: I would prefer NORMAL to compress a bit better! Ok, one more dceision...

Another option would be the reduction of the maximum predictor order from 128 to 96. V0.09 will give access to 8, 96 and 192 predictors. Probably HIGH will use only 192 predictors in the future.


I thought about it too. But is it really practicable? We need the comparison results for our discussion.

Another approach: We open another thread, where only the comparisons (of any or only of the latest version) are beeing posted.

Could you use a representation compatible with both normal and parcor coefficients?

Ah, perhaps this is the crux of the matter. I must admit, part of my logic revolves around Yalac Normal compressing at roughly the same speed as WavPack default, which is currently approximately 140% the speed of Yalac Normal, according to both mine and Josef's results. If Fast could match FLAC, and Normal could match WavPack, it would be quite a feat.

I must admit I don't consider Monkey's Audio that much. The benefit gained by using parcor would close this gap nicely.

OK, at least I know not to pursue that any further.

That is promising. However, as you say, I suppose the decision needs to be made whether you aim for the compression of Monkey's Audio, which is very achievable (perhaps achieved), or the speed of WavPack, which is a lot of ground to make up. I suppose it may be prudent to make the decision and then go all out for one or the other, and it's looking like Monkey's Audio is the goal to aim for.

It's no real effort for me to move posts to another thread, or split posts to another thread. Whatever you see fit, but I'll leave it for the moment.

Thanks for your time and patience Thomas.

The truth is: The discussion with you did help me to become more aware of my (sometimes hidden) motivations! It had been not clear for me, that the comparison with Monkey Normal was the most important reason for my (earlier...) preference for the parcor coefficients. And sometimes i am loosing the bigger image, when i am too involveld into some optimization details. This thread can correct this... and often did so.

No. It's the difference between the representations which makes one work better than the other.

Current Progress (V0.09)

I had to come to a deceision: Use parcor coefficients or not. I have deceided against it.

The speed penality for NORMAL and the higher presets was mostly responsible for the final deceision. Ok, the parcor coefficients would not be slower than the PreFilter, but i don't want to drop the PreFilter, beacuse it has such a huge advantage for some files. But keeping both -PreFilter and parcor coefficients- would have slowed encoding and decoding down by an inacceptable amount. And the PreFilter can be turned off (for higher speeds), which would not have been possible for the parcor coefficients.

Nice to get rid of this difficult deceision... But somehow i wasn't too happy afterwards.

I could not forget about the encoding speed up with the parcor coeffecients: about 25 percent for HIGH.

Again time for a reconfiguration of the presets. NORMAL encodes now 17 percent faster and looses 0.05 percent compression on my primary test file set.

Unfortunately this increases the distance to Monkey's NORMAL... But Synthetic Soul is right: Speed is the main advantage of Yalac! Hence i could sacrify a tiny bit of compression.

Now for HIGH: The parcor coefficients provided a speed up, because they did not need the "Optimize Quantization" option. Time to speed up this option. It 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!

There will be more changes for V0.09, but i will talk later about them.

BTW: Preset FASTEST is back. Not too important for me, but why not provide both extremes: INSANE for the upper, FASTEST for the lower end.

Thomas

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?

It would be nice if you could make YALAC decompress faster than WAV can be read (which is approx 200x on my system, I think)

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.

I think this is a huge factor. It allows you more flexibility for each preset.

That all sounds like very good news indeed.

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

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.

Yes, it's difficult, and i can not swear, that they will never come back...


Yes, IO speeds will increase. But usually CPU speeds are increasing faster! Therefore the gap between theoretical and practical (with IO) decoding speed will even grow!

One may sometimes get another impression, because cpu speed increases smoothly (ok, it will change with multi core cpus) while io speed always makes big jumps when the manufacturers double the density of the disk surfaces. And serial ATA has brought some nice improvements for the interface.

I can not get this out of my mind: Does it make sense to drop stronger compression methods ony because they slow down decoding by 20 to 30 percent? Isn't 2 to 3 times faster decoding than Monkey's Audio sufficient?

Ok, it may be a different matter if portable devices with very limited cpu power are beeing used for decoding. But here some other point becomes important: We are always evaluating the average decoding performance, but what's about the worst case?

For each subframe the encoder chooses the maximum predictor order (up to the limit defined by the preset), which increases compression. Your file may for instance use 20 predictors on average , but 256 for some subframes. These high predictor order subframes may need up to 3 times more cpu power! If your playback device is slow, you may have to limit the maximum predictor order to for instance 32 or 64 to avoid stuttering!

And this is important: If you limit the predictor order to such low values, the decoding speed penality for the parcor coefficients is not significant!

I think that as long as you can encode an album from a CD at real-time speeds versus extraction (which places the speeds at approx. 50x, tops), then it shouldn't really pose a problem to implement less computationally efficient methods. The thing is, though, that I consider 50-60 x encoding really important -- I quite dislike having to wait for the encoder when I extract a CD (though I don't extract at that speed either, don't worry)

The faster the better, though. I _am_ willing to sacrifice compression levels for speed and vice versa, but a compromise is always necessary. I think that for now, the thing to do would be to find the compromise that most people would choose to have, and match the results to that. Maybe starting a poll could help. If so, I'd be pleased to compile some questions and start that poll.

Keep us in touch, Master Tom

Have a nice day,
Tristan.

Well, i have been talking about decoding performance but most of it is relevant for encoding too.

For instance: The encoding speed for individual frames is variable. The variation is smaller than for decoding.

Would it matter for your purposes (extracting a cd), if for instance the average encoding speed is 50* but only 25* on some frames? Does this disturb the extracting process?


I will think about a poll. Thanks.

Thomas

Some very good points, and ones that I can't disagree with.

It's just so difficult to call! It's great to have the compression of Monkey's Audio Normal, but it's also great to encode as fast as FLAC and WavPack. Yalac is in a strange, perhaps difficult, place between fast codecs and high compressing codecs. Yalac has some superb qualities (I was looking at Josef's results earlier and noticed that Yalac is "only" 7th fastest at encoding, but it encodes 13% better than its nearest rival!), and it is a case of trying to make best use of those qualities, to find the right niche.

I suppose the decision has to be made regarding which users would opt for Yalac. Is it FLAC users wanting better compression, or Monkey's Audio users wanting faster decoding? That said, will a little variation in either direction stop the opposing factor from switching? Yalac could be very appealing to both factions, irrespective of which it tends slightly toward.

If parcor coefficients will be less effected by limiting predictor orders then that does seem an important point. If Yalac goes for speed the possibility of hardware support is higher, and this factor will be an issue.

I would dearly love to hear the opinions of some other, more knowledgeable, members.

It would be a pity to sacrifice encoding speed for extra reduction, but this seems inevitable given the increasing CPU speeds. However, it would be best if decoding speed remained as optimal as possible. The reasons for this are obvious when you see the hardware support for FLAC because of its fast decoding and finalized file format (container). I know that finaliziation for Yalac is further along than the current discussion, but it is worthwhile to consider.

During my testing I've enjoyed seeing how Yalac performs, it has accomplished quite a feat in both filesize reduction, encoding speeds and fast decoding. My opinion, I would not want to give up more than 10% encoding speed for a mere 2% file reduction

Oops, I just read this part. My bad

The current discussion might fit better under the "Optimizing Yalac" thread, not that I'm militant about these things

Because speed seems that much important, i could not resist: Looks as if V0.09 will include a FASTEST preset with at least 50 percent higher speed than FAST! It may compress 1.5 to 2.0 percent worse than FAST.

This should be sufficient to get a better rank in (not only) Josef Pohm's table...

Well, for me it's enough to pay for one night without sleep.