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.

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)

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.

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

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.

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.

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"?