HydrogenAudio

Lossless Audio Compression => Lossless / Other Codecs => Topic started by: TBeck on 2006-04-10 07:30:00

Title: Yalac - Comparisons
Post by: TBeck on 2006-04-10 07:30:00
Content

In this thread the testers should post comparisons of the preset modes of Yalac (Working name for "Yet another lossless audio compressor") with other lossless compressors.

The results for specific variations of individual encoder options should go into the thread " Yalac – Evaluation and optimization".

Guidelines

Please post the exact version number of the compressors. Compression ratio should be specified in percent of the uncompressed file size. Speed figures should be specified as multiple of real time (duration of the test files). A specification of your test system, especially the CPU, would be helpful.

Open end: Feel free to add more results later.

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!

Goals

Yalac should finally achieve compression ratios on par with Monkey's Audio High. Decoding speed should be at least two times higher than Monkey and never be significantly lower than with FLAC (possibly Yalac will later be integrated into FLAC).

My next steps

The first results i have received from the testers show me some weaknesses of the encoder. That's a good thing, because that means, that there definitely is a chance to increase the compression efficiency! Same is true for the speed; especially the decoder is not fully optimized yet. But it will take some time, before i will come up with an optimized release.

Links to 24 bit files i have used

I think, they are hard to find.

Code: [Select]
44 KHz, 24 bit

mytek_8X96_24bit_web.wav
Mytek-stereo96adc_evans.wav
Mytek-stereo96adc_ravel.wav

Source: http://www.mytekdigital.com/compare/comparison1.htm

48 KHz, 24 bit

McDougalsMen24bit_48kHz.wav
sister24bit_48kHz.wav

Source: http://ff123.net/samples.html


Or make a better Google search. foosion shows you how: http://www.hydrogenaudio.org/forums/index....ndpost&p=381702 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=43289&view=findpost&p=381702)
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-11 18:05:54
My results can be found at the following address:

http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

 
Goals

Yalac  should finally achieve compression ratios on par with Monkey's Audio  High. Decoding speed should be at least two times higher than Monkey  and never be significantly lower than with FLAC (possibly Yalac will  later be integrated into FLAC).
My results seem to bear that out  completely:

Code: [Select]
Encoder Setting       Comp. %    Enc. Rate  Dec. Rate
Monkey's Audio High   52.002%       36.14x     34.30x
YALAC High            52.241%        5.70x     68.50x
FLAC -8               65.369%        8.76x     68.30x


A little more info in the main testing thread (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=43289&view=findpost&p=381527).
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-12 03:22:54
I had issues with the inability for Yalac to accept mono files and other files with RIFF header issues. I am most interested in default/normal settings.

Code: [Select]
29 files @ 16bit 44KHz   98,376,576 bytes   duration 9:03
=========================================================
name/mode         Ratio    EncTime    DecTime
--------------    ------    ------    ------
MAC 4.01 beta2    58.52%    48.70x    40.04x
normal
--------------    ------    ------    ------    
Yalac 0.02        59.78%    26.83x    132.87x
normal


edit: System = A64 3000+ 512MB Win2Ksp4
Title: Yalac - Comparisons
Post by: onthejazz on 2006-04-12 04:52:34
My results can be found at the following address:

http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

 
Goals

Yalac  should finally achieve compression ratios on par with Monkey's Audio  High. Decoding speed should be at least two times higher than Monkey  and never be significantly lower than with FLAC (possibly Yalac will  later be integrated into FLAC).
My results seem to bear that out  completely:

Code: [Select]
Encoder Setting       Comp. %    Enc. Rate  Dec. Rate
Monkey's Audio High   52.002%       36.14x     34.30x
YALAC High            52.241%        5.70x     68.50x
FLAC -8               65.369%        8.76x     68.30x



That is quite impressive how you have your site set up soul, so very easy to read and access the info within.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-12 22:09:07
Comparison now includes Yalac Fastest.
That  is quite impressive how you have your site set up soul, so very easy to  read and access the info within.
Thank you.  It made sense to me to store the data in a relational database rather than a spreadsheet or other flat file.

That said, I do mean to add the abilty to download any view in CSV format, for viewing in Excel.  Maybe tomorrow.
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-13 21:54:56
These are benchmarks with Yalac 0.03 with two albums (EAC CDImage file). The first album is rock recording that was remastered and represents modern, heavily compressed albums. The second is an un-remasted pop/rock album.

Notice that the behavior of each codec on different types albums affect both compression ratio and processing time:

Code: [Select]
Slayer - South of Heaven (remaster)  390,702,524 bytes   duration 36:54
=======================================================================
name/params Ratio EncTime DecTime
--------------------- ------ ------ ------
Yalac 0.03 fastest 74.20% 44.92x 66.64x
Yalac 0.03 fast 73.61% 37.91x 66.06x
MAC 4.01 beta2 -c1000 74.34% 63.26x 48.13x
FLAC 1.1.2 --fast 79.47% 65.12x 67.09x
WavPack 4.3 -f 76.73% 63.26x 60.81x
OFR 4.520 --mode fast 73.60% 23.55x 35.14x
--------------------- ------ ------ ------
Yalac 0.03 normal 73.33% 24.47x 66.90x
MAC 4.01 beta2 -c2000 73.14% 48.13x 41.77x
FLAC 1.1.2 (default) 75.70% 51.49x 65.12x
WavPack 4.3 (default) 75.42% 58.26x 61.50x
OFR 4.520 (default) 73.00% 16.65x 24.60x
LA 0.4 normal 71.65% 5.93x 7.72x
TTA 3.3 (default) 74.78% 55.68x 55.52x
--------------------- ------ ------ ------
Yalac 0.03 high 73.14% 7.30x 67.62x
MAC 4.01 beta2 -c3000 72.88% 41.93x 37.85x
FLAC 1.1.2 --best 75.49% 11.78x 67.09x
WavPack 4.3 -h 73.82% 44.61x 53.92x
OFR 4.520 --mode high 72.77% 11.41x 16.65x
LA 0.4 high 71.52% 4.44x 5.38x
--------------------- ------ ------ ------
Code: [Select]
The Police - Synchonicity (1983)   471,176,204 bytes   duration 44:31
=====================================================================
name/params Ratio EncTime DecTime
------------------ ------ ------ ------
Yalac 0.03 fastest 51.44% 49.25x 76.49x
Yalac 0.03 fast 50.73% 39.84x 82.54x
MAC 4.01 beta2 -c1000 51.46% 66.94x 53.85x
FLAC 1.1.2 --fast 58.43% 74.19x 78.56x
WavPack 4.3 -f 53.29% 73.52x 76.86x
OFR 4.520 --mode fast 50.76% 23.43x 35.61x
--------------------- ------ ------ ------
Yalac 0.03 normal 50.34% 25.45x 71.72x
MAC 4.01 beta2 -c2000 49.88% 50.01x 44.08x
FLAC 1.1.2 (default) 52.92% 56.83x 78.56x
WavPack 4.3 (default) 52.22% 67.95x 75.10x
OFR 4.520 (default) 49.73% 17.12x 25.44x
LA 0.4 (normal) 48.42% 6.04x 7.94x
TTA 3.3 (default) 51.05% 65.77x 57.87x
--------------------- ------ ------ ------
Yalac 0.03 high 50.12% 7.22x 79.10x
MAC 4.01 beta2 -c3000 49.57% 42.80x 39.87x
FLAC 1.1.2 --best 52.63% 12.20x 78.56x
WavPack 4.3 -h 50.61% 48.44x 64.41x
OFR 4.520 --mode high 49.38% 11.77x 16.59x
LA 0.4 -high 48.23% 4.54x 5.48x
--------------------- ------ ------ ------

Yalac already has great performance and ratio. It would be interesting to see if the encoding time can be further optimized

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]edit: added LA scores, not interesting since it usually gets the best ratio, is extremely slow and it crashed
edit2: added TTA scores[/size]
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-13 22:40:42
Yalac already has great performance and ratio. It would be interesting to see if the encoding time can be further optimized


Many thanks!

I will work on the speed of the HIGH preset later. I would like it to be only two times slower than NORMAL.

  Thomas
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-18 01:13:24
Test #3 - LP recorded to cassette, includes vinyl pops, tape hiss, distortion from the A/D conversion process, etc.:
Code: [Select]
Harry Nilsson - Son of Schmilsson (3rd gen copy)   434,970,156 bytes   duration 41:05
=====================================================================================
name/params Ratio EncTime DecTime
--------------------- ------ ------ ------
Yalac 0.03 fastest 61.92% 47.60x 70.00x
Yalac 0.03 fast 61.49% 38.79x 71.55x
MAC 4.01 beta2 -c1000 62.42% 61.87x 52.00x
FLAC 1.1.2 --fast 67.98% 66.99x 69.90x
WavPack 4.3 -f 66.82% 65.30x 68.09x
OFR 4.520 --mode fast 61.31% 22.88x 35.48x
--------------------- ------ ------ ------
Yalac 0.03 normal 61.30% 24.35x 70.01x
MAC 4.01 beta2 -c2000 61.22% 49.61x 41.86x
FLAC 1.1.2 (default) 63.24% 53.94x 70.84x
WavPack 4.3 (default) 60.93% 62.43x 67.68x
OFR 4.520 (default) 60.69% 16.70x 25.20x
LA 0.4 (normal) 59.84% 5.77x 7.88x
TTA 3.3 (default) 63.42% 60.31x 57.60x
--------------------- ------ ------ ------
Yalac 0.03 high 61.17% 7.09x 69.69x
MAC 4.01 beta2 -c3000 60.94% 40.63x 38.48x
FLAC 1.1.2 --best 62.95% 11.86x 70.75x
WavPack 4.3 -h 62.47% 43.76x 57.96x
OFR 4.520 --mode high 60.54% 11.62x 16.56x
LA 0.4 -high 59.66% 4.51x 5.42x
--------------------- ------ ------ ------

Test #4 - spoken word, dialogue, mono, recorded directly to digital medium - no transfer
Code: [Select]
spoken word - mono - 16bit 44KHz   183,064,762 bytes   duration 34:35
=====================================================================
name/params Ratio EncTime DecTime
--------------------- ------ ------ ------
Yalac 0.04 fastest 26.52% 316.88x 237.72x
Yalac 0.04 fast 26.10% 205.96x 301.75x
MAC 4.01 beta2 -c1000 27.84% 157.16x 120.84x
FLAC 1.1.2 --fast 30.30% 272.13x 349.50x
WavPack 4.3 -f 28.86% 232.99x 262.46x
OFR 4.520 --mode fast 25.52% 63.24x 81.27x
--------------------- ------ ------ ------
Yalac 0.04 normal 25.84% 103.70x 287.82x
MAC 4.01 beta2 -c2000 26.36% 109.30x 94.39x
FLAC 1.1.2 (default) 28.41% 214.20x 332.85x
WavPack 4.3 (default) 28.07% 195.59x 225.86x
OFR 4.520 (default) 25.26% 44.70x 57.92x
LA 0.4 normal 25.39% 14.13x 18.66x
TTA 3.3 (default) 26.81% 202.44x 129.33x
--------------------- ------ ------ ------
Yalac 0.04 high 25.70% 17.22x 284.41x
MAC 4.01 beta2 -c3000 26.05% 95.47x 83.21x
FLAC 1.1.2 --best 28.18% 47.48x 327.90x
WavPack 4.3 -h 27.08% 94.31x 106.24x
OFR 4.520 --mode high 25.14% 29.05x 38.15x
LA 0.4 high 25.44% 9.23x 10.36x
--------------------- ------ ------ ------
edit: added TTA scores
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-04-18 01:21:52
Destroid's results prove that YALAC is the best asymetric lossless audio codec to date.

Congrats, Thomas!

Keep up the hard work.  And tell us if your house is still in one piece.
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-18 02:56:03
Quote
' date='Apr 18 2006, 12:21 AM' post='383537']
Destroid's results prove that YALAC is the best asymetric lossless audio codec to date.

Congrats, Thomas!

Keep up the hard work.  And tell us if your house is still in one piece.

The most obvious thing I'm overlooking is testing with MPEG-4 ALS, which has many confusing parameters. I do not know the equivilent command line for fast/normal/high settings. And I'm not sure if either of the two existing MPEG-4 ALS binaries is representative of the codec at this time.

