## Topic: Yalac - Comparisons (Read 149804 times)previous topic - next topic

0 Members and 1 Guest are viewing this topic.
• Synthetic Soul
• Global Moderator
Yalac - Comparisons
##### Reply #25 – 18 April, 2006, 01:49:51 PM
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
I'm on a horse.

Yalac - Comparisons
##### Reply #26 – 18 April, 2006, 02:13:39 PM
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

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

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

• Synthetic Soul
• Global Moderator
Yalac - Comparisons
##### Reply #27 – 18 April, 2006, 05:06:52 PM
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.
I'm on a horse.

Yalac - Comparisons
##### Reply #28 – 18 April, 2006, 05:30:56 PM
That second method is evaluating the compresser's algorithmic efficiency, more or less.

• audiofreak
Yalac - Comparisons
##### Reply #29 – 18 April, 2006, 07:43:36 PM
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

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`

Yalac - Comparisons
##### Reply #30 – 18 April, 2006, 08:19:00 PM
Good idea.  Now make it

• audiofreak
Yalac - Comparisons
##### Reply #31 – 18 April, 2006, 08:42:46 PM
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.

• Synthetic Soul
• Global Moderator
Yalac - Comparisons
##### Reply #32 – 19 April, 2006, 02:44:28 AM
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.
I'm on a horse.

• TBeck
• Developer
Yalac - Comparisons
##### Reply #33 – 23 April, 2006, 05:50:21 AM
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

• audiofreak
Yalac - Comparisons
##### Reply #34 – 23 April, 2006, 10:19:25 AM
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...

• TBeck
• Developer
Yalac - Comparisons
##### Reply #35 – 23 April, 2006, 09:43:35 PM
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.

Thomas

• Destroid
Yalac - Comparisons
##### Reply #36 – 24 April, 2006, 01:11:08 PM
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.09xYalac 0.04 fast		30.60%	213.64x	312.14xMAC 4.01 beta2 -c1000	33.14%	149.20x	116.94xFLAC 1.1.2 --fast	35.03%	270.69x	310.34xWavPack 4.3 -f		32.67%	242.46x	260.90xOFR 4.520 --mode fast	28.55%	 64.11x	 86.13x---------------------	------	------	------Yalac 0.04 normal	30.35%	111.24x	272.57xMAC 4.01 beta2 -c2000	31.78%	102.93x	 91.09xFLAC 1.1.2 (default)	32.92%	218.19x	320.06xWavPack 4.3 (default)	33.04%	201.69x	227.14xOFR 4.520 (default)	28.36%	 44.58x	 59.85xTTA 3.3 (default)	31.22% 211.15x	146.05x---------------------	------	------	------Yalac 0.04 high		30.13%	20.08x	289.26xMAC 4.01 beta2 -c3000	31.56%	89.50x	 80.36xFLAC 1.1.2 --best	32.97%	49.28x	324.29xWavPack 4.3 -h		31.79%	97.56x	109.10xOFR 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).
"Something bothering you, Mister Spock?"

• TBeck
• Developer
Yalac - Comparisons
##### Reply #37 – 25 April, 2006, 11:31:20 PM
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

• Synthetic Soul
• Global Moderator
Yalac - Comparisons
##### Reply #38 – 26 April, 2006, 05:01:33 AM
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.
I'm on a horse.

• TBeck
• Developer
Yalac - Comparisons
##### Reply #39 – 29 April, 2006, 06:18:48 AM
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
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

• guruboolez
• Members (Donating)
Yalac - Comparisons
##### Reply #40 – 29 April, 2006, 06:39:56 AM
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!

• Supacon
• Members (Donating)
Yalac - Comparisons
##### Reply #41 – 29 April, 2006, 01:41:27 PM
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)

• Destroid
Yalac - Comparisons
##### Reply #42 – 29 April, 2006, 05:29:47 PM
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
"Something bothering you, Mister Spock?"

• boombaard
Yalac - Comparisons
##### Reply #43 – 29 April, 2006, 05:58:35 PM
V0.05 is done
I hope to send the new version to the following testers within the next hours:

Destroid
guruboolez
Josef Pohm
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 )

• Destroid
Yalac - Comparisons
##### Reply #44 – 29 April, 2006, 10:07:14 PM
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.62xYalac 0.04 fast		77.34%	60.57x	63.34xYalac 0.05 fast		77.47%	46.80x	66.60xYalac 0.04 normal	77.20%	27.97x	64.48xYalac 0.05 normal	77.20%	26.58x	62.78xYalac 0.04 high		77.06%	 7.99x	68.93xYalac 0.05 high		77.02%	11.60x	64.31xYalac 0.04 insane	77.00%	 4.84x	63.10xYalac 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.60xMAC 4.01 beta2 -c1000	77.64%	62.01x	47.25xFLAC 1.1.2 --fast	84.91%	64.29x	56.95xWavPack 4.3 -f		80.49%	54.73x	56.56xOFR 4.520 --mode fast	77.04%	22.08x	34.80x---------------------	------	------	------Yalac 0.05 normal	77.20%	26.58x	62.78xMAC 4.01 beta2 -c2000	76.67%	47.93x	40.65xFLAC 1.1.2 (default)	78.61%	47.18x	60.89xTTA 3.3			77.77%	54.73x	57.00xWavPack 4.3 (default)	78.85%	55.74x	54.82xMP4ALS RM17 (default)	77.84%	28.95x	43.95xOFR 4.520 (default)	76.58%	16.44x	24.77xLA 0.4 normal		75.87%	 6.11x	 7.80x---------------------	------	------	------Yalac 0.05 high		77.02%	11.60x	64.31xMAC 4.01 beta2 -c3000	76.54%	41.87x	37.04xFLAC 1.1.2 --best	78.46%	11.75x	61.18xWavPack 4.3 -h		77.42%	42.20x	52.07xMP4ALS RM17 -7		76.98%	 1.40x	18.05xOFR 4.520 --mode high	76.57%	11.42x	16.50xLA 0.4 high		75.82%	 4.53x	 5.34x`
edit: clarification - RG scan, changes were not applied
"Something bothering you, Mister Spock?"

• TBeck
• Developer
Yalac - Comparisons
##### Reply #45 – 02 May, 2006, 08:07:19 AM
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.

• TBeck
• Developer
Yalac - Comparisons
##### Reply #46 – 02 May, 2006, 08:31:13 AM
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.

Yalac - Comparisons
##### Reply #47 – 02 May, 2006, 10:07:44 AM
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.

• TBeck
• Developer
Yalac - Comparisons
##### Reply #48 – 02 May, 2006, 10:38:14 AM
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...

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.

Yalac - Comparisons
##### Reply #49 – 02 May, 2006, 11:40:28 AM
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 encoderyalacc (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.