Skip to main content

Notice

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


Yalac - Comparisons

Reply #27
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
That second method is evaluating the compresser's algorithmic efficiency, more or less.

Yalac - Comparisons

Reply #29
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
Good idea.  Now make it   

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

Reply #36
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).
"Something bothering you, Mister Spock?"

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

Reply #41
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)

Yalac - Comparisons

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

Yalac - Comparisons

Reply #43
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 )

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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

Yalac - Comparisons

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