Otherwise, yes. Yalac delivers MA compression ratio with FLAC decompression speed.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-18 09:47:51
Garf posted some suggestions for "presets" here (http://www.hydrogenaudio.org/forums/index.php?showtopic=40451), and there are some other suggestions in that thread. Also, in the main Yalac thread, Joseph Pohm suggested a setting which I used here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=43289&view=findpost&p=379098), and Thomas responded with some settings that he had used here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=43289&view=findpost&p=379305).

When I tested there were three binaries: the reference software, the bug-fixed version, and Garf's optimised version.  On checking the MP4ALS page (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads) now it seems a newer version will be released in the next few days.

As you say, whether testing against a reference encoder is relevant at all is another matter.  I didn't put too much emphasis on MP4ALS as I am more interested in testing Yalac against current popular codecs.
Title: Yalac - Comparisons
Post by: vinnie97 on 2006-04-18 10:13:00
I'm still waiting for something to beat LA's compression ratio...I guess it would take a pretty substantial breakthrough in lossless compression before that happens.
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-18 11:09:11
Garf posted some suggestions for "presets" here (http://www.hydrogenaudio.org/forums/index.php?showtopic=40451), and there are some other suggestions in that thread. Also, in the main Yalac thread, Joseph Pohm suggested a setting which I used here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=43289&view=findpost&p=379098), and Thomas responded with some settings that he had used here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=43289&view=findpost&p=379305).

When I tested there were three binaries: the reference software, the bug-fixed version, and Garf's optimised version.  On checking the MP4ALS page (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads) now it seems a newer version will be released in the next few days.

As you say, whether testing against a reference encoder is relevant at all is another matter.  I didn't put too much emphasis on MP4ALS as I am more interested in testing Yalac against current popular codecs.


This is exactly what I approximated. I will look into MP4ALS benchmarks from these threads. It appears that MP4ALS is better at multichannel. Not all lossless encoders are outfitted for such applications.
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-18 11:23:31
This is exactly what I approximated. I will look into MP4ALS benchmarks from these threads. It appears that MP4ALS is better at multichannel. Not all lossless encoders are outfitted for such applications.


I agree. And that's one reason, why i was very interested into the results of your test of mono files. They seem to comfirm my own findings: The difference between YALAC and other better performing compressors is smaller with mono than with stereo files. My channel decorrelation obviously needs some improvement.

Many thanks for your tests!

  Thomas
Title: Yalac - Comparisons
Post by: Firon on 2006-04-18 11:40:04
I'm really impressed, the fast compression ratio is almost as good as MA on normal! If the encoding speed could be improved a little on high, then YALAC would even be more amazing.

Thanks for testing it Destroid, and thanks for working on this TBeck, this format might just rock the lossless world
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-18 11:47:34
I'm really impressed, the fast compression ratio is almost as good as MA on normal! If the encoding speed could be improved a little on high, then YALAC would even be more amazing.


High will be improved! One simple way to achieve this would be the deactivation of one encoder options, which is most responsible for the speed decrease from Normal to high, but usually gives only a small improvement of compression ratio.

Another possibility would be the optimization of the slow encoder option. I allready have one prototype, which performs about 70 percent better speedwise.

  Thomas
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-18 11:49:01
I agree. And that's one reason, why i was very interested into the results of your test of mono files. They seem to comfirm my own findings: The difference between YALAC and other better performing compressors is smaller with mono than with stereo files. My channel decorrelation obviously needs some improvement.


Wow.

My first observations in monural audio is your codec is very competitive. And for your information, I was running binary comparisons of the output from Yalac to the original and the source file, and there were no differences.

Very well done.
Title: Yalac - Comparisons
Post by: JB_ on 2006-04-18 12:01:06
Hello, its my 1st post here.
Have you guys know this audio lossless software? (http://www.true-audio.com/)
it compresses very good too, better than flac and also has a winamp plugin.
it would be interesting to test it and compare it with Yalac in these listings.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-18 12:11:41
Following my comparison using 16bit 44.1KHz stereo tracks I had started preparing for a comparison using the same tracks converted to mono, and also 48KHz and 24 bit.

Is it worth me continuing with this?

I am also wary that you, Thomas, are currently in the process of changing things around a fair bit.  I wonder whether I might do better to hold off until you release these changes?

That said, I am, of course, happy to help if you would like more variety in your results.  I just don't want to be wasting my time really, if you feel that you already have enough data for the current run.
Title: Yalac - Comparisons
Post by: [proxima] on 2006-04-18 12:18:56
Have you guys know this audio lossless software? (http://www.true-audio.com/)

Of course, the developer Alexander Djourik (ald (http://www.hydrogenaudio.org/forums/index.php?showuser=10478)) is a member of Hydrogen Audio.
Quote
it would be interesting to test it and compare it with Yalac in these listings.

TTA was considered in previous tests by guruboolez (http://guruboolez.free.fr/lossless/ (http://guruboolez.free.fr/lossless/)), speek (http://members.home.nl/w.speek/comparison.htm (http://members.home.nl/w.speek/comparison.htm)) and Hans Heijden (http://web.inter.nl.net/users/hvdh/lossless/lossless.htm (http://web.inter.nl.net/users/hvdh/lossless/lossless.htm))
Title: Yalac - Comparisons
Post by: pest on 2006-04-18 12:23:26
Quote
My channel decorrelation obviously needs some improvement.


i think most stereo decorrelation is in the predictors. if you do something
simple as ms-decorrelation + predictors the results are always suboptimal.
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-18 14:20:01
Following my comparison using 16bit 44.1KHz stereo tracks I had started preparing for a comparison using the same tracks converted to mono, and also 48KHz and 24 bit.

Is it worth me continuing with this?

I am also wary that you, Thomas, are currently in the process of changing things around a fair bit.  I wonder whether I might do better to hold off until you release these changes?

That said, I am, of course, happy to help if you would like more variety in your results.  I just don't want to be wasting my time really, if you feel that you already have enough data for the current run.


Very nice!

But good that you have asked:

1) More mono tests aren't necessary for my purposes. It's good that one tester has confirmed my own findings.

2) 48 Khz vs.  44 Khz shouldn't change much.

3) If i convert 16 to 24 bit files with Cooledit, it only does shift the original lower bits 8 bits up and fills the free space (the new lower 8 bits) with 0. If you try such files with YALAC, you will only find, that YALAC doesn't look for this special case (an option sometimes called 'Look for wasted bits') and will perform very bad compared to other compressors. The implementation of such a check is easy but not done yet.

Real 24 bit files would be far more interesting.

I surely will ask for more specific tests, if there are improvements, that are worth the effort.

This should not stop testing! Other files can always give surprising results, which give me hints for further improvements.

One important note:

I tend to write too much about my actual improvements. But they are only prototypes! It will take a considerable amount of time to optimize and debug them! There will be no considerably improved releases within the next weeks! Speedups are a different matter, they may come fast.

I tend to forget, how long it did take, to built the actual YALAC.

  Thomas
Title: Yalac - Comparisons
Post by: JB_ on 2006-04-18 16:31:33
Quote
TTA was considered in previous tests by guruboolez (http://guruboolez.free.fr/lossless/ (http://guruboolez.free.fr/lossless/)), speek (http://members.home.nl/w.speek/comparison.htm (http://members.home.nl/w.speek/comparison.htm)) and Hans Heijden (http://web.inter.nl.net/users/hvdh/lossless/lossless.htm (http://web.inter.nl.net/users/hvdh/lossless/lossless.htm))


is there a reason not to test it along with Yalac?
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-18 16:42:51
Not especially.  Is there a compelling reason to include it though?

Personally I chose to compare Yalac with the popular codecs, at relevant settings.

It doesn't seem that TTA offers anything spectacular to warrant it being included.  It appears to be no real competition in compression or decoding speed.

I don't mind adding a run to my comparison, it would be little trouble.
Title: Yalac - Comparisons
Post by: moozooh on 2006-04-18 18:20:30
TBeck,

Your compressor is actually a BOMB. Right now, it offers the best possible compromise between compression ratio and decoding speed. Thank you for being so awesome.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-18 18:49:51
Out of interest on my part TTA is now included when specifying All=1

http://synthetic-soul.co.uk/comparison/los...index.asp?All=1 (http://synthetic-soul.co.uk/comparison/lossless/index.asp?All=1)
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-04-18 19:13:39
Out of interest on my part TTA is now included when specifying All=1

http://synthetic-soul.co.uk/comparison/los...index.asp?All=1 (http://synthetic-soul.co.uk/comparison/lossless/index.asp?All=1)

Is there any way you can add some columns? 
Code: [Select]
Compression rate / decompression rate

.. and
Code: [Select]
100*log(compression rate / compression ratio)
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-18 22:06:52
Yes, that would be possible.

Another member previously suggested that I include some rating based on compression and speed, in an attempt to rate an en-/decoder further.  I know Joseph Pohm uses such a calculation (I've seen his impressive comparison results), but I'm not sure of the algorithm.

I'm a little limited for width on the table.  I would have to drop a column or two to accommodate more data.

I'll try to take a look tomorrow though.

Is the second calculation standard, i.e.: is that a well-known method to obtain a rating for an encoder?

Edit: I may actually include TTA in the core results, as it does hold one record; that of fastest compressor.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-04-18 22:30:56
That second method is evaluating the compresser's algorithmic efficiency, more or less.
Title: Yalac - Comparisons
Post by: audiofreak on 2006-04-19 00:43:36
Quote
' date='Apr 18 2006, 02:13 PM' post='383820']

Out of interest on my part TTA is now included when specifying All=1

http://synthetic-soul.co.uk/comparison/los...index.asp?All=1 (http://synthetic-soul.co.uk/comparison/lossless/index.asp?All=1)

Is there any way you can add some columns? 
Code: [Select]
Compression rate / decompression rate

.. and
Code: [Select]
100*log(compression rate / compression ratio)



The first one looks good, but I can't see how the log helps at all in the second one.  If the encoder was in fact logarithmic, it should be x*log(compression rate) / compression ratio, where x is a coefficient.  100 would work for x.  If you would like a more detailed explanation as to why compression ratio shouldn't be in the log, I could explain.

Therefore, I would suggest:
Code: [Select]
100*log(compression rate) / compression ratio
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-04-19 01:19:00
Good idea.  Now make it   
Title: Yalac - Comparisons
Post by: audiofreak on 2006-04-19 01:42:46
Quote
' date='Apr 18 2006, 08:19 PM' post='383926']
Good idea.  Now make it   

On second thought, since none of the codecs work logarithmically but rather asymptotically, then it wouldn't work.  Sorry.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-19 07:44:28
Well, OK, if anyone can suggest an algorithm that would provide a useful rating then I will be happy to add it.

You could always use my "Download to CSV" feature to test using my data in Excel...

I don't have much time at the moment (I've quit my job and need to learn PHP/Postgre before I start my new one) so I need to be certain that any time I do allocate is being spent wisely.
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-23 10:50:21
Current Progress

you may call it Tom's diary...

For the time beeing i have given up the idea to look for bigger (> 0.3 percent) increases of the compression efficiency of the higher presets. There are promising new methods, but they have to be evaluated which will take a long time (maybe months).

For now it seems a better approach to optimize the existing methods:

- Squeeze the last bits out of the algorithms.
- Make them faster.
- Clean up the source code.
- Constitute better presets that are well balanced for speed-compression ratio.

First results:

Preset FASTEST is gone. The new FAST preset achieves the same speed on my system and does this with only a small decrease in compression efficiency (maximum 25 percent of the difference between old FAST and FASTEST).

Next goals:

Make preset HIGH faster.

I would be glad, if one or two of the testers, who allready have posted results, would check the new FAST-Preset against the old one.

A new version for all testers will be released, when more presets are tuned or i am unsure about the general effect (my test corpus isn't representative) of specific optimizations. The current version may not be too stable and besides FAST anything might change soon.

  Thomas
Title: Yalac - Comparisons
Post by: audiofreak on 2006-04-23 15:19:25
Moderation: Removed unnecessary quote

This may sound like a stupid question, but where would I download it?  I would be very interested to test some stuff on it...
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-24 02:43:35
Moderation: Removed unnecessary quote

This may sound like a stupid question, but where would I download it?  I would be very interested to test some stuff on it...


No stupid question!

But it's a closed test now, because there are enough testers to help me with my current optimizations. If one of the testers should leave, you were welcome to participate. I put your name on my list.

Thanks for your interest

  Thomas
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-24 18:11:08
At last, the first set of monural instrument tracks  Notice how this type of material favors all lossless encoders.
Code: [Select]
single instrument tracks -- mono, 16bit 44KHz    11 files    99,822,476 bytes
=============================================================================
name/params Ratio EncTime DecTime
--------------------- ------ ------ ------
Yalac 0.04 fastest 31.12% 328.67x 260.09x
Yalac 0.04 fast 30.60% 213.64x 312.14x
MAC 4.01 beta2 -c1000 33.14% 149.20x 116.94x
FLAC 1.1.2 --fast 35.03% 270.69x 310.34x
WavPack 4.3 -f 32.67% 242.46x 260.90x
OFR 4.520 --mode fast 28.55% 64.11x 86.13x
--------------------- ------ ------ ------
Yalac 0.04 normal 30.35% 111.24x 272.57x
MAC 4.01 beta2 -c2000 31.78% 102.93x 91.09x
FLAC 1.1.2 (default) 32.92% 218.19x 320.06x
WavPack 4.3 (default) 33.04% 201.69x 227.14x
OFR 4.520 (default) 28.36% 44.58x 59.85x
TTA 3.3 (default) 31.22% 211.15x 146.05x
--------------------- ------ ------ ------
Yalac 0.04 high 30.13% 20.08x 289.26x
MAC 4.01 beta2 -c3000 31.56% 89.50x 80.36x
FLAC 1.1.2 --best 32.97% 49.28x 324.29x
WavPack 4.3 -h 31.79% 97.56x 109.10x
OFR 4.520 --mode high 28.26% 28.74x 39.00x
--------------------- ------ ------ ------
It's safe to exclude LA for obvious reasons, but also because of the binary's odd behavior in my script.

TTA was benchmarked (and TTA was added to my previous tests in this thread). TTA is comparable to MAC fast (-c1000).
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-26 04:31:20
Current Progress (V0.05)

In my last post i asked for testers for a partial update with an optimized FAST preset. But the general optimization goes faster than expected, hence the next full release for any tester will come soon and an intermediate release wouldn't make much sense.

Done:

- Preset FASTEST is gone. The new FAST preset achieves the same speed on my system and does this with only a small decrease in compression efficiency (maximum 25 percent of the difference between old FAST and FASTEST).

- Preset HIGH is now 40 percent faster on my system. INSANE should benefit even more from the optimizations, but you know, that it isn't really useful.

- Removed 'Apply Window' from preset HIGH, because it sometimes hurts enormously. Because of some other slight optimizations HIGH should not perform worse than before.

To do (for V.0.05):

- Speed optimization of Frame Partition Calculator resolution 256, which is much slower than 128.

- Look for more speed optimizations.


If someone should remember some older post: My home is still intact. They digged for world war II bombs but obviously only found some rotten metal... 


  Thomas
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-04-26 10:01:33
Cool, thanks for the update Thomas.

I thought I should reply to let you know that I, and I'm sure many other members, do find these updates of interest.

Oh, and I'm glad that your home is still in one piece. 
Title: Yalac - Comparisons
Post by: TBeck on 2006-04-29 11:18:48
V0.05 is done

Changes:

- Preset FASTEST is gone. The new FAST preset achieves the same speed on my system and does this with only a small decrease in compression efficiency (maximum 25 percent of the difference between old FAST and FASTEST).
- Preset HIGH is 40 percent faster on my system.
- Preset HIGH activates the option "Bitcoder / Optimize choice".
- Preset INSANE uses frame partition resolution 256 and the new encoder option "BitCoder / Optimize Partition".
- Modification of the window function used by "Apply Window". Might help with some problem files...
- Selection of a preset doesn't affect the debug options in the encoder options dialog anymore.
- Select the new debug option "No output" to encode without generating files.
- Redesign of the dialogue options for frame partitioning.
- Error in BitCoder fixed, which sometimes generated errors in the file stream.
- Working data of the decoder was not properly aligned. The fix can improve decoding performance on some systems.
- Clean up of source code. Could give new errors...
- File format changed!

Not done:

- Speed optimization of Frame Partition Calculator resolution 256, which is much slower than 128. Unfortunately my new algorithm didn't work well.

Release:

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

Destroid
guruboolez
Josef Pohm
Shade[ST]
Synthetic Soul

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 could be tested:

The performance of the new implementations of the presets FAST, HIGH and INSANE  might have changed.

Apply window should hurt less on the rare problem files.

Plans for V 0.06:

- Implementation of a simple command line version.
- Possibly some further assembler optimization to speed up especially preset HIGH. All optimizations in V0.05 were algorithmic.
- More clean ups of my source code. Not really interesting for the tests.


  Thomas
Title: Yalac - Comparisons
Post by: guruboolez on 2006-04-29 11:39:56
I have a question, related to the fact that I haven't post any result these last days. Is it possible, or not too hard or too long, to get a CLI encoder?
The reason I'm asking for that is simple:

My collection of (classical music) files is losslessly ~4GB; once uncompressed to work with YALAC, it's 10 GB. And once encoded with YALAC, I have to deal with 14 GB (10 GB of wav file and 4 of .yaa ones). I'm in vacation, with my laptop, but I can't get such free space on my HDD. Even my desktop computer is currently short in free space.
With a CLI encoder testing would be easier (direct lossless -> yalac transcoding).

N.B. the slowness of my laptop harddrive, and the level of fragmentation, is making speed comparison absolutely unreliable at the moment.

N.B. a "test" tool (i.e. decoding the stream but without file writing, thus with limited disk access) should also significantly increase the speed measurement accuracy.


EDIT:
just noticed that:
Quote
Plans for V 0.06:

- Implementation of a simple command line version.


Cool!
Title: Yalac - Comparisons
Post by: Supacon on 2006-04-29 18:41:27
It's good to see that you're progressing rapidly, TBeck.  It's very exciting to see progress on this.  And I'm really glad that your house didn't get blown up too!

Keep it up!

By the way, I see you have some goals for your 0.06 release.  Maybe you're not yet prepared to answer this, but what all do you want to have done before releasing a public, stable version of your codec? (One that can be addid into the HA Lossless wiki)
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-29 22:29:47
EDIT:
just noticed that:
Quote
Plans for V 0.06:

- Implementation of a simple command line version.


Cool!


Yes!

I am for this as well. Why? Because my script is dumb-smart and doesn't need to be monitored. Any testers that are interested cam PM me. It's main proficiencies are that it works on only files that start with an underscore, outputs files with double-underscore and deletes the output files starting with double-underscore. It  outputs the time/filesize to screen with simple commands which can be logged to file with the redirect option. And now it works with LA using a work-around
Title: Yalac - Comparisons
Post by: boombaard on 2006-04-29 22:58:35
V0.05 is done
I hope to send the new version to the following testers within the next hours:

Destroid
guruboolez
Josef Pohm
Shade[ST]
Synthetic Soul

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


myea, sorry.. but between increased workload at uni, and seeing the depressingly professionally done results of Synthetic (), and knowing guru is also helping testing (knowing he also tests classical music specifically), it's a bit hard to figure out what i might still add to the mix that isn't represented already ;(

still, the CLI in the next version might make it a bit easier for me to just batch-test stuff to see if i can find odd behavior in random tracks, so who knows )
Title: Yalac - Comparisons
Post by: Destroid on 2006-04-30 03:07:14
The speed up in high mode is there.
Code: [Select]
Occult - Elegy for the Weak    428,957,804 bytes   duration 40:31
=================================================================
name/params Ratio EncTime DecTime
--------------------- ------ ------ ------
Yalac 0.04 fastest 77.76% 48.03x 59.62x
Yalac 0.04 fast 77.34% 60.57x 63.34x
Yalac 0.05 fast 77.47% 46.80x 66.60x

Yalac 0.04 normal 77.20% 27.97x 64.48x
Yalac 0.05 normal 77.20% 26.58x 62.78x

Yalac 0.04 high 77.06% 7.99x 68.93x
Yalac 0.05 high 77.02% 11.60x 64.31x

Yalac 0.04 insane 77.00% 4.84x 63.10x
Yalac 0.05 insane 76.94% 4.47x 68.69x

This time I threw at Yalac the most difficult CD I own (AlbumRG scan = -12.24dB) to see if any compression changes were present with the increased encoding speed.

Code: [Select]
name/params		Ratio	EncTime	DecTime
--------------------- ------ ------ ------
Yalac 0.05 fast 77.47% 46.80x 66.60x
MAC 4.01 beta2 -c1000 77.64% 62.01x 47.25x
FLAC 1.1.2 --fast 84.91% 64.29x 56.95x
WavPack 4.3 -f 80.49% 54.73x 56.56x
OFR 4.520 --mode fast 77.04% 22.08x 34.80x
--------------------- ------ ------ ------
Yalac 0.05 normal 77.20% 26.58x 62.78x
MAC 4.01 beta2 -c2000 76.67% 47.93x 40.65x
FLAC 1.1.2 (default) 78.61% 47.18x 60.89x
TTA 3.3 77.77% 54.73x 57.00x
WavPack 4.3 (default) 78.85% 55.74x 54.82x
MP4ALS RM17 (default) 77.84% 28.95x 43.95x
OFR 4.520 (default) 76.58% 16.44x 24.77x
LA 0.4 normal 75.87% 6.11x 7.80x
--------------------- ------ ------ ------
Yalac 0.05 high 77.02% 11.60x 64.31x
MAC 4.01 beta2 -c3000 76.54% 41.87x 37.04x
FLAC 1.1.2 --best 78.46% 11.75x 61.18x
WavPack 4.3 -h 77.42% 42.20x 52.07x
MP4ALS RM17 -7 76.98% 1.40x 18.05x
OFR 4.520 --mode high 76.57% 11.42x 16.50x
LA 0.4 high 75.82% 4.53x 5.34x
edit: clarification - RG scan, changes were not applied
edit2: other compressors' scores added
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-02 13:07:19
The speed up in high mode is there.


Many thanks for your immediate testing! I am always very curious after a release...

Good to see the overall performance at about the levels i would have expected. Why old Fast is faster than new Fast is a tough question. Maybe the bigger frame size of old fast is better for your system. Possibly disk IO is faster when the data is beeing written in bigger chunks. Or it's a strange issue with the CPU cache.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-02 13:31:13
By the way, I see you have some goals for your 0.06 release.  Maybe you're not yet prepared to answer this, but what all do you want to have done before releasing a public, stable version of your codec? (One that can be addid into the HA Lossless wiki)


The public release should add at least those features:

- Integrity checking of individual frames and error resistance: Possibility to skip damaged frames.
- Seektables for fast seeking.
- Inclusion of additional RIFF-info of the source wave file to reconstruct not only the original audio data but the whole source data.
- Some tagging support.

I will think about the details later.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-02 15:07:44
Hello Thomas,

Do you think you could slightly interrupt your optimizations to make a command line mode?  I don't think this should be programmatically complicated, but it would be very useful for batch series of tests...

Thanks,
Tristan.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-02 15:38:14
Quote
' date='May 2 2006, 04:07 PM' post='388504']
Hello Thomas,

Do you think you could slightly interrupt your optimizations to make a command line mode?  I don't think this should be programmatically complicated, but it would be very useful for batch series of tests...


Thanks for asking so careful... 

Ok, i will try a minimalistic command line version:

- Specification of encode/decode.
- Specification of a single file or any files (*) of an directory (how should this be specified?).
- Specification of a preset.
- Switch protocol on/off.

Would this be sufficient for the tests?

I wanted to add more options, e.g. the specification of any encoder option (far more than accessible by the dialog) within external script files. But i should make the testing easier as soon as possible.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-02 16:40:28
That should be fine.. if no filename is listed, maybe you could make it automatically check for a --all switch or something like that.

Most of us will probably be using Synthetic Soul's batch file to do our testing (because, for sure, he WILL release one.. He likes to make batch files so much!), and that will be per-file, anyways. 


Here is (maybe) the text you could put in the docs.

Code: [Select]
YALAC command-line audio encoder

yalacc (filename | --all) [--decode] (-f | [-n] | -h | -i ) [--log]

filename : file to compress or decompress.
--all : compresses all files in current folder, using the specified settings.

--decode : decodes specified YALAC file(s)

-f (--fast) : compress using fast compression.
-n (--normal) : compress using normal compression (default)
-h (--high) : compress using high compression
-i (--insane) : compress using insane compression (SLOW)

--log : enable logging (debug / off by default)

The extra c on yalacc is for command-line (that way, gui-inclined people can still use the gui, if they want to)
Also, I suggest using "log" instead of "protocol" -- it's more relevant to the english language.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-02 16:58:35
Quote
' date='May 2 2006, 05:40 PM' post='388534']

yalacc (filename | --all) [--decode] (-f | [-n] | -h | -i ) [--log]

The extra c on yalacc is for command-line (that way, gui-inclined people can still use the gui, if they want to)
Also, I suggest using "log" instead of "protocol" -- it's more relevant to the english language.



How comes you did steal my latest innovation: "yalacc" !? 

The preset options will possibly get a bit modified.

What about overwriting files? Would the GUI-behaviour be ok (for the tests): Overwriting without warning but with added suffix "_d"?
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-02 18:23:16
Maybe add a target directory option, so that the decoded file is in another directory.  This shouldn't be necessary, though : if filenames are passed correctly, they can be from another folder, and that will not pose a problem.

Are you seriously mad that I guessed what you would call your command-line YALAC?  Sorry
Title: Yalac - Comparisons
Post by: Destroid on 2006-05-02 22:28:45
My $0.02 USD, I would like to avoid the wildcard function in the command-line version and focus on:

YALAC [-f(ast), -h(igh), -d(ecode) {default=normal}] infile [outfile]


The batch file I test with uses FOR loop, but one problem I ran into LA.EXE was not being able to control the output filename, so I had to resort to using a hack.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-02 22:54:45
In that case, (infile | --all) (compression options) (logging on) -o (outputfile) would be best.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-02 22:55:34
My $0.02 USD, I would like to avoid the wildcard function in the command-line version and focus on:

YALAC [-f(ast), -h(igh), -d(ecode) {default=normal}] infile [outfile]


The batch file I test with uses FOR loop, but one problem I ran into LA.EXE was not being able to control the output filename, so I had to resort to using a hack.



Yes, because i did read your posts regarding batch processing i allready knew about the need to specify the outputfile. 

Would it be ok for now, if the file extensions were fixed?

Would a simple wilcard option hurt?

My current spec looks like this:


Code: [Select]
YALACC infile [outfile] [-px -l {default=normal}] 

infile might be:

Dir\*        (any file in DIR with the proper extension)
Dir\File     (File FILE in DIR
File         (File FILE in current dir)

outfile may only work with a single file spec.

-p specifies preset:

F or 0 = Fast
N or 1 = Normal (Default)
H or 2 = High
I or 3 = Insane

-l switches the log file generation on.


Quick and dirty...
Title: Yalac - Comparisons
Post by: Destroid on 2006-05-02 23:57:19
Quote
Would it be ok for now, if the file extensions were fixed?

Yes.

Quote
Would a simple wilcard option hurt?

Sure, I guess  I imagined wildcard-handling being tedious to implement (for some programs).

The spec looks good. As mentioned, I use the batch redirect (>filename) to log filesize (ex. DIR __*.yaa) and operation time (TIMETHIS.EXE). Of course, it would be great to save a few minutes using the calculator if the ratio % and realtime x were output to CON and/or logfile.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-03 09:44:45
Quick and dirty...
Looks fine to me for using the presets.

I take it it will encode or decode depending on the extension of the source file?  Edit: I guess wildcard method will have to default to one or the other (most likely encode), unless the format is actually "DIR\*.wav" or "DIR\*.yaa". (NB: I'm not sure what you guys mean by the file extension being "fixed" so I may be going over old ground here )

I don't see the need to specify a switch for the output filename with that setup.

Quote
What about overwriting files? Would the GUI-behaviour be ok (for the tests): Overwriting without warning but with added suffix "_d"?
My personal preference would be that "<name>.yaa" is decoded to "<name>.wav"; if "<name>.wav" exists a prompt appears; and a switch is provided to enable automatic overwriting.  However, if we are just talking about a "Quick and dirty..." version for now then the current method is fine by me.

I've been away for a little while but I'm hoping to do some testing with 0.05 soon.  I suppose it depends when yalacc.exe will be released; maybe I should wait until then.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-03 09:55:42
The spec looks good. As mentioned, I use the batch redirect (>filename) to log filesize (ex. DIR __*.yaa) and operation time (TIMETHIS.EXE). Of course, it would be great to save a few minutes using the calculator if the ratio % and realtime x were output to CON and/or logfile.
I use "%~z1" in the encoding batch file to output the new file's filesize to a log.  Same idea.

The following VBS (Windows Script) file will look at any text files in the same directory for TimeThis' "Elapsed Time" entries and write them (in seconds format) all to a new text file (e.g.: "la.txt" > "la.txt.times.txt").  It's an easy way to scrape TimeThis times from a log created using a redirect.  I'm not sure whether it may be of any use, but here it is anyway.

timethis.vbs:

Code: [Select]
Dim objFSO, objFolder, objFile
Dim objStream, objOutput, strProcessed

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder("./")

For Each objFile in objFolder.Files
  If GetExtension(objFile.Name) = ".txt" Then
    Set objStream = objFile.OpenAsTextStream(1)
    strProcessed = ProcessFile(objStream.ReadAll)
    objStream.Close
    If strProcessed > "" Then
      Set objOutput = objFSO.OpenTextFile(objFile.Name & ".times.txt", 2, True)
      objOutput.Write strProcessed
      objOutput.Close
    End If
  End If
Next

Set objOutput = Nothing
Set objStream = Nothing
Set objFile = Nothing
Set objFSO = Nothing

Function ProcessFile(ByVal strString)
  Dim objRegExp, objMatch, colMatches
  Dim strLine, i, arrPart, sngSeconds
  Set objRegExp = New RegExp
  objRegExp.Pattern = "TimeThis :  Elapsed Time :  (\d+:\d+:\d+\.*\d*)"
  objRegExp.IgnoreCase = True
  objRegExp.Global = True
  Set colMatches = objRegExp.Execute(strString)
  For Each objMatch in colMatches
    arrPart = Split(objMatch.SubMatches(0), ":")
    sngSeconds = (arrPart(0) * 60 * 60) + (arrPart(1) * 60) + arrPart(2)
    strLine = strLine & CStr(sngSeconds) & vbCrLf
  Next
  Set objRegExp = Nothing
  ProcessFile = strLine
End Function

Function GetExtension(ByVal strFile)
  GetExtension = LCase(Mid(strFile, InstrRev(strFile, ".")))
End Function
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-03 14:25:37
...
I take it it will encode or decode depending on the extension of the source file?  Edit: I guess wildcard method will have to default to one or the other (most likely encode), unless the format is actually "DIR\*.wav" or "DIR\*.yaa". (NB: I'm not sure what you guys mean by the file extension being "fixed" so I may be going over old ground here )
...
My personal preference would be that "<name>.yaa" is decoded to "<name>.wav"; if "<name>.wav" exists a prompt appears; and a switch is provided to enable automatic overwriting.  However, if we are just talking about a "Quick and dirty..." version for now then the current method is fine by me.

I've been away for a little while but I'm hoping to do some testing with 0.05 soon.  I suppose it depends when yalacc.exe will be released; maybe I should wait until then.


This specification is only a fast approach for the tests. It will change for the public release.

Code: [Select]
YALACC -mode infile [outfile] [-px -lx -overwrite]

-e          mode encode
-d          mode decode
infile      specify file(s) to be processed
  Dir\*       any file in DIR with the proper extension
  Dir\File    File FILE in DIR
  File        File FILE in current dir
outfile     specify output file or directory, see infile
-px         select encoder preset x
              F or 0 = Fast
              N or 1 = Normal (default)
              H or 2 = High
              I or 3 = Insane
-lx         select log file level x
              0 = no log file (default)
              1 = log compression results
              2 = log compression results and encoder diagnostics
-overwrite  overwrite existing wave files when decoding


In- and output files always have to contain the proper extension ".yaa" or ".wav". Yalac files will always be overwritten without warning. Wave files will be overwritten (again without warning), if the -overwrite switch has been specified. Otherwise the program will stop with an error message.

It's ok to wait until V0.06 for further testing. It's great, that destroid has tested V0.05 and that there were no unexpected results. That's enough for now.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-05 12:28:14
Current Progress (V0.06)

Sorry if i should talk to much...

Done:

- Preset FAST and NORMAL now are using Apply Window, which gives about 0.05 percent better compression (on my test corpus).
- Other slight improvements can give another 0.05 percent improvement to FAST and NORMAL on most files.
- Selection of Partition calculator resolution 64 gives another 0.05 percent improvement to FAST. It should now  achieve the same compression as the (slow) FAST preset of V.04.
- Optimizations of the channel decorrelation make FAST 30 percent and NORMAL 10 percent faster (than V.0.05) on my system (caution: maybe CPU-dependent).
- Command line version is done. In addition to my last spec it let's you overwrite the predictor order of the presets.

To do (for V.0.06):

- More speed optimizations of the channel decorrelation.
- Optimization of the compression efficiency of the channel decorrelation. Some files give 0.50 percent better compression in my evaluation. Average may be about 0.20 (dont know yet).


Maybe i will cancel the optimizations of the channel decorrelation for now and release V0.06 this weekend.


  Thomas
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-05 13:22:53
Take your time if you should wish to, but I don't think our testers will mind an intermediary release ;-)

@Synthetic soul : You'll probably see this, so once we get the command-line encoder, could you make a package with batch files and batch file processors to process the logs / data?  Then, we could all send our results to you and you could sort them in your database...

That would be really great!


Peace,
Tristan.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-05 13:56:36
Quote
' date='May 5 2006, 02:22 PM' post='389567']
Take your time if you should wish to, but I don't think our testers will mind an intermediary release ;-)

@Synthetic soul : You'll probably see this, so once we get the command-line encoder, could you make a package with batch files and batch file processors to process the logs / data?  Then, we could all send our results to you and you could sort them in your database...


I didn't want to stress the testers too much... For me it would be better to test an intermediary release. If some release shouldn't perform well, it is easier to find the reason, if not too much had been changed at once.

I could sent Synthetic soul soon a possibly buggy pre release to check the command line interface with his scripts. It's only an option.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-05 21:10:27
I'm not sure what the priority is for testing 0.06.  Would we be comparing against other encoders, or is the idea that we simply run Yalac on numerous files using all its presets?

I'm quite happy to pass some batch files on if it will help people test, but I'm not sure the database I used in my initial test is adequate for this round of testing.

The way I see it, if we are simply testing how Yalac performs, we need to test a greater variety of files (mono; 24bit; etc).  The database is only really set up to deal with 44.1KHz 16bit stereo files.  If you consider what my pages detailed, it would really just be a table to show that fast is faster than normal, and high compresses better than normal.  We know that already (well, we can assume).

Don't get me wrong, I think amalgamating the results is a great idea.  Joseph Pohm and I have communicated regarding a similar thing.  I think I'm being a little short-sighted and just need some help to understand how and what we would all be testing.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-05 22:18:33
I'm not sure what the priority is for testing 0.06.  Would we be comparing against other encoders, or is the idea that we simply run Yalac on numerous files using all its presets?
...
The way I see it, if we are simply testing how Yalac performs, we need to test a greater variety of files (mono; 24bit; etc).  The database is only really set up to deal with 44.1KHz 16bit stereo files.  If you consider
...
Don't get me wrong, I think amalgamating the results is a great idea.  Joseph Pohm and I have communicated regarding a similar thing.  I think I'm being a little short-sighted and just need some help to understand how and what we would all be testing.

To be honest, i don't have an elaborated plan for test design beyond my current interests.

I did work on

- mainly speed optimizations
- improvements of my source code quality
- some slight compression improvements (found some opportunities while evaluating my source code).

Hence current tests should check

a) if the speed optimizations are present on different platforms (especially CPU's)
b) if the speed and source code optimizations didn't affect the reliability
c) if the changes made for the slight compression improvements don't hurt on other files.

For this purposes an evaluation based upon the existing test sets and a comparison with previous results would be quite helpful. For a) and b) the tests sets don't have to be really representative.

Most work for V0.07 will probably again consist of speed optimizations of the channel decorrelation. V0.06 brings algorithmic, V0.07 will bring assembler optimizations.

Reason: I want to improve the channel decorrelation in terms of compression efficiency. The current speed optimizations should guarantee, that later increases of the algorithm complexity will not hurt speed too much. And i really like Yalac to be fast... 

V0.08 should contain an improved channel decorrelation. Then it will be really useful to test it on heterogenous file sets to tweak it. Mono and 24-Bit files wouldn't be important here.

Besides testing for my development purposes i am surely interested into comparisons with other compressors! Why else should i look for some tenth of a percent better compression...

I hope this shows some direction for possible further testing.

  Thomas

P.S.: Some time in the future i will activate my ominous pre filter, which gives up to 4 percent better compression on some rare problem files! But this one needs really much evaluation on big test sets.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-06 10:08:08
Hence current tests should check

a) if the speed optimizations are present on different platforms (especially CPU's)
b) if the speed and source code optimizations didn't affect the reliability
c) if the changes made for the slight compression improvements don't hurt on other files.
...
Besides testing for my development purposes i am surely interested into comparisons with other compressors! Why else should i look for some tenth of a percent better compression...

I hope this shows some direction for possible further testing.
Yes, thank you.  So in essence we should be testing Yalac 0.06 against previous Yalac tests, to ensure that speed and compression have improved.  Also, we should ensure that decompressed files are not corrupt.  We can compare against other codecs using the new Yalac results and the previous results for the other codecs (if we are testing on the same corpus).

With this in mind I don't see how all results can be amalgamated into my system, unless testers are prepared to  format their previous results into something I can easily import.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-06 16:37:31
@Synthetic soul : If you make your batch files available, or give us VBScripts or whatever, the few testers that we are can convert our data to your format, and send it to you!  It's just a problem of whether you can do something with the data afterwards.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-10 13:21:06
Most work for V0.07 will probably again consist of speed optimizations of the channel decorrelation. V0.06 brings algorithmic, V0.07 will bring assembler optimizations.

No,  V0.06 will bring both. That's the reason, why i didn't send V0.06 to the testers last weekend.

By the way: Preset FAST is now 60 percent faster than V0.05 on my system! This may be the limit, please don't expect more optimizations here. And we have to try, if this improvement will show up on other systems to.

  Thomas
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-12 15:37:16
V0.06 is done

Changes:

Compression efficiency and presets:

- Preset FAST and NORMAL now are using Apply Window, which gives about 0.05 percent better compression (on my test corpus).
- Other slight improvements can give another 0.05 percent improvement to FAST and NORMAL on most files.
- Selection of Partition calculator resolution 128 gives another 0.05 percent improvement to FAST. It should now achieve the same compression as the (slow) FAST preset of V.04.

Speed:

- Algorithmic and assembler optimizations of the channel decorrelation.
- Rework of my basic signal processing functions. Dangerous: I didn't touch them for years and i did know why!
- Because my compiler doesn't support proper code alignment, i had to do some strange things to help him out. I hope that there will be no trouble on operating systems with more strict security checks.
- Implementation of a memory manager to avoid cache trashing caused by too many simultaneous uses of the same cache line set.
- Rework of my File-IO. To my surprise this has been most important for the speedup of decoding. Possibly i will have to do some adaptions for specific operating systems.
- Changed floating point precision from double to single. Can sometimes reduce compression efficiency by 0.01 to 0.02 percent.

Probably other systems will benefit far less from my optimizations than my good old pentium 3. Maybe that the optimizations are compensating weaknesses of my CPU that are not present on modern CPUs. Nevertheless i want to provide some data as a baseline:

Speed up of encoding:

Preset FAST    55 %
Preset NORMAL  20 %
Preset HIGH    10 %

Speed up of decoding:

Preset FAST    25 %

Command line:

Command line version is done. Unfortunately the binary is nearly as large as the GUI-Version. Delphi seems to put most of the basic GUI libraries into the binary of a console application, if the code uses exception handling. The initialization of the program may take considerably longer than without the GUI libraries. The compression speed of small audio files may suffer from this overhead.

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.

Other:

- Clean up of source code. Could give new errors...
- File format changed!

Release:

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

Destroid
Josef Pohm
Shade[ST]
Synthetic Soul

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

- The speed and compression performance of presets FAST, NORMAL and HIGH.
- The decoding speed.

Evaluation of internal encoder options:

I wrote a SSE-Implementation of the Levinson-Durbin-algorithm used for the calculation of the predictor coefficients. It is disabled by default.

You can activate it via command line option -c1 and check it with Preset HIGH. There is definitely no reason to check it with other presets!

On my system this option gives only 1 - 2 % more speed on HIGH. I would like to know, if other systems are getting more out of it, before i will try more SSE optimizations.

Plans for V 0.07:

- Improvement of the compression efficiency of the channel decorrelation.


  Thomas
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-12 16:31:33
My exams are now done, I'd be glad to test the encoder on my system.

Could synthetic soul provide batch files to test?

Thanks,

Tristan
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-13 00:49:09
On SSE optimization :
Code: [Select]
=== New test ===============================================

Linear Predictor
  Predictors:                                32
  Optimize quantization:                  Nein
  Apply window:                              Ja

Frames
  Duration:                                100 ms

Channel decorrelation
  Enable:                                    Ja
  Full search:                            Nein

Frame partition calculator
  Resolution:                                64
  Search level:                              1 (0 - 3)

Bit coder
  Optimize Choice:                        Nein
  Optimize Partition:                      Nein

Diagnostics
  Verify:                                  Nein
  No output:                              Nein
  Use MMX:                                  Ja
  Use SSE:                                  Ja


=== Bitcoder ===============================================

Resolution
  N:                                          0


=== LPC Predictors =========================================

Number
    4                                      4.31  %
    8                                      9.88  %
  12                                    19.68  %
  16                                    22.57  %
  24                                    17.48  %
  32                                    26.08  %
  48                                      0.00  %
  64                                      0.00  %
  80                                      0.00  %
  96                                      0.00  %
  112                                      0.00  %
  128                                      0.00  %
  160                                      0.00  %
  192                                      0.00  %
  224                                      0.00  %
  256                                      0.00  %
  Mean:                                  19.48 *

Resolution
  N:                                    115927
  Minimum:                                5.00
  Mittelwert:                              8.96
  Maximum:                                11.00
  Verteilung                       
    5                                    0.001 %  (1)
    6                                    0.203 %  (235)
    7                                    4.246 %  (4922)
    8                                  17.197 %  (19936)
    9                                  56.678 %  (65705)
    10                                  20.745 %  (24049)
    11                                    0.931 %  (1079)
    12                                    0.000 %  ()
    13                                    0.000 %  ()
    14                                    0.000 %  ()
    >                                    0.000 %  ()

ShiftNum (Resolution reduction)
  N:                                    115927
  Minimum:                                3.00
  Mittelwert:                              3.00
  Maximum:                                3.00
  Verteilung                       
    0                                    0.000 %  ()
    1                                    0.000 %  ()
    2                                    0.000 %  ()
    3                                  100.000 %  (115927)
    4                                    0.000 %  ()
    5                                    0.000 %  ()
    6                                    0.000 %  ()
    7                                    0.000 %  ()
    >                                    0.000 %  ()

Resolution / Predictor number        Min    Mean    Max    StdDev
    4                                    6.00    8.97  11.00    0.67 Bit
    8                                    5.00    8.69  11.00    0.88 Bit
  12                                    6.00    9.01  11.00    0.73 Bit
  16                                    6.00    9.08  11.00    0.73 Bit
  24                                    6.00    8.97  11.00    0.85 Bit
  32                                    6.00    8.93  11.00    0.75 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

ShiftNum / Predictor number          Min    Mean    Max    StdDev
    4                                    3.00    3.00    3.00    0.00 Bit
    8                                    3.00    3.00    3.00    0.00 Bit
  12                                    3.00    3.00    3.00    0.00 Bit
  16                                    3.00    3.00    3.00    0.00 Bit
  24                                    3.00    3.00    3.00    0.00 Bit
  32                                    3.00    3.00    3.00    0.00 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Bits for whole predictor set          Min    Mean    Max    StdDev
    4                                      33      45      53      3 Bit
    8                                      49      76      97      7 Bit
  12                                      74    110    141      8 Bit
  16                                      98    144    181      13 Bit
  24                                    139    196    271      21 Bit
  32                                    182    245    334      23 Bit
  48                                      0      0      0      0 Bit
  64                                      0      0      0      0 Bit
  80                                      0      0      0      0 Bit
  96                                      0      0      0      0 Bit
  112                                      0      0      0      0 Bit
  128                                      0      0      0      0 Bit
  160                                      0      0      0      0 Bit
  192                                      0      0      0      0 Bit
  224                                      0      0      0      0 Bit
  256                                      0      0      0      0 Bit

Bits per predictor                    Min    Mean    Max    StdDev
    4                                    8.25  11.15  13.25    0.71 Bit
    8                                    6.13    9.52  12.13    0.83 Bit
  12                                    6.17    9.19  11.75    0.71 Bit
  16                                    6.13    9.01  11.31    0.84 Bit
  24                                    5.79    8.15  11.29    0.87 Bit
  32                                    5.69    7.66  10.44    0.73 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Absolute Sum of coefficients          Min    Mean    Max    StdDev
    4                                    8.67  11.62  13.51    0.77 Bit
    8                                    9.09  11.91  14.36    0.88 Bit
  12                                    9.75  12.65  14.85    0.79 Bit
  16                                  10.04  13.13  15.29    0.95 Bit
  24                                  10.44  13.02  16.03    0.98 Bit
  32                                  10.60  13.06  15.81    0.83 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Absolute Sum of shifted coefficients  Min    Mean    Max    StdDev
    4                                    5.67    8.62  10.51    0.77 Bit
    8                                    6.09    8.91  11.36    0.88 Bit
  12                                    6.75    9.65  11.85    0.79 Bit
  16                                    7.04  10.13  12.29    0.95 Bit
  24                                    7.44  10.02  13.03    0.98 Bit
  32                                    7.60  10.06  12.81    0.83 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit


=== Frame partition ========================================

SubFrameNum
  N:                                      72252
  Minimum:                                1.00
  Mittelwert:                              1.60
  Maximum:                                3.00
  Verteilung                       
    1                                  61.543 %  (44466)
    2                                  16.442 %  (11880)
    3                                  22.015 %  (15906)
    4                                    0.000 %  ()
    5                                    0.000 %  ()
    >                                    0.000 %  ()


=== Joint Stereo ===========================================

Modes
  N:                                      36126
  Minimum:                                0.00
  Mittelwert:                              1.25
  Maximum:                                2.00
  Verteilung                       
    0                                  21.641 %  (7818)
    1                                  31.288 %  (11303)
    2                                  47.071 %  (17005)
    >                                    0.000 %  ()


=== Results ================================================
                                   
01. American Idiot.yaa                                                         
64.18 % -  29.1 * -    5.987 sec
02. Carl Orff - Fortune plango vulnera.yaa                                     
48.95 % -  41.5 * -    3.855 sec
02. Carl Orff - Veris leta facies; Omnia Sol temperat.yaa                     
31.18 % -  61.1 * -    5.622 sec
02. Parallel Universe.yaa                                                     
59.39 % -  48.8 * -    5.548 sec
02. Wolfgang Amadeus Mozart - O Isis und Osiris (Sarastro - Chor).yaa         
41.39 % -  53.2 * -    3.700 sec
03. Who's sorry now.yaa                                                       
27.95 % -  48.1 * -    3.782 sec
04. Burke - Johnston - Pennies From Heaven.yaa                                 
55.58 % -  44.5 * -  13.726 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa                         
39.80 % -  54.0 * -    2.002 sec
04. Japanese sandman.yaa                                                       
22.89 % -  49.2 * -    4.314 sec
05. Koop - Summer Sun.yaa                                                     
64.10 % -  17.1 * -  13.122 sec
05. Wolfgang Amadeus Mozart - Rex tremendae majestatis.yaa                     
44.97 % -  28.3 * -    4.970 sec
06. The Subject Was Faggots.yaa                                               
44.04 % -  25.7 * -    7.470 sec
08. Morgana King - It's De-lovely.yaa                                         
36.95 % -  38.2 * -    3.521 sec
08. Wolfgang Amadeus Mozart - Requiem in D Minor, KV 626, VIII. 08.
Wolfgang Amadeus Mozart - Requiem in D Minor, KV 626, VIII.
Lacrimosa.yaa  40.82 % -  31.5 * -    7.984 sec
11. Nil (Instrumental).yaa                                                     
20.58 % -  40.7 * -    3.367 sec
11. Throb.yaa                                                                 
54.05 % -  45.4 * -    6.019 sec

Compression:    45.44 %
Duration:      95.03 sec
Speed:          38.01 * real time


=== New test ===============================================

Linear Predictor
  Predictors:                                32
  Optimize quantization:                  Nein
  Apply window:                              Ja

Frames
  Duration:                                100 ms

Channel decorrelation
  Enable:                                    Ja
  Full search:                            Nein

Frame partition calculator
  Resolution:                                64
  Search level:                              1 (0 - 3)

Bit coder
  Optimize Choice:                        Nein
  Optimize Partition:                      Nein

Diagnostics
  Verify:                                  Nein
  No output:                              Nein
  Use MMX:                                  Ja
  Use SSE:                                Nein


=== Bitcoder ===============================================

Resolution
  N:                                          0


=== LPC Predictors =========================================

Number
    4                                      4.31  %
    8                                      9.88  %
  12                                    19.68  %
  16                                    22.57  %
  24                                    17.48  %
  32                                    26.08  %
  48                                      0.00  %
  64                                      0.00  %
  80                                      0.00  %
  96                                      0.00  %
  112                                      0.00  %
  128                                      0.00  %
  160                                      0.00  %
  192                                      0.00  %
  224                                      0.00  %
  256                                      0.00  %
  Mean:                                  19.48 *

Resolution
  N:                                    115927
  Minimum:                                5.00
  Mittelwert:                              8.96
  Maximum:                                11.00
  Verteilung                       
    5                                    0.001 %  (1)
    6                                    0.203 %  (235)
    7                                    4.246 %  (4922)
    8                                  17.197 %  (19936)
    9                                  56.678 %  (65705)
    10                                  20.745 %  (24049)
    11                                    0.931 %  (1079)
    12                                    0.000 %  ()
    13                                    0.000 %  ()
    14                                    0.000 %  ()
    >                                    0.000 %  ()

ShiftNum (Resolution reduction)
  N:                                    115927
  Minimum:                                3.00
  Mittelwert:                              3.00
  Maximum:                                3.00
  Verteilung                       
    0                                    0.000 %  ()
    1                                    0.000 %  ()
    2                                    0.000 %  ()
    3                                  100.000 %  (115927)
    4                                    0.000 %  ()
    5                                    0.000 %  ()
    6                                    0.000 %  ()
    7                                    0.000 %  ()
    >                                    0.000 %  ()

Resolution / Predictor number        Min    Mean    Max    StdDev
    4                                    6.00    8.97  11.00    0.67 Bit
    8                                    5.00    8.69  11.00    0.88 Bit
  12                                    6.00    9.01  11.00    0.73 Bit
  16                                    6.00    9.08  11.00    0.73 Bit
  24                                    6.00    8.97  11.00    0.85 Bit
  32                                    6.00    8.93  11.00    0.75 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

ShiftNum / Predictor number          Min    Mean    Max    StdDev
    4                                    3.00    3.00    3.00    0.00 Bit
    8                                    3.00    3.00    3.00    0.00 Bit
  12                                    3.00    3.00    3.00    0.00 Bit
  16                                    3.00    3.00    3.00    0.00 Bit
  24                                    3.00    3.00    3.00    0.00 Bit
  32                                    3.00    3.00    3.00    0.00 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Bits for whole predictor set          Min    Mean    Max    StdDev
    4                                      33      45      53      3 Bit
    8                                      49      76      97      7 Bit
  12                                      74    110    141      8 Bit
  16                                      98    144    181      13 Bit
  24                                    139    196    271      21 Bit
  32                                    182    245    334      23 Bit
  48                                      0      0      0      0 Bit
  64                                      0      0      0      0 Bit
  80                                      0      0      0      0 Bit
  96                                      0      0      0      0 Bit
  112                                      0      0      0      0 Bit
  128                                      0      0      0      0 Bit
  160                                      0      0      0      0 Bit
  192                                      0      0      0      0 Bit
  224                                      0      0      0      0 Bit
  256                                      0      0      0      0 Bit

Bits per predictor                    Min    Mean    Max    StdDev
    4                                    8.25  11.15  13.25    0.71 Bit
    8                                    6.13    9.52  12.13    0.83 Bit
  12                                    6.17    9.19  11.75    0.71 Bit
  16                                    6.13    9.01  11.31    0.84 Bit
  24                                    5.79    8.15  11.29    0.87 Bit
  32                                    5.69    7.66  10.44    0.73 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Absolute Sum of coefficients          Min    Mean    Max    StdDev
    4                                    8.67  11.62  13.51    0.77 Bit
    8                                    9.09  11.91  14.36    0.88 Bit
  12                                    9.75  12.65  14.85    0.79 Bit
  16                                  10.04  13.13  15.29    0.95 Bit
  24                                  10.44  13.02  16.03    0.98 Bit
  32                                  10.60  13.06  15.81    0.83 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Absolute Sum of shifted coefficients  Min    Mean    Max    StdDev
    4                                    5.67    8.62  10.51    0.77 Bit
    8                                    6.09    8.91  11.36    0.88 Bit
  12                                    6.75    9.65  11.85    0.79 Bit
  16                                    7.04  10.13  12.29    0.95 Bit
  24                                    7.44  10.02  13.03    0.98 Bit
  32                                    7.60  10.06  12.81    0.83 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit


=== Frame partition ========================================

SubFrameNum
  N:                                      72252
  Minimum:                                1.00
  Mittelwert:                              1.60
  Maximum:                                3.00
  Verteilung                       
    1                                  61.543 %  (44466)
    2                                  16.442 %  (11880)
    3                                  22.015 %  (15906)
    4                                    0.000 %  ()
    5                                    0.000 %  ()
    >                                    0.000 %  ()


=== Joint Stereo ===========================================

Modes
  N:                                      36126
  Minimum:                                0.00
  Mittelwert:                              1.25
  Maximum:                                2.00
  Verteilung                       
    0                                  21.641 %  (7818)
    1                                  31.288 %  (11303)
    2                                  47.071 %  (17005)
    >                                    0.000 %  ()


=== Results ================================================
                                   
01. American Idiot.yaa                                                         
64.18 % -  39.6 * -    4.403 sec
02. Carl Orff - Fortune plango vulnera.yaa                                     
48.95 % -  34.5 * -    4.641 sec
02. Carl Orff - Veris leta facies; Omnia Sol temperat.yaa                     
31.18 % -  31.3 * -  10.980 sec
02. Parallel Universe.yaa                                                     
59.39 % -  43.7 * -    6.196 sec
02. Wolfgang Amadeus Mozart - O Isis und Osiris (Sarastro - Chor).yaa         
41.39 % -  53.7 * -    3.663 sec
03. Who's sorry now.yaa                                                       
27.95 % -  60.7 * -    2.996 sec
04. Burke - Johnston - Pennies From Heaven.yaa                                 
55.58 % -  50.5 * -  12.088 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa                         
39.80 % -  58.9 * -    1.834 sec
04. Japanese sandman.yaa                                                       
22.89 % -  62.3 * -    3.409 sec
05. Koop - Summer Sun.yaa                                                     
64.10 % -  38.5 * -    5.836 sec
05. Wolfgang Amadeus Mozart - Rex tremendae majestatis.yaa                     
44.97 % -  42.3 * -    3.321 sec
06. The Subject Was Faggots.yaa                                               
44.04 % -  50.0 * -    3.836 sec
08. Morgana King - It's De-lovely.yaa                                         
36.95 % -  51.3 * -    2.625 sec
08. Wolfgang Amadeus Mozart - Requiem in D Minor, KV 626, VIII. 08.
Wolfgang Amadeus Mozart - Requiem in D Minor, KV 626, VIII.
Lacrimosa.yaa  40.82 % -  41.7 * -    6.033 sec
11. Nil (Instrumental).yaa                                                     
20.58 % -  58.0 * -    2.366 sec
11. Throb.yaa                                                                 
54.05 % -  44.6 * -    6.136 sec

Compression:    45.44 %
Duration:      80.38 sec
Speed:          44.93 * real time


=== New test ===============================================

Linear Predictor
  Predictors:                                32
  Optimize quantization:                  Nein
  Apply window:                              Ja

Frames
  Duration:                                100 ms

Channel decorrelation
  Enable:                                    Ja
  Full search:                            Nein

Frame partition calculator
  Resolution:                                64
  Search level:                              1 (0 - 3)

Bit coder
  Optimize Choice:                        Nein
  Optimize Partition:                      Nein

Diagnostics
  Verify:                                  Nein
  No output:                              Nein
  Use MMX:                                  Ja
  Use SSE:                                  Ja


=== Bitcoder ===============================================

Resolution
  N:                                          0


=== LPC Predictors =========================================

Number
    4                                      4.31  %
    8                                      9.88  %
  12                                    19.68  %
  16                                    22.57  %
  24                                    17.48  %
  32                                    26.08  %
  48                                      0.00  %
  64                                      0.00  %
  80                                      0.00  %
  96                                      0.00  %
  112                                      0.00  %
  128                                      0.00  %
  160                                      0.00  %
  192                                      0.00  %
  224                                      0.00  %
  256                                      0.00  %
  Mean:                                  19.48 *

Resolution
  N:                                    115927
  Minimum:                                5.00
  Mittelwert:                              8.96
  Maximum:                                11.00
  Verteilung                       
    5                                    0.001 %  (1)
    6                                    0.203 %  (235)
    7                                    4.246 %  (4922)
    8                                  17.197 %  (19936)
    9                                  56.678 %  (65705)
    10                                  20.745 %  (24049)
    11                                    0.931 %  (1079)
    12                                    0.000 %  ()
    13                                    0.000 %  ()
    14                                    0.000 %  ()
    >                                    0.000 %  ()

ShiftNum (Resolution reduction)
  N:                                    115927
  Minimum:                                3.00
  Mittelwert:                              3.00
  Maximum:                                3.00
  Verteilung                       
    0                                    0.000 %  ()
    1                                    0.000 %  ()
    2                                    0.000 %  ()
    3                                  100.000 %  (115927)
    4                                    0.000 %  ()
    5                                    0.000 %  ()
    6                                    0.000 %  ()
    7                                    0.000 %  ()
    >                                    0.000 %  ()

Resolution / Predictor number        Min    Mean    Max    StdDev
    4                                    6.00    8.97  11.00    0.67 Bit
    8                                    5.00    8.69  11.00    0.88 Bit
  12                                    6.00    9.01  11.00    0.73 Bit
  16                                    6.00    9.08  11.00    0.73 Bit
  24                                    6.00    8.97  11.00    0.85 Bit
  32                                    6.00    8.93  11.00    0.75 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

ShiftNum / Predictor number          Min    Mean    Max    StdDev
    4                                    3.00    3.00    3.00    0.00 Bit
    8                                    3.00    3.00    3.00    0.00 Bit
  12                                    3.00    3.00    3.00    0.00 Bit
  16                                    3.00    3.00    3.00    0.00 Bit
  24                                    3.00    3.00    3.00    0.00 Bit
  32                                    3.00    3.00    3.00    0.00 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Bits for whole predictor set          Min    Mean    Max    StdDev
    4                                      33      45      53      3 Bit
    8                                      49      76      97      7 Bit
  12                                      74    110    141      8 Bit
  16                                      98    144    181      13 Bit
  24                                    139    196    271      21 Bit
  32                                    182    245    334      23 Bit
  48                                      0      0      0      0 Bit
  64                                      0      0      0      0 Bit
  80                                      0      0      0      0 Bit
  96                                      0      0      0      0 Bit
  112                                      0      0      0      0 Bit
  128                                      0      0      0      0 Bit
  160                                      0      0      0      0 Bit
  192                                      0      0      0      0 Bit
  224                                      0      0      0      0 Bit
  256                                      0      0      0      0 Bit

Bits per predictor                    Min    Mean    Max    StdDev
    4                                    8.25  11.15  13.25    0.71 Bit
    8                                    6.13    9.52  12.13    0.83 Bit
  12                                    6.17    9.19  11.75    0.71 Bit
  16                                    6.13    9.01  11.31    0.84 Bit
  24                                    5.79    8.15  11.29    0.87 Bit
  32                                    5.69    7.66  10.44    0.73 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Absolute Sum of coefficients          Min    Mean    Max    StdDev
    4                                    8.67  11.62  13.51    0.77 Bit
    8                                    9.09  11.91  14.36    0.88 Bit
  12                                    9.75  12.65  14.85    0.79 Bit
  16                                  10.04  13.13  15.29    0.95 Bit
  24                                  10.44  13.02  16.03    0.98 Bit
  32                                  10.60  13.06  15.81    0.83 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit

Absolute Sum of shifted coefficients  Min    Mean    Max    StdDev
    4                                    5.67    8.62  10.51    0.77 Bit
    8                                    6.09    8.91  11.36    0.88 Bit
  12                                    6.75    9.65  11.85    0.79 Bit
  16                                    7.04  10.13  12.29    0.95 Bit
  24                                    7.44  10.02  13.03    0.98 Bit
  32                                    7.60  10.06  12.81    0.83 Bit
  48                                    0.00    0.00    0.00    0.00 Bit
  64                                    0.00    0.00    0.00    0.00 Bit
  80                                    0.00    0.00    0.00    0.00 Bit
  96                                    0.00    0.00    0.00    0.00 Bit
  112                                    0.00    0.00    0.00    0.00 Bit
  128                                    0.00    0.00    0.00    0.00 Bit
  160                                    0.00    0.00    0.00    0.00 Bit
  192                                    0.00    0.00    0.00    0.00 Bit
  224                                    0.00    0.00    0.00    0.00 Bit
  256                                    0.00    0.00    0.00    0.00 Bit


=== Frame partition ========================================

SubFrameNum
  N:                                      72252
  Minimum:                                1.00
  Mittelwert:                              1.60
  Maximum:                                3.00
  Verteilung                       
    1                                  61.543 %  (44466)
    2                                  16.442 %  (11880)
    3                                  22.015 %  (15906)
    4                                    0.000 %  ()
    5                                    0.000 %  ()
    >                                    0.000 %  ()


=== Joint Stereo ===========================================

Modes
  N:                                      36126
  Minimum:                                0.00
  Mittelwert:                              1.25
  Maximum:                                2.00
  Verteilung                       
    0                                  21.641 %  (7818)
    1                                  31.288 %  (11303)
    2                                  47.071 %  (17005)
    >                                    0.000 %  ()


=== Results ================================================
                                   
01. American Idiot.yaa                                                         
64.18 % -  57.1 * -    3.055 sec
02. Carl Orff - Fortune plango vulnera.yaa                                     
48.95 % -  51.5 * -    3.109 sec
02. Carl Orff - Veris leta facies; Omnia Sol temperat.yaa                     
31.18 % -  61.7 * -    5.567 sec
02. Parallel Universe.yaa                                                     
59.39 % -  44.9 * -    6.025 sec
02. Wolfgang Amadeus Mozart - O Isis und Osiris (Sarastro - Chor).yaa         
41.39 % -  54.5 * -    3.609 sec
03. Who's sorry now.yaa                                                       
27.95 % -  62.4 * -    2.913 sec
04. Burke - Johnston - Pennies From Heaven.yaa                                 
55.58 % -  22.9 * -  26.612 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa                         
39.80 % -  9.8 * -  11.049 sec
04. Japanese sandman.yaa                                                       
22.89 % -  37.1 * -    5.727 sec
05. Koop - Summer Sun.yaa                                                     
64.10 % -  22.7 * -    9.888 sec
05. Wolfgang Amadeus Mozart - Rex tremendae majestatis.yaa                     
44.97 % -  33.4 * -    4.212 sec
06. The Subject Was Faggots.yaa                                               
44.04 % -  46.7 * -    4.111 sec
08. Morgana King - It's De-lovely.yaa                                         
36.95 % -  54.6 * -    2.464 sec
08. Wolfgang Amadeus Mozart - Requiem in D Minor, KV 626, VIII. 08.
Wolfgang Amadeus Mozart - Requiem in D Minor, KV 626, VIII.
Lacrimosa.yaa  40.82 % -  25.0 * -  10.069 sec
11. Nil (Instrumental).yaa                                                     
20.58 % -  60.2 * -    2.277 sec
11. Throb.yaa                                                                 
54.05 % -  29.8 * -    9.163 sec

Compression:    45.44 %
Duration:      109.87 sec
Speed:          32.87 * real time

With FAST mode, it seems SSE slows things down.  Further lookout for this type of behavior would be necessary.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-13 01:33:52
Quote
' date='May 13 2006, 01:49' post='391904']
On SSE optimization :
...
With FAST mode, it seems SSE slows things down.  Further lookout for this type of behavior would be necessary.

You are really fast!

But please don't post the whole protocol file. Most of the info isn't helpful yet.

Summary of your results:
Code: [Select]
Run1: MMX + SSE

Compression:    45.44 %
Speed:          38.01 * real time

Run 2: MMX

Compression:    45.44 %
Speed:          44.93 * real time

Run 3: MMX + SSE

Compression:    45.44 %
Speed:          32.87 * real time

You see the speed difference between Run 1 and Run 3, which use the same settings? And regarding Run 2: I advised to test SSE on Preset HIGH. You did use Preset FAST with 32 Predictors. But SSE will never be used with less than 64 Predictors!

Hence all three test runs have used exactly the same optimizations: Always MMX, never SSE.

The big speed variations are most probably beeing caused by variations of your test systems: Disk caching issues or disturbances by background activity. Under controled conditions all three runs should have achieved about the same speed (maybe within the range of +/- 10 %; on my system i achieve +/- 3 %).

BTW: Activation of the protocol function slows encoding down.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-13 01:48:09
It seems my disk caching is quite unstable, then.  I did hear thrashing sounds between the encoding of two songs.  Also, run 1 is command-line; runs 2+3 are GUI.

I am currently testing Insane mode with/without SSE on my corpus (which compresses quite a bit, as you can see..)

Results will be posted in approx 5 min.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-13 01:54:51
Quote
' date='May 13 2006, 02:48' post='391912']
songs.  Also, run 1 is command-line; runs 2+3 are GUI.

That's important. There can be speed differences between command line and gui versions.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-13 02:06:33
These results are actually quite surprising, as they show discrepancies in the SSE optimizations versus compression ratio.  It should normally be the same, no?

Code: [Select]
Insane (search level 4) + SSE
Compression:    44.65 %
Duration:     1289.32 sec
Speed:           2.80 * real time

Insane (search level 3) + SSE
Compression:    44.66 %
Duration:      955.93 sec
Speed:           3.78 * real time

Insane (search level 3) + No SSE
Compression:    44.65 %
Duration:     1161.98 sec
Speed:           3.11 * real time
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-13 02:29:10
Quote
' date='May 13 2006, 03:06' post='391920']
These results are actually quite surprising, as they show discrepancies in the SSE optimizations versus compression ratio.  It should normally be the same, no?

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). But 0.01 percent deviation shouldn't be too important. But we should keep an eye on it (?).

Far more interesting for me to see a significant speed benefit for SSE. At least big enough to try a bit more SSE optimizations later.

Thanks

  Thomas

P.S. Could you please post your CPU-type? Encoding speed for INSANE is more than two times higher than on my system. Surprising, because the speed of FAST isn't higher than on my system. FAST seems to be very sensitive to disk io performance.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-13 02:38:22
Do the rounding errors mean that the encoding may no longer be lossless?
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-13 02:46:48
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.
Title: Yalac - Comparisons
Post by: Destroid on 2006-05-13 02:51:17
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
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-13 03:03:24
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?
Title: Yalac - Comparisons
Post by: Destroid on 2006-05-13 03:25:41
Oops, keep forgetting the sustem specs. I fixed that along with a couple of humorous typos
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-13 03:33:39
Oops, keep forgetting the sustem specs. I fixed that along with a couple of humorous typos


Thanks.

I did miss the typos...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-13 08:03:39
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 (http://www.dinosaur-park.com/) though...
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-13 12:52:08
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 (http://www.dinosaur-park.com/) 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!
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-15 11:09:27
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/ (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.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-15 12:52:38
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.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-15 13:41:35
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.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-15 15:26:07
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/ (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 (http://synthetic-soul.co.uk/comparison/yalac/?all=1)

Edit 2: OK, http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/) now uses the 0.06 (commandline) results.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-15 15:57:37
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 (http://synthetic-soul.co.uk/comparison/yalac/?all=1)

Edit 2: OK, http://synthetic-soul.co.uk/comparison/lossless/ (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.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-15 16:09:43
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.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-15 16:17:07
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.
Title: Yalac - Comparisons
Post by: Hyp-X on 2006-05-15 16:21:15
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!!!
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-15 16:33:19
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!).
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-15 18:35:50
Perhaps I should add some fast settings for FLAC and WavPack as a comparison.
Added.

FLAC -0 is now tops for encoding speed (http://synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=EncodeRate&Desc=1), with Yalac Fast in second place.

However, Yalac Fast is still tops for decoding speed (http://synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=DecodeRate&Desc=1) (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.
Title: Yalac - Comparisons
Post by: Firon on 2006-05-15 18:53:56
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.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-15 19:45:33
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.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-15 22:20:32
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.
Title: Yalac - Comparisons
Post by: audiofreak on 2006-05-16 03:14:44

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)
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-17 02:57:37
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
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-17 05:58:01
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.
Title: Yalac - Comparisons
Post by: Destroid on 2006-05-17 20:21:20
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!
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-17 20:52:47
Quote
' date='May 17 2006, 06:58' post='393177']
I think people looking at this codec are looking at speed also.
...
As such, I would make both modifications.  Make fast faster by 15%, and make a (new) fastest preset, faster than what we currently have.

I agree the speed aspect is a Yalac specialty.

Yes, without the speed it would be quite useless. Then i would prefer Monkey or OptimFrog for maximum compression.

Hence speed will be my highest priority. I will not implement compression ratio improvements that significantly reduce decoding speed. It's a different matter at the encoding side.

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


Yes, disk-IO is the limit. On my good old pentium III-866 i can achieve higher decoding speeds than you with your fast machines, if i turn off the decoder output (i should give public access to this option for evaluation purposes...).

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

Thanks to you and thanks to ShadeST for your work and the encouragement!

I am not sure, if i can make Yalac that fast. Main reason seems to be, that yalac has to use bigger data blocks than symmetrical encoders for the disk io. Possibly things will change if i implement asynchronous file io, which unfortunately is not beeing supported by my Windows 98...

And to achieve the maximum encoding speed for FASTEST, i would have to build a special variant of my encoder. Currently FASTEST would do much work unneccesarily twice. My encoder has not been designed for those ultra fast modes.

  Thomas
Title: Yalac - Comparisons
Post by: foosion on 2006-05-18 00:28:44
Possibly things will change if i implement asynchronous file io, which unfortunately is not beeing supported by my Windows 98...
Asynchronous I/O would be harder to integrate into a future (cross-platform) library which I hope you plan to create.  Such a library should let the caller handle I/O operations instead of directly trying to open a file itself. In the simplest case, the caller would feed chunks of data to the library to encode or decode data linearly. Obviously, things get a little more complicated, if you want to support playback in audio players where it is desirable to be able to seek.
I am no expert regarding audio codec libraries (meaning I haven't used many), but I think Monkey's Audio has a nice library interface.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-18 00:54:34
Asynchronous I/O would be harder to integrate into a future (cross-platform) library which I hope you plan to create.  Such a library should let the caller handle I/O operations instead of directly trying to open a file itself. In the simplest case, the caller would feed chunks of data to the library to encode or decode data linearly.

Good point. But asynchronous io would only be an option. I may define an abstract interface for file io, which has to be implemented by the user and can use asynchronus io if available.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-18 14:28:34
Current Progress (V0.07)

Done

- New option for the channel decorrelation to detect bigger lags between channels. Without this option files with lags outside of the search range of the standard decorrelation algorithm can not use channel decorrelation. It's usually some "All or nothing" case: Either it helps compression or not. Don't expect too much, on my test corpus it only helps about 1 of 20 files. And it slows encoding down.

- Evaluation of other possibilities to improve the channel decorrelation. Most of them didn't work well. Some of them look promising but have to be further evaluated (the file format is perepared now for their later use). And some would help but considerably slow down both encoding and decoding. That's not acceptable.

- New preset FASTEST, which is about 50 percent faster than FAST on my system and compresses about 0.9 percent worse than FAST on my test corpus.

To do (for V0.07)

- Clean up of my new channel decorrelation code.

- Speed optimization of the new channel lag detection. Possibly i will wait for test results of the new algorithm, before i optimize it. If it doesn't help compression a bit, its optimization has no priority.

- Implementation of an extra path within my codec to avoid unnecessary processing when using preset FASTEST. May give another 25 % speed up.

- Possibly new options for the variation of some parameters of the disk io to tune the performance on individual systems.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-19 10:24:37
Firstly, thanks for the update Thomas.  As I said before, I, and I'm sure the other testers, find your reports very interesting.  I can't believe that you are squeezing even more speed out, let alone a 50% increase!

Now, the reason for my post:

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
- 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
Yes, disk-IO is the limit. On my good old pentium III-866 i can achieve higher decoding speeds than you with your fast machines, if i turn off the decoder output (i should give public access to this option for evaluation purposes...).
Joseph Pohm and I have been discussing this issue for the past three days.

Joseph has very eloquently highlighted some anomolies in my results, due to IO limitations.  He has some superb charts which articulate the issues I am encountering with speeds over 60x or so.  My max is around 80x, while his is 120x.

We are currently looking at Timer (http://www.7-zip.org/igor.html) as a replacement for TimeThis, which I have used previously.  Joseph's initial tests suggest that Timer (http://www.7-zip.org/igor.html) can accurately report CPU time only (what it calls "Process Time", as opposed to its "Global Time", which is the figure that TimeThis reports).  This would be very useful for me to record times unaffected by IO.  In fact, I could scrape both CPU (Processed) and CPU+IO (Global) times from the report, for a comparison...

While it is likely that we will pursue this further, we thought that others may find this useful information now.  Although no-one else is currently using TimeThis, the times reported by Yalac itself suffer the same fate, and will therefore be affected by IO latency also.  Therefore, if you are interested in seeing results unaffected by IO latency, but can't wait for Thomas to provide a switch to turn off decoding output, you may want to take a look at Timer (http://www.7-zip.org/igor.html).
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-19 12:15:14
Firstly, thanks for the update Thomas.  As I said before, I, and I'm sure the other testers, find your reports very interesting.  I can't believe that you are squeezing even more speed out, let alone a 50% increase!

Fine. I like to post my reports. One reason: It forces me to define goals for the next release. Otherwise there is always a fair chance, that i am loosing myself in little structured evaluations of my daily ideas.

For the speed increase: I did achieve 50 percent, but the next release will only bring 20 percent for FAST. I will explain the reasons in another post.
Quote
Joseph has very eloquently highlighted some anomolies in my results, due to IO limitations.  He has some superb charts which articulate the issues I am encountering with speeds over 60x or so.  My max is around 80x, while his is 120x.

Yes, Joseph has many superb charts. The Html-reports he is sending me are seldom smaller than 500 KB...
Quote
Joseph's initial tests suggest that Timer (http://www.7-zip.org/igor.html) can accurately report CPU time only (what it calls "Process Time", as opposed to its "Global Time", which is the figure that TimeThis reports).  This would be very useful for me to record times unaffected by IO.  In fact, I could scrape both CPU (Processed) and CPU+IO (Global) times from the report, for a comparison...

The comparison of the pure processing time would be very intersting for speed evaluations of my code optimizations. And it would give a hint for what to expect if faster pc's or hard disks become available in the future

But it possibly wouldn't be optimal for general comparisons of different compressors. On my system the frame size of my encoder significantly affects encoder and decoder performance. The frame size here equals the block size of the disk io's. On my system 100 ms would be the optimum for speed, but 250 ms are providing maximum compression. This is caused by the way may encoder works. Other -possibly symmetrical- encoders may be able to process smaller frames and therefore could use the optimum of 100 ms on my system. Hence their possible speed advantage would be caused by the design of the encoder and shoud be taken into account for fairness (even if this is an disadvantage for Yalac...).

My 2 cents...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-19 12:54:19
Yes, Joseph has many superb charts. The Html-reports he is sending me are seldom smaller than 500 KB...
His dedication to the art is phenominal.  I have been trying to pursuade him to post more, as I believe you have.  I don't think I can actually imagine the amount of data that you must be sent following a new release.

The comparison of the pure processing time would be very intersting for speed evaluations of my code optimizations. And it would give a hint for what to expect if faster pc's or hard disks become available in the future
I am intending to perform some runs this weekend, targetting the faster decoders, to see how the figures all tie up.  I have some data from Jospeh to compare with.  My slower decoders are faster than his, as my machine is faster, but currently he gets better speeds with the faster decoders, by minimising the IO latency. Hopefully I can use his figures, accounting for the difference in PCs, to make a comparison.  I'll be sure to post here.

My 2 cents...
I must admit that I'm not sure that I understand the paragraph.  You state that "it possibly wouldn't be optimal for general comparisons of different compressors" but conclude that it "shoud be taken into account for fairness".  I hope I have not taken those quotes completely out of context.    Do you basically mean that Yalac may not fair so well if IO latency is taken out of the equation?

Joseph and I have discussed the issue that IO latency will be a "real world" issue for most users,  when decoding to WAVE.  However, when decoding to RAM (playback) it will not be a factor.  It also seems to me to be a perverting influence for test conditions, unless I could somehow provide data that allowed you to detimine the degree to which the IO latency was affecting the speed.

There's another $0.02 for the pot.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-19 15:45:02
If I use YALAC, I will be using it for playback and transcoding purposes (in the eventuality of a foobar2000 playback plugin).  As such, I really don't care much for IO speeds.  Don't waste too much time, if you don't need to
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-19 16:23:16
But this is it.  The way I understand it we are currently analysing IO speeds.

To analyse the speed to decode, for transcoding or playback, we need to look at the time taken in memory only, and not the memory plus IO time (which is what TimeThis and Yalac.exe will report).

IMHO both rates are of great interest, but until now I was blissfully unaware of the difference.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-19 19:42:57
I must admit that I'm not sure that I understand the paragraph.  You state that "it possibly wouldn't be optimal for general comparisons of different compressors" but conclude that it "shoud be taken into account for fairness".  I hope I have not taken those quotes completely out of context.    Do you basically mean that Yalac may not fair so well if IO latency is taken out of the equation?

No. What i wanted to say: If smaller frame  sizes speed up disk io, then the ability of other encoders to use smaller frame sizes (than yalac) is a strength of them, which shoudn't be neglected, because it woud be relevant for the practical use. Hence general comparisons of encoder speed should include disk-io. If yalac should perform better without disk-io, that would be interesting but not too important for the performance under real world conditions. (I am voting against a test setup, which would possibly favour yalac...).

I hope it's more clear now. Have to learn some better english...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-19 20:06:48
Thanks for the clarification Thomas.  Your English is infinately better than my German.

From what I understand though, CPU-only timings are also relevant in "real world" scenarios, when decoding to memory while playing, rather than decoding to file (WAVE).  Therefore, both timings are of interest: CPU-only/decoding to memory, and CPU+IO/decoding to file.

Thankfully Timer will report both.

I may change my database so that both timings can be reported.  I would certainly like to, but time is an issue as always.  I thought I had concluded all my little projects, but it always seems there's another just around the corner.  I suppose I should stop peering around corners so often...
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-19 20:13:25
From what I understand though, CPU-only timings are also relevant in "real world" scenarios, when decoding to memory while playing, rather than decoding to file (WAVE).  Therefore, both timings are of interest: CPU-only/decoding to memory, and CPU+IO/decoding to file.

I forgot about this.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-19 21:17:47
Current Progress (V0.07)

In my last report i was talking about a speed advantage of 50 percent for the new preset FASTEST over FAST. But i did deceide against it.

I did play around with some parameters to speed up FAST. I could achieve more than 50 percent more speed with an compression penality of about 1 percent. But one single parameter variation gave me 20 percent speed up with a penality of only 0.1 percent. Obviously a far better speed-compression ratio.

Therefore i dropped the FASTEST preset. V0.07 will instead contain a 20 percent faster FAST preset.

Then i looked at the other presets. I always had the feeling, that they are not very well balanced. After many evaluations of existing test data and new parameter variations i came up with a new configuration of the presets:

- Presets: FAST, NORMAL, HIGH, EXTRA, INSANE.
- INSANE sets any accessible parameter to the maximum to evaluate the currently possible maximum compression (Joseph Pohm may call it I2...).
- With the exception of INSANE, any preset should be only two times slower than it's predecessor. I find this simple rule more user friendly.
- Therefore NORMAL and HIGH needed a speed up. HIGH is now about 80 percent faster than before.
- EXTRA now uses the parameter configuration of the old HIGH preset with the addition of the new improvements of the stereo decorrelation.

To make it clear: I didn't perform any code optimizations. The new preset configuration is only based upon new selections of the underlying encoder parameters.

On my test corpus the new presets are considerably faster than the old ones with a compression penality of about 0.1 percent. I hope that your evaluation of V0.07 will confirm this. Otherwise i may have to perform some more fine tuning.

I am not sure, what more i will do for V0.07. Possibly i will drop some other plans for now (for instance the possibility to vary disk-io parameters), because there is allreday enough to be evaluated.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-22 10:08:41
Questions regarding release date and license have been moved to Yalac: Miscellaneous Questions (http://www.hydrogenaudio.org/forums/index.php?showtopic=44867).

FYI, we now have:
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-25 01:12:47
V0.07 is done

Changes:

Compression algorithms:

- New option for the channel decorrelation to detect bigger lags between channels. Without this option files with lags outside of the search range of the standard decorrelation algorithm can not use channel decorrelation. Don't expect too much, on my test corpus it only helps about 1 of 20 files. And it slows encoding and -in case of a bigger lag- even decoding down. Sometimes this option slightly (less than 0.05 percent) decreases compression efficiency.

Presets:

- Reconfiguration of the existing presets and inclusion of the new preset EXTRA.
- With the exception of INSANE, any preset should be only two times slower than it's predecessor. I find this simple rule more user friendly.
- INSANE sets any accessible parameter to the maximum to evaluate the currently possible maximum compression (Joseph Pohm may call it I2...).
- EXTRA now uses the parameter configuration of the old HIGH preset with the addition of the new improvements of the stereo decorrelation.
- Speedup of the presets FAST (20 %), NORMAL (35 %) and HIGH (60 %). The compression efficiency should be only 0.1 percent worse than before.

Internals:

- New way to scale sample values down for the reduced precision arithmetic of my 16 Bit DSP. Can slightly change compression ratio of individual files.

GUI:

- Debug option "No Output" of the GUI-Version now disables generation of output files for both encoding and decoding.

Command line:

- Specify the new switch "-debug1" to disable file output when encoding or decoding.

- New test cases to evaluate the new channel decorrelation option "Extra lag":
Code: [Select]
-c0 = Off
-c1 =  8
-c2 = 16
-c3 = 32
-c4 = 64


Other:

- Clean up of source code. Could give new errors...
- File format changed!

Release:

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

Destroid
Josef Pohm
Shade[ST]
Synthetic Soul

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.06: Speed and compression performance of presets FAST, NORMAL, HIGH and EXTRA.
- If the new preset EXTRA should perform better than HIGH of V0.06, then it would make sense to further evaluate the new channel decorrelation option "Extra lag". You may try preset EXTRA with bigger lags: -c3 or c4 for 32 / 64. The protocol file contains a new section with a distribution of the lags the encoder has used.
- A verification of the decoded files makes most sense for preset EXTRA. There is no need to verify the output of the other presets.

Plans for V 0.08:

- I am always working on the optimization of some new filter algorithm, which can significantly improve compression. Probably the next version will contain a first suboptimal implementation.

- Some complex modifications of my frame partitioning may provide a small increase of compression efficiency. I am not quite sure, if it is worth the considerable amount of work.

  Thomas
Title: Yalac - Comparisons
Post by: Destroid on 2006-05-25 02:46:51
What should be tested:

- Comparison with V0.06: Speed and compression performance of presets FAST, NORMAL, HIGH and EXTRA.
- If the new preset EXTRA should perform better than HIGH of V0.06, then it would make sense to further evaluate the new channel decorrelation option "Extra lag". You may try preset EXTRA with bigger lags: -c3 or c4 for 32 / 64. The protocol file contains a new section with a distribution of the lags the encoder has used.
- A verification of the decoded files makes most sense for preset EXTRA. There is no need to verify the output of the other presets.


I am writing the batch file for a full-scale test/comparison now for 0.06 vs. 0.07 and all the other major compressors  I am going assume that EXTRA will be tested four times using -c[n] variants. If it's worth bothering, would testing INSANE with -c3 and -c4 be of interest?

And yes, I'll be adding FC /b verification for the EXTRA settings.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-25 03:09:45
I am writing the batch file for a full-scale test/comparison now for 0.06 vs. 0.07 and all the other major compressors  I am going assume that EXTRA will be tested four times using -c[n] variants. If it's worth bothering, would testing INSANE with -c3 and -c4 be of interest?

Wow! That's very exciting!

If -c3 and -c4 don't help EXTRA, there would be little to expect for INSANE. But if you can do it automatically...
Title: Yalac - Comparisons
Post by: Destroid on 2006-05-25 10:56:42
Another album comparison benchmark  This album is rock and multiple types of instruments (acoustic and electric guitar, electric bass, woodwinds, drums) with monologue and chorus vocals.
Code: [Select]
King Missile - Mystical S**t/Fluting on the Hump  697,725,548 bytes (65:55)
===========================================================================
name/params Ratio EncTime/CPU% DecTime/CPU%
--------------------- ------ ------------ ------------
Yalacc 0.06 -p0 55.04% 76.54x / 76% 92.42x / 55%
Yalacc 0.07 -p0 55.16% 84.01x / 72% 93.40x / 56%
MAC 4.01 beta2 -c1000 55.56% 66.31x / 96% 51.70x / 85%
FLAC 1.1.2 --fast 62.60% 86.09x / 68% 83.15x / 52%
WavPack 4.3 -f 58.03% 90.62x / 74% 87.16x / 60%
OFR 4.520 --mode fast 54.80% 24.70x / 87% 34.41x / 98%
--------------------- ------ ----------- ------------
Yalacc 0.06 -p1 54.73% 33.27x / 94% 87.80x / 60%
Yalacc 0.07 -p1 54.76% 43.49x / 90% 84.83x / 60%
MAC 4.01 beta2 -c2000 54.60% 49.61x / 96% 42.71x / 92%
FLAC 1.1.2 (default) 58.12% 59.22x / 83% 85.89x / 57%
WavPack 4.3 (default) 57.15% 77.69x / 79% 80.53x / 67%
OFR 4.520 (default) 54.10% 17.88x / 91% 24.76x / 99%
MP4ALS RM17 (default) 56.45% 29.76x / 95% 55.96x / 63%
LA 0.4 normal 53.05% 6.20x / 99% 7.72x / 99%
--------------------- ------ ----------- ------------
Yalacc 0.06 -p2 54.57% 11.92x / 99% 83.29x / 61%
Yalacc 0.07 -p2 54.63% 17.59x / 98% 82.40x / 64%
MAC 4.01 beta2 -c3000 54.32% 43.41x / 98% 38.13x / 93%
MAC 4.01 beta2 -c4000 53.90% 23.97x / 99% 23.40x / 98%
FLAC 1.1.2 --best 57.95% 12.12x / 99% 88.97x / 60%
WavPack 4.3 -h 55.27% 52.10x / 89% 66.47x / 87%
OFR 4.520 --best 53.84% 4.85x / 95% 6.57x / 99%
MP4ALS RM17 -7 55.07% 0.99x / 99% 12.57x / 96%
LA 0.4 high 52.89% 4.61x / 99% 5.45x / 99%
--------------------- ------ ----------- ------------
Yalacc 0.06 -p3 54.51% 4.47x / 99% 84.66x / 62%
Yalacc 0.07 -p3 * 54.57% 11.58x / 99% 84.20x / 63% (FC /b = OK)
Yalacc 0.07 -p3 -c3 * 54.57% 11.43x / 99% 84.00x / 62% (FC /b = OK)
Yalacc 0.07 -p3 -c4 * 54.57% 11.16x / 99% 84.04x / 62% (FC /b = OK)
Yalacc 0.07 -p4 54.51% 3.36x / 99% 85.72x / 63%

* Denotes modes with files compared after encoding and decoding


No noticable difference in EXTRA using -c3 and -c4 except for encoding times, so I didn't bother using the switches on INSANE mode. Perhaps different material would make a noticable difference. As noted above, the EXTRA mode had no problems with file integrity as proven by file comparison.

There are some nice improvements in performance here. Awesome

Oh yeah  -- System A64 3000+, 512MB, Caviar 80GB, Win2K
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-26 23:08:43
http://synthetic-soul.co.uk/comparison/yalac/ (http://synthetic-soul.co.uk/comparison/yalac/)

As before, all Yalac runs (0.02-0.07) can be viewed by using http://synthetic-soul.co.uk/comparison/yalac/?all=1 (http://synthetic-soul.co.uk/comparison/yalac/?all=1).

NB: This table uses Timer's Global Time, which equates to the time reported by TimeThis (CPU+IO).  I do have the Process times recorded as well, but I need to get some time to create version 2 of my system to report them.  If I can't find time soon I may just upload a/some suplimentary spreadsheet/s.

My scripts now automatically check the MD5 on decode against the source MD5, and all hashes match.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-27 00:26:17
Many thanks again to Destroid and Synthetic Soul!

For me the reconfiguration of the presets looks advantageous. There are some nice speed improvements for FAST, NORMAL and HIGH and the reduction in compression efficiency is on average less than 0.1 percent. I would like to keep the new presets. What do you think?

The extended search range of the stereo decorrelation (preset EXTRA) seems useless. Nothing really new for me: About 95 percent of my work on optimizations of the compression efficiency were useless. But you have to try it before you know it... I will probably remove the extra lag option from the encoder. Fortunately there is another currently hidden option aimed to some different purpose within the frame decorrelation which can replace the extra lag option to some extent, if it should be really needed.

I am currently working on the new prefilter option. Earlier (when applied to yalac 0.01) it gave 0.35 percent better compression, but now only 0.2 percent on average... Maybe that some other optimizations of yalac are allready providing some of the benefits of the prefilter. On the other hand there are some files which compress more than 4 percent better with the filter. Possibly there is some room for improvements left.

It seems, as if i am near to the maximum compression my codec design can achieve. In this case i would call the 0.2 percent improvement significant...

That doesn't mean, that there will be no more improvements. For instance the frame partition calculator isn't fully optimized yet.
Title: Yalac - Comparisons
Post by: moozooh on 2006-05-27 02:57:46
I am currently working on the new prefilter option. Earlier (when applied to yalac 0.01) it gave 0.35 percent better compression, but now only 0.2 percent on average... Maybe that some other optimizations of yalac are allready providing some of the benefits of the prefilter. On the other hand there are some files which compress more than 4 percent better with the filter. Possibly there is some room for improvements left.

It seems, as if i am near to the maximum compression my codec design can achieve. In this case i would call the 0.2 percent improvement significant...

That doesn't mean, that there will be no more improvements. For instance the frame partition calculator isn't fully optimized yet.

TBeck, are you a good wizard or something?
I will definitely start using your codec right after the fb2k plugin comes out!
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-27 09:33:19
Thomas, as per previous request, 0.07 values have now replaced 0.06 values in the multi-encoder comparison:

http://www.synthetic-soul.co.uk/comparison/lossless/ (http://www.synthetic-soul.co.uk/comparison/lossless/)

As previously, non-standard settings (-cX) can be viewed by appending ?all=1 (and removed by using ?all=0):

http://www.synthetic-soul.co.uk/comparison/lossless/?all=1 (http://www.synthetic-soul.co.uk/comparison/lossless/?all=1)


Personally, I like the way that the new presets have a good spread of encoding speed (roughly halfing, except for insane which just goes all out).  Compression does not alter drastically, so you can pick a preset according to your speed requirements, and know that it won't make a horrendous difference, and that the difference will be exponentially relative to the speed benefit.  It seems a very tidy way of doing things, and easy for a user to find the best trade-off.
Title: Yalac - Comparisons
Post by: dethis on 2006-05-27 10:35:32
Hi Thomas. You are realy a wizard

As about the presets, they look perfectly balanced except the 0.7 extra. Looking at SyntheticSoul's and Destroid's results 0.6 HIGH gives better or equal compression compared to 0.7 EXTRA while being 5-10% faster.

Waiting for the FooBar plugin.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-27 14:48:08
Yalac fast mode beats them all, when you sort by encoding rate / size ratio, but monkey's normal is faster AND compresses better than yalac...  I don't know if anything is to be done with this, but right now fast mode seems fine.  Maybe if you could concentrate on the other modes..
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-27 19:19:35
Quote
' date='May 27 2006, 14:48' post='396419']monkey's normal is faster AND compresses better than yalac...
It decodes twice as slowly though.

I'm not sure that you can compare a preset name so directly.  Yalac can't expect to compete in every league.

The difference in compression and encoding rate is minimal.  However, trying to equal Monkey's Audio in either value would be at the detriment to the other... unless Thomas can squeeze another 0.3-0.4% compression out, so that he can afford to speed encoding up a little.

Hey, if he can do it then I'll not complain!

I just think that tackling Monkey's Audio head on is unrealistic, especially if you look at Monkey's High surpassing Yalac's Insane compression marginally, and encoding rate substantially.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-28 22:17:24
It decodes twice as slowly though.

The ratio my be even better for playback (where disk-io shouldn't matter) or when decoding from memory. I am not sure, if my following estimation for cpu usage of real time playback from memory based upon Destroid's timings and cpu times is valid:
Code: [Select]
Yalacc 0.07    -p1    54.76% 43.49x / 90% 84.83x / 60% -> 60 / 84.83 = 0.707 %
MAC 4.01 beta2 -c2000 54.60% 49.61x / 96% 42.71x / 92% -> 92 / 42.71 = 2.154 %

We will have to wait for a Yalac playback plugin to confirm it. Or for someone, who tells me, why this calculation is wrong...
Quote
...I'm not sure that you can compare a preset name so directly.  Yalac can't expect to compete in every league.

...unless Thomas can squeeze another 0.3-0.4% compression out, so that he can afford to speed encoding up a little.

...I just think that tackling Monkey's Audio head on is unrealistic, especially if you look at Monkey's High surpassing Yalac's Insane compression marginally, and encoding rate substantially.

Very good arguments! I totally agree.
Title: Yalac - Comparisons
Post by: Josef Pohm on 2006-05-29 09:25:25
We will have to wait for a Yalac playback plugin to confirm it. Or for someone, who tells me, why this calculation is wrong...


Just to confirm that your calculation is obviously right, and that I think it could be more readable like this:

Code: [Select]
Yalac Normal
Enc: 43,49x @ 90% -> 43,49/0,90 =  48,32x
Dec: 84,83x @ 60% -> 84,83/0,60 = 141,38x

Monkey Normal
Enc: 49,61x @ 96% -> 49,61/0,96 =  51,68x
Dec: 42,71x @ 92% -> 42,71/0,92 =  46,42x


Which shows that Yalac v0.07 Normal encodes slightly slower than Monkey Normal 4.01 but decodes more than three times faster.
I have some results of mine for confirmation:

Code: [Select]
               Yalac Normal     Monkey Normal
Encode            36,53x           40,23x
Decode           106,77x           33,05x


Test repeated on another PC:

Code: [Select]
               Yalac Normal     Monkey Normal
Encode            28,33x           31,19x
Decode            92,53x           29,22x


Both confirming Yalac v0.07 Normal encodes slightly slower than Monkey Normal 4.01 but decodes more than three times faster.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-29 12:06:19
OK, OK, you guys got me.  Considering I've been harping on about CPU-only time constantly in the last week you would have thought I might have picked up on that one...

In response to Thomas' post I was actually just in the middle of looking at my Process Time (CPU-only) times, when I spotted that Josef had posted.  Here they are anyway:

Code: [Select]
Codec             Encode    Decode
==================================
Yalac   Normal    34.11x    97.49x
Monkeys Normal    41.05x    37.96x
Yalac   High      15.07x    91.01x
Monkeys High      36.31x    34.34x

Just a note to say that you can now view Josef's full comparison details here (http://synthetic-soul.co.uk/comparison/josef/).
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-29 13:45:30
Just a note to say that you can now view Josef's full comparison details here (http://synthetic-soul.co.uk/comparison/josef/).

Excellent!

But a bit depressing: Yalac compares worse than on any other sample set i have seen!

I will speed up my work on the PreFilter implementation. Although it gives only about 0.15 to 0.20 percent better compression on my test corpus, i am confident because it were some sample files of joseph which have shown a advantage of several percent (!) with the prefilter turned on...

I hope to release the next version within the next days.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-29 19:32:18
But a bit depressing: Yalac compares worse than on any other sample set i have seen!
Yes, I can see how you must be disappointed (even ashamed): only 5th fastest decoder:

Code: [Select]
Encoder Setting    Compressed    Decoding
=========================================
Shorten Default       66.238%     132.44x
DaxWav VQH            70.102%     124.80x
DaxWav VQS            69.568%     124.80x
DaxWav VQM            70.008%     119.33x
Yalac Fast            58.527%     114.06x
Flac - Garf -0        66.435%     102.81x

... but look at the compression (and who's 6th fastest)...

Well, if such high standards means you will look to squeezing even more MB out then who am I to correct you.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-29 21:37:04
But a bit depressing: Yalac compares worse than on any other sample set i have seen!
Yes, I can see how you must be disappointed (even ashamed): only 5th fastest decoder:
...
... but look at the compression (and who's 6th fastest)...

Well, if such high standards means you will look to squeezing even more MB out then who am I to correct you.

You are right. No, i wasn't fishing for compliments... But they are welcome.

It's my point of view. In the many years of the development of yalac i never cared about FAST modes, i always compared HIGH modes. FAST is the result of the last months interaction with the hydrogen forum members.

And the comparison with LPAC and Mpeg4Als -7 is always most important for me, because they are using basically the same technology as yalac. It's ok to be a bit (up to 0.5 percent) worse, because i had to sacrifice some compression efficiency for the high decoding speed. But the difference is higher in Josefs comparison! That's what depresses me a bit. Ok, it's only one of many test sets, but it isn't ok.

For now i am pinning all my hope on the PreFilter (do you notice the dramatic?).

The four sample files Josef sent me earlier perform very well with the PreFilter:
Code: [Select]
Preset High            Prefilter
                       off       on
03_06_03.yaa           64.21 % - 62.24 %
B04_01.yaa             53.76 % - 49.62 %
B04_02.yaa             58.97 % - 54.11 %
C17_01.yaa             66.59 % - 63.16 %

                       60.59 % - 56.83 %


But i don't know, if josef's test set does contain more such Prefilter friendly files...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-29 22:38:24
In the many years of the development of yalac i never cared about FAST modes, i always compared HIGH modes. FAST is the result of the last months interaction with the hydrogen forum members.
That must be quite strange for you.  I would probably use High if using Yalac, maybe Normal.  There isn't a huge variation in the compression rate, and all presets decode very fast.  I am happy to go with a relatively slow encode if it will save me a few MB, as I generally start the process going and leave the room.  I use WavPack -h as it has decent compression, decent speed, but also very much because of other aspects, like error tolerance, simple inline tagging, etc.

And the comparison with LPAC and Mpeg4Als -7 is always most important for me, because they are using basically the same technology as yalac. It's ok to be a bit (up to 0.5 percent) worse, because i had to sacrifice some compression efficiency for the high decoding speed.
Ah, that is interesting to know.  I must admit I know little of MP4ALS and nothing of LPAC.  I will have to investigate further.

The four sample files Josef sent me earlier perform very well with the PreFilter:
Wow.  I'm looking forward to checking that on my corpus.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-29 23:10:48
...
I use WavPack -h as it has decent compression, decent speed, but also very much because of other aspects, like error tolerance, simple inline tagging, etc.

V 0.08 (which is nearly done) will bring the PreFilter. If there are no problems with this new feature, then my work on V 0.09 will consist of clean ups of my source code and error tolerance.

I must admit I know little of MP4ALS and nothing of LPAC.  I will have to investigate further.

Feel free to ask me. I would like to write some short text about the similarities, but you know, english is not a strength of mine. Maybe i will pause the development work on some point and write a german text. One friend of mine will translate it to english.

The four sample files Josef sent me earlier perform very well with the PreFilter:
Wow.  I'm looking forward to checking that on my corpus.

Don't forget: On my test corpus the PreFilter achieves only 0.15 to 0.20 percent improvement! Josef is always providing me with some very special files which are giving me much fun! I don't know, if you can find them on the free market...

BTW: I have the feeling, that i should make a plan for the next development steps of yalac and possibly post it with some other general info within some new YALAC Faq post... For me it's always advantegous to force myself to think about a better structure of my work. And Yalac surely has raised some expectations and people should know what will be going on. If i know it...
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-29 23:47:14
I think YALAC developpement has reached another step which you might not have envisioned previously;  I am sure many other people follow YALAC development closely, and would be very willing to test it, which is why I suggest you consider testing on a larger scale.  That way, you could really see if your optimizations pay off and if you have the same general results everywhere.

Perhaps Synthetic soul could set up a small system on his site to receive feedback from testers, and distribute the executable.  If not, I might be able to piece something together, and I can surely help you with the hosting part.  I could even give you a ftp account password.

Consider all this well,
Tristan.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-30 16:43:32
Quote
' date='May 30 2006, 00:47' post='397364']
... which is why I suggest you consider testing on a larger scale.  That way, you could really see if your optimizations pay off and if you have the same general results everywhere.

Perhaps Synthetic soul could set up a small system on his site to receive feedback from testers, and distribute the executable.  If not, I might be able to piece something together, and I can surely help you with the hosting part.  I could even give you a ftp account password.

Many thanks, Tristan! It's quite probable that i will come back to your hosting offer!

But for the extended testing: I am not sure, if it is worth the effort, because more testers means far more results to be evaluated and far more communications and discussions, hence less time left for the development. And new testers wouldn't know about the development history and probably come up with old questions. And i wouldn't know much about their test sets. The active testers have tried the different versions on their test sets and the varying results (between versions) have shown me something about the characteristics of their files.

I know, that it isn't possible, but: If there were only one or two new testers who provided me with such valuable and detailed reports as Josef Pohm, i would spent my whole time on reading and analysing...

  Thomas

BTW: I hope that you will try the new version on your test set. If i remember it right, you are having some interesting music within your set, which other test sets are possibily missing...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-05-30 17:07:50
V 0.08 (which is nearly done) will bring the PreFilter. If there are no problems with this new feature, then my work on V 0.09 will consist of clean ups of my source code and error tolerance.
Wow.  Sounds like we may be getting close to a beta release.

BTW: I have the feeling, that i should make a plan for the next development steps of yalac and possibly post it with some other general info within some new YALAC Faq post... For me it's always advantegous to force myself to think about a better structure of my work. And Yalac surely has raised some expectations and people should know what will be going on. If i know it...
Sounds intriguing.  I love reading these things.  I used to love reading the diaries of games developers in computer magazines when I was a lad (Andrew Braybrook's Paradroid diary (http://www.zzap64.co.uk/zzap3/para_birth01.html) and Jeff Minter's (http://www.zzap64.co.uk/zzap13/daily_llama01.html)Iridis Alpha (what a game!) diary (http://www.medwaypvb.com/yakstuff/) spring to mind).

Perhaps Synthetic soul could set up a small system on his site to receive feedback from testers, and distribute the executable.  If not, I might be able to piece something together, and I can surely help you with the hosting part.  I could even give you a ftp account password.
I'm sorry, but I cannot commit myself any further than I am at the moment (which is really more than I should, but I just can't stop it).  If Thomas thinks this would be useful, then please, take it on.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-30 22:14:38
V0.08 is done

Changes:

Compression algorithms:

- New PreFilter option. Achieves on average 0.15 to 0.20 percent better compression on my test corpus, up to 4 percent on some special files.
- Extra lag option (introduced in V0.07) for the channel decorrelation removed.
- Channel decorrelation option FULL SEARCH removed.

Presets:

- HIGH now uses the new PreFilter. Expect a speed decrease of about 10 % for encoding. The effect on decoding performance should be minimal.
- EXTRA now uses the new PreFilter and the frame partition search level EXTRA (formerly known as insane). Extra lag option for the channel decorrelation removed. Should be about two times slower than HIGH.
- INSANE now uses the new PreFilter. Channel decorrelation option FULL SEARCH removed. Should be considerably faster now.

INSANE is only a temporary storage for methods, which are far too slow for the compression improvements they achieve. Instead of immediately removing them i keep them within INSANE because i may speed them up later or because i am unsure, if they can help other files more, and want to wait for more test results.

Josef Pohms test results show a significant compression advantage for partition search level EXTRA (formerly known as insane), therefore i deceided to move it into the standard presets. But for the channel decorrelation option FULL SEARCH it was time to say goodbye...

Command line:

- New test cases to evaluate the new PreFilter-option:

-c0 = Off
-c1 = Level Fast
-c2 = Level Normal

Other:

- Clean up of source code. Could give new errors...
- File format changed!

Release:

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

Destroid
Josef Pohm
Shade[ST]
Synthetic Soul

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.08: Speed and compression performance of presets HIGH,  EXTRA and possibly INSANE.
- HIGH now uses the new PreFilter option with level FAST. You may try -c2 on HIGH, which activates level NORMAL, and check, if it makes any difference.
- A verification of the decoded files makes most sense for preset HIGH or EXTRA (simply choose a preset, which uses the new PreFilter).

Plans for V 0.09:

- Optimizations and corrections of the PreFilter, if neccessary.
- Error tolerance: Detect and skip damaged frames.

Possibly you will have to wait for V0.10 for more error tolerance. After removing the FULL SEARCH option of the channel decorrelation there are some new opportunities for speed improvements, which i may implement in V0.09. And i just have found some interactions of the PreFilter with other encoder methods which have to be evaluated. Maybe it hurts them a bit.
Title: Yalac - Comparisons
Post by: Supacon on 2006-05-30 23:48:28
Awesome!  Glad to hear that you're hard at work. 

I can't wait to try a beta version in the near future.  I guess you still need to add a few features, like seekability, streamability, tagging, et al, but it sounds like you've got a great algorithm for the most important aspects.  It's pretty impressive that you think you can still squeeze some more speed out of your codec too!

Keep it up Thomas!
Title: Yalac - Comparisons
Post by: SebastianG on 2006-05-31 00:26:13
Hello, TBeck!

I'm wondering what the "PreFilter" actually does and how it is related to the other parts. Could you shed some light on it?

Sebi
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-31 02:17:09
...
It's pretty impressive that you think you can still squeeze some more speed out of your codec too!

Thanks!

But don't expect big speed improvements. Maybe 10 to 20 percent for the presets HIGH and EXTRA.

FAST could be speed up, if i would implement a specialized version of my codec. But this has not a high priority for me.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-31 03:11:06
I'm wondering what the "PreFilter" actually does and how it is related to the other parts. Could you shed some light on it?

Sorry, but i don't want to publish details at this point.

As i wrote earlier, i definitely want to benefit from my work in form of some reputation. One way may be the publication of one or two papers.

Some (not directed to you!) may find this a bit selfish or egocentric (earlier you have been a hero, if you published useful freeware, these days you are often a bad guy, if you do not immediately release the source code too...).

What could i reply?

I have been working on Yalac for more than 8 years, always in my free time. To give an estimate: This means about 1.5 years of full work (or of my life time)!

With this in mind, it seems not too easy to give all the work away for nothing...

Very important:

1) This is not directed to you! You only provided me the opportunity to clear some points, which tend to come up now and then.

2) I do not want to start an ideological or philosophical discussion about open source or intellectual property. If necessary, this should be done within a seperate thread. And given my limited english skills, it's very unlikely that i would participate.


What i can say:

Short description from Yalac's readme: "The prefilter cleans the signal a bit, before it is beeing sent to the linear predictor." In other words: It removes some disturbing aspects of the signal, which reduce the quality of the predictor coefficients and hence hurt the compression.

But to be honest: If there is one method within yalac, which i myself do not fully understand yet, then it is the PreFilter! Surely i had reasons to implement it and it works as expected, but sometimes far better than i would have predicted and i will have to evaluate why.

Possibly it compensates some disturbances of the signal which are beeing caused by the scaling needed for my reduced precision (14-Bit) arithmetic. If that's true, then the PreFilter would only be useful for my specific implementation and not for other compressors which are using full scale arithmetics.

  Thomas
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-31 03:44:37
Output is disabled for all encoding settings;  SSE is enabled, and all files are transcoded from LAME 3.98a3 -V2 --vbr-new.  As such, this doesn't make for a _real-world_ test, but it's quite revelating nonetheless, on different settings, and the quality of the stereo decorellator (indeed better than LAME's)
If you want the bitrates of the original mp3s, I can have them for you.  I can also test with a few CD Audio files, if you like, but I doubt the results will be different.
Files are cached before reading
Code: [Select]
Default + prefilter
01. Giant Steps.yaa                                          57.45 % -  20.2 * -  14.220 sec
01. La Vie, L'amour.yaa                                      47.70 % -  21.3 * -    5.200 sec
01. Le vieux Léon.yaa                                        36.69 % -  22.8 * -    9.962 sec
02. Parallel Universe.yaa                                    71.40 % -  23.0 * -  11.740 sec
02. Sa jeunesse.yaa                                          36.48 % -  23.1 * -  12.362 sec
03. Memories of You.yaa                                      32.29 % -  23.3 * -    8.253 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.29 % -  20.3 * -    5.311 sec
04. Celle qui a dit non.yaa                                  65.00 % -  12.2 * -  23.318 sec
04. Comme Moi (Like Me).yaa                                  43.11 % -  14.5 * -  12.365 sec
05. Le chemin de la dompe (présentation).yaa                  43.90 % -  15.2 * -    4.182 sec
06. Frédéric.yaa                                              47.80 % -  17.3 * -  11.657 sec
11. Nil (Instrumental).yaa                                    20.22 % -  23.2 * -    5.905 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  43.06 % -  22.4 * -  14.418 sec
15. Stroker Ace.yaa                                          54.57 % -  22.1 * -  12.201 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.24 % -  23.2 * -    5.669 sec
20. Sleighride.yaa                                            56.57 % -  22.1 * -    8.094 sec

Compression:    47.88 %
Duration:      164.89 sec
Speed:          19.71 * real time

Default + no prefilter :
01. Giant Steps.yaa                                          57.53 % -  24.2 * -  11.877 sec
01. La Vie, L'amour.yaa                                      47.54 % -  34.2 * -    3.236 sec
01. Le vieux Léon.yaa                                        36.61 % -  37.0 * -    6.134 sec
02. Parallel Universe.yaa                                    71.41 % -  36.6 * -    7.395 sec
02. Sa jeunesse.yaa                                          36.45 % -  36.6 * -    7.791 sec
03. Memories of You.yaa                                      32.23 % -  39.6 * -    4.855 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.25 % -  33.2 * -    3.252 sec
04. Celle qui a dit non.yaa                                  65.08 % -  29.3 * -    9.714 sec
04. Comme Moi (Like Me).yaa                                  43.00 % -  33.3 * -    5.392 sec
05. Le chemin de la dompe (présentation).yaa                  43.88 % -  33.0 * -    1.927 sec
06. Frédéric.yaa                                              47.78 % -  31.4 * -    6.443 sec
11. Nil (Instrumental).yaa                                    20.04 % -  41.0 * -    3.347 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  43.07 % -  34.9 * -    9.234 sec
15. Stroker Ace.yaa                                          54.47 % -  32.5 * -    8.285 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.21 % -  14.4 * -    9.118 sec
20. Sleighride.yaa                                            56.63 % -  18.2 * -    9.813 sec

Compression:    47.85 %
Duration:      107.83 sec
Speed:          30.14 * real time

Default + search level extra :
01. Giant Steps.yaa                                          57.44 % -  14.0 * -  20.430 sec
01. La Vie, L'amour.yaa                                      47.48 % -  14.3 * -    7.735 sec
01. Le vieux Léon.yaa                                        36.56 % -  14.6 * -  15.500 sec
02. Parallel Universe.yaa                                    71.39 % -  11.0 * -  24.493 sec
02. Sa jeunesse.yaa                                          36.44 % -  12.0 * -  23.722 sec
03. Memories of You.yaa                                      32.18 % -  13.7 * -  14.090 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.24 % -  14.2 * -    7.623 sec
04. Celle qui a dit non.yaa                                  65.04 % -  11.3 * -  25.109 sec
04. Comme Moi (Like Me).yaa                                  42.99 % -  13.4 * -  13.403 sec
05. Le chemin de la dompe (présentation).yaa                  43.86 % -  13.0 * -    4.898 sec
06. Frédéric.yaa                                              47.77 % -  13.4 * -  15.114 sec
11. Nil (Instrumental).yaa                                    19.88 % -  14.0 * -    9.815 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  43.05 % -  12.9 * -  25.004 sec
15. Stroker Ace.yaa                                          54.45 % -  13.5 * -  19.926 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.20 % -  14.4 * -    9.105 sec
20. Sleighride.yaa                                            56.55 % -  10.9 * -  16.407 sec

Compression:    47.81 %
Duration:      252.39 sec
Speed:          12.88 * real time

Default + frame partition 32 :
01. Giant Steps.yaa                                          57.59 % -  21.7 * -  13.203 sec
01. La Vie, L'amour.yaa                                      47.57 % -  26.7 * -    4.150 sec
01. Le vieux Léon.yaa                                        36.70 % -  36.6 * -    6.203 sec
02. Parallel Universe.yaa                                    71.48 % -  37.6 * -    7.192 sec
02. Sa jeunesse.yaa                                          36.46 % -  39.5 * -    7.227 sec
03. Memories of You.yaa                                      32.27 % -  41.8 * -    4.611 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.25 % -  38.3 * -    2.821 sec
04. Celle qui a dit non.yaa                                  65.16 % -  31.7 * -    8.968 sec
04. Comme Moi (Like Me).yaa                                  43.00 % -  34.5 * -    5.204 sec
05. Le chemin de la dompe (présentation).yaa                  43.94 % -  36.1 * -    1.765 sec
06. Frédéric.yaa                                              47.84 % -  35.7 * -    5.659 sec
11. Nil (Instrumental).yaa                                    20.04 % -  43.6 * -    3.145 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  43.08 % -  38.2 * -    8.442 sec
15. Stroker Ace.yaa                                          54.60 % -  34.4 * -    7.825 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.21 % -  39.4 * -    3.338 sec
20. Sleighride.yaa                                            56.67 % -  35.4 * -    5.052 sec

Compression:    47.90 %
Duration:      94.82 sec
Speed:          34.28 * real time


Default + 64 preds :
01. Giant Steps.yaa                                          57.79 % -  27.0 * -  10.625 sec
01. La Vie, L'amour.yaa                                      47.68 % -  41.2 * -    2.684 sec
01. Le vieux Léon.yaa                                        36.65 % -  45.1 * -    5.037 sec
02. Parallel Universe.yaa                                    71.42 % -  43.8 * -    6.171 sec
02. Sa jeunesse.yaa                                          36.58 % -  45.6 * -    6.261 sec
03. Memories of You.yaa                                      32.25 % -  47.8 * -    4.023 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.34 % -  42.1 * -    2.568 sec
04. Celle qui a dit non.yaa                                  65.11 % -  33.7 * -    8.446 sec
04. Comme Moi (Like Me).yaa                                  43.21 % -  35.5 * -    5.046 sec
05. Le chemin de la dompe (présentation).yaa                  43.89 % -  25.4 * -    2.507 sec
06. Frédéric.yaa                                              47.86 % -  29.4 * -    6.885 sec
11. Nil (Instrumental).yaa                                    19.96 % -  31.1 * -    4.405 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  43.56 % -  37.1 * -    8.691 sec
15. Stroker Ace.yaa                                          54.49 % -  29.9 * -    9.002 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.36 % -  36.7 * -    3.576 sec
20. Sleighride.yaa                                            56.89 % -  33.7 * -    5.310 sec

Compression:    47.99 %
Duration:      91.25 sec
Speed:          35.62 * real time

Fast :
01. Giant Steps.yaa                                          57.98 % -  33.0 * -    8.691 sec
01. La Vie, L'amour.yaa                                      47.94 % -  63.4 * -    1.746 sec
01. Le vieux Léon.yaa                                        37.05 % -  78.2 * -    2.901 sec
02. Parallel Universe.yaa                                    71.55 % -  74.9 * -    3.614 sec
02. Sa jeunesse.yaa                                          37.19 % -  72.5 * -    3.940 sec
03. Memories of You.yaa                                      32.63 % -  80.5 * -    2.391 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.80 % -  71.9 * -    1.503 sec
04. Celle qui a dit non.yaa                                  65.26 % -  36.6 * -    7.766 sec
04. Comme Moi (Like Me).yaa                                  43.35 % -  49.4 * -    3.629 sec
05. Le chemin de la dompe (présentation).yaa                  44.07 % -  50.3 * -    1.265 sec
06. Frédéric.yaa                                              48.16 % -  65.1 * -    3.107 sec
11. Nil (Instrumental).yaa                                    20.58 % -  91.2 * -    1.504 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  44.06 % -  76.7 * -    4.204 sec
15. Stroker Ace.yaa                                          54.67 % -  58.7 * -    4.590 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.64 % -  85.3 * -    1.541 sec
20. Sleighride.yaa                                            57.32 % -  51.7 * -    3.466 sec

Compression:    48.31 %
Duration:      55.87 sec
Speed:          58.18 * real time

Fast + 16 preds :
01. Giant Steps.yaa                                          58.14 % -  31.8 * -    9.012 sec
01. La Vie, L'amour.yaa                                      48.36 % -  79.3 * -    1.395 sec
01. Le vieux Léon.yaa                                        37.22 % -  97.1 * -    2.337 sec
02. Parallel Universe.yaa                                    71.71 % -  77.1 * -    3.509 sec
02. Sa jeunesse.yaa                                          37.38 % -  99.6 * -    2.868 sec
03. Memories of You.yaa                                      32.76 % - 106.2 * -    1.812 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        40.01 % -  73.7 * -    1.465 sec
04. Celle qui a dit non.yaa                                  65.50 % -  41.1 * -    6.919 sec
04. Comme Moi (Like Me).yaa                                  43.59 % -  71.8 * -    2.497 sec
05. Le chemin de la dompe (présentation).yaa                  44.38 % -  53.1 * -    1.199 sec
06. Frédéric.yaa                                              48.39 % -  61.8 * -    3.271 sec
11. Nil (Instrumental).yaa                                    20.62 % -  95.0 * -    1.443 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  44.23 % -  82.6 * -    3.905 sec
15. Stroker Ace.yaa                                          54.76 % -  52.1 * -    5.171 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.78 % -  93.1 * -    1.412 sec
20. Sleighride.yaa                                            57.76 % -  70.5 * -    2.539 sec

Compression:    48.50 %
Duration:      50.77 sec
Speed:          64.02 * real time

Fast + 16 preds + partition 32 :
01. Giant Steps.yaa                                          58.20 % -  32.4 * -    8.860 sec
01. La Vie, L'amour.yaa                                      48.40 % -  71.2 * -    1.554 sec
01. Le vieux Léon.yaa                                        37.31 % -  94.5 * -    2.401 sec
02. Parallel Universe.yaa                                    71.80 % -  85.5 * -    3.166 sec
02. Sa jeunesse.yaa                                          37.38 % -  72.6 * -    3.931 sec
03. Memories of You.yaa                                      32.78 % - 104.5 * -    1.842 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        40.01 % -  84.4 * -    1.280 sec
04. Celle qui a dit non.yaa                                  65.59 % -  46.2 * -    6.163 sec
04. Comme Moi (Like Me).yaa                                  43.59 % -  74.6 * -    2.405 sec
05. Le chemin de la dompe (présentation).yaa                  44.44 % -  61.6 * -    1.033 sec
06. Frédéric.yaa                                              48.45 % -  63.5 * -    3.185 sec
11. Nil (Instrumental).yaa                                    20.62 % - 105.8 * -    1.297 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  44.23 % -  71.6 * -    4.505 sec
15. Stroker Ace.yaa                                          54.86 % -  59.7 * -    4.516 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.78 % -  97.7 * -    1.345 sec
20. Sleighride.yaa                                            57.79 % -  75.5 * -    2.372 sec

Compression:    48.55 %
Duration:      49.87 sec
Speed:          65.18 * real time

Insane :
01. Giant Steps.yaa                                          56.91 % -  4.4 * -  65.189 sec
01. La Vie, L'amour.yaa                                      47.30 % -  4.5 * -  24.585 sec
01. Le vieux Léon.yaa                                        36.27 % -  4.6 * -  49.639 sec
02. Parallel Universe.yaa                                    71.14 % -  4.6 * -  58.226 sec
02. Sa jeunesse.yaa                                          36.29 % -  4.4 * -  64.992 sec
03. Memories of You.yaa                                      32.06 % -  4.6 * -  41.468 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.14 % -  4.5 * -  23.817 sec
04. Celle qui a dit non.yaa                                  64.66 % -  4.5 * -  63.896 sec
04. Comme Moi (Like Me).yaa                                  42.84 % -  4.3 * -  41.489 sec
05. Le chemin de la dompe (présentation).yaa                  43.64 % -  4.6 * -  13.877 sec
06. Frédéric.yaa                                              47.47 % -  4.4 * -  45.504 sec
11. Nil (Instrumental).yaa                                    19.99 % -  4.4 * -  31.310 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  42.64 % -  4.2 * -  76.918 sec
15. Stroker Ace.yaa                                          54.26 % -  4.7 * -  57.914 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.03 % -  4.4 * -  29.740 sec
20. Sleighride.yaa                                            56.17 % -  4.2 * -  42.857 sec

Compression:    47.55 %
Duration:      731.44 sec
Speed:          4.44 * real time
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-31 03:56:18
Quote
' date='May 31 2006, 04:44' post='397815']
Default + prefilter

Compression:    47.88 %
Duration:      164.89 sec
Speed:          19.71 * real time

Default + no prefilter :

Compression:    47.85 %
Duration:      107.83 sec
Speed:          30.14 * real time


Wow, you are really fast! Many thanks!

Even if you are not providing good news: The prefilter hurts!

Sorry, it will take some time to evaluate the other results. It's a bit too late here...

Could you please try preset EXTRA with PreFilter on/off? No need to hurry...

  Thomas
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-31 04:47:34
Quote
' date='May 31 2006, 04:44' post='397815']
Output is disabled for all encoding settings;  SSE is enabled, and all files are transcoded from LAME 3.98a3 -V2 --vbr-new.  As such, this doesn't make for a _real-world_ test, but it's quite revelating nonetheless, on different settings, and the quality of the stereo decorellator (indeed better than LAME's)
...

Ok, had to take a closer look at it. Maybe more handy this way:
Code: [Select]
                    FAST    NORMAL
                            Prefilter
                            Off     On      SL Extr PR 32   64 P    
-------------------------------------------------------------------
01. Giant Steps.y    57.98   57.53   57.45   57.44   57.59   57.79  
01. La Vie, L'amo    47.94   47.54   47.70   47.48   47.57   47.68  
01. Le vieux Léon    37.05   36.61   36.69   36.56   36.70   36.65  
02. Parallel Univ    71.55   71.41   71.40   71.39   71.48   71.42  
02. Sa jeunesse.y    37.19   36.45   36.48   36.44   36.46   36.58  
03. Memories of Y    32.63   32.23   32.29   32.18   32.27   32.25  
04. Carl Orff - I    39.80   39.25   39.29   39.24   39.25   39.34  
04. Celle qui a d    65.26   65.08   65.00   65.04   65.16   65.11  
04. Comme Moi (Li    43.35   43.00   43.11   42.99   43.00   43.21  
05. Le chemin de     44.07   43.88   43.90   43.86   43.94   43.89  
06. Frédéric.yaa     48.16   47.78   47.80   47.77   47.84   47.86  
11. Nil (Instrume    20.58   20.04   20.22   19.88   20.04   19.96  
12. Sergei Sergey    44.06   43.07   43.06   43.05   43.08   43.56  
15. Stroker Ace.y    54.67   54.47   54.57   54.45   54.60   54.49  
17. Carl Orff - I    39.64   39.21   39.24   39.20   39.21   39.36  
20. Sleighride.ya    57.32   56.63   56.57   56.55   56.67   56.89  
-------------------------------------------------------------------
Sum:                 48.31   47.85   47.88   47.81   47.90   47.99  
EncoRate:            58.18   30.14   19.71   12.88   34.28   35.62  
-------------------------------------------------------------------

SL Extr = Frame partition search level Extra
PR 32   = Frame partition resolution 32
64 P    = 64 Predictors


First thoughts:

- The PreFilter hurts here.
- There is no big difference when using only 64 instead of the (default) 128 predictors. Possibly the PreFilter only helps files which are benefiting from higher predictor orders.
- The other variations are not really significant. The reduction of the frame partition resolution doesn't make the preset considerably faster and often the compression advantage of the higher default resolution is bigger than the 0.05 percent here. No urgent reason to change the default resolution.
- The variations (not in this table) of the FAST preset don't give a considerable speed up.

Addendum:

I nearly forgot about my previous post:

"Possibly it compensates some disturbances of the signal which are beeing caused by the scaling needed for my reduced precision (14-Bit) arithmetic. If that's true, then the PreFilter would only be useful for my specific implementation and not for other compressors which are using full scale arithmetics."

If this hypothesis is true, then files with high levels should benefit the most from the PreFilter.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-31 06:02:33
Quote
' date='May 31 2006, 04:44' post='397815']
Output is disabled for all encoding settings;  SSE is enabled, and all files are transcoded from LAME 3.98a3 -V2 --vbr-new.  As such, this doesn't make for a _real-world_ test, but it's quite revelating nonetheless, on different settings, and the quality of the stereo decorellator (indeed better than LAME's)

Which PreFilter level did you use, Fast or Normal? Could you please try the other one too?
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-05-31 11:56:21
Prefilter was at normal.  I'll be posting the Extra / Prefilter soon.

Are fast and normal two completely different algorithms?

Also, maybe the prefilter doesn't always hurt, but in this case mp3 artifacts (which YALAC doesn't expect) make it so...

Peace,
Tristan.
Title: Yalac - Comparisons
Post by: TBeck on 2006-05-31 14:04:49
Quote
' date='May 31 2006, 12:56' post='397899']
Are fast and normal two completely different algorithms?

Also, maybe the prefilter doesn't always hurt, but in this case mp3 artifacts (which YALAC doesn't expect) make it so...

No, Normal only performs a more elaborated check, if the PreFilter would hurt (theoretically...). But both checks are very limited, because i didn't want to slow down encoding.

But...

I did ask Joseph Pohm for a quick check on his sample sets...

...and...

it seems as if there will be a need for some very nice modifications of his comparison!
Title: Yalac - Comparisons
Post by: Josef Pohm on 2006-05-31 18:01:06
I did ask Joseph Pohm for a quick check on his sample sets and it seems as if there will be a need for some very nice modifications of his comparison!


I'll do it very gladly. Here you have my first impression on Yalac v0.08 new feature, PreFilter. Preliminary results, only High mode tested, only compression ratio tested, there are no speed results here. I usually test Yalac on 4 sample set.

Code: [Select]
Set A - Primary Sample Set

Yalac v0.08      Preset High - PreFilter Off   57,69%
LPAC v1.40       ExtraHigh                     57,32%
Monkey v4.01     High                          57,31%
MP4ALS Garf      -a -o32                       57,25%
OptimFrog 4.520b Normal                        57,04%
Yalac v0.08      Preset High - PreFilter On    56,46%

Improvement 2,10%, Yalac surpasses all four competitors.

Code: [Select]
Set B - BackUp Sample Set

Yalac v0.08      Preset High - PreFilter Off   54,69%
Monkey v4.01     High                          54,00%
LPAC v1.40       ExtraHigh                     53,94%
OptimFrog 4.520b Normal                        53,73%
MP4ALS Garf      -a -o32                       53,54%
Yalac v0.08      Preset High - PreFilter On    52,78%

Improvement 3,49%, Yalac surpasses all four competitors.

Code: [Select]
Set C - Yalac-Unfriendly Sample Set

Yalac v0.08      Preset High - PreFilter Off   62,53%
OptimFrog 4.520b Normal                        61,78%
Monkey v4.01     High                          61,67%
LPAC v1.40       ExtraHigh                     60,68%
MP4ALS Garf      -a -o32                       60,46%
Yalac v0.08      Preset High - PreFilter On    60,43%

Improvement 3,35%, Yalac surpasses all four competitors. I'll have to change Sample Set nickname...

Code: [Select]
Set D - Yalac-Friendly Sample Set

MP4ALS Garf      -a -o32                       64,40%
LPAC v1.40       ExtraHigh                     64,32%
Monkey v4.01     High                          63,99%
Yalac v0.08      Preset High - PreFilter Off   63,81%
OptimFrog 4.520b Normal                        63,53%
Yalac v0.08      Preset High - PreFilter On    63,00%


Improvement 1,27%. With PreFilter Off Yalac is already better than three competitors out of four. With PreFilter On Yalac surpasses the fourth one as well, and gets very near to OptimFrog High (62,82%).

As a general rule, on all my four sample set, Yalac High compression ratio is now able to stand right between Monkey High and ExtraHigh, as well as between OptimFrog Normal and High. As Thomas pointed out, I can give a positive feedback (actually it's not really me, numbers speak for themselves).
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-06-01 03:52:27
Extra + Prefilter :
Code: [Select]
01. Giant Steps.yaa                                           56.95 % -   6.2 * -   46.555 sec
01. La Vie, L'amour.yaa                                      47.33 % -  6.5 * -  16.996 sec
01. Le vieux Léon.yaa                                        36.33 % -  6.7 * -  33.727 sec
02. Parallel Universe.yaa                                    71.18 % -  6.8 * -  39.617 sec
02. Sa jeunesse.yaa                                          36.30 % -  6.5 * -  44.245 sec
03. Memories of You.yaa                                      32.08 % -  6.9 * -  27.761 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.15 % -  6.6 * -  16.280 sec
04. Celle qui a dit non.yaa                                  64.70 % -  6.5 * -  43.630 sec
04. Comme Moi (Like Me).yaa                                  42.86 % -  6.3 * -  28.539 sec
05. Le chemin de la dompe (présentation).yaa                  43.67 % -  6.8 * -    9.327 sec
06. Frédéric.yaa                                              47.50 % -  6.5 * -  31.049 sec
11. Nil (Instrumental).yaa                                    20.02 % -  6.5 * -  20.986 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  42.66 % -  5.6 * -  57.195 sec
15. Stroker Ace.yaa                                          54.30 % -  6.4 * -  42.013 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.04 % -  6.2 * -  21.053 sec
20. Sleighride.yaa                                            56.20 % -  5.9 * -  30.155 sec

Compression:    47.58 %
Duration:      509.14 sec
Speed:          6.38 * real time
Extra :
Code: [Select]
01. Giant Steps.yaa                                           57.18 % -   6.3 * -   45.765 sec
01. La Vie, L'amour.yaa                                      47.40 % -  7.1 * -  15.553 sec
01. Le vieux Léon.yaa                                        36.36 % -  7.4 * -  30.858 sec
02. Parallel Universe.yaa                                    71.22 % -  7.8 * -  34.675 sec
02. Sa jeunesse.yaa                                          36.31 % -  7.2 * -  39.927 sec
03. Memories of You.yaa                                      32.08 % -  7.8 * -  24.630 sec
04. Carl Orff - I. Primo vere - Omnia sol temperat.yaa        39.11 % -  7.5 * -  14.454 sec
04. Celle qui a dit non.yaa                                  64.80 % -  7.4 * -  38.459 sec
04. Comme Moi (Like Me).yaa                                  42.86 % -  7.0 * -  25.534 sec
05. Le chemin de la dompe (présentation).yaa                  43.67 % -  7.6 * -    8.404 sec
06. Frédéric.yaa                                              47.62 % -  7.3 * -  27.794 sec
11. Nil (Instrumental).yaa                                    19.77 % -  7.4 * -  18.589 sec
12. Sergei Sergeyevich Prokofiev - Dance of the knights.yaa  42.82 % -  6.9 * -  47.060 sec
15. Stroker Ace.yaa                                          54.30 % -  7.6 * -  35.319 sec
17. Carl Orff - III. Cour d'amours - Dies, nox et omnia.yaa  39.03 % -  6.6 * -  19.822 sec
20. Sleighride.yaa                                            56.30 % -  6.8 * -  26.276 sec

Compression:    47.64 %
Duration:      453.14 sec
Speed:          7.17 * real time
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-01 10:34:50
Thomas,

I will run the usual tests at home as always; however, as always, these will take me a few days to complete.

In the meantime I have been running a test here at work on the corpus I used for the FLAC testing I performed (28 files, with a better compression spread than my 50 file corpus I use for my Yalac testing).  I can't provide timings, as I have been running the test in low priority.  I need some CPU cycles to at least make it look like I'm working...

Anyway, here are the compression results:

Code: [Select]
Setting    Compressed
=====================
Fast          58.653%
Normal        58.078%
High -c0      57.891%
High          57.638%
High -c2      57.631%
Extra -c0     57.848%
Extra -c1     57.590%
Extra         57.587%
Insane -c0    57.806%
Insane -c1    57.548%
Insane        57.545%

The spreadsheet, which also details the files in the corpus, can be found here (http://synthetic-soul.co.uk/temp/0.08-compression-results-for-flac-corpus.xls).  If a file in the corpus is of particular interest it may be worth looking at the overall results (http://synthetic-soul.co.uk/temp/flac-overall-results.xls) of my FLAC test to gain a further insight.

As soon as I have the full results for my corpus/PC at home I'll upload them, but that is likely to be tonight or sometime Friday.

I just thought I may as well make some use of this PC, even if it is only to provide compression values.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-01 11:27:50
I will run the usual tests at home as always; however, as always, these will take me a few days to complete.

Please wait a bit! Joseph Pohm has just reported some decoding errors i want to fix first.

No need to worry: I am quite sure that i allready know the reason and the fix will not significantly affect the compression performance. Somehow i allready had the feeling, that some slight modification necessary for the PreFilter could give some trouble. But my test corpus and the sample files of Josef decoded well hence i released the V0.08.

In the meantime I have been running a test here at work on the corpus I used for the FLAC testing I performed (28 files, with a better compression spread than my 50 file corpus I use for my Yalac testing).  I can't provide timings, as I have been running the test in low priority.  I need some CPU cycles to at least make it look like I'm working...

Anyway, here are the compression results:

Code: [Select]
Setting    Compressed
=====================
High -c0      57.891%
High          57.638%
High -c2      57.631%

Nice to see some improvements with the PreFilter.

Thanks

  Thomas
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-01 11:55:38
The tests at home have nearly completed.  My decoding batch files decode the YAA files and record the time taken; once this is done they then check the MD5 hash of the decoded WAVs against the MD5 hashes of the source files (using FSUM).

This morning I noticed a problem with file "13.wav (http://www.synthetic-soul.co.uk/comparison/lossless/file.asp?FilePKID=14)".  I bought the file into work and have just encoded and decoded it again with all settings.  These are the results:

Code: [Select]
File        MD5
============================================
13.wav      e3df9b6dc143cb473f66091ad5208681

F.wav       e3df9b6dc143cb473f66091ad5208681
N.wav       e3df9b6dc143cb473f66091ad5208681
H-c0.wav    e3df9b6dc143cb473f66091ad5208681
H.wav       e3df9b6dc143cb473f66091ad5208681
H-c2.wav    e3df9b6dc143cb473f66091ad5208681
E-c0.wav    2040c93a2ea07f2b4d5b4b41b5e770b0
E-c1.wav    2040c93a2ea07f2b4d5b4b41b5e770b0
E.wav       2040c93a2ea07f2b4d5b4b41b5e770b0
I-c0.wav    e3df9b6dc143cb473f66091ad5208681
I-c1.wav    e3df9b6dc143cb473f66091ad5208681
I.wav       e3df9b6dc143cb473f66091ad5208681

As you can see, this demonstrates what I briefly noticed at home this morning: There is an issue when encoding this file with the preset "Extra".

I didn't have the time to do a thorough examination this morning, and I didn't have all the results in, but with the data I did have this was the only file and the only settings that had a problem.  I have run the same decoding batch file on the "FLAC" corpus I have here at work and no files or settings have an issue.  Therefore, out of 78 files encoded using 11 settings this is the only evidence I have.

The Yalac_diag.txt report can be found here (http://www.synthetic-soul.co.uk/comparison/lossless/yalac/Yalac_diag_13.wav_0.08_Extra.txt).

Let me know if I can provide you with any more information.

Please wait a bit!
Too late, by the time I get home today all data should be in.

Joseph Pohm has just reported some decoding errors i want to fix first.
Ah, I'm glad it's not just me (see above, posted before I had seen this response), and I'm glad you already have an idea what might be happening.

Nice to see some improvements with the PreFilter.
Yes, the Fast pre-filter definately seems worth a go.  Until I can look at my timings then I can't see what performance hit there is, but from looking at Shade[ST]'s results it doesn't appear to be much at all, if any.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-01 12:37:48
...
This morning I noticed a problem with file "13.wav (http://www.synthetic-soul.co.uk/comparison/lossless/file.asp?FilePKID=14)".  I bought the file into work and have just encoded and decoded it again with all settings.  These are the results:
...
As you can see, this demonstrates what I briefly noticed at home this morning: There is an issue when encoding this file with the preset "Extra".
...
I didn't have the time to do a thorough examination this morning, and I didn't have all the results in, but with the data I did have this was the only file and the only settings that had a problem.  I have run the same decoding batch file on the "FLAC" corpus I have here at work and no files or settings have an issue.  Therefore, out of 78 files encoded using 11 settings this is the only evidence I have.
...
Let me know if I can provide you with any more information.

It seems as if i have fixed the error. I could only check one of Josef's files. I will sent him the corrected version and let him try it. If everything seems ok, i will sent the corrections to the other testers. This error should not have affected compression by more than about 0.01 percent.

The error would be more likely to show up on preset EXTRA, hence i am quite confident, that you are suffering from the same error.

Sorry for the inconvenience

  Thomas
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-01 13:08:13
It seems as if i have fixed the error. I could only check one of Josef's files. I will sent him the corrected version and let him try it. If everything seems ok, i will sent the corrections to the other testers. This error should not have affected compression by more than about 0.01 percent.

The error would be more likely to show up on preset EXTRA, hence i am quite confident, that you are suffering from the same error.
Ok, thanks Thomas.  Looks like I'm starting my tests all over.

FYI, I have just been looking at the spreadsheet for my "FLAC" corpus, and here are a few more figures for you:

Code: [Select]
                                                 Improvement
Preset: PreFilter                        Average      Best      Worst
=====================================================================
High:   Fast PreFilter                    0.253%    1.024%    -0.004%
High:   Normal PreFilter                  0.260%    1.024%     0.011%

Extra:  Fast PreFilter                    0.258%    1.038%     0.006%
Extra:  Normal PreFilter                  0.261%    1.035%     0.014%

Insane: Fast PreFilter                    0.258%    1.038%     0.005%
Insane: Normal PreFilter                  0.261%    1.036%     0.015%
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-01 13:30:14
FYI, I have just been looking at the spreadsheet for my "FLAC" corpus, and here are a few more figures for you:

Code: [Select]
                                                 Improvement
Preset: PreFilter                        Average      Best      Worst
=====================================================================
High:   Fast PreFilter                    0.253%    1.024%    -0.004%
High:   Normal PreFilter                  0.260%    1.024%     0.011%

Extra:  Fast PreFilter                    0.258%    1.038%     0.006%
Extra:  Normal PreFilter                  0.261%    1.035%     0.014%

Insane: Fast PreFilter                    0.258%    1.038%     0.005%
Insane: Normal PreFilter                  0.261%    1.036%     0.015%

Very interesting! It lightens me to see, that not only Josef's files (which my encoder sometimes finds very special...) can achive a significantly bigger advantage (your best case) than the average.

The main purpose of search level NORMAL is to avoid using the prefilter, if it would hurt. But it's effect seems not very significant.

BTW: I just sent Josef the fixed V0.08a.

Edit: Just learned, that there is a difference between "lightens" and "enlightens"...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-01 19:55:12
http://synthetic-soul.co.uk/comparison/yalac/ (http://synthetic-soul.co.uk/comparison/yalac/) now compares 0.07 and 0.08 (?all=1 to view all versions tested so far).

http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/) now compares 0.08 with other codecs (?all=1 to view the additional prefilter settings).
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-02 15:46:25
Plans for V0.09

Before i forget:
http://synthetic-soul.co.uk/comparison/yalac/ (http://synthetic-soul.co.uk/comparison/yalac/) now compares 0.07 and 0.08 (?all=1 to view all versions tested so far).

http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/) now compares 0.08 with other codecs (?all=1 to view the additional prefilter settings).

Many thanks! It's nice to see some improvement with the PreFilter.

Actually i wanted to pause the work on compression improvements after the introduction of the PreFilter and instead begin the work on the file format (error tolerance etc.) to prepare a public release. But some analysis of the PreFilter results has changed this. In addition to its main purpose the PreFilter seems to generate some nice side effects, which help compression in another way than i would have expected. After some thinking i came to the conclusion, that this (and possibly bigger) improvements could be achieved outside of the PreFilter by some other modifications.

A quick and dirty implementation looks promising: About 0.20 percent improvement for preset FAST, 0.30 percent for NORMAL! The encoding speed penality is small for those presets, but because it grows with higher predictor orders may be significant (about 10 percent) for HIGH. The effect on decoding speed is very small.

Because the new method is in no way optimized yet, i would expect some more improvements soon.

But caution: My quick and dirty implementation may contain errors! There is a very small chance, that i am overestimating the possible compression improvements!

Sorry, i can not resist. I have to evaluate this for V0.09.
Title: Yalac - Comparisons
Post by: Supacon on 2006-06-04 11:57:57
No need to apologize TBeck.  There are lots of great lossless encoders available for free right now, so there's no hurry towards a public release.  You do what you need to do to make your encoder the best it can be so that it becomes the new paradigm in Lossless compression!

I have a feeling that your encoder will set a new standard, so we certainly want you to be very methodical, careful, and thoughtful in terms of how you design it, rather than try to rush a release just for the sake of having it publicly available, then try to hack it later with improvements and have to struggle to maintain backwards compatibility and such.

I'm very impressed with your commitment and the consistency that you have been working on this.  You're an inspiration for all developers, for sure!
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-05 03:32:14
No need to apologize TBeck.  There are lots of great lossless encoders available for free right now, so there's no hurry towards a public release.  You do what you need to do to make your encoder the best it can be so that it becomes the new paradigm in Lossless compression!

I have a feeling that your encoder will set a new standard, so we certainly want you to be very methodical, careful, and thoughtful in terms of how you design it, rather than try to rush a release just for the sake of having it publicly available, then try to hack it later with improvements and have to struggle to maintain backwards compatibility and such.

I'm very impressed with your commitment and the consistency that you have been working on this.  You're an inspiration for all developers, for sure!

Many thanks!

I appreciate encouraging posts very much (even if i am not always responding)! They are especially helpful, if i just spent several days of work for possible optimizations, which in the end didn't work...

And you are right: I should not hurry. Better develop a well thought design, instead of having to fix bugs or correct shortcomings of a too early public release.

  Thomas
Title: Yalac - Comparisons
Post by: Destroid on 2006-06-05 20:51:38
A little late, but I had was requested to  submit the test results conducted on version 0.08a.
Code: [Select]
Alice In Chains - Sap      220,770,524 bytes      duration 20:51
================================================================
name/params Ratio EncTime/CPU% DecTime/CPU%
--------------------- ------ ------------ ------------
Yalacc 0.07 -p0 57.47% 111.97x / 95%  152.51x / 96%
Yalacc 0.08a -p0 57.57% 83.83x / 71%  149.37x / 95%
MAC 4.01 beta2 -c1000 58.33% 66.78x / 97% 55.52x / 91%
FLAC 1.1.2 --fast 63.97% 80.88x / 64%  117.39x / 76%
WavPack 4.3 -f 60.68% 86.65x / 71%  137.56x / 97%
OFR 4.520 --mode fast 57.33% 24.34x / 86% 34.89x / 99%
--------------------- ------ ------------ ------------
Yalacc 0.07 -p1 57.22% 46.68x / 96%  139.48x / 96%
Yalacc 0.08a -p1 57.22% 43.44x / 90%  138.51x / 97%
MAC 4.01 beta2 -c2000 56.87% 50.74x / 97% 43.87x / 94%
FLAC 1.1.2 (default) 59.70% 56.54x / 78%  137.81x / 93%
WavPack 4.3 (default) 59.03% 77.96x / 80%  112.61x / 95%
OFR 4.520 (default) 56.64% 16.99x / 86% 24.83x / 98%
MP4ALS RM17 (default) 57.83% 30.08x / 96% 55.06x / 63%
LA 0.4 normal 55.68% 6.23x / 99% 8.06x / 99%
--------------------- ------ ------------ ------------
Yalacc 0.07 -p2 57.09% 17.94x / 98%  123.94x / 96%
Yalacc 0.08a -p2 56.86% 16.93x / 99%  100.71x / 98%
MAC 4.01 beta2 -c3000 56.60% 43.12x / 98% 40.13x / 97%
MAC 4.01 beta2 -c4000 56.24% 23.83x / 98% 23.63% / 99x
FLAC 1.1.2 --best 59.52% 12.08x / 99%  142.47x / 97%
WavPack 4.3 -h 57.36% 52.16x / 90% 73.86x / 98%
OFR 4.520 --best 56.38% 4.96x / 97% 6.61x / 99%
MP4ALS RM17 -7 56.57% 0.97x / 99% 11.64x / 99%
LA 0.4 high 55.49% 4.55x / 99% 5.43x / 99%
--------------------- ------ ------------ ------------
Yalacc 0.07 -p2 * 57.09% 17.94x / 98%  123.94x / 96%  (FC /b = OK)
Yalacc 0.08a -p2 -c0 * 57.09% 18.06x / 98%  127.29x / 99%  (FC /b = OK)
Yalacc 0.08a -p2 * 56.86% 16.93x / 99%  100.71x / 98%  (FC /b = OK)
Yalacc 0.08a -p2 -c2 * 56.85% 14.80x / 99%  100.08x / 98%  (FC /b = OK)

Yalacc 0.07 -p3 * 57.03% 11.80x / 99%  132.77x / 97%  (FC /b = OK)
Yalacc 0.08a -p3 * 56.80% 7.61x / 99%  105.49x / 98%  (FC /b = OK)
Yalacc 0.08a -p3 -c0 * 57.03% 8.45x / 99%  134.56x / 98%  (FC /b = OK)
Yalacc 0.08a -p3 -c2 * 56.80% 7.61x / 99%  106.61x / 99%  (FC /b = OK)

Yalacc 0.07 -p4 * 56.97% 3.39x / 99%  134.34x / 98%  (FC /b = OK)
Yalacc 0.08a -p4 -c0 * 56.99% 4.44x / 99%  135.24x / 98%  (FC /b = OK)
Yalacc 0.08a -p4 * 56.76% 5.26x / 99%  106.47x / 99%  (FC /b = OK)
Yalacc 0.08a -p4 -c2 * 56.76% 5.26x / 99%  106.75x / 98%  (FC /b = OK)

* Denotes modes with files compared after encoding and decoding


System specs: A64 3000+, 512MB, Caviar 120GB, Win2K
Using -c0 and -c2 switches show a tradeoff with ratio vs. decoding speed, as discussed earlier.

Now, returning to your previous discussion...
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-10 10:38:32
Current progress (V0.09)

There is still some more to do before the next evaluation release. But there will be no important changes for the performance. Therefore i like to present some data:

Code: [Select]
Absolute values for test set rw

Enco-Rate    Fastest Fast    Normal  High    Extra                                            
V0.08a                37.93   15.63    6.01    2.69                                            
V0.09         61.23   38.67   17.96    7.17    4.53                                            

Deco-Rate    Fastest Fast    Normal  High    Extra                                            
V0.08a                69.46   57.83   43.79   46.63                                            
V0.09         76.57   69.84   60.39   44.90   46.73                                            

Compression  Fastest Fast    Normal  High    Extra                                            
V0.08a                57.31   56.71   56.20   56.10                                            
V0.09         58.44   57.30   56.64   56.17   56.08                                            

Test system: Pentium 3 / 800 MHz


FASTEST encodes 60 percent faster than FAST. The compression penality is only 1.14 percent on this file set. Decoding is only 10 percent faster. I would expect a bigger advantage, but possibly my system is too slow.

NORMAL encodes 15 and HIGH 20 percent faster.

Sorry, i couldn't resist. I am quite happy, that i could make FASTEST much faster than i had expected.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-10 11:14:45
I took the liberty of adding your previous 0/07 results.

Code: [Select]
Absolute values for test set rw

Enco-Rate    Fastest   Fast  Normal    High   Extra
V0.07                 37.75   15.74    6.45    3.95
V0.08a                37.93   15.63    6.01    2.69
V0.09         61.23   38.67   17.96    7.17    4.53

Deco-Rate    Fastest   Fast  Normal    High   Extra
V0.07                 68.61   58.37   51.81   53.67
V0.08a                69.46   57.83   43.79   46.63
V0.09         76.57   69.84   60.39   44.90   46.73

Compression  Fastest   Fast  Normal    High   Extra
V0.07                 57.31   56.71   56.36   56.27
V0.08a                57.31   56.71   56.20   56.10
V0.09         58.44   57.30   56.64   56.17   56.08

Test system: Pentium 3 / 800 MHz

No nasty surprises there.  It seems to me to be an excellent mix of additional compression and speed in the faster presets.  The addition of Fastest is extremely welcome, and its stats are extremely impressive.  From my intitial understanding it seems what little compromises there are are all in the right places.

I'm looking forward to comparing it on my corpus; it seems to make it more real when using your own data/files.  From past experience I expect to achieve very similar results though (you often accurately predict the benefits seen by my results when releasing new versions).

I would dearly love to hear the opinions of some other, more knowledgeable, members.
Oops, I just read this part. My bad
Ah, better than nothing I guess...
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-10 13:07:05
I took the liberty of adding your previous 0/07 results.

Thanks.

No nasty surprises there.  It seems to me to be an excellent mix of additional compression and speed in the faster presets.  The addition of Fastest is extremely welcome, and its stats are extremely impressive.  From my intitial understanding it seems what little compromises there are are all in the right places.

I hope you don't mind... I would like to increase the predictor order of FASTEST from 8 to 16, which makes encoding 10 percent slower:
Code: [Select]
Enco-Rate    Fastest Fast
V0.09         61.23   38.67
V0.09 16 P    55.93

Deco-Rate    Fastest Fast
V0.09         76.57   69.84
V0.09 16 P    73.88

Compression  Fastest Fast
V0.09         58.44   57.30
V0.09 16 P    58.12

On other test file sets this increase of the predictor order nearly halves the compression difference to FAST. And my P3-800 still encodes 56 * faster than real time...

Yow will be able to evaluate the speed advantage of 8 predictors via command line switches. If you find it important, i may change the preset again.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-06-10 15:52:09
As it was with 8 predictors, YALAC looked like my perfect contender.  I'm looking forward to testing it as soon as it's out, to see if results are uniform with what I've expected!

Peace,
Tristan.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-12 05:04:29
V0.09 is done

Changes:

Compression algorithms:

- New PreFilter option "Sensitivity": Tries to limit the PreFilter usage to those frames, that benefit from it by a significant amount.
- New channel decorrelation method "Difference". While beeing nearly always inferior to the standard decorrelation method, it has two advantages: It's much faster and it compresses better, if both channels contain exactly the same signal (mono signal copied to both channels, seems to happen sometimes).

Presets:

- New preset TURBO, which encodes up to 60 % faster than FAST.
- NORMAL encodes 10 % faster and compresses slightly better.
- HIGH encodes 30 % faster and compresses slightly worse.
- EXTRA encodes 15 % faster.
- INSANE encodes 10 % faster.

Command line:

- New test cases to evaluate the PreFilter-Sensitivity-option:

-c0 = PreFilter off
-c1 = Low
-c2 = Medium
-c3 = High (same sensitivity as in V0.08)

Caution: The preset numbers have changed because of the insertion of TURBO!
0 is now TURBO, 1 = FAST and so on.

Bug fixes:

- Fixed the bug that Synthetic Soul has reported. The smaller frames of the new preset TURBO could easily reproduce it...

Other:

- Clean up of source code. Could give new errors...
- File format changed!

Release:

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

Destroid
Josef Pohm
Shade[ST]
Skymmer
Synthetic Soul

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.09: Speed and compression performance.
- Try preset TURBO with 16 instead of 8 predictors: -p04. If this is not encoding significantly slower, we may change the preset.
- Not too important, but you could evaluate the PreFilter Sensitivity: Try preset HIGH with -c0 (off), c1 (Low) and c2 (Medium). No need to check -c3, because this is the default for HIGH.

Plans for V 0.10:

- Try to speed up the PreFilter.
- Possibly evaluate a new method to improve the compression.


Edit: EXTRA encodes only 15 % faster.
Edit 2: Added Skymmer to the tester list.
Title: Yalac - Comparisons
Post by: jido on 2006-06-12 14:15:10
Edit: Never mind... You are comparing the new presets with the 0.8 presets, I was confused.
So what is the new distribution of compression speed?
Title: Yalac - Comparisons
Post by: Destroid on 2006-06-12 17:23:12
Code: [Select]
Red Hot Chili Peppers - Mother's Milk    475,939,004 bytes    duration 44:57
============================================================================
name/params Ratio EncTime/CPU% DecTime/CPU%
--------------------- ------ ------------ ------------
Yalacc 0.08a -p0 64.21% 79.14x / 67% 90.00x / 55%
Yalacc 0.09 -p0 64.89% 98.80x / 57% 93.05x / 56%
Yalacc 0.09 -p04 64.27% 88.38x / 66% 89.54x / 56%
Yalacc 0.09 -p1 64.20% 81.19x / 69% 90.85x / 56%

MAC 4.01 beta2 -c1000 64.54% 63.95x / 95% 51.34x / 86%
FLAC 1.1.2 --fast 69.38% 83.23x / 67% 85.15x / 54%
WavPack 4.3 -f 66.44% 79.62x / 67% 84.78x / 61%
OFR 4.520 --mode fast 63.64% 24.20x / 86% 34.63x / 98%
--------------------- ------ ------------- ------------
Yalacc 0.08a -p1 64.00% 42.74x / 87% 87.35x / 59%
Yalacc 0.09 -p2 63.95% 49.74x / 84% 85.61x / 56%

MAC 4.01 beta2 -c2000 63.70% 49.25x / 97% 41.58x / 91%
FLAC 1.1.2 (default) 65.89% 55.77x / 81% 83.67x / 59%
WavPack 4.3 (default) 65.42% 75.01x / 78% 76.85x / 66%
OFR 4.520 (default) 63.23% 17.63x / 90% 24.83x / 99%
MP4ALS RM17 (default) 64.93% 29.33x / 94% 54.09x / 63%
LA 0.4 normal 62.72% 6.19x / 99% 7.84x / 99%
--------------------- ------ ------------- ------------
MAC 4.01 beta2 -c3000 63.57% 42.83x / 98% 37.27x / 91%
MAC 4.01 beta2 -c4000 63.36% 23.74x / 99% 23.07x / 97%
FLAC 1.1.2 --best 65.73% 11.87x / 99% 82.04x / 57%
WavPack 4.3 -h 64.23% 50.46x / 87% 64.07x / 87%
OFR 4.520 --best 63.19% 4.95x / 97% 6.58x / 99%
MP4ALS RM17 -7 63.92% 1.21x / 99% 18.20x / 91%
LA 0.4 high 62.64% 4.57x / 99% 5.40x / 99%

Yalacc 0.08a -p2 * 63.84% 18.40x / 97% 75.44x / 64%  (FC /b = OK)
Yalacc 0.08a -p3 * 63.73% 7.95x / 99% 75.81x / 63%  (FC /b = OK)
Yalacc 0.08a -p4 * 63.70% 5.39x / 99% 76.00x / 63%  (FC /b = OK)
Yalacc 0.09 -p3 -c0 * 63.90% 21.68x / 96% 83.39x / 57%  (FC /b = OK)
Yalacc 0.09 -p3 -c1 * 63.88% 22.86x / 96% 87.04x / 61%  (FC /b = OK)
Yalacc 0.09 -p3 -c2 * 63.82% 22.86x / 96% 79.51x / 60%  (FC /b = OK)
Yalacc 0.09 -p3 * 63.79% 22.79x / 95% 74.14x / 64%  (FC /b = OK)
Yalacc 0.09 -p4 * 63.74% 13.10x / 99% 75.77x / 63%  (FC /b = OK)
Yalacc 0.09 -p5 * 63.70% 5.79x / 99% 76.00x / 62%  (FC /b = OK)

* Denotes modes with files compared after encoding and decoding

System = A64 3000+, 512MB, Caviar 120GB, Win2K
I hit a disk IO wall encoding with TURBO, but note the lower CPU usage in addition to the speed advantage over FASTEST. Over all, all the presets encode notably faster. I was disappointed that the material I used was harder to reduce than I'd hoped, so even tenths of a percent can be important here.

For the next test I'll have my hard disk and RAM upgrades, we'll see if SATA 1.5Gbps does anything

edit: typo fixed, added other compressors' high scores
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-06-12 18:13:02
Destroid's results are greatly inspiring;  I'll try the same experiment with an Edith Piaf and an Oliver Jones albums;  From files that weren't previously mp3s, this time...

Peace,
Tristan.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-13 08:47:33
Yalac 0.09 vs The Rest of The World (?all=1 to show non-standard (-pT4; -pH c-0; pH c-1; pH c-2))
http://www.synthetic-soul.co.uk/comparison/lossless/ (http://www.synthetic-soul.co.uk/comparison/lossless/)

Yalac 0.09 vs Yalac 0.08 (?all=1 to show all Yalac versions)
http://www.synthetic-soul.co.uk/comparison/yalac/ (http://www.synthetic-soul.co.uk/comparison/yalac/)

The IO throttling makes my results for Turbo inconclusive, although I suppose that is an argument to go for 16 predictors instead of 8, and therefore pertinent.

I must say I still like the idea of using 8, otherwise Fastest isn't the fastest it can be.  That said, my IO-limited results are an argument against it, for sure.

I will try to add some CPU-only figures to this post ASAP.

Edit: And lo

Code: [Select]
Setting            Encoding                 Decoding
                   CPU    CPU+IO            CPU    CPU+IO
=========================================================
Turbo          122.71x    81.74x        122.45x    82.57x
Turbo -pT4     112.75x    80.31x        121.24x    82.00x
Fast            83.08x    68.84x        112.10x    79.89x
Normal          39.16x    36.73x         95.71x    75.70x
High            18.12x    17.65x         77.85x    68.08x
High -c2        18.01x    17.55x         85.18x    70.63x
High -c1        18.03x    17.53x         89.59x    70.66x
High -c0        17.86x    17.40x         90.19x    72.09x
Extra           10.75x    10.55x         78.90x    67.97x
Insane           5.05x     4.96x         79.72x    67.09x

Dig these in chart form (http://www.synthetic-soul.co.uk/comparison/lossless/0.09-chart-all.gif) baby.

NB: All MD5 hashes match, including the troublesome (for 0.8(a)) "13.wav".
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-13 09:01:07
Yalac Turbo, according to my corpus, compresses better than WavPack default and FLAC -8.  It is also faster at both encoding and decoding.

Yalac 0.09 is providing better compression than 0.08 in all presets.

The improvement in High is superb: 0.4% better compression with a decent increase in encoding speed.

Normal compresses slightly better, and is again faster than 0.08.  I would still perhaps like to see it encode faster.

That said, there is currently still a nice spread of encoding speeds (122.71x; 83.08x; 39.16x; 18.12x; 10.75x; 5.05x).

I really can't decide about Turbo.  My heart says 8, but my head says 16.  My stomach on the other hand is saying "Hmm... breakfast"!

- HIGH encodes 30 % faster and compresses slightly worse.
Not according to the results so far:

Code: [Select]
Results     0.08(a)     0.09
===============================
Me          63.656      63.617%
Destroid    63.84%      63.79%

You're spot on with the 30% for my CPU+IO results.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-13 17:06:25
Normal compresses slightly better, and is again faster than 0.08.  I would still perhaps like to see it encode faster.

First, again thanks for your great work! And for providing such welcome results... 

Currently i see no way to speed up NORMAL further without a significant compression penality. We could reduce the maximum predictor order from 128 to 96 or 64. This possibly would not affect your test corpus much, but makes a very noticeable difference on other file sets.

That said, there is currently still a nice spread of encoding speeds (122.71x; 83.08x; 39.16x; 18.12x; 10.75x; 5.05x).

Yes. That's the way i wanted it to be: While you can not predict the compression advantage of higher presets on individual file sets, you should at least be able to easily predict the increase of the compression time.

I really can't decide about Turbo.  My heart says 8, but my head says 16.  My stomach on the other hand is saying "Hmm... breakfast"!

That's a very healthy reaction! And possibly the second best after trowing dices for the deceision...

- HIGH encodes 30 % faster and compresses slightly worse.
Not according to the results so far:

Code: [Select]
Results     0.08(a)     0.09
===============================
Me          63.656      63.617%
Destroid    63.84%      63.79%

You're spot on with the 30% for my CPU+IO results.

Well, it was hard do predict. High now uses only 192 instead of 256 predictors. Some files of my test corpus really don't like this. But your test corpus anyway does not benefit from higher predictor orders. And HIGH now tries the simple new difference method for the channel decorrelation, that has been added for TURBO. Possibly it helps sometimes. If so, then V0.10 may compress even a little better, because it too contains the Mid-Side variant of the classic difference decorrelation.

And i performed some very slight modifications on some encoder parts; maybe that they help a bit.

Hmm... the compression rate for High (-c3) (63.617%) seems a little odd, considering -c0 (63.743%), -c1 (63.734%),  and -c2 (63.665%).  I would have expected around 63.6%.  I have checked the batch file and it is definately using -pH.  Any thoughts?  Can there possibly be such a difference between -c2 and -c3 ?

Oh yes!

The channel sensitivity option is a quick and dirty approach to solve this problem: With the default sensitivity (same as with V0.08) the PreFilter is even beeing applied, if it does not help compression at all. Unfortunately this decreases decoding speed.

Now i try to predict the PreFilter advantage and disable it (for an individual frame), if the predicted advantage is below a criterion (percent of improvement) set by the sensitivity level:

High: 0.00 = Use it if it does not hurt...
Medium: 0.3
Low: 1.00

But this prediction is not reliable. The deceision is performed at the PreFilter stage and the PreFilter is in front of the whole processing chain of the encoder. You can not reliable predict it's effect on the successing processing steps!

I have selected the sensitivity parameters by simply trying different values on my test corpus. There is no guarantee, that they work well on other file sets.

But on your and destroids test set they perform as expected:

HIGH (sensitivity): Maximum compression advantage but maximum decoding speed penality too.

MEDIUM: Should provide 50 to 70 percent of the advantage of HIGH, but should half the decoding speed penality compared to OFF.

LOW: Only use the PreFilter on the special files (of Joseph Pohm...), which benefit extremely from its usage. Your files are not among them...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-14 10:18:08
With regard to Turbo, I have dug out a few CPU-only results for FLAC and WavPack to compare with Yalac.

Code: [Select]
Setting                  Enc        Dec       Comp
==================================================
Yalac Turbo          122.71x    122.45x    65.219%
Yalac Turbo -pT4     112.75x    121.24x    64.926%
Yalac Fast            83.08x    112.10x    64.258%
Yalac Normal          39.16x     95.71x    63.880%
Yalac High            18.12x     77.85x    63.617%
Yalac Extra           10.75x     78.90x    63.566%
Yalac Insane           5.05x     79.72x    63.522%

FLAC -0               94.15x    105.84x    70.734%
FLAC -5               42.24x     96.71x    66.279%
FLAC -8                9.67x     94.84x    66.028%

WavPack -f            68.61x     91.34x    67.095%
WavPack Default       59.23x     78.74x    65.750%
WavPack -h            33.15x     53.12x    64.487%
WavPack -x             3.56x     78.32x    65.144%

Firstly, I was suprised at how fast WavPack -f is; I've never really paid it any attention before.  I assume that it would be comparible with FLAC -2 or -3, at a guess.

But, to the reason for this table.  I was very pleased to see both Turbo settings producing such excellent results, and that Fast isn't far off FLAC -0 (when comparing speed).

I was going to say that the table suggests that 8 predictors aren't required, and that 16 could easily be used.  This does ring true, but you could equally say that another 0.3% compression is not required!  When looking at the faster settings Yalac is providing much better compression than the codecs to which I am comparing it.  The fact that Yalac Turbo is faster, at both encoding and decoding, than FLAC -0, and provides an additional 5% compression, is astounding.  Considering FLAC's upcoming improvement (http://www.hydrogenaudio.org/forums/index.php?showtopic=44229), it is possible that Turbo will no longer compress better than FLAC -8, but we will see; it seems Thomas has even further plans up his sleeve as well.

I guess I would have to say, as long as further processes do not slow down Turbo to any relevant degree, 16 predictors makes most sense.  Why not take that little more compression if it means Yalac is still top of the table?

I have no idea what impact the inclusion of error checking, seeking, and tagging will have.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-14 10:39:21
...
When looking at the faster settings Yalac is providing much better compression than the codecs to which I am comparing it.  The fact that Yalac Turbo is faster, at both encoding and decoding, than FLAC -0, and provides an additional 5% compression, is astounding.  Considering FLAC's upcoming improvement (http://www.hydrogenaudio.org/forums/index.php?showtopic=44229), it is possible that Turbo will no longer compress better than FLAC -8, but we will see; it seems Thomas has even further plans up his sleeve as well.

I guess I would have to say, as long as further processes do not slow down Turbo to any relevant degree, 16 predictors makes most sense.  Why not take that little more compression if it means Yalac is still top of the table?

Exactly my thinking!

And thanks for the table. And not to forget: for your speed graph from the previous post! It took me some time to find it....

I have no idea what impact the inclusion of error checking, seeking, and tagging will have.

To give an first estimate: About 0.02 percent for seeking and error checking when using 250 ms frames. More for Fast and Turbo because of their smaller frames.

But i don't know, how large the average tagging info is.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-14 14:10:52
Discussion regarding PreFilter vs Parcor Coefficients moved to Yalac – Evaluation and optimization (http://www.hydrogenaudio.org/forums/index.php?showtopic=43493).  I have tried to make the split as neat as possible.  It's a difficult call, as this thread also doubles at the news update thread; however I have moved 27 posts which are not in any way related to comparing Yalac with other codecs.

Discussion regarding tagging moved to new thread: Yalac: Tagging Scheme (http://www.hydrogenaudio.org/forums/index.php?showtopic=45659), as this will surely require further discussion, although perhaps not quite yet maybe.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-19 02:56:38
Current Progress (V0.10)

Maybe this will later be moved to "Evaluation and optimization"...

Bad News: The time of significant compression or speed improvements every two weeks is now over!

This had to happen sooner or later...

There is only one thing left, that i will try to possibly improve compression on some problem files. But no guarantee!

For the speed: No matter where i am looking into my code, speed optimizations everywhere. You can expect about 10 percent more speed for the fast presets, when i disable my self check code. And possibly cpu specific optimizations could help a bit, but not enough for me to perform them.

This time the list of improvements is quite small:

Presets

- Removed preset INSANE. With one exception any of it's exclusive options provided to litttle additional compression to pay for the speed penality.
- Combined the power of Partition search level Extra (from INSANE) with the speed of level High, which is used by preset EXTRA. Makes preset Extra less than 10 percent slower, but provides at least 70 percent of the compression advantage of old search level extra. With the PreFilter turned on, Search level High (old Extra) is quite useless, but if someone disables the PreFilter to achieve higher decoding speeds, the new Partition search level High can be very advantegous for some files.
- Preset EXTRA now uses the new (classical) channel decorrelation method Mid-Side. Again; not too useful if the PreFilter is turned on, but very fast and therefore a valuable option for faster presets. Makes Extra about 3 percent slower.

Need for speed...

or not?!

Do we really need a TURBO preset, if even FAST is allready beeing limited by today's hard disk performance? Would it at least be useful for transcoding purposes, if the disk-io allready has been performed by the transcoder software (Well, then it's the transcoder software that has to wait for disk-io, our super fast turbo mode isn't responsible, but does this make a difference?)?

My personal opinion (after some introspection...): That can not convince me. At least not, if we are talking about file encoding, decoding and playback on a PC.

But many of you were talking about possible hardware support and the need to take care for the possible limitations. And this surely is very important!

But for me this are some different things, that also should be handled seperately!

Therefore some new (not really) approach for V0.10:

1) I will keep the the presets FAST, NORMAL, HIGH and EXTRA for archival and playback on a PC.

2) The hardware (player) compatibility should be achieved by the definition of profiles, which limit the maximum cpu and memory requirements for decoding.

Basically the profiles are a additional set of presets, hence some kind of TURBO will still be avail...

V0.10 will contain a preliminary definition of 4 profiles (possibly to many), which may get redifined, when i know more about the limitations of hardware players.

Possibly nothing new or surprising for you, but for me a good way to get out of the never ending speed discussion (within my head)...
Title: Yalac - Comparisons
Post by: Supacon on 2006-06-20 18:25:11
Great stuff.  It's exciting to hear that you've got most of the codec worked out.  Do you think that you're just about ready to work on the other features, like error correction, seeking and tagging?

Would it make any sense at this juncture to port it to C or something so that it could be made cross-platform compatible?  I thought perhaps it would be less work in the long run to do it now, rather than writing the whole program, then having to do it over again.

I'm glad that you're thinking about compatibility on other platforms, and hardware, because that's one of Monkey's Audio's shortcomings.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-21 01:20:33
Great stuff.  It's exciting to hear that you've got most of the codec worked out.  Do you think that you're just about ready to work on the other features, like error correction, seeking and tagging?

Probably. But i just found some new optimization i want to evaluate first. It compresses some files more than 1 percent better, too much to be ignored.

Afterwards i will care for error correction and seeking. Then for tagging.

But it is quite probable, that the progress will slow down. Since my first post at April 1st i have spent nearly my whole time on YALAC! But soon i will have to go back to some work, i get paid for!

Would it make any sense at this juncture to port it to C or something so that it could be made cross-platform compatible?  I thought perhaps it would be less work in the long run to do it now, rather than writing the whole program, then having to do it over again.

The allready very compact source of the encoder core (without any file handling or interface) is currently more than 700 KByte big! Very much work to translate it. Possibly i will first translate the far less complex decoder source to C.

I'm glad that you're thinking about compatibility on other platforms, and hardware, because that's one of Monkey's Audio's shortcomings.

But it is really a long way to go... Currently i am only preparing Yalac for such later extensions (of it's possibilities).
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-21 03:35:07
Current progress (V0.10)

Evaluation of compression efficiency and speed of the new Hardware profile presets of V0.10 and comparison to preset FAST of V0.09.

Performed on my primary test sets "rw" and "songs".

Test system: P3-800

All tests performed without file output.

Code: [Select]
         | Compression             | Encoding speed          | Decoding speed  |
         | Evaluation              | Evaluation              | Evaluation High |
Preset   | Fast    Normal  High    | Fast    Normal  High    | MMX     Pascal  |
---------+-------------------------+-------------------------+-----------------+
rw       |                         |                         |                 |
Level 0  |  58.34   58.11   58.06  |  53.32   35.54   19.30  |  74.80   66.51  |
Level 1  |  58.00   57.71   57.66  |  51.77   28.10   15.75  |  74.06   61.24  |
Level 2  |  57.75   57.43   57.36  |  43.07   23.11   12.96  |  71.72   53.32  |
Fast     |  57.30                  |  38.65                  |  69.51   50.31  |
---------+-------------------------+-------------------------+-----------------+
songs    |                         |                         |                 |
Level 0  |  49.70   49.49   49.45  |  56.59   35.86   19.54  |  75.84   67.64  |
Level 1  |  49.07   48.81   48.75  |  53.13   28.55   15.92  |  74.70   60.84  |
Level 2  |  48.68   48.38   48.29  |  44.39   23.63   13.11  |  69.38   52.14  |
Fast     |  48.51                  |  37.54                  |  67.42   48.88  |
---------+-------------------------+-------------------------+-----------------+

Preset

Hardware profiles Level0/1/2 with 8/16/32 predictors and frame durations 63/100/131 ms. Preset Fast taken from V0.09.

Evaluation

Fast/Normal/High determines the evaluation depth of the encoder. This should only affect encoding but not decoding speed.

Compression

Compression ratio in percent.

Encoding / Decoding speed

Multiple of real time. Because decoding speed should not depend on the Evaluation level, i only tested High. MMX is the speed of the optimized assembler code, Pascal the speed of pure Pascal code.

Short summary

Level 2 with Evaluation High is about on par with preset FAST although it's implementation is far less complex.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-21 09:22:30
I must admit that I am finding this new system quite confusing.  I'm not very familiar with OptimFROG but it is reminding me of its --mode and --optimize switches.

One suggestion?  Perhaps you could find the best balances in that matrix and allow users to use presets to access them?  E.g.:

YALACC.EXE --level 0 --evaluation fast c:\path\to\myfile.wav

... becomes:

YALACC.EXE --preset turbo c:\path\to\myfile.wav

I have just realised that this isn't a new idea - FLAC, LAME, etc. all do this already - and you were probably already planning to. ... ah, well; I'll leave it here anyway.

Edit:  Hang on, have I got the wrong end of the stick?
Evaluation of compression efficiency and speed of the new Hardware profile presets of V0.10 and comparison to preset FAST of V0.09.
Sorry, does this mean that the above are additional to the existing presets, or replacements?
Title: Yalac - Comparisons
Post by: jido on 2006-06-21 11:46:29
Edit:  Hang on, have I got the wrong end of the stick?
Evaluation of compression efficiency and speed of the new Hardware profile presets of V0.10 and comparison to preset FAST of V0.09.
Sorry, does this mean that the above are additional to the existing presets, or replacements?

As I understand it, they are different sets of presets. The normal presets are for playback on a computer, the new hardware profile presets are for playback on devices with limited hardware resources (low complexity).

The hardware presets can be played on a computer of course, only they may not be as optimal as the normal presets in terms of speed and compression ratio. So normally you would use the normal presets, and convert to a hardware preset when you want to play on a hardware device (with Yalac impressive speed that should not be that painful!)
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-06-21 11:58:44
Thanks for your input jido.  On reflection I believe that you are right.

Hmm... I am still confused though.  I wouldn't want to have to decide on which of the nine combinations would fit my particular hardware (if I had some).  I assume things will become clearer to me as they become more relevant (i.e.: when there is hardware support, perhaps a combo will be issued a preset name, like --rockbox or something...).
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-21 17:36:37
I must admit that I am finding this new system quite confusing.  I'm not very familiar with OptimFROG but it is reminding me of its --mode and --optimize switches.

One suggestion?  Perhaps you could find the best balances in that matrix and allow users to use presets to access them?  E.g.:

YALACC.EXE --level 0 --evaluation fast c:\path\to\myfile.wav

... becomes:

YALACC.EXE --preset turbo c:\path\to\myfile.wav

Jido is right:
As I understand it, they are different sets of presets. The normal presets are for playback on a computer, the new hardware profile presets are for playback on devices with limited hardware resources (low complexity).

The hardware presets can be played on a computer of course, only they may not be as optimal as the normal presets in terms of speed and compression ratio. So normally you would use the normal presets, and convert to a hardware preset when you want to play on a hardware device (with Yalac impressive speed that should not be that painful!)

Thanks for making it clear! I should have written some more explaination for the new presets...

But:
Hmm... I am still confused though.  I wouldn't want to have to decide on which of the nine combinations would fit my particular hardware (if I had some).  I assume things will become clearer to me as they become more relevant (i.e.: when there is hardware support, perhaps a combo will be issued a preset name, like --rockbox or something...).

Yes, there are 9 possible combinations: 3 Profiles * 3 Evaluation levels.

How to make your choice:

1) Select the maximum hardware profile your hardware can support.

If you don't know or want highest compatibility to other devices, you may select 0 or 1.

I like your idea to select the profile by specifying it's name. On the other hand, it would not be too difficult to look into a list, which contains the maximum possible level for each hardware. And you anyway may have to do this, even with your named switch option, because it often will not be clear, how exactly the name of your hardware has to be specified. What if there are different models: Rockbox A3-B and Rockbox A4-9?

2) Select the evaluation level based upon your time constraints for encoding.

The hardware compatibility of a profile does not depend on the evaluation level. Select a higher evaluation level, if you are willing to wait longer for a bit more compression.

One suggestion?  Perhaps you could find the best balances in that matrix and allow users to use presets to access them?  E.g.:

You know, that we all together have done this for the old PC-Presets. There is now a very good balance between encoding speed and compression ratio. But here we never really cared about the effect on decoding speed and hence the hardware requirements!

But we have to to this for the hardware profiles. The most important factor determining the (minimum) decoding speed is the predictor order. Not surprising: this one is the main difference between our well balanced PC-Presets.

But with the hardware profiles we are restricted to a certain predictor order. Within a profile we can only vary those encoder options, which have no effect on the decoding speed, and this is, what the evaluation level does. And because of the constraints of a particular profile, there is far less variation possible.

If you find three evaluation levels too confusing: Just ignore them and use the default (Normal). It anyhow provides the best speed compression ratio. Fast is only there to make the good old TURBO-Preset vailable.

I would be happy with less than 3 profiles. I would like to remove Level 0. But there is some conversation with Josh Coalson, and he told me, that he had good reasons to restrict FLAC -8 to 12 predictors for maximum hardware compatibility. Currently it is not clear, if Yalac would achieve the same decoding speed with 8 or 16 predictors.

Sorry for the confusion! But all this (thinking about hardware support) is very new for me.

But it's good, that i have written about it. Your feedback shows me possible failures and shortcomings of my concept.

Thanks

  Thomas
Title: Yalac - Comparisons
Post by: Supacon on 2006-06-29 00:51:21
Hmm... haven't heard of any new developments lately.  Hopefully that doesn't mean that TBeck couldn't sustain this project.  I'd hate to see this be relegated to vaporware after getting so close!

Hopefully something can be released soon enough that will demonstrate YALAC's capabilities well, but be able to maintain future compatibility with upcoming versions and revisions.  I'm no expert on the subject, but I thought that implementing seeking, error correction, and tagging would be fairly easy because good existing algorithms can be used.
Title: Yalac - Comparisons
Post by: TBeck on 2006-06-29 01:25:15
Hmm... haven't heard of any new developments lately.  Hopefully that doesn't mean that TBeck couldn't sustain this project.  I'd hate to see this be relegated to vaporware after getting so close!

Hopefully something can be released soon enough that will demonstrate YALAC's capabilities well, but be able to maintain future compatibility with upcoming versions and revisions.  I'm no expert on the subject, but I thought that implementing seeking, error correction, and tagging would be fairly easy because good existing algorithms can be used.

After the many years of work something really strange had to happen to prevent me from finishing and releasing it. But i allready wrote, that i will not always be able to spend most of my time (for the last 3 month i did hardly anything else...) for yalac, hence development will progress a bit slower.

And i want a robust and extensible public release. I don't want to have to change the file format after a public release. The design takes some time.

Some things seem to be easier than they really are. For instance it is easy to add some error recognition code to yalac to detect damaged frames. But this check is usually beeing performed, when the decoder allready has tried to decode the whole frame. Damaged data can create invalid states within the decoder, which have to be detected and handled. Because decoding speed is very important for me, i am currently trying to design the decoder for maximum error tolerance without the need to frequently check the input data for invalid states, which could take a significant amount of time.

I am still working hard on Yalac, but currently there is not much that would be worth to be posted.

  Thomas
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-01 10:54:19
Current progress (V0.10)

Well, this time it will take more than my usual 2 weeks to get the next version done, because i have to make more fundamental deceisions, for instance about the file format. But now it's at least clear, what the next version will bring.

Done:

- Slightly better compression for preset EXTRA.
- 2 hardware profiles.
- Each frame contains a CRC32 Checksum for error recognition.
- Each frame starts with a sync code, to make streaming possible and data recovery of damaged files easier.
- Further preparations for later streaming support.
- More error tolerance within the decoder.

Preset Turbo will be a bit slower, because the checksum generation takes some time and because i have increased the frame size from 63 to 100 ms to compensate the space requirements of sync code and checksum.

To do:

My primary goal for V0.10 is far more error tolerance and a function to repair damaged files. I had to deal a bit earlier than i wanted with the streaming implementation, because some of the features needed for streaming are also important for the error resistance.

V0.10 will bring a new GUI function to manually repair damaged files. Later versions will support some automatic recovery while decoding. It's anyhow needed for streaming.

I would like the testers to damage files (be bad!) and then try the new repair function. Probably i will provide a little tool, that will randomly replace some bits of the files.

Unfortunately i can not predict, how long the implementation of the repair function  will take. It's very probable, that i will find, that many parts of the decoder have to be rewritten for more error tolerance, when i start the testing of damaged files. Maybe a week...


BTW: Thanks to Joseph Pohm and Synthetic Soul for updating Joseph Pohm's comparison (http://synthetic-soul.co.uk/comparison/josef/).

Warning: A comparison performed on a limited file set is nearly never representative for the average performance of a codec! For instance this set is the only one so far, where Yalac High comes so close to OptimFrog High. These files are really something special!

  Thomas


Edit: Warning added.
Title: Yalac - Comparisons
Post by: LaserSokrates on 2006-07-01 13:28:22
Quote
Each frame contains a CRC32 Checksum for error recognition

Does this make sense?
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-01 14:04:22
Quote
Each frame contains a CRC32 Checksum for error recognition

Does this make sense?

Good question!

I wanted to ask the same in the Yalac-format-development-thread...

It's very possible, that the file header will contain a MD5 check sum for the whole files. This should allready provide some safety.

The frame crc's should be able to detect more errors and their location (I hope so). What is it worth?

If the errors are so minimal, that you wouldn't notice them, you will anyhow want to ignore the check sum errors.

If you can hear them, you don't need a check sum to verify this.

They may be useful, if you don't want to listen to the file to check for errors...

And it's a question of the error probability; if there are not many, one MD5 check sum should be sufficient.

To be honest, i myself could live witout frame checksums. But most other audio compressors are using them, and i would feel bad, if users would not trust yalac because it does not use them...

  Thomas
Title: Yalac - Comparisons
Post by: LaserSokrates on 2006-07-01 14:26:30
A CRC for each frame is possible in LAME, but with a penalty of 16 bits per frame. I'd go with MD5 for the raw audio data like in FLAC and WavPack. In this case, you either know if a file is corrupt or not, but that's sufficient IMHO.

Edit: Why do you "expect" data loss? I never had any problem with data corruption with my lossless files.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-01 14:49:37
Or, you could implement a CRC-16 code, maybe, in each frame.  I don't think the system needs to be _that_ sturdy...
Title: Yalac - Comparisons
Post by: bryant on 2006-07-01 17:12:33
To be honest, i myself could live witout frame checksums. But most other audio compressors are using them, and i would feel bad, if users would not trust yalac because it does not use them...
The advantage of per-frame error checking is that you can mute the audio when you detect an error, thereby avoiding loud bursts of noise. Also, if you are recovering a corrupt file it's nice to have the option of throwing away (or muting) the bad blocks. If you somehow lost the global MD5 you would have no idea whether what you had was mostly garbage or perfectly fine.
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-01 21:23:29
How much would this actually impact the compression ratio?

I'm not really sure in what context you'd get so many bad frames... usenet posting of lossless image files, maybe?
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-03 06:47:02
The advantage of per-frame error checking is that you can mute the audio when you detect an error, thereby avoiding loud bursts of noise. Also, if you are recovering a corrupt file it's nice to have the option of throwing away (or muting) the bad blocks. If you somehow lost the global MD5 you would have no idea whether what you had was mostly garbage or perfectly fine.

Thanks!
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-05 03:19:44
Current progress (V0.10)

And again a report... The main reason for the increased report frequency: I am now working on features which are more important for the practical usability for average users than some specific encoder options. I want to make sure, that i don't miss necessary features.

Decompression and error recovery

Now you can deceide, if you want to decompress files or only test their integrity.

Errors can be corrected on the fly while decompressing.

You can choose, how damaged files should be handled:

1) Skip: Don't decompress them.

2) Repair: Make a new file from the valid frames.

You can choose, how damaged frames within each file should be handled:

1) Skip: The damaged data is beeing cut out.

2) Mute: Replace the damaged data with a frame of silence. This can be useful, if you want to perform manual corrections with an audio editor on the recovered file.

For each damaged file an error log is beeing created:

Code: [Select]
--- 41_30sec_err.yaa ---

Result: Frames damaged

Header frames:       477
Valid  frames:       474
Skipped blocks:        3
Skipped end:           0
Crc errors:            1

Skipped data blocks

No       Source pos  Size        Sample pos  Count
       1      979895       12617      394476        2778
       2     1445939       12924      575046        2778
       3     2637911       14806     1033416        2778

It contains:

- The frame count the file header reported.
- The count of valid frames.
- The count of damaged data blocks which have been skipped.
- Skipped end is 1, if there was a damaged data block after the last recovered frame.
- The count of crc errors. Most errors may be detected by the decoder, but some will go through and than be detected by the checksum.

Skipped data blocks contains a list of the defective data blocks:

- The position and size of the block within the compressed source file in bytes.
- The position and size of the block within the decompressed file in samples. With this info it is easy to find the affected file parts within an audio editor.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-05 04:01:25
Looks great.  In a software decoder implementation, ideal fuction would be play and silence bad frames.  It's nice to check for errors too, though, with a skip function -- if compressing a CD, for example.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-05 04:46:48
Quote
' date='Jul 5 2006, 05:01' post='408985']
Looks great.  In a software decoder implementation, ideal fuction would be play and silence bad frames.  It's nice to check for errors too, though, with a skip function -- if compressing a CD, for example.

Thanks.

But i forgot to implement two other useful options to handle corrupted frames:

3) Insert a frame of silence, but let it perform a fadeout (go down to 0) for the previous frame and a fadein for the next frame to avoid clicks.

4) Insert no frame of silence (skip), but instead perform a fadeout for the previous frame and a fadein for the next frame within their data to avoid clicks.
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-05 08:09:18
Are these things really functions of the codec?  I thought it would be the decoder, or even the player that is responsible for behavior like this.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-05 08:28:18
Are these things really functions of the codec?  I thought it would be the decoder, or even the player that is responsible for behavior like this.

Surely not.

The interface to the codec is simple: Here are n bytes of data representing one frame of audio data of format x. Decompress it. The codec knows nothing about sync codes, crc, streaming, metadata, files etc.

But woudn't users like to compress and decompress files? 

I am not sure, if i have understood your question...
Title: Yalac - Comparisons
Post by: LaserSokrates on 2006-07-05 10:12:57
Don't you think you are paying a bit too much work into error correction? I think I never had a file with corrupt frames, and the only scenario I could imagine would be an audio stream over WLAN, not the best way to transport lossless files to be saved on another computer.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-05 12:20:09
Don't you think you are paying a bit too much work into error correction? I think I never had a file with corrupt frames, and the only scenario I could imagine would be an audio stream over WLAN, not the best way to transport lossless files to be saved on another computer.

It's possibly a matter of personal taste. Some people are being eased by error recognition and recovery. That's one reason for me. Others:

- I have read many of the older threads of this forum and found many posts regarding verifying and error correction.
- I anyhow needed sync codes and checksums for the preparation of streaming.
- I knew, that my decoder could crash when encountering data errors. I had to test and fix it. Not to much additional work to implement the whole thing.
- The comparioson table in the wiki contains a field for error recovery. I wouldn't like it to be red, if yalac should be drawn up (right?).
- Some trauma from the release of the first evaluation version: one tester had nothing better to do than damaging the files and reporting errors and crashes...
- I never before had used checksums and wanted to learn a bit more about them.
Title: Yalac - Comparisons
Post by: MedO on 2006-07-05 12:29:25
Don't you think you are paying a bit too much work into error correction? I think I never had a file with corrupt frames, and the only scenario I could imagine would be an audio stream over WLAN, not the best way to transport lossless files to be saved on another computer.


I store my lossless "archive" on CDs. I use Monkey's Audio for this, because it compresses good enough so I can always find two albums together to put on one CD. However, when I can I put the files in a rar archive with recovery information to fill up the rest of the available space on the CD, because I would hate to lose my lossless copied due to holes in the CD. If this protection can be provided by the audio codec itself, I'd consider this a point to chose that format.
Title: Yalac - Comparisons
Post by: Zergen on 2006-07-05 12:43:01

Don't you think you are paying a bit too much work into error correction? I think I never had a file with corrupt frames, and the only scenario I could imagine would be an audio stream over WLAN, not the best way to transport lossless files to be saved on another computer.


I store my lossless "archive" on CDs. I use Monkey's Audio for this, because it compresses good enough so I can always find two albums together to put on one CD. However, when I can I put the files in a rar archive with recovery information to fill up the rest of the available space on the CD, because I would hate to lose my lossless copied due to holes in the CD. If this protection can be provided by the audio codec itself, I'd consider this a point to chose that format.


May be, Reed-Solomon codes may be put into some tag? Or I hane another chance to suggest "special" frames - this time with error-correction codes. Anyway, it would be very valuable feature.
Title: Yalac - Comparisons
Post by: smack on 2006-07-05 13:19:55
May be, Reed-Solomon codes may be put into some tag? Or I hane another chance to suggest "special" frames - this time with error-correction codes. Anyway, it would be very valuable feature.

IMO, error correction measures (for a stream or file) are not within the scope of a specific (audio) codec. The place to implement such a feature would be the (generic) container format and its software components like muxer and parser/splitter.

@TBeck
I just have to ask again: 
Have you had a look at existing container formats like Ogg, Matroska and others? What's your reason for not using one of them?
Title: Yalac - Comparisons
Post by: Zergen on 2006-07-05 13:37:09
IMO, error correction measures (for a stream or file) are not within the scope of a specific (audio) codec. The place to implement such a feature would be the (generic) container format and its software components like muxer and parser/splitter.


I'm not sure about this. Yes, it's logical - but only sound samples must be covered by ECC - not tags, or something else. I don't know, if it can be done on generic container level.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-05 13:54:03
- Some trauma from the release of the first evaluation version: one tester had nothing better to do than damaging the files and reporting errors and crashes...

That tester was me

As a sidenote, implementing a facultative recovery record, like PAR2 (http://en.wikipedia.org/wiki/PAR2)/ RAR Recovery record (redundancy (http://en.wikipedia.org/wiki/Data_redundancy))/ CIRC (http://en.wikipedia.org/wiki/Cross-Interleaved_Reed-Solomon_Coding) would be nice -- it would allow partial recovery of a compressed file, or total recovery if it isn't too damaged;  this type of damage happens often on removable media like DVDs or CDs, or in case of HDD failures.

Think about it.
Title: Yalac - Comparisons
Post by: MedO on 2006-07-05 13:59:09

IMO, error correction measures (for a stream or file) are not within the scope of a specific (audio) codec. The place to implement such a feature would be the (generic) container format and its software components like muxer and parser/splitter.


I'm not sure about this. Yes, it's logical - but only sound samples must be covered by ECC - not tags, or something else. I don't know, if it can be done on generic container level.


Why exclude the tags etc. from error correction? They are maybe 0,1% of the compressed file size, so excluding them won't save much space or gain much security.

However, I agree that error correction should be provided by the container format.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-05 14:02:20
Why exclude the tags etc. from error correction? They are maybe 0,1% of the compressed file size, so excluding them won't save much space or gain much security.

Because if someone changes the tags, it flags an error.
Title: Yalac - Comparisons
Post by: smack on 2006-07-05 14:26:57

Why exclude the tags etc. from error correction? They are maybe 0,1% of the compressed file size, so excluding them won't save much space or gain much security.

Because if someone changes the tags, it flags an error.

No, the tagging software must update the error correction codes when it changes the tags. Otherwise it is really damaging the file.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-05 14:33:58
@TBeck
I just have to ask again: 

Do you?

Have you had a look at existing container formats like Ogg, Matroska and others? What's your reason for not using one of them?

Well, that's me, somewhat lost in the new wonderful world of streaming and container formats...

I've become a bit lazy over the years. I am dealing only with things i need or find interesting. Unfortunately streaming and container formats have not been among them.

But because of yalac i had to take a fast look at them. And then come to a fast deceision.

Things that seem important for me:

- The container for yalac should be easy to use by other developers.
- For audio purposes it can be quite simple and limited.
- Matroska seems to be an extremely ambitious approach, that i really appreciate. But i often read, that it is seldom beeing used because of it's complexity. I don't know enough about matroska to say if that is really true. But it seems to scare away some developers.
- FLAC and WavPack are successful although they are using their own container (yes, i know that you can wrap another container around it, that's always possible).

My current plan (may change if i know more):

Make a simple container format for yalac, that other developers can easily use. I doubt, that this would prevent yalac from beeing succesful (there may be other more important reasons for little success).

And if my deceision is wrong? Just throw away my container, use only the codec and wrap the data into a container of your choice.
Title: Yalac - Comparisons
Post by: MedO on 2006-07-05 14:55:46


Why exclude the tags etc. from error correction? They are maybe 0,1% of the compressed file size, so excluding them won't save much space or gain much security.

Because if someone changes the tags, it flags an error.

No, the tagging software must update the error correction codes when it changes the tags. Otherwise it is really damaging the file.


Shade has a good point, though. Updating the ECCs for every tagging operation might be really slow.
I think we're getting off topic again... This discussion should be in the file format thread.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-05 15:03:41
Because if someone changes the tags, it flags an error.
No, the tagging software must update the error correction codes when it changes the tags. Otherwise it is really damaging the file.

Generally, hashes are audio only.  There is no reason to hash the tags with the audio data, and therefore if done properly, no need to recycle the ECCs if you update the file tags.
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-08 12:15:43
Wow... it's funny that I've been involved in these discussions about error detection, because I just had to majorly make use of that tonight.

I was doing a very large encode of hundreds of lossless albums, and I started noticing that foobar was giving me unmatching checksum errors, so I plunked my ape files into the Monkey's Audio GUI, and I found that I had several corrupt files.

It was quite a bit of work to do this, and took a lot of time.  The fact that I could still do it fairly easily was good though.  Fortunately, I had backups of my music, but if I didn't I'd hope that there would still be some way of salvaging what wasn't damaged, since these were lossless image files. (i.e. a whole CD in one file).

When developing YALAC, I hope that attention is given to some kind of a system that allows quick and easy detection of errors, and also can pinpoint the frame (time into the track, perhaps) where the error is.  If an error is found, it should be trivial to skip it, silence the bad frame, and go onto the next one.

As for my problem, I'm guessing that I had a bad disk drive, or a poor USB2 connection or something like that, but whatever the case, I had corrupted files, and I would never have known if I hadn't tried to encode them all, and noticed that foobar was popping up some mysterious error, that I couldn't read.  Some detective work allowed me to find out what was going on, and now I'm back to normal...


I thought my real-world scenario here would help to drive home the relevance of this topic, because I know how often this stuff just seems like abstract theory with no likely application to the real world.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-08 20:01:15
When developing YALAC, I hope that attention is given to some kind of a system that allows quick and easy detection of errors, and also can pinpoint the frame (time into the track, perhaps) where the error is.  If an error is found, it should be trivial to skip it, silence the bad frame, and go onto the next one.

Sounds a bit, as if you would describe some of the new features of V0.10.  They are done...

Just a quick summary of the new features of V0.10:

- Error detection, automatic repairing of damaged files, error protocol.
- 1 Hardware profile (a variation of the old TURBO preset). Yes, only 1 is better... Some of you told me so earlier.
- File format is ready for streaming. Currently not too useful without software, that can use it.

I thought my real-world scenario here would help to drive home the relevance of this topic, because I know how often this stuff just seems like abstract theory with no likely application to the real world.

Thanks!
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-12 03:16:27
Enough progress for V0.10?

Much has be done, but there is even more left to do. I could easily spend another 2 month or more to implement all the things from my to do list. And it keeps growing...

I am tempted to release V0.10 soon (to the testers), because it is always very motivating to receive some feedback and because there may be enogh new to be tested.

Please read about the new features and tell me, if you would like to test them.

File format

You know that most of my latest work has gone into the file format:

- Error detection and recovery of damaged files
- Streaming support

First thing to test would be the recovery of damaged files. You may have read, that i have built a tiny tool to damage files.

Hardware profiles and presets

We have talked about this earlier. First i wanted to implement the hardware profiles as additional presets. Some of you found this confusing (special thanks to Synthetic soul) and i guess you are right.

Therefore V0.10 again will only provide the familar presets TURBO to EXTRA (i dropped INSANE, part of it went into EXTRA). But TURBO, FAST and NORMAL are now beeing called hardware profiles with restrictions for the encoder options. You will see that some of the encoder options are now disabled in the options dialog, if you select a restricted preset.

For the restricted presets you can now choose the evaluation level: Normal, Extra or Max. A higher evaluation level means lower encoding speed but better compression. It's your choice! Regardless of the evaluation level you will always stay within the set of allowed options for the selected preset.

Evaluation level Normal is the default and mostly equal to the old presets. Level Extra has been configured to provide you as much compression as possible at half the  encoding speed of level Normal. Level Max sets all possible options to the maximum and compresses only slighttly better than Extra.

Important: The evaluation level has nearly no effect on the decoding speed!

The following table provides some results from my primary test file sets "rw" and "songs". Test system: P3-800. All tests performed without file output.

Code: [Select]
        | Compression             | Encoding speed          | Decoding speed  |
        | Evaluation              | Evaluation              | Evaluation Max  |
Preset  | Normal  Extra   Max     | Normal  Extra   Max     | MMX     Pascal  |
--------+-------------------------+-------------------------+-----------------+
rw      |                         |                         |                 |
Turbo   |  58.29   57.90   57.84  |  57.54   29.53   17.68  |  71.05   61.03  |
Fast    |  57.32   57.03   56.93  |  38.56   19.86   11.79  |  66.45   47.96  |
Normal  |  56.75   56.58   56.55  |  20.29   10.94    7.85  |  61.06   37.38  |
N 0.09  |  56.66   56.45   56.41  |  18.03    7.94    5.67  |  54.86   32.59  |
--------+-------------------------+-------------------------+-----------------+
songs   |                         |                         |                 |
Turbo   |  49.47   49.16   49.11  |  54.69   29.87   17.97  |  72.85   62.20  |
Fast    |  48.49   48.19   48.09  |  39.24   19.82   11.77  |  67.73   47.20  |
Normal  |  47.79   47.67   47.63  |  19.68   10.78    7.72  |  60.31   33.19  |
N 0.09  |  47.69   47.54   47.50  |  17.50    7.86    5.56  |  54.89   28.83  |
--------+-------------------------+-------------------------+-----------------+

Preset

Restricted presets of V0.10. "N 0.09" is preset Normal of V0.09.

Evaluation

Normal/Extra/Max determines the evaluation depth of the encoder. This should only affect encoding but not decoding speed.

Compression

Compression ratio in percent.

Encoding / Decoding speed

Multiple of real time. Because decoding speed should not depend on the Evaluation level, i only tested Max. MMX is the speed of the optimized assembler code, Pascal the speed of pure Pascal code.

Two presets have been modified:

Turbo now uses 12 instead of 8 predictors. You may remember our discussion about 8 vs. 16 predictors for preset Turbo. Well, 12 lies in between and FLAC -8 is using 12 predictors too, hence we may be able to perform some nice comparisons. Frame duration of Turbo has been increased from 63 to 94 ms to compensate for the compression penality caused by the space requirements of the new file format additions (sync codes, crc, streaming info).

Normal now is using smaller frames and only 96 instead of 128 predictors. Compression is about 0.1 percent worse, but encoding speed is more than 10 percent higher on my system. Decoding speed is more than 15 percent higher which seems important for a (restricted) hardware profile.

Final question to the testers:

- Would you like to test it now?
- Or wait for more new features?
- Or quit testing? (Don't even think about it... please...)
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-12 03:41:17
The preliminary report you give us and progress you've made in organization is encouraging.  I do not think that any supplemental optimizations would be required from different test groups, but you can always release the version... Most testers will give you feedback in the next 2 days anyways ;-)

As you've noticed, I've mainly concentrated (of late) on giving opinion -- I don't think my test bench is particular in any way, so...

Anyways, your choice depends on whether you want to analyse the data that Joseph will give you ;-)

I'm sure, in any case, that positive feedback is welcome and encouraging.

Good luck,
Tristan.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-12 03:59:01
Quote
' date='Jul 12 2006, 04:41' post='410941']
As you've noticed, I've mainly concentrated (of late) on giving opinion -- I don't think my test bench is particular in any way, so...

And your opinion is important for me!

Possibly you could be so nice and damage some files later... 

Quote
' date='Jul 12 2006, 04:41' post='410941']
Anyways, your choice depends on whether you want to analyse the data that Joseph will give you ;-)

Good point. Probably he is allready missing something. 

Quote
' date='Jul 12 2006, 04:41' post='410941']
I'm sure, in any case, that positive feedback is welcome and encouraging.

Oh yes!
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-12 04:30:13
Possibly you could be so nice and damage some files later...
I'm always one for wanton destruction and violence -- I'd be pleased to 
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-12 07:30:09
I'm all up for some testing Thomas.  I think the usual runs comparing 0.10 to 0.9 and other codecs plus some new error recovery testing is ample to be getting on with.

I may be slower with the error detection tests as that sounds like some manual process (e.g.: listening) will be required, and I don't get much time for such things.  My speed/compression tests look after themselves pretty much on the whole.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-12 07:57:50
I'm all up for some testing Thomas.  I think the usual runs comparing 0.10 to 0.9 and other codecs plus some new error recovery testing is ample to be getting on with.

Great!

I may be slower with the error detection tests as that sounds like some manual process (e.g.: listening) will be required, and I don't get much time for such things.  My speed/compression tests look after themselves pretty much on the whole.

Oh, "Listening"?  That would be really much work!

The test could consist of two parts:

1) Damage files with my damaging utility. Then decompress them and look if yalac is crashing. This all can be performed automatically. If yalac crashes, you can stop the test and let me correct the program.

2) Pick some files, load them into an audio editor and look if the error positions (frames) reported by the error log file have been muted.

Ok, a listening test on one or two files would be nice, but this is really far more than i would have expected you to do. And all this is not urgent.

It may take some days, until V0.10 is done.

Edit: I am too dumb... There is no need for a listening test! Just perform a binary compare of the decoded file. If any difference (muted frames) has been reported by the error protocol, everything is ok!
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-12 07:59:38
TBeck, I had not been too interested in running encoding tests, because it's kind of mundane, and I think the others can do a better job with some of the scripts they have.

I would like to see how your codec can handle damaged files though, so you can include me in your test group when you're ready.  Now that I've had some firsthand experience with damaged files, I'd like to see how your codec compares to others I've used.

BTW, is there a "test" mode in YALAC's command line utility?  I guess even if the file is repaired, it should have a flag of some sort in it indicating that it is different from the original encode, or that it is a repaired damaged file, and not identical to the original source.  That might be important for testing the integrity of a backup or something.
Title: Yalac - Comparisons
Post by: jido on 2006-07-13 22:52:01
- Error detection and recovery of damaged files
- Streaming support

Great!

Quote
Therefore V0.10 again will only provide the familar presets TURBO to EXTRA (i dropped INSANE, part of it went into EXTRA). But TURBO, FAST and NORMAL are now beeing called hardware profiles with restrictions for the encoder options. You will see that some of the encoder options are now disabled in the options dialog, if you select a restricted preset.

For the restricted presets you can now choose the evaluation level: Normal, Extra or Max. A higher evaluation level means lower encoding speed but better compression. It's your choice! Regardless of the evaluation level you will always stay within the set of allowed options for the selected preset.

Is it a bit confusing that Turbo Max encoding is slower than Normal?
If the speed is "Turbo" at decoding, I would like a preset name that suggests that. Maybe Fast--> Light, Turbo--> Superlight (Ultralight?)... Shows that it doesn't have heavy requirements for decoding. Encoding may be fast or slow depending on evaluation level.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-14 17:49:25
V0.10 is (nearly) done

Compression algorithms:

- Implementation of the classic channel decorrelation method "Mid-Side". Because of it's high speed it's a welcome addition for the fast presets.
- Lower criterion for PreFilter sensitivity Low, that makes it a bit more sensitive.

Presets:

- TURBO uses 12 instead of 8 predictors and a frame duration of 94 instead of 63 ms. Therefore and because of the processing time needed for the new checksum calculation it will be a bit slower.
- FAST uses a frame duration of 125 instead of 100 ms.
- NORMAL uses 96 instead of 128 predictors and a frame duration of 188 instead of 250 ms. It should encode 10 percent faster, but may loose about 0.1 percent compression.
- HIGH uses 160 instead of 192 predictors. It should encode 5 percent faster, but may loose about 0.05 percent compression.
- EXTRA uses an optimized implementation of old frame partition search level Insane, that has replaced High. Encoding will be a bit slower. Compression can be slightly better.
- INSANE is gone.
- Presets TURBO, FAST and NORMAL are now beeing called restricted hardware profiles. New evaluation levels let you vary their encoding efficiency (encoding speed-compression tradeoff).

File format:

- Streaming support.
- Error detection.

Because the new streaming format is only partially implemented, only a subset of the possible sample rates is beeing supported in this version: 8000, 11025, 16000, 22050, 32000, 44100, 48000 and 96000 Hz.

The full implementation will support any sample rate from at least 8 to 192 KHz and up to 16 Channels.

Program functions:

- Test the integrity of a compressed file.
- Perform a test encode of a file without creating any output.
- Reconstruct damaged files.

Release:

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

Destroid
JohanDeBock
Josef Pohm
Shade[ST]
Supacon
Synthetic Soul

You may ask, why it may take another 3 days instead of the usual 24 hours to release it. I always begin my final testing after this announcement. And this time it is very probable that i will find some errors i will have to correct before the release.

What should be tested:

- Comparison with V0.10: Speed and compression performance of the presets.
- Because TURBO, FAST and NORMAL now allow the selection of one of three evaluation levels, there would be 9 combinations. No need to test them all! I would only vary the evaluation level on preset TURBO, that is possibly the most attractive preset for possible hardware support.
- Test the error detection and recovery:

1) Damage files with my damaging utility. Then decompress them and look if yalac is crashing. This all can be performed automatically. If yalac crashes, you can stop the test and let me correct the program.

2) Perform a binary compare of the decoded file. If any difference (muted frames) has been reported by the error protocol, everything is ok!

3) If you can't get enough: Pick some files, load them into an audio editor and look if the error positions (frames) reported by the error log file have been muted.

Warning:

I never changed so much at once. This time program errors are very probable! Sorry in advance...

Plans for V 0.11:

- Better functionality: Possibility to cancel encoding/ decoding, specify what to do if an (output) file allready exists.
- New switches for the command line version to give access to more options only available in the GUI-version.
- Finalization of the streaming format.
- Possibly try some new ideas for some compression improvements... I need this from time to time...

Other important items from my to do list:

- File format should support tagging and metadata.
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-16 00:04:12
Well, I've run a small test on a single file.  I tested out the error handling, and I'm impressed... it works very elegantly.  If an APE file had the slightest error, it'd just bork the whole file and you couldn't do much about it.  YALAC has a great deal of configurability to work for anyone's purposes, I suppose.

I'm not going to get into the detailed results of compression and such, but I noticed that the restricted "Fast" preset produced a file that seemed very slow to decode, exceeded only by Unrestricted Extra in the time it took to decode.  That's an odd anomaly.  Perhaps my computer was just busy, or I have a freak file?

From what I've seen, unrestricted high appears to be the most useful, with reasonable encoding speed (much faster than extra, at least), and excellent compression ratios, and also very fast decoding speed.

Perhaps later I can convert several albums containing different genres of contemporary popular music using your codec for a more involved analysis.


I do have a question that I hadn't thought of before:

For seeking in audio players, does the stream info frame have anything to do with that?  It was implied in the documentation that you could only seek to a spot every 2 seconds in the file by default, but I presume that's only over a streamed connection, and seeking on a local disk or something in a program like foobar would be normal, correct?
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-16 01:13:29
Well, I've run a small test on a single file.  I tested out the error handling, and I'm impressed... it works very elegantly.  If an APE file had the slightest error, it'd just bork the whole file and you couldn't do much about it.  YALAC has a great deal of configurability to work for anyone's purposes, I suppose.

Great news! Thanks.

I'm not going to get into the detailed results of compression and such, but I noticed that the restricted "Fast" preset produced a file that seemed very slow to decode, exceeded only by Unrestricted Extra in the time it took to decode.  That's an odd anomaly.  Perhaps my computer was just busy, or I have a freak file?

That's a bit strange. It can not be caused by the calculations performed by the decoder. Only reasons i could think of:

1) Disturbances by other system activities.
2) The disk io of some systems seems to be sensitive to the block size yalac uses for file io. Turbo and fast are using smaller blocks than the other presets. But usually this makes them faster!

I do have a question that I hadn't thought of before:

For seeking in audio players, does the stream info frame have anything to do with that?  It was implied in the documentation that you could only seek to a spot every 2 seconds in the file by default, but I presume that's only over a streamed connection, and seeking on a local disk or something in a program like foobar would be normal, correct?

You are right. No restrictions for the common software players.

A streamed connection could have a start up latency (when linking to the stream) up to the info frame interval.

Seeking on some hardware players could be limited to the user selected stream info interval (2 seconds are the default). But with a good decoder implementation they could overcome this limitation. Seeking to non-info-frames is always possible (at least if the hardware has enough resources), but it will be a bit slower.

Thank you for your fast feedback!
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-16 19:22:59
http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

http://synthetic-soul.co.uk/comparison/yalac/ (http://synthetic-soul.co.uk/comparison/yalac/)

I hope to get some error testing done the beginning of next week (in the next 3-4 days).
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-16 22:16:12
How can streaming now be tested?  Can anyone advise on how to set up a remote streaming server somewhere, so I could see how effective YALAC is as a streaming format?

Perhaps it could be tested with some classical music, or something that compresses to low bitrates.
Title: Yalac - Comparisons
Post by: JohanDeBock on 2006-07-17 00:36:28
Tested on my (still limited) benchmark:
http://uclc.info/LossLess.ods (http://uclc.info/LossLess.ods)
http://uclc.info/LossLess.pdf (http://uclc.info/LossLess.pdf)

The result on Idioteque is interesting, many compressors behave strange on this file.
-p12 gives the smallest result on this file.
Title: Yalac - Comparisons
Post by: Zergen on 2006-07-17 08:15:59
If an APE file had the slightest error, it'd just bork the whole file and you couldn't do much about it.


If APE file is broken, at least Foobar2000 can play it after 1-2 seconds of silence, and you can conver it to another file without errors - but, of cource, with silence samples.

And compression of new version isn't better - it even worse than 0.0.9, and even Extra worse than APE High...
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-17 16:25:21
Good test JohanDeBock!

About APE, I had problems where I was decoding ape images with cuesheets, and an error was encountered.  Foobar 0.9 would usually just abort and go to the next file, and foobar 0.8 would play static for the remainder of the file, or jumble things up quite a bit... one time it also skipped ahead, and I heard the beginning of the next song at the end of what was supposed to be the current one.  There's some very inconsistent error handling with Monkey's.

Zergen, I wonder if the new error correction and stream info impacts the compression? 
Did you change much else about the codec Tbeck, like what options are used in the presets?
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-17 16:57:24
Zergen, I wonder if the new error correction and stream info impacts the compression? 
Did you change much else about the codec Tbeck, like what options are used in the presets?

Yes to both questions.

You can find a detailed specification of the preset modifications in the release post (V0.10). Normal and High sarcifice some compression for a bit more speed.

Extra now uses an optimized variation of some older encoder option earlier used by the removed preset Insane, that seems to perform slightly worse than before. Possibly i will go back to the old implementation.

The position of yalac is a bit difficult. I want it to decode considerably faster than other encoders with similar compression ratios. Therefore i can not use some better performing but slower compression algorithms.

Another restriction: I don't want to use methods, that could be patented.

Monkey for instance is using a range encoder for the compression of the prediction residuals. It is believed to be patent free, but you can not be totally sure.

I too have played with range coding (about 6 years ago), but later removed it because of the possible patent issues.

If i would reactivate and optimize it a bit, any preset of yalac could compress about 0.25 to 0.30 percent better with a very small speed penality. On many test sets this would be sufficient to be on par with Monkey.

But currently i want to avoid the possible patent issues. Maybe i will add it as an option, that can be removed if it should give trouble.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-17 17:10:09
If you add range coding back and there is a patent on the technology, wouldn't the patent be necessary to decode that same info?  eg. if you remove the range coding from the encoder, old files with range coding will still need to have an 'illegal' decoder to uncompress them, no?

I suppose that's not your problem as long as you don't distribute all the decoders, but still...
Title: Yalac - Comparisons
Post by: SebastianG on 2006-07-17 17:14:31
Monkey for instance is using a range encoder for the compression of the prediction residuals. It is believed to be patent free, but you can not be totally sure.

The "range coder" publication is quite dated and until now nobody has claimed anything. I think it's a safe thing.  (I'd make use of it for any future codec). Besides, in Germany you don't need to worry about that unless you plan to earn money with it, IIRC. (PPL who want to make commercial use of your codec would have to worry, though)

BTW: Reportedly, the company On2 uses a range coder for their VP6 video codec. I don't think they pay any fees to anyone because of that.

Sebastian
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-17 17:33:17
The "range coder" publication is quite dated and until now nobody has claimed anything. I think it's a safe thing.  (I'd make use of it for any future codec). Besides, in Germany you don't need to worry about that unless you plan to earn money with it, IIRC. (PPL who want to make commercial use of your codec would have to worry, though)

Thanks for the encouragement!

But you know that there are strong forces in europe who want to change this. But you are right: Often the patent trouble begins, if someone is earning money with the code (and hence has something to pay the fees...) .

BTW: Reportedly, the company On2 uses a range coder for their VP6 video codec. I don't think they pay any fees to anyone because of that.

That's a very good point!

To be honest, besides the patent issues there is one other reason why i didn't use it: I did not understand any detail of the range coder... Shame... But that's no excuse! I will have to learn a bit more.

(Hm, i shouldn't write such things, if i cared about my self presentation...)

  Thomas
Title: Yalac - Comparisons
Post by: Zergen on 2006-07-18 08:03:07
Good test JohanDeBock!

About APE, I had problems where I was decoding ape images with cuesheets, and an error was encountered.  Foobar 0.9 would usually just abort and go to the next file, and foobar 0.8 would play static for the remainder of the file, or jumble things up quite a bit... one time it also skipped ahead, and I heard the beginning of the next song at the end of what was supposed to be the current one.  There's some very inconsistent error handling with Monkey's.

Zergen, I wonder if the new error correction and stream info impacts the compression? 
Did you change much else about the codec Tbeck, like what options are used in the presets?

Well, may be realy there's some very inconsistent error handling with Monkey's Audio. I had not so many such errors, and in my case it did resonably well.
About compression - I understand that formatted stream cannot be efficient as raw data, and don't complain about this. As for me, ratio decrease due to new format is fully acceptable, even while I cannot imagine situation when I would stream lossless. But new Normal and High don't make me happy (especially because I don't care much about decompression speed - if can be played and written to CD on-the-fly, all ok). But it's just another priorities...
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-18 20:24:53
I too have played with range coding (about 6 years ago), but later removed it because of the possible patent issues.

If i would reactivate and optimize it a bit, any preset of yalac could compress about 0.25 to 0.30 percent better with a very small speed penality. On many test sets this would be sufficient to be on par with Monkey.

Well, i have to reply to myself to correct me...

I should have known better.

Some weeks ago i played a bit with my old arithmetic encoding implementation and could only achieve about 0.150 percent better compression on average. But i was quite sure, that i could improve it.

Now i have optimized my models and am achieving 0.165 better compression...

Then i switched to a rangecoder and even worse: Only 0.123 percent left!

My current (very fast) bit coder seems to compare better than expected to range coding.

For me an advantage of 0.123 percent isn't enough to switch to the slower rangecoder.

It's a bit different with low level files, which can be compressed to about 25 to 30 percent. Here the range coder can indeed achieve 0.30 to 0.35 percent better compression. But overall it's not good enough for me.

Sorry for my misinformation.
Title: Yalac - Comparisons
Post by: Zergen on 2006-07-19 08:23:37
Then i switched to a rangecoder and even worse: Only 0.123 percent left!

My current (very fast) bit coder seems to compare better than expected to range coding.

For me an advantage of 0.123 percent isn't enough to switch to the slower rangecoder.


Is it possible to implement range coding in one preset (HIGH, for example)?
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-19 15:13:28
Is it possible to implement range coding in one preset (HIGH, for example)?

Yes, it could be implemented as an option. It even has to, because the current bitcoder still has to be kept, because the rangecoder does not perform too well on very small audio data blocks.

I am not sure, if i will add it. Unfortunately i have to do very much work before i can say, how much slower on decoding the range coder will be. It's not too nice to have all the work done and then find, that it was useless because decoding is too slow.

Other reasons against using the rangecoder:

- Considerably more complex source code.
- There may be other optimizations possible, which don't affect decoding speed but provide the same compression improvements.
- And if i wouldn't care about decoding speed at all, there would be many better ways to improve compression, for instance the symmetric algorithms used by the better compressing encoders. If i wanted maximum compression at any price (slow...), i would write a totally different compressor.

Well, i really don't know if i will implement it.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-19 15:38:23
Well, i really don't know if i will implement it.

You know what? Don't.  You're not trying to beat Monkey's.  Nobody uses the deprecated format anyways.  Your targets are FLAC, WavPack, and maybe OptimFrog's fast modes.  And you're doing fine -- Much better than people would have fathomed 4 months ago, on april first.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-19 16:17:45
http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

http://synthetic-soul.co.uk/comparison/yalac/ (http://synthetic-soul.co.uk/comparison/yalac/)

I hope to get some error testing done the beginning of next week (in the next 3-4 days).

Thanks for your fast test and sorry for my late reply... The summer heat is making me a bit lazy.

What i find interesting:

- New fast is encoding more than 10 percent slower. That's a bit strange, because i have not changed anything except the frameduration (125 instead of 100 ms). Possibly your disk io is sensitive to the higher block size.
- New Normal compresses only slightly worse but unfortunately can not achieve the expected encoding speed up of 10 percent. Possibly it's allreday a bit limited by disk io.
- New Extra is slower and compresses a bit worse. Possibly i will go back to the old version of frame partition search level high.

  Thomas
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-19 20:49:36
Quote
' date='Jul 19 2006, 16:38' post='413434']

Well, i really don't know if i will implement it.

You know what? Don't.  You're not trying to beat Monkey's.  Nobody uses the deprecated format anyways.  Your targets are FLAC, WavPack, and maybe OptimFrog's fast modes.  And you're doing fine -- Much better than people would have fathomed 4 months ago, on april first.

Thanks. 

I guess you are right. There are other possible optimizations i could evaluate. But it's good, that i have tried it. Now i can be sure, that it isn't too important.

  Thomas
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-19 22:15:24
What i find interesting:

- New fast is encoding more than 10 percent slower. That's a bit strange, because i have not changed anything except the frameduration (125 instead of 100 ms). Possibly your disk io is sensitive to the higher block size.
I should have CPU only figures for 0.10 and 0.9.  I'll try to post them soon.

I'm trying to find some time to play with Damage, but I'm getting nowhere fast.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-20 16:18:39
As promised, CPU-only figures for Turbo:

Code: [Select]
             0.09       0.10      Extra        Max
==================================================
Encode    x122.71    x107.71     x61.66     x39.39
Decode    x122.45    x115.73    x114.85    x114.50


Maybe I should try a few files with both encoders in the same run, to see whether the machine state is at fault?
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-20 16:27:30
Maybe I should try a few files with both encoders in the same run, to see whether the machine state is at fault?
I think machine state is in for a lot, at these speeds.  Do you disable your antivirus scanner?

(Nice new avatar, btw -- I like it much better than the old one.  Kind of the same style as dev0's, whom I complimented on his )
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-20 17:17:33
As promised, CPU-only figures for Turbo:

Code: [Select]
             0.09       0.10      Extra        Max
==================================================
Encode    x122.71    x107.71     x61.66     x39.39
Decode    x122.45    x115.73    x114.85    x114.50


Maybe I should try a few files with both encoders in the same run, to see whether the machine state is at fault?

No, not for me,  thanks. Maybe it's CPU dependend, for instance: The smaller frames of V0.09 just fitted into the CPU cache and the slightly bigger ones of V0.10 don't always.

The speed loss isn't to bad, isn't it? You know, i had to increase the frame size a bit to compensate for the new stream info and error check data.

BTW: What do you think about new NORMAL? (A bit more speed but 0.05 to 0.1 percent less compression.)

And for something different: I find JohanDeBock's comparison very interesting. Especially the compression performance of the new evaluation levels for NORMAL. They can come very close to High without loosing decoding speed. I have to look into his comparison for such evaluations, because your file set does not benefit from higher predictor orders and therefore the advantage of HIGH over NORMAL is always quite small.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-20 17:32:19
I think machine state is in for a lot, at these speeds.  Do you disable your antivirus scanner?

(Nice new avatar, btw -- I like it much better than the old one.  Kind of the same style as dev0's, whom I complimented on his )
I don't disable antivirus, as I wouldn't if I was ripping/encoding/decoding/etc. in real life.  I just ensure that nothing else is active, like Outlook Express, Google Talk, etc.

(I'm glad you approve. )

The speed loss isn't to bad, isn't it?
No, it seems quite negligable to me.

BTW: What do you think about new NORMAL? (A bit more speed but 0.05 to 0.1 percent less compression.)
Very, very slight drop in compression but faster encoding and decoding.  I'm always happy to see Normal drift in that direction.

And for something different: I find JohanDeBock's comparison very interesting.
I can't view the Open Office document and the PDF I can see (http://www.hydrogenaudio.org/forums/index.php?showtopic=46476) doesn't appear to have Yalac (should we be using TAK now?) in it.
Title: Yalac - Comparisons
Post by: JohanDeBock on 2006-07-20 17:37:27
I can't view the Open Office document and the PDF I can see (http://www.hydrogenaudio.org/forums/index.php?showtopic=46476) doesn't appear to have Yalac (should we be using TAK now?) in it.


http://uclc.info/LossLess.pdf (http://uclc.info/LossLess.pdf)
http://uclc.info/LossLess.ods (http://uclc.info/LossLess.ods)

The OpenOffice spreatsheet is interactive, contains macros's for sorting. This the first time I actually use OpenOffice, seems to be very good and free .
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-20 19:30:45
http://uclc.info/LossLess.pdf (http://uclc.info/LossLess.pdf)
http://uclc.info/LossLess.ods (http://uclc.info/LossLess.ods)
Thank you.

The OpenOffice spreatsheet is interactive, contains macros's for sorting. This the first time I actually use OpenOffice, seems to be very good and free .
It does look very nice, but I already have MS Office, and don't want to bloat my machine even further.

And for something different: I find JohanDeBock's comparison very interesting. Especially the compression performance of the new evaluation levels for NORMAL. They can come very close to High without loosing decoding speed. I have to look into his comparison for such evaluations, because your file set does not benefit from higher predictor orders and therefore the advantage of HIGH over NORMAL is always quite small.
Ah yes, I see what you mean now.  Normal Max (59.49%) is very, very close to High (59.46%) with no difference in decompression speed compared to  Normal.

It's good to see other user's results and compare.  Very good work Johan.
Title: Yalac - Comparisons
Post by: JohanDeBock on 2006-07-20 20:25:26
It does look very nice, but I already have MS Office, and don't want to bloat my machine even further.


I started with Excel but on request I switched to OpenOffice's Calc so that anyone can open it, for free.
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-21 01:33:44
Can't open office open Excel files just fine?
Title: Yalac - Comparisons
Post by: JohanDeBock on 2006-07-21 08:58:37
Can't open office open Excel files just fine?

Yes, but it can't run the macro's.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-21 11:58:56
Off-topic, anyone?  Synthetic, maybe you should split the OpenOffice discuttion elsewhere.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-21 12:07:54
This thread is off-topic 50% of the bloody time! (see file format posts, and previous splits I've made)

I was leaving the Open Office discussion until it had run it's course, especially as I am partly to blame.


Anyway, while I'm here:  Anyone done much Damage testing yet?  Why does nobody post any results here anymore?  I like to see other people's work as well as my own.

I'm hoping to actually perform some Damage tests very soon, and was wondering what others have already tested...
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-21 19:29:19
I did a bit of damage testing.  I didn't do anything too in depth... just random damage.  It results in missing frames in the playback... just little gaps in the audio.

It might be interesting to wipe out the first or last bit of the file, and see if it still works without the headers and such intact.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-21 20:20:42
I'll ready my chainsaw tonight : I'll try doing some damage testing on the lastest version of the encoder.  Won't be much or much interesting, probably, but I'm going to change the files by hand.. Try to generate some valid compressed audio frames with mismatching CRC, or something.  Maybe some obvious (cut-and-paste) steganography, too... (I know, obvious and steganography don't go together)

It's been a while since I ran TAK...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-21 20:27:02
It might be interesting to wipe out the first or last bit of the file, and see if it still works without the headers and such intact.
Yes, I was thinking along these lines.  I've done some preliminary tests with Damage and it seems that Yalac/TAK can easily report and ignore.

Let's see what happens when we chop its head and feet off...
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-21 20:42:41
Let's see what happens when we chop its head and feet off...

"head and feet"! Huh, i could not imagine, that testers could be that much cruel to innocent bits. 
Really. I wasn't prepared.

But thanks for working careful!

Possibly this test is less interesting for you than the earlier tests.

Even more thanks!

  Thomas
Title: Yalac - Comparisons
Post by: jcoalson on 2006-07-24 07:20:59

Monkey for instance is using a range encoder for the compression of the prediction residuals. It is believed to be patent free, but you can not be totally sure.

The "range coder" publication is quite dated and until now nobody has claimed anything. I think it's a safe thing.  (I'd make use of it for any future codec). Besides, in Germany you don't need to worry about that unless you plan to earn money with it, IIRC. (PPL who want to make commercial use of your codec would have to worry, though)

in monkey's the patent "danger" is in his hybrid rice-range coder implementation, which I think is genuinely novel.  but because of submarining you never know.

I have done experiments years back with range coding in FLAC.  range coding itself is for the most part believed to be patent free.  as soon as you start using range coding for losslessly coding the residual of an audio signal, which includes a statistical modelling part, you're in unknown territory, and since it goes in the decoder that is even more worrying.

unfortunate.

Josh
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-24 16:12:17
in monkey's the patent "danger" is in his hybrid rice-range coder implementation, which I think is genuinely novel.  but because of submarining you never know.

My quite old implementation (from 2000) is quite similar to Monkey's. Possibly a bit more elaborated because of the use of more probability models from which the encoder can choose the best fitting one. For me that seemed to be a logical step if you have started with rice coding and wanted to overcome it's limitations.

Allready two with the same idea, hence i guess that it's quite probable that others had the same or a similar idea and patented it.

I have done experiments years back with range coding in FLAC.  range coding itself is for the most part believed to be patent free.  as soon as you start using range coding for losslessly coding the residual of an audio signal, which includes a statistical modelling part, you're in unknown territory, and since it goes in the decoder that is even more worrying.

unfortunate.


I had little success with adaptive models. Too slow (especially when decoding) and too little advantage over my approach with a limited set of static (order 0) models. But possibly i have not tried it hard enough...
Title: Yalac - Comparisons
Post by: pest on 2006-07-24 21:28:06
a simple possible improvement with a rangecoder can be made when encoding the signs.
you need often less than a bit if you for example test the current sign against the last one.
i think that in your approach an adaptive model can improve the current rice-codes
because the static lpc-predictor often lefts out some of the linearity. But as you already
mentioned it's a bit slow. Dmitry Subbotin has a fast public-domain rangecoder by the way.
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-25 14:17:08
a simple possible improvement with a rangecoder can be made when encoding the signs.
you need often less than a bit if you for example test the current sign against the last one.

You maybe right. I tried it in the early days of Yalac, before i knew about arithmetic compression. Without arithmetic compression it wasn't advantegous because i could not efficiently represent the quite small probability differences. But i will try it again with range coding. Thanks!

But i wouldn't expect more than about 0.3 percent better compression (best case).

mentioned it's a bit slow. Dmitry Subbotin has a fast public-domain rangecoder by the way.

Oh yes, it's fast! For my evaluations i just switched from Michael Schindler's implementation to this one. It's really fast and compresses my data only about 0.03 percent worse.

  Thomas
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-25 19:36:23

a simple possible improvement with a rangecoder can be made when encoding the signs.
you need often less than a bit if you for example test the current sign against the last one.

You maybe right. I tried it in the early days of Yalac, before i knew about arithmetic compression. Without arithmetic compression it wasn't advantegous because i could not efficiently represent the quite small probability differences. But i will try it again with range coding. Thanks!

But i wouldn't expect more than about 0.3 percent better compression (best case).

Well, a first quick and simple approach improves compression by about 0.04 percent...

Possibly it works better if only one Lpc-Filter is beeing used. But yalac currently sends the signal through up to 4 different filters. If you visually inspect the residuals after the last filter in an audio editor, you will not find many regularities. Ok, a statistical analysis will still find some.
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-07-25 20:31:57
Without performance hits?  Every fraction of an inch gets us closer to REAL ULTIMATE POWER! (http://www.realultimatepower.net/)

Tom, you're definitly the best. Even better than a ninja !
Title: Yalac - Comparisons
Post by: pest on 2006-07-28 07:33:12
Quote
Well, a first quick and simple approach improves compression by about 0.04 percent...


this is the sign-encoding? do you use an adaptive model? if, make sure the model
adapts very fast.

i could post a very complex entropy coder, if you like...just to see how things could be done
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-28 10:01:26
Quote

Well, a first quick and simple approach improves compression by about 0.04 percent...


this is the sign-encoding? do you use an adaptive model? if, make sure the model
adapts very fast.

i could post a very complex entropy coder, if you like...just to see how things could be done


Thanks for your offer. I know a bit about adaptive modelling (i have played with it earlier).

But i doubt that i will use it in Yalac, because

- i am a bit dogmatic: no (complex) adaption on the decoder side. Decoding should be as fast as possible. (From my experience model parameters would need too much space, therefore you had to perform the model adaption in the encoder and decoder).
- The residuals (and signs) after the last filter stage look quite random. If you are using only one prediction filter you will usually find regularities within the residuals (i agree with you), but as i wrote earlier, Yalac is using a cascade of up to 4 filters.

I guess it could be advantegous for some signals to limit yalac's filter chain to only one filter and then use the sign compression afterwards. I suspect that especially low frequency signals sometimes could compress better than when using the whole filter chain without sign compression. This could be an interesting option.

But currently i am a bit to lazy to evaluate this possibility (which would need many changes of my code). Maybe later...

Not to forget: Adaptive range coding could generally be very advantegous for low level files (for instance classic music).

In the meantime i have tried two other optimizations:

1) Improved compression of the filter coefficients. Nice for files which are benefiting from medium or high predictor orders. Results from my primary test file set: TURBO 0.03 percent, FAST 0.06 percent, NORMAL 0.10 percent better compression.

This may not be much, but if you remember, that i thought about implementing (the slower) Range encoding to get about 0.12 percent better compression...

This optimization will have no significant effect on decoding speed.

2) Evaluation of the PreFilter and looking for speed ups. I wrote earlier, that i did not fully understand, why it sometimes helps. Now i know more about it.

The prefilter produced a dramatic compression improvement (more than 3 percent) on some of Joseph Pohm's special files. I could now implement a much faster filter which would achieve nearly the same compression advantage as the old implementation on those files.

But i see no chance for a general speed up of the PreFilter for average files. Sorry...
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-29 09:53:37
Thomas,

I would expect the DAMAGE command:

DAMAGE file.yaa -f a 1024 -p 1024 2048 -r $571ff

... to damage 1024 bytes in the bytes between 1024 and 2048, but only five bytes appear to be changed.

Is this because the 128 per MB kicks in?

Also, the command line:

DAMAGE file.yaa -e i 24 r 01010101 i 16 r 1010 i 8 -f a 1024 -r $571ff

... fails with "Command line error: - expected".

What am I doing wrong?

If I want to damage right at the end how do I set the first -p value, i.e.: -p <?> -1 ?
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-29 12:46:55
I would expect the DAMAGE command:

DAMAGE file.yaa -f a 1024 -p 1024 2048 -r $571ff

... to damage 1024 bytes in the bytes between 1024 and 2048, but only five bytes appear to be changed.

Is this because the 128 per MB kicks in?

That's exactly the reason...

Also, the command line:

DAMAGE file.yaa -e i 24 r 01010101 i 16 r 1010 i 8 -f a 1024 -r $571ff

... fails with "Command line error: - expected".

What am I doing wrong?

Nothing. It's my mistake. I did an error while parsing the error definition -e. Sorry! I just fixed the bug and will sent you the new version soon.

If I want to damage right at the end how do I set the first -p value, i.e.: -p <?> -1 ?

Well, you should be able to specify an offset to the file end as first parameter. Unfortunately i have not implemented it yet... I will look at it this today. I wanted to reply first.

Thanks for testing this buggy little thing! Strange to find more errors here than in the average yalac release.

  Thomas

Edit: I have changed the specification of the error positions. You can now specify negative values for positions relative to the file end:

-p -100 -50 Damage between FileSize  - 100 and FileSize - 50
-p -100  -1 Damage between FileSize  - 100 and FileSize - 1 (= FileEnd, because counting starts at 0)

Or should we write -99 0 instead of -100 - 1?
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-07-29 13:42:25
Thanks for the response Thomas.

I look forward to the new version of Damage.  I have to say though, I'm finding it hard to come up with anything to foil the Yalac decompressor so far.

0 or -1?  I guess 0 is OK as (I assume) it cannot be used as a starting position.  I.e.: I assume positive numbers run from 1 to n, where n is the filesize.

So -p 1 1024 would be the first 1024 bytes and -p -1023 0 would be the last...

Hmm, looking at it like that -p -1024 -1 looks a better format.

Code: [Select]
   1   2      3    .... n-2  n-1  n
  -n -(n-1) -(n-2) .... -3   -2  -1

Then you would say -p 1 100 is the first one hundred bytes and -p -100 -1 is the last hundred bytes.  To me that seems easier to work with... I think. 
Title: Yalac - Comparisons
Post by: TBeck on 2006-07-29 14:50:41
Thanks for the response Thomas.

That's the least i can do!

I just sent you the V1.01. I hope it works better now, although i have done it in a hurry...

I look forward to the new version of Damage.  I have to say though, I'm finding it hard to come up with anything to foil the Yalac decompressor so far.

Very good news! Thanks.

0 or -1?  I guess 0 is OK as (I assume) it cannot be used as a starting position.  I.e.: I assume positive numbers run from 1 to n, where n is the filesize.

So -p 1 1024 would be the first 1024 bytes and -p -1023 0 would be the last...

Hmm, looking at it like that -p -1024 -1 looks a better format.

Code: [Select]
   1   2      3    .... n-2  n-1  n
  -n -(n-1) -(n-2) .... -3   -2  -1

Then you would say -p 1 100 is the first one hundred bytes and -p -100 -1 is the last hundred bytes.  To me that seems easier to work with... I think. 

Sorry, it's a bit different now (at least for this version):

-p 0 99 slecets the first 100 bytes,
-p -99 0 selects the last 100 bytes.
Title: Yalac - Comparisons
Post by: Supacon on 2006-07-30 23:04:08
TBeck, I was curious about whether or not there is some way to send a signal to the audio player (i.e. foobar) if errors in the file are detected, so that the user could be alerted that there is a problem with the file.

I know that foobar will pop up an error console reporting some kinds of sync errors and such, but is there a way for the actual decoder to communicate with the player software so that such errors could be reported explicitly and logged?  This could be handy for weeding out bad files and such.
Title: Yalac - Comparisons
Post by: Supacon on 2006-08-27 20:16:51
Has anyone heard from TBeck lately?  I was just wondering if there have been any updates to this project.  It's been quite a while...
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-08-27 23:04:06
Has anyone heard from TBeck lately?  I was just wondering if there have been any updates to this project.  It's been quite a while...

Finding a job can take some time.  Let's just hope his project hasn't met a void without the community being able to continue his work.
Title: Yalac - Comparisons
Post by: TBeck on 2006-08-29 11:31:00
Has anyone heard from TBeck lately?  I was just wondering if there have been any updates to this project.  It's been quite a while...


Quote
' date='Aug 28 2006, 00:04' post='424963']
Finding a job can take some time.  Let's just hope his project hasn't met a void without the community being able to continue his work.


Thanks for asking!

I am still alive!

And i have been working on Yalac. And i had to take some deceisions.

There has been no new release, because i wasn't sure, if the small improvements would justify the work of the testers. And finally i came to the conclusion, that it's now really time to stop looking for more improvements. It's possible, that i will have some new ideas sometime, but obviously i can not force them.

V0.11 will be the last version with new compression methods. Some further improvements can be achieved by optimizing the encoder parameters of the existing methods. But this has no high priority for me.

What will be new in V0.11:

- 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).
- Presets switched back to V0.09 and somewhat modified.

I have tried far more optimizations but with little success.

What i am doing now:

- Removing code from the encoder which has only been needed for the evaluation of new compression methods.
- Cleaning up and simplifying (if possible) of the source code.
- Look for design errors.

Next things to do:

- Support for 8-Bit samples (Is anyone using them?)
- tweaking of some paramters for 24-Bit samples and other sampling rates than 44.1K.

After this has been done i will have to complete the file format (container, support for metadata).

Possibly i will publish the specification of my simple container format and ask for feedback before finalizing it.

All this will take some time, especially because it looks as if i will have far less time than before for my work on Yalac. Please don't expect a public release within the next 1 or 2 months. Sorry...

If one of the testers wants to evaluate the performance of the final encoder engine, i will release a V0.11.

  Thomas
Title: Yalac - Comparisons
Post by: pest on 2006-08-29 11:39:40
Quote
- New Wasted-Bits-option to remove the least significant bits of the samples, if they are all zero.


I guess this is done automatically?
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-08-29 11:51:09
I see Josef is lingering at this moment, and he's probably the best candidate, but I am happy to run a test on the latest version, as it takes very little user time (something I have little to none of at the moment) for me to run my scripts and report the results.

While I'm on: I felt very frustrated that I got little time to test the error tollerence of 0.10, and never reported any results (everything I did test acted as expected BTW).  Did you get enough feedback from other testers?
Title: Yalac - Comparisons
Post by: TBeck on 2006-08-29 19:04:18
Quote

- New Wasted-Bits-option to remove the least significant bits of the samples, if they are all zero.

I guess this is done automatically?

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.
Title: Yalac - Comparisons
Post by: pest on 2006-08-29 19:21:00
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.
Title: Yalac - Comparisons
Post by: TBeck on 2006-08-29 19:56:19
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.
Title: Yalac - Comparisons
Post by: Supacon on 2006-08-31 23:43:23
Thanks for the update TBeck.  I'm glad to hear that you're still working on things.
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-10 21:10:17
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.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-09-11 09:17:10
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?

- 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
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-11 18:02:27
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.
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-11 19:33:02
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.

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

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
Title: Yalac - Comparisons
Post by: MedO on 2006-09-11 19:52:56
I could not translate "nusiance"...


"Professional nuisance" würd ich in etwa mit "berufsmäßige Nervensäge" übersetzen . "nusiance" ist wahrscheinlich nur ein Tippfehler.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-09-11 22:51:12
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.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-09-14 20:25:22
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/ (http://synthetic-soul.co.uk/comparison/lossless/)

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

I'll analyse at a later date.
Title: Yalac - Comparisons
Post by: Madman2003 on 2006-09-14 21:41:50
Synthetic Soul: Considered adding flake to the test?
Title: Yalac - Comparisons
Post by: kanak on 2006-09-15 01:10:58
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/ (http://synthetic-soul.co.uk/comparison/lossless/)

Yalac 0.11 vs Yalac 0.10
http://synthetic-soul.co.uk/comparison/yalac/ (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?
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-09-15 01:34:14
I'm presuming you mean it compresses more, faster, and decodes faster too.
Title: Yalac - Comparisons
Post by: kanak on 2006-09-15 02:57:10
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?
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-09-15 05:38:10
Tom stated in another post that the actual final name was to be TAK.  We'll see, though.
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-15 13:19:47
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!
Title: Yalac - Comparisons
Post by: jido on 2006-09-15 13:37:50
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/ (http://synthetic-soul.co.uk/comparison/lossless/)

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

I'll analyse at a later date.

Nice results. The decoding speed (complexity) is specially impressive.
Title: Yalac - Comparisons
Post by: jarsonic on 2006-09-15 16:18:18
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?)
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-09-15 19:24:35
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.


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.
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-15 20:34:32
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
Title: Yalac - Comparisons
Post by: Cpt. Spandrel on 2006-09-16 05:43:46
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)
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-09-16 09:11:48
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=45013&view=findpost&p=431076) 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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=44229), and use settings that I think will be used in 1.1.3 following Josh's posts #77 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=44229&view=findpost&p=391582) and  #79 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=44229&view=findpost&p=391729) (-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.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-09-16 10:23:02
Yalac vs The Rest Of The World
http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

Yalac 0.11 vs Yalac 0.10
http://synthetic-soul.co.uk/comparison/yalac/ (http://synthetic-soul.co.uk/comparison/yalac/)
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.
I have now added High Max and Extra Max.  Extra Max provides an additional 0.087% compression - not a bad guess.
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-16 19:16:24
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/ (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?
Title: Yalac - Comparisons
Post by: jcoalson on 2006-09-17 01:39:47
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
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-17 02:34:13
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!

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.
Title: Yalac - Comparisons
Post by: SebastianG on 2006-09-17 13:31:51
"sh_2444" contains 5 files with 24 bit and 44 or 48 Khz.

And these are compressed to around 60% of the original file sizes?
Unbelievable!
Are the lower bits of the samples constant?
Is the audio signal very quiet?
Doesn't 24/44 usually compress to around 80%?
(taking typical recording levels into account)
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-17 14:52:55

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

And these are compressed to around 60% of the original file sizes?
Unbelievable!
Are the lower bits of the samples constant?
Is the audio signal very quiet?

The lower bits are not constant, but the amplitudes are quite small. For me it was a bit difficult to find files with 24 Bit and only 44 or 48 KHz. I am not to happy with such a small and possibly unusual set.

But i found it ok to post the results, because the comparison with FLAC should make it clear, that Yalac isn't doing wonders on such files. Possibly i will add some other compressors to the comparison.

Doesn't 24/44 usually compress to around 80%?
(taking typical recording levels into account)

As a rule of thumb i would say:

If music is sampled at 44/48 KHz, you can expect compressors similar to mine to remove about the same amount of bits from the same music sampled at 16 or 24 bit. If it can remove 8 bits, you will achieve 50 percent compression ratio for 16 bit and 67 percent for 24 bit files.

But this statement is based upon only a small selcetion of 24-Bit files, i may be wrong.

If someone knows a place to download some more 48K/24-bit samples of high quality (not sampled with a cheap and noisy soundcard), please let me know.

  Thomas
Title: Yalac - Comparisons
Post by: pest on 2006-09-17 15:06:40
Quote
If someone knows a place to download some more 48K/24-bit samples of high quality (not sampled with a cheap and noisy soundcard), please let me know.


this isn't very useful for your situation but i hope posting this link is still ok
it contains samples of different and non-standard wave-files...
perhaps this helps you improving the wave-reader.

http://www-mmsp.ece.mcgill.ca/Documents/Au...VE/Samples.html (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html)
Title: Yalac - Comparisons
Post by: SebastianG on 2006-09-17 15:18:44
As a rule of thumb i would say:

If music is sampled at 44/48 KHz, you can expect compressors similar to mine to remove about the same amount of bits from the same music sampled at 16 or 24 bit. If it can remove 8 bits, you will achieve 50 percent compression ratio for 16 bit and 67 percent for 24 bit files.

Yeah, this is what I had in mind (with the exception of my bad guesswork) since the LSBs are very unpredictable at higher resolution levels.

If someone knows a place to download some more 48K/24-bit samples of high quality (not sampled with a cheap and noisy soundcard), please let me know.

You could decode a high quality MP3 to 24 bits
Title: Yalac - Comparisons
Post by: madorangepanda on 2006-09-17 15:27:38
If someone knows a place to download some more 48K/24-bit samples of high quality (not sampled with a cheap and noisy soundcard), please let me know.

You may be able to find stuff at archive.org. Alot of it has been converted to 44.1khz and 16bit though
Archive.org 24bit Flacs (http://www.archive.org/search.php?query=%28format%3A%2824Bit%20FLAC%29%20OR%20%28flac24%29%20OR%20%2824-bit%29%20OR%2024bit%29%20AND%20collection%3Aetree) Some of these may be 48khz
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-17 16:28:46
this isn't very useful for your situation but i hope posting this link is still ok
it contains samples of different and non-standard wave-files...perhaps
this helps you improving the wave-reader.

http://www-mmsp.ece.mcgill.ca/Documents/Au...VE/Samples.html (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html)


You may be able to find stuff at archive.org. Alot of it has been converted to 44.1khz and 16bit though
Archive.org 24bit Flacs (http://www.archive.org/search.php?query=%28format%3A%2824Bit%20FLAC%29%20OR%20%28flac24%29%20OR%20%2824-bit%29%20OR%2024bit%29%20AND%20collection%3Aetree) Some of these may be 48khz

Thanks!


Here an update for my high resolution comparison with more participiants:

Yalac V0.11a  slightly improved over V0.11.
FLAC  1.1.2
MPEG4-Als RM17. Parameters: -7
Monkey's Audio 3.99. Mode: High
Optimfrog  4.600ex. Parameters: --mode high --optimize fast

I am only testing the compression modes, i am currently interested in.

Code: [Select]
          Yalac V0.11a                                    |  FLAC  | Monkey | Mpeg4  | Ofr    |
          Turbo  Fast   Light  Normal High   Extra  Insane|  -8    |  High  |  -7    | High   |
----------------------------------------------------------+--------+--------+--------+--------+
sh_2444                                                   |        |        |        |        |
Ratio:    58.53  58.23  57.98  57.87  57.76  57.64  57.57 |  60.28 |  57.77 |  57.45 |  57.64 |
EncoTime:  6.33   8.48  10.88  15.05  19.65  27.70  86.32 |  96.54 |  20.96 | 877.74 |  63.29 |
----------------------------------------------------------+--------+--------+--------+--------+
sh_2496                                                   |        |        |        |        |
Ratio:    54.58  54.33  54.21  54.18  53.84  53.79  53.76 |  57.92 |  53.88 |  53.65 |  53.50 |
EncoTime: 12.66  17.34  22.04  29.22  38.18  48.59 107.73 | 184.58 |  40.78 |2458.40 | 121.57 |
----------------------------------------------------------+--------+--------+--------+--------+
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-21 04:41:05
Current progress (V0.12)

I hope i am not boaring you with my reports. It's just some kind of a reward for me to post about some progress after many lonely hours of work.

Done:

- Another final reconfiguration of the presets. Turbo achieves now about 0.1 percent better compression at the same speed. Some tiny improvements of some other presets.
- Removed evaluation level Extra, because it was too irritating to have so many options. Only evaluation level Max has been kept and it is significantly faster than before. Simple to use: Specify for instance -p0 for preset 0 (Turbo) with standard evaluation, add 'm' for max evaluation: -p0m
- Optimized encoder for lower sampling rates from 8 to 32 KHz. Verified it's function.

To do (for V0.12):

- Add seek table. Might decrease compression by about 0.02 percent.

Probably not too exiting news. Just some steps further on my way to a public release.

BTW: How important is 8-Bit support? I will implement it sooner or later, but is it really needed for a first release? The tuning would take some time.

  Thomas
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-09-21 05:30:32
8-bit is not important, IMO.  I have yet to see a sample on a computer capable of running TAK that would use 8-bit files, anyways.
Title: Yalac - Comparisons
Post by: Gnerma on 2006-09-21 06:20:48
I hope i am not boaring you with my reports. It's just some kind of a reward for me to post about some progress after many lonely hours of work.

This certainly isn't the case for me and I'm sure many others like me who are very interested in what you're up to but might not be actively participating in the thread  In fact many coders could learn a thing or two from you about running a useful, open dialogue about what they have in development.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-09-24 10:48:40
I have added FLAC 1.1.2_CVS, Flake SVN Rev.42 and WavPack 4.4a3 to my comparison.

The settings are not part of the core encoder set, so to view them you need to append "All=1" to the URL, i.e.:

http://www.synthetic-soul.co.uk/comparison...sp?All=1 (http://www.synthetic-soul.co.uk/comparison/lossless/index.asp?All=1)

IMHO the table is just too busy to easily make deductions.  If I can get some time I may add a hack to limit the output to certain settings.

Until then, you may do better to download the table in CSV, open in Excel, cut out the rows that don't interest you and use "Data" > "Sort" to sort the table to your liking.
Title: Yalac - Comparisons
Post by: Destroid on 2006-09-24 21:15:37
Yalac TURBO & TURBO extra :drool: Fastest encoding speeds and great size reduction

Thanks for multiple sorting ability of your table.
Title: Yalac - Comparisons
Post by: pest on 2006-09-27 12:16:20
@TBeck

i have read that you cascade different predictors (up to 5 if i remember correctly).
do you use a special weighting between the different stages (such as a sign-sign lms filter)?

edit: spelling as always
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-27 13:16:21
i have read that you cascade different predictors (up to 5 if i remember correctly).
do you use a special weighting between the different stages (such as a sign-sign lms filter)?

Sorry, i can't remember to have said something about 5 predictors.

Do you mean this statement: "...Possibly it works better if only one Lpc-Filter is beeing used. But yalac currently sends the signal through up to 4 different filters...."?

The signal may go through up to 4 filters:

1) Initial filtering
2) PreFilter (optional)
3) Channel decorrelation (optional)
4) Linear prediction

Each next filter is working on the output of the previous one. They are not working in parallel. No output of different filters is beeing weighted and summed up and there is no feedback from the output of later filters to the input of earlier filters.

I would expect an weighting approach of different parallel filters to be most efficient, if it is adapting very fast to changes of the signal characteristics. Because it isn't efficient to store the updated filter parameters and weights too frequently into the bit stream, you would have to perform the adaption on the encoder and decoder side to avoid the need to store the parameters.

But i don't want the decoder to perform any (continous) adaption, because 1) it would be slower and 2) i suppose, that it is far more probable to run into patent issues witch such adaptive approaches. Hence abolutely no adaption in the decoder and only a block (subframe) based adaption in the encoder.
Title: Yalac - Comparisons
Post by: pest on 2006-09-27 14:55:01
Quote
Do you mean this statement: "...Possibly it works better if only one Lpc-Filter is beeing used. But yalac currently sends the signal through up to 4 different filters...."?


yeah, i thought about predictors when you mean different filters, and next time i read more careful!

Quote
The signal may go through up to 4 filters:

1) Initial filtering
2) PreFilter (optional)
3) Channel decorrelation (optional)
4) Linear prediction


ok, then a cascaded weighting is not really useful if you only do one stage of linear prediction


Quote
I would expect an weighting approach of different parallel filters to be most efficient, if it is adapting very fast to changes of the signal characteristics. Because it isn't efficient to store the updated filter parameters and weights too frequently into the bit stream, you would have to perform the adaption on the encoder and decoder side to avoid the need to store the parameters.


i think that the weighting of a cascade is better because it's more stable against sudden changes
in signal characteristics. you can look at a cascade as some sort of parallel filters too

  P0 = predictor of the first stage
  P1 = predictor of the next stage

  PW = weight0 * P0 + weight1 * P1 // weight the cascade
or
  PW = weight0 * P0 + weight1 * (P0+P1) // weight them paralell

Quote
But i don't want the decoder to perform any (continous) adaption, because 1) it would be slower and 2) i suppose, that it is far more probable to run into patent issues witch such adaptive approaches. Hence abolutely no adaption in the decoder and only a block (subframe) based adaption in the encoder.


the algorithm i mentioned is extreme simple. it's used in MP4ALS btw.
here's some C pseudo code

Code: [Select]
weight0 = weight1 = weight2 = init_weight

for (i=0;i<NumSamples;i++)
{
  P0 = first stage predictor
  P1 = second stage predictor
  P2 = third stage predictor

  PW = (weight0 * P0 + weight1 * P1 + weight2 * P2) >> Shift

  Error = Input - PW

  if (Error > 0)
  {
    (P0<0)?weight0--:weight0++;
    (P1<0)?weight1--:weight1++;
    (P2<0)?weight2--:weight2++;
  } else if (Error < 0)
  {
    (P0<0)?weight0++:weight0--;
    (P1<0)?weight1++:weight1--;
    (P2<0)?weight2++:weight2--;
  }
}
Title: Yalac - Comparisons
Post by: SebastianG on 2006-09-27 14:59:02
1) Initial filtering
2) PreFilter (optional)
3) Channel decorrelation (optional)
4) Linear prediction
Each next filter is working on the output of the previous one.

And with what precision do you work here? Are the samples quantized to the original precision after each stage? If yes: Have you thought about that the quantization noise adds up and is likely to decrease compression performance?

Hence abolutely no adaption in the decoder and only a block (subframe) based adaption in the encoder.

I assume you're talking about forward-adaptive versus backward-adaptive prediction and that you're using a pure forward-adaptive scheme. Correct?
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-27 15:20:44
i think that the weighting of a cascade is better because it's more stable against sudden changes
in signal characteristics. ...

Surely.

Possibly the best approach would be: Use this backwards adaption, but also check against a forward predictor and use it, if the backwards predictor fails because of a too fast change of the signal:

  (backwards prediction error) > (forwards prediction error + size of forwards predictor coefficients)

To have the best from both worlds...

I know, that the lack of fast adaption sometimes makes Yalac perform worse than the compressors with backwards adaption. But i wanted to know, what can be achieved with forwards prediction (without continouus adaption) only. And not to forget about my preference for speed and my worryness about patent troubles.

Possibly i will work on another (adaptive) encoder if the current encoder has been released...


the algorithm i mentioned is extreme simple. it's used in MP4ALS btw.

Thanks. I allready looked at it.



And with what precision do you work here? Are the samples quantized to the original precision after each stage? If yes: Have you thought about that the quantization noise adds up and is likely to decrease compression performance?

I'm always using 14 bits. I could increase it to 15 bits, but this would make the encoder slower and would only give less than 0.05 percent better compression.

The output of each filter has the original precision. If necessary it is again beeing scaled down to 14 bits before sending it to the next filter.


Hence abolutely no adaption in the decoder and only a block (subframe) based adaption in the encoder.

I assume you're talking about forward-adaptive versus backward-adaptive prediction and that you're using a pure forward-adaptive scheme. Correct?

Exactly.
Title: Yalac - Comparisons
Post by: pest on 2006-09-27 15:26:12
Quote from: TBeck link=msg=0 date=
Possibly i will work on another (adaptive) encoder if the current encoder has been released...


that's nice to know. i've hacked something together in 1month and it's on par with Monkey's Audio
compression wise. perhaps you use something of my ideas in your future codec or
integrate adaptive predictors into yalac for people who only want to archive their music.
Title: Yalac - Comparisons
Post by: SebastianG on 2006-09-27 15:27:27
the algorithm i mentioned is extreme simple. it's used in MP4ALS btw.
here's some C pseudo code

That's news to me. I havn't found any informations on the net regarding ALS doing backward-adaptive prediction. From what I know it's strictly forward-adaptive and nonlinear quantized parcor coefficients are transmitted per subblock. At least this was the case a year ago (http://www.nue.tu-berlin.de/publications/papers/AES118Liebchen.pdf). 
Quote from: Tilman Liebchen link=msg=0 date=
The MPEG-4 ALS codec uses forward-adaptive Linear
Predictive Coding (LPC) to reduce bit rates compared
to PCM, leaving the optimization entirely to
the encoder.


Cheers!
Title: Yalac - Comparisons
Post by: pest on 2006-09-27 15:31:26
Quote from: SebastianG link=msg=0 date=
That's news to me. I havn't found any informations on the net regarding ALS doing backward-adaptive prediction. From what I know it's strictly forward-adaptive and nonlinear quantized parcor coefficients are transmitted per subblock. At least this was the case a year ago (http://www.nue.tu-berlin.de/publications/papers/AES118Liebchen.pdf). 

Cheers!


You're right the paper is only about forward-adaptive prediction but the -z modes are using
a cascade of dpcm, rls and lms filters.
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-27 16:27:51
that's nice to know. i've hacked something together in 1month and it's on par with Monkey's Audio
compression wise.
...

You shouldn't tell me this! It's cruel!  I have spend years to be on par with at least Monkey High!
Title: Yalac - Comparisons
Post by: pest on 2006-09-27 16:49:51
Quote from: TBeck link=msg=0 date=
You shouldn't tell me this! It's cruel!  I have spend years to be on par with at least Monkey High!


that was not my intention. that you've archived such a high compression ratio with a foward-only predictor is really awesome.
and since i'm working in the field of compression for about 10 years i'm able to code very fast 
but as always i'm too shy to publish something...
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-09-27 17:49:08
Quote from: TBeck link=msg=0 date=

You shouldn't tell me this! It's cruel!  I have spend years to be on par with at least Monkey High!


that was not my intention. that you've archived such a high compression ratio with a foward-only predictor is really awesome.
and since i'm working in the field of compression for about 10 years i'm able to code very fast 
but as always i'm too shy to publish something...

It's funny that we discover the best members / developpers only after like.. 10 years of lurking
Title: Yalac - Comparisons
Post by: TBeck on 2006-09-27 23:58:25
Quote from: TBeck link=msg=0 date=

You shouldn't tell me this! It's cruel!  I have spend years to be on par with at least Monkey High!


that was not my intention. that you've archived such a high compression ratio with a foward-only predictor is really awesome.

Thanks. And i know that it's a lot easier with backwards prediction.

But sometimes i am asking myself, if my choice (forward prediction) has been wrong... But that's ok, the same would happen now and then, if i had used backward prediction...

but as always i'm too shy to publish something...

Someone should push you a bit.
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-01 18:02:39
V0.12 is done

(but still needs some testing performed by myself)

Names:

Yalac is now beeing called TAK! And that's also the file extension: ".tak'.

Encoder:

- Speed up of some common functions.
- Removed frame partition resolution 256, which had been reintroduced in V0.11 for evaluation purposes. It wasn't able to achieve at least 0.05 percent better compression, which is my criterion for the inclusion of (very) slow encoder options.
- Removed frame partition resolution 32, beacuse 64 is now nearly as fast.
- Removed frame partition search level normal, because it was quite useless. Now fast is the default, old high can be selected by checking the option "Validate".

Presets:

(I call this the really, really, really... final configuration!)

- TURBO is using frame partition resolution 64 instead of 32 and a frame duration of 94 instead of 102 ms. Should compress up to 0.1 percent better without a significant speed penality.
- FAST is using a frame duration of 125 instead of 102 ms. Should compress up to 0.05 percent better without a significant speed penality.
- NORMAL activates channel decorrelation method Mid-Side, which is very useful for some files. Possible slowdown of about 5 percent.
- EXTRA is using PreFilter sensitivity medium instead of high. Shouldn't compress worse but decode a bit faster.
- Removed evaluation level EXTRA to avoid confusion caused by too many options. Only evaluation level MAX has been kept. On the command line you may append 'm' to activate it: -p1m for preset FAST with evaluation MAX (old syntax was -p12).

Functionality:

- It's now possible to copy the original wave file header and other non-audio information located at the end of the wave file into the compressed file. It can be restored by the decompressor to get a file which is totally bit identical to the source (not only regarding the audio data, which is always identical). Currently the size of the non-audio data is limited to 1 MByte (The file format itself supports up to 16 MByte).

File format:

- Added meta data container.
- Added seek table for fast random access to audio positions. Select a seek point distance from 2, 1 (default) or 0.5 seconds or set one for each frame. Because of a very compact representation you will not loose more than 0.02 percent compression with the highest setting (a seek point for each frame) when compressing CD-Audio. Support for user defined seek positions (markers, possibly text labeled) to save specific positions of interest will be implemented later.
- Added a new frame header type "Seek info frame", which can be optionally inserted into the file to improve seeking on playback devices, which can not use the seek table. Otherwise they have to use the "Format info frames", which by default are beeing inserted only every 2 seconds. Because "Format info frames" are considerably bigger than the new "Seek info frames", the latter should be used for this purpose.
- Switched to stronger checksums (CRC's) for some sensitive data.

Release:

I hope to send the new version to the following testers within the next 3 days (this time i may need a bit more time to verify the program function, because there are so many modifications of the file format):

Destroid (welcome back!)
Josef Pohm
Robby (new tester)
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.11: Speed and compression performance of the presets. Probably no big surprises here, but nevertheless interesting, because V0.12 should show the same performance as the later first public release.
- Try the new option -wx ("wave extra data") to save and restore non-audio data from the original wave file.
- Not urgent: Possibly perform another damage test. V0.12 may loose a bit more data than V0.11, if the first frame has been damaged, because my error handling code needs some more adaptions to the new file format.

Plans for V 0.13:

- You should be able to cancel encoding and decoding.
- Option to control the overwriting of existing files.
- Possibly better command line interface (more and clearer options).
- Remove bugs in the handling of the new file format. I'm quite sure, that you will find some in V0.12...
- Better (there is nearly none...) handling of file io errors.

  Thomas
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-10-01 18:28:34
V0.12 is done
I have only one thing I can say : WICKED
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-01 18:47:24
Quote
' date='Oct 1 2006, 19:28' post='436819']
V0.12 is done
I have only one thing I can say : WICKED

Huh...

Why? Sorry, if i should have missed something.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-01 18:52:52
"Wicked" means "superb".

Werd dawg.

Edit: Thomas, you should probably add http://www.urbandictionary.com/ (http://www.urbandictionary.com/) to your list of translators.

Urban Dictionary's definition of Wicked (http://www.urbandictionary.com/define.php?term=wicked).
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-01 18:59:01
"Wicked" means "superb".

Werd dawg.

Shame on google translation (or my inability to use it right...)! It said "gemein" (vulgarity, meanness).

Thanks

  Thomas
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-01 19:02:53
The English word "wicked" does mean evil, mischievous or morally bad, but as slang it means something is cool, excellent, or fantastic.

http://dictionary.reference.com/browse/wicked (http://dictionary.reference.com/browse/wicked)

http://www.urbandictionary.com/define.php?term=wicked (http://www.urbandictionary.com/define.php?term=wicked)
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-04 10:29:26
Code: [Select]
TAKC -mode infile [outfile] [-px -wx -lx -w -overwrite -cx]

-mode      -e encode, -d decode, -t test decode, -te test encode
infile     specify file or directory (Dir\*) to be processed
outfile    specify output file or directory (Dir\*)
-px        select encoder preset x
             T/F/L/N/H/E or 0-5 for Turbo/Fast/Light/Normal(default)/High/Extra
             Append M to increase the evaluation level to the Maximum:
               -p0m = Preset 0 with evaluation level Max
               -p0s = Preset 0 with evaluation level Standard = -p0 (default)
-wx        save (encoding)/restore(decoding) non-audio wave file data
-lx        select log file level x
             0 = no log file (default)
             1 = log compression results
             2 = log compression results and encoder diagnostics
-w         wait for enter key when finished
-overwrite overwrite existing wave files when decoding
-cx        test case x

A couple of suggestions (feel free to ignore):
I should be posting my results for the normal compression stats this evening (in 10 hours or so).

Do you (or anyone else) have any suggestions how to get additional data into a WAVE file?  I have no experience with RIFF chunks.
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-04 11:08:14
A couple of suggestions (feel free to ignore):

Never! Thanks.

It's funny: After the release i played a bit with TAK and stumbled exactly over those issues!

WARNING: Slightly anal.  It is slightly confusing to use -px, -wx, -cx and -lx where the 'x' in -px. -cx and -lx means a variable, but in -wx it does not.  It may be better to use a format like -pX, -p<X>, -p?, or -p#.

I would like p<X> or -p#. Possibly -p# is better, because <X> could be misunderstood as optional parameter.

BTW: What's a good way to specify enabled/disabled? Is 0/1 ok: -wx0 or -wx1?
I would be tempted to include and extract additional WAVE data by default, and provide the option to exclude from compression, and perhaps from decompression (although if they have been encoded they are most likely required).  TAK is a lossless compressor, and users may not understand why data has been lost during the compression/decompression process.  WavPack includes by default (with the option to ignore) IIRC, and FLAC excludes by default (with no option to include) IIRC.  I seem to remember FLAC's stance confusing some people.  I say, save yourself the bother.  Maybe there is a good reason to remove this data?  I assume WAVE files created by EAC or fooabr for example would not contain additional RIFF chunks?

Yes, it should be always turned on by default!  It's most important purpose is to avoid irritation of newbies in lossless compression, who would doubt, that TAK is really lossless, if the decompressed file is a bit different.

Possibly i disabled it, because i am not sure yet, if it always works...

And you sometimes will have to disable it, if you want to decode a severely damaged file.

I should be posting my results for the normal compression stats this evening (in 10 hours or so).

Great!
Do you (or anyone else) have any suggestions how to get additional data into a WAVE file?  I have no experience with RIFF chunks.

Some audio editors have an option to include meta data, that's at least true for the good old CoolEdit.
Title: Yalac - Comparisons
Post by: Emanuel on 2006-10-04 12:31:51

Do you (or anyone else) have any suggestions how to get additional data into a WAVE file?  I have no experience with RIFF chunks.

Some audio editors have an option to include meta data, that's at least true for the good old CoolEdit.

The same goes for at least Wavelab, Soundforge, Audition (former Cooledit Pro) and Samplitude.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-04 12:41:15
I would like p<X> or -p#. Possibly -p# is better, because <X> could be misunderstood as optional parameter.

BTW: What's a good way to specify enabled/disabled? Is 0/1 ok: -wx0 or -wx1?
Yeah, -p# looks good.

Personally, I would suggest that -wx is enabled, and no switch is disabled, e.g.:

TAKC.EXE -e -wx file.wav <- Enabled, ignore extra data

TAKC.EXE -e file.wav <- Disabled, include extra data

If you use -wx0 and -wx1 one of them needs to be the default (let's say -wx0).  If that is the case you don't really need it, leaving you with only one (-wx1) that makes a difference.  In that case -wx1 may as well just be -wx... IM(not so)HO.

And you sometimes will have to disable it, if you want to decode a severely damaged file.
Ah, very good point.

Some audio editors have an option to include meta data, that's at least true for the good old CoolEdit.
OK, thanks.  I'll take a look at Goldwave and Audacity (the two I have) for now.

The same goes for at least Wavelab, Soundforge, Audition (former Cooledit Pro) and Samplitude.
Thanks for the info.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-04 19:13:32
TAK vs The Rest of The World
http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

TAK vs Yalac
http://synthetic-soul.co.uk/comparison/tak/ (http://synthetic-soul.co.uk/comparison/tak/)
Title: Yalac - Comparisons
Post by: Shade[ST] on 2006-10-04 19:20:26
TAK vs The Rest of The World
http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

TAK vs Yalac
http://synthetic-soul.co.uk/comparison/tak/ (http://synthetic-soul.co.uk/comparison/tak/)

TAK Turbo compresses more than Flac-8...
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-04 20:05:04
TAK vs The Rest of The World
http://synthetic-soul.co.uk/comparison/lossless/ (http://synthetic-soul.co.uk/comparison/lossless/)

TAK vs Yalac
http://synthetic-soul.co.uk/comparison/tak/ (http://synthetic-soul.co.uk/comparison/tak/)

Thanks!

Short analysis:

- As expected no big surprises.
- Not as much improvement for TURBO and NORMAL as on my file sets, but also no significant speed penality.
- I find the comparison less confusing (too many options/presets) after the removal of evaluation level EXTRA. And on your system evaluation MAX is only 2 times slower than evaluation STANDARD (Default), hence no big gap that had to be filled by another evaluation level.

For me this final preset configuration looks well balanced.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-04 20:07:33
For this corpus it out-performs Flake -12 and FLAC 1.1.2_CVS as well.

Code: [Select]
                                     Encode          Decode
Encoder Setting    Compression    CPU+IO   CPU    CPU+IO   CPU
==============================================================
TAK Turbo              64.890%       76x  103x       79x  113x
Flake -12 -v 1         65.259%        7x    7x       70x   84x
Flake -12              65.368%        7x    7x       69x   83x
FLAC 1.1.2_CVS -9      65.528%        6x    6x       71x   92x


- As expected no big surprises.
- Not as much improvement for TURBO and NORMAL as on my file sets, but also no significant speed penality.
- I find the comparison less confusing (too many options/presets) after the removal of evaluation level EXTRA. And on your system evaluation MAX is only 2 times slower than evaluation STANDARD (Default), hence no big gap that had to be filled by another evaluation level.

For me this final preset configuration looks well balanced.
I agree, it's all looking very balanced, and quite easy to judge a preset of choice.
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-05 16:44:51
I have made some small tests using the -wx switch, which stores and retrieves meta data.

I created two 30s wave files, "sine.wav" and "noise.wav", using Audacity's "Generate" functions.  I then used Goldwave to add various meta data to the files (view dialogue (http://www.synthetic-soul.co.uk/temp/goldwave-meta-data.gif)).

I encoded the files using all presets with the -wx switch.  I then decoded them all using the -wx switch, and, as usual with my scripts, I compared the MD5 of the decoded file with that of the source.  In all cases they matched.

I then dragged some of the decoded files into Goldwave to check that the meta data could be viewed, which it could.

Finally, I decoded some files without using the -wx switch, dragged those into Goldwave and confirmed that the meta data was missing.

So, in conclusion, it all worked as expected.

Looking at a file in a hex editor the meta data has been stored at the end of the file, and is using chunk IDs as per this document (http://www.matroska.org/technical/specs/tagging/othertagsystems/riffmcispecs.html).
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-05 18:04:12
...
I encoded the files using all presets with the -wx switch.  I then decoded them all using the -wx switch, and, as usual with my scripts, I compared the MD5 of the decoded file with that of the source.  In all cases they matched.

I then dragged some of the decoded files into Goldwave to check that the meta data could be viewed, which it could.

Finally, I decoded some files without using the -wx switch, dragged those into Goldwave and confirmed that the meta data was missing.

So, in conclusion, it all worked as expected.
...

What a work! Thanks so much!

Looking at a file in a hex editor the meta data has been stored at the end of the file, and is using chunk IDs as per this document (http://www.matroska.org/technical/specs/tagging/othertagsystems/riffmcispecs.html).

Fine! I must admit, that i never tried it with metadata located at the end.

And to be honest: I am still using my absolutely minimalistic wave parser. With -wx it simply looks for the first audio data chunk and handles anything else as black box and simply copies it into the appropriate meta data structure.

That's also the reason, why you may have to remove the -wx switch when decoding damaged files: If some frames at the end of the file are missing, TAK has to update the audio data size in the wave file header. But because the header generated with -wx is only a black box for TAK, it does not know how to do this right.

Something more problematic: I am not sure, but i think, that it is possible to create a wave file with more than one audio data chunk. Currently TAK would simply drop any audio data behind the first chunk! Very bad, but i never have seen a file witch such a structure.

You may notice, that i don't know really much about the wave file format...
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-28 01:21:11
V0.13 is done

(but still needs some testing performed by myself)

Encoder:

- Support for any sample rate from 8000 to 96000 Hz.
- Support for 8-Bit samples. Not too important, but TAK should be quite efficient here.

Presets:

I call this the really, really, really, really... final configuration! You may have noticed, that i have appended a fourth (only 3 in V0.12) "really". You may read it as final preset configuration V4...

- Preset LIGHT is gone!
- Preset NORMAL is basically preset LIGHT of V0.12, but with channel decorrelation option 'Check both' enabled and 'Partitition resolution' increased to 128. Encoding speeed should be closer to old LIGHT than old NORMAL.
- EXTRA enables 'Bitcoder/Optimize choice' and encodes a bit slower. Tiny compression increase of about 0.05 percent.

How comes? I found the compression difference between FAST/LIGHT, LIGHT/NORMAL and NORMAL/HIGH too small and wanted a faster default preset (NORMAL). Encoding speed resolution is nevertheless quite good: On my system NORMAL is about 1.6 times slower than FAST and HIGH about 1.7 times slower than NORMAL. Same ratio for EXTRA vs. HIGH.

Functionality:

- GUI version supports an user defined output directory.
- Overwrite option for encoding and decoding.
- More and better error messages and warnings for screen and log file protocol.
- Summary of errors and warnings at the end of the protocol.
- Better error handling: The program should only be aborted, if a file io error occurs (i am working on this too).
- Warning, if the meta data of a wave file is too big to be stored into the TAK file.
- Added log file generation for decoding.
- Possibility to abort encoding/decoding.
- Saving and restoring of non-audio- (Meta-) wave file data is now enabled by default.

Not too many news here but nevertheless much work. I had to rewrite considerable parts of my code to improve the error handling and to prepare a later translation to C (I had been using exceptions for the error handling, which are not beeing supported by standard C).

File format:

- Meta data stores the preset used for compression.
- Removed any configuration option for the stream format: Seek point interval, info-frame-interval and seek-frame-interval.
- Seekpoint interval is now fixed to 1 second. Needs very little space and allows for very fast seeking.
- Info-Frame interval is now fixed to 2 seconds. It's only important for the start up latency when linking to a running stream.
- Now every frame is a Seek-Frame. Allows for fast seeking even if the decoder can't use the seek table. Compression penality ranging from 0.03 percent for TURBO and 0.01 percent for EXTRA.
- Many corrections of the stream format. Hope it's still working...

Command line:

- Now files have to be specified as last parameters on the command line.
- By default, log files are no longer beeing appended to existing ones. You have to append an 'A' to the log file option (-L1A) to enable the appending.
- You can specify most of the encoder options available in the GUI version on the command line to overwrite the default settings of the selected preset.
- Option to control saving and restoring of non-audio- (Meta-) wave file data is now -wm (wave file meta data) instead of -wx.

Release:

I hope to send the new version to the following testers within the next 2 days (this time i may need a bit more time to verify the program function, because there are so many modifications of the file format):

Destroid
JohanDeBock
Josef Pohm
Robby
Synthetic Soul

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.12: Performance of new NORMAL.
- Verify, that the decoded files match the original. Too many changes to be sure, that everything is still ok...
- Is the GUI ok? Is there any essential option missing?
- Is the command line interface ok?
- After the implementation of the abort option (ESCape key) for the command line, the program sometimes paused without any reason. A keypress was necessary to continue. This only happened, when i started the program from my development framework. Possibly this has only been caused by the debugger, but please tell me, if you should have similar trouble.

Plans for V 0.14:

- Possibly some final modifications of the encoder data stream. Should not affect the performance.
- Final examination of the container format to be sure, that i haven't forgot something.
- Bug fixes.

Well, this should be the last announcement of a new version in this thread. For 0.14 i will open a new thread "TAK - Preparing the public release". Then (!!!) i will ask for 5 to 10 new testers who want to try TAK for real work.

I would be happy to release TAK in early december. Unfortunately i will not have much time to work on TAK within the next four weeks. But i will do my very best!

  Thomas
Title: Yalac - Comparisons
Post by: foxyshadis on 2006-10-28 08:40:13
BTW, a lot of GNU projects use a syntax like +wx to mean disabled (opposite of -wx, kind of). Alternately a named switch like -wx-off.

I haven't followed this since June, the recent results are quite stunning. =o
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-28 16:59:58
V0.13 is done

And on the way.

- After the implementation of the abort option (ESCape key) for the command line, the program sometimes paused without any reason. A keypress was necessary to continue. This only happened, when i started the program from my development framework. Possibly this has only been caused by the debugger, but please tell me, if you should have similar trouble.

Unfortunately i had to remove this option. It also happened without my debugger running in the background. The module i am using for console input is the only source code in Tak, that i have not written by myself. Therefore it will be a bit more difficult to find the bug. But this option anyhow seems not too important for me.

Possibly i am having trouble sending Mails. And sometimes they are beeing caught by spam filters...

Be assured, that until now i have answered any mail regarding TAK.

  Thomas
Title: Yalac - Comparisons
Post by: Synthetic Soul on 2006-10-29 20:32:35
TAK vs The Rest of The World
http://www.synthetic-soul.co.uk/comparison/lossless/ (http://www.synthetic-soul.co.uk/comparison/lossless/)

TAK 0.12 vs TAK 0.13
http://www.synthetic-soul.co.uk/comparison/tak/ (http://www.synthetic-soul.co.uk/comparison/tak/)
Title: Yalac - Comparisons
Post by: TBeck on 2006-10-29 20:47:59
TAK vs The Rest of The World
http://www.synthetic-soul.co.uk/comparison/lossless/ (http://www.synthetic-soul.co.uk/comparison/lossless/)

TAK 0.12 vs TAK 0.13
http://www.synthetic-soul.co.uk/comparison/tak/ (http://www.synthetic-soul.co.uk/comparison/tak/)

Thanks. That was very fast!

Comments:

- As expected we see a compression penality of 0.01 to 0.03 percent caused by the extensions of the streaming format.
- I like the new NORMAL preset. It's faster than the old one, the compression difference to FAST and HIGH is bigger and the encoding speed ratio compared to FAST/HIGH is about 1.5.

Fine.
Title: Yalac - Comparisons
Post by: Destroid on 2006-11-02 04:20:25
Code: [Select]
(Compilation -- hard rock) 69:24   19 files   734,536,700 bytes
===============================================================
name/params Ratio EncTime/CPU% DecTime/CPU%
--------------------- ------ ------------ ------------
TAK 0.12 -p0 70.87% 83.83x / 58% 79.96x / 56% *
TAK 0.13 -p0 70.90% 79.57x / 56% 79.57x / 53% *
MAC 4.01 beta2 -c1000 71.48% 48.92x / 73% 52.10x / 88%
WavPack 4.4a2 -f 73.29% 63.98x / 55% 72.52x / 53%
FLAC 1.1.3b1 --fast 77.58% 52.64x / 43% 68.46x / 45%
OFR 4.520 --mode fast 70.73% 22.95x / 82% 35.13x / 98%
--------------------- ------ ----------- -----------
TAK 0.12 -p1 70.36% 63.72x / 60% 77.25x / 57% *
TAK 0.13 -p1 70.39% 61.17x / 59% 78.18x / 54% *
MAC 4.01 beta2 -c2000 70.51% 46.93x / 94% 42.95x / 94%
WavPack 4.4a2 (default) 72.12% 57.17x / 60% 70.41x / 61%
FLAC 1.1.3b1 (default) 72.03% 45.79x / 68% 69.60x / 50%
OFR 4.520 (default) 69.78% 17.09x / 87% 25.08x / 99%
MP4ALS RM17 (default) 71.40% 27.02x / 85% 47.27x / 54%
LA 0.4 normal 68.66% 6.16x / 99% 7.60x / 99%
--------------------- ------ ----------- -----------
TAK 0.12 -p2 70.17% 51.67x / 66% 78.66x / 58% *
TAK 0.13 -p2 70.14% 51.87x / 77% 80.59x / 57% *
MAC 4.01 beta2 -c3000 69.74% 40.17x / 93% 38.58x / 95%
WavPack 4.4a2 -h 71.21% 46.44x / 64% 64.56x / 71%
OFR 4.520 --high 69.46% 11.72x / 91% 16.59x / 99%
MP4ALS RM17 -7 69.66% 1.30x / 99% 15.86x / 90%
LA 0.4 high 68.59% 4.56x / 99% 5.40x / 99%
--------------------- ------ ----------- -----------
TAK 0.12 -p3 70.04% 44.59x / 81% 74.92x / 57% *
TAK 0.13 -p3 69.77% 38.39x / 91% 75.01x / 66% *
MAC 4.01 beta2 -c4000 69.29% 23.08x / 98% 23.17x / 98%
WavPack 4.4a2 -h -x 70.99% 27.42x / 82% 57.55x / 63%
FLAC 1.1.3b1 --best 71.58% 11.72x / 99% 65.01x / 47%
OFR 4.520 --best 69.12% 4.87x / 96% 6.60x / 99%
TAK 0.12 -p4 69.75% 31.40x / 75% 68.53x / 62% *
TAK 0.13 -p4 69.70% 22.77x / 89% 67.04x / 60% *


* = Binary comparison OK (TAK tests only)


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

Edit: Re-ran 'TAK 0.13 -p3' test and updated results
Title: Yalac - Comparisons
Post by: jido on 2006-11-03 18:01:20
Nice results.

TAK is beaten for compression by some other codecs, but it has no rival when it comes to size/decode time ratio!

The TURBO and NORMAL presets look very good all-rounders in Soul's comparison.
Title: Yalac - Comparisons
Post by: kanak on 2006-11-03 18:31:54
Nice results.

TAK is beaten for compression by some other codecs, but it has no rival when it comes to size/decode time ratio!


This is exactly the reason i'm so excited by this codec. I can get compression on par with Monkey's audio AND a decoding speed on par with WavPack. Since i use my lossless as a transcoding source as well, this is very important. Can't wait for it to be released!
Title: Yalac - Comparisons
Post by: TBeck on 2006-11-04 11:02:27
Bug report 1 for V0.13

Destroid has sent me a mail with a bug report. Decoding of a big file (about 700 MB) gave the error "Meta data damaged". Nevertheless the audio data itself could be decoded without any errors.

It took some time to locate the error. There is a bug in my file io class (which i have been using for years without any trouble). It shows up when the class performs buffered reading and then has to jump to a file position outside of the buffer. This is likely to happen when reading the seek table and a file is longer than about 7 to 10 minutes.

Probably i will wait with a fix until the next version, because i anyhow want to replace my object oriented file io class with some function oriented code which would be easier to translate to standard C.

Thanks for the bug report!

  Thomas
Title: Yalac - Comparisons
Post by: TBeck on 2006-11-12 20:16:11
Squeeze Chart 2006

now contains results for TAK 0.13:

Lossless Data Compression Benchmarks (http://www.maximumcompression.com/benchmarks/benchmarks.php)

Many thanks to Stephan Busch!

  Thomas
Title: Yalac - Comparisons
Post by: quas on 2006-12-11 15:21:58
Thomas! It's been almost a month since the last update. Any news on 0.14? Are you still making progress?

I don't mean to rush you, but I am really anxious to try out TAK. Watching the development has been very exciting; hope things are going OK.

Cheers,
quas
Title: Yalac - Comparisons
Post by: TBeck on 2006-12-11 21:18:28
Thomas! It's been almost a month since the last update. Any news on 0.14? Are you still making progress?

I don't mean to rush you, but I am really anxious to try out TAK. Watching the development has been very exciting; hope things are going OK.

Hi quas,

thanks for asking and for the kind words!

I am working on TAK!

I wanted to release an Alpha version at the end of november, but unfortunately had not enough time. With some luck it could be done until next week.

Then i will ask for some additional testers and let them try it. If everything is ok, we will see a public beta in january.

  Thomas
Title: Yalac - Comparisons
Post by: quas on 2006-12-12 04:29:43
Great! Thanks for the update. Looking forward to trying it. :)