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 - Need some testing (Read 77911 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Yalac - Need some testing

Reply #25 –
Wow TBeck... you seem to know what you are doing.  I don't think the world needs another lossless encoder all too badly, but it looks like you're on the right track to providing a better compression/decompression speed ratio than most other encoders out there; this is probably the most important criteria for me, so I'm certainly intrigued. I look forward to seeing what subsequent versions are capable of.

As for the name, before deciding on anything, you should check out http://www.filext.com/ for the extension that you propose to use.

YAA is safe for now.

Also, perhaps you're not quite there yet, but what do you propose to use for tagging?  And how would your codec compare to others in terms of features?  Seekable? Streamable? Support for multi-channel audio?  Support for widely varying sampling rates? (reference http://wiki.hydrogenaudio.org/index.php?ti...less_comparison for a comparison between other codecs)

Yalac - Need some testing

Reply #26 –
I think having many configurable options is key to having a widespread format.  Look at lame and vorbis encoders -- of course, they have simple presets (-V XX, or -Q XX), but you can always tune settings even more.  In the case of a lossless compressor, of course, this has less prevalence, but nevertheless, I think you should leave all parameters in, while making some only active if a debug switch is toggled.

Additionally, if you need help with documentation, I am fluent in french and english, and can read pascal and C++.

I might get you other samples tested soon.  I'll keep you posted,
Tristan.
----
Quote from: Supacon on
Also, perhaps you're not quite there yet, but what do you propose to use for tagging?  And how would your codec compare to others in terms of features?  Seekable? Streamable? Support for multi-channel audio?  Support for widely varying sampling rates? (reference http://wiki.hydrogenaudio.org/index.php?ti...less_comparison for a comparison between other codecs)

From the software readme :

As of yet, supported Formats: Only Wave, 16 Bits per Sample, Stereo, up to 48 KHz.
This limitation is due to my unfinished file-io-library. The compresor itself supports 8 - 28 Bit, 8 - 192 KHz.
---
Another point, also : I have a few ideas about codec implementation, that I'm not sure how you use.
Do you check for recurring patterns in the audio?  Do you compare channels and use M/S encoding (One of my samples was mono, but only compressed to 43%..)
I'm very interested in knowing how the codec works.

Yalac - Need some testing

Reply #27 –
Quote from: Supacon on
Also, perhaps you're not quite there yet, but what do you propose to use for tagging?  And how would your codec compare to others in terms of features?  Seekable? Streamable? Support for multi-channel audio?  Support for widely varying sampling rates? (reference http://wiki.hydrogenaudio.org/index.php?ti...less_comparison for a comparison between other codecs)


I am not totally sure, what i will do next (after the tests). But my actual preference would be:

1) Make a simple public release of the codec. It will not contain any sophisticated features besides (fast) seeking, error checking and possibly tagging. I think this would be the minimum features to make it a bit usable. Support for 8, 16, 24 bit and sampling rates up to 192 KHz is allreday implemented into the codec but not in my file io library.

2) Look for a good way to publish a paper about my codec design. I would like to get some reputation...

3) Optimize the public release and fix the bugs the users will report.

4) When everything seems quite stable (and i possibly had enough fun...), release the source code.

But things can change. My first post about my compressor (on April 1) was absolutely spontaneous. So i was in no way prepared.

  Thomas


Have some trouble with the forum software. Replies to other posts are beeing added to this one. Will better wait some time.

Yalac - Need some testing

Reply #28 –
A little testing done by gURuBoOleZZ on classical music (AMD Duron 800) :

Quote
655.45 (ALAC)  ENC/DEC Speed = ~x?/x35 (iTunes) or x20 (CLI decoder)
625.11 (flac 8)  ENC/DEC Speed = ~x4/x60
628.72 (WV -fx5)  ENC/DEC Speed = ~x2/x60
618.27 (WV -x4)  ENC/DEC Speed = ~x1/x40
617.47 (YALAC fast opt)  ENC/DEC Speed = ~x6/x38
616.05 (MAC -fast)  ENC/DEC Speed = ~X20/x20
614.25 (MPEG-4 default)  ENC/DEC Speed =    ?/?
603.20 (MAC -normal)  ENC/DEC Speed = ~x15/x15
603.14 (YALAC -normal opt) ENC/DEC Speed = ~x3.5/x34
598.56 (YALAC -high opt) ENC/DEC Speed = ~2.4/x31


Original post (in French) http://forum.hardware.fr/forum2.php?config...nojs=0#t1058206

Yalac - Need some testing

Reply #29 –
I promised a new version for the testers within 1 or 2 days. May take a bit longer.

Done:

1) Support for 24 Bit and samplingrates up to 96 KHz.

2) Encoder options dialog now gives access to far more options that were hidden behind the parameter determination mode settings.

To do:

3) Explaination of the new settings. I don't want "dumb" testers, who don't know what they are doing. Wouldn't be fair. Given my limited english skills, this will take some time.

4) Enabling of the protocol function, which writes internal encoder diagnostics and statistics to a text file.

  Thomas

Yalac - Need some testing

Reply #30 –
Where i can download?

Yalac - Need some testing

Reply #31 –
you can't yet.. i'm fairly sure it'll come soon (within weeks), though

anyway, Aquamarine makes for awkward abbreviations (AAC, anyone? ), but you could always call it something horribly presumptuous, like (for instance) Mozart's Choice?  (seeing how it's his birthyear )

Yalac - Need some testing

Reply #32 –
Evaluation Release 0.02 for the testers

New features of this second and probably last release for this test:

1) Support for 24 Bit and samplingrates up to 96 KHz.

2) Encoder options dialog now gives access to far more options that were hidden behind the parameter determination mode settings.

3) Switch to disable the use of MMX-Optimizations.

4) Switch to enable the protocol function, which writes internal encoder diagnostics and statistics to a text file.

5) Explaination of the new settings.

What i would like the testers to do

1) Repeat the test with your files with Normal and High-Presets and with the protocol function enabled. Send me the protocol files. You will have to save or rename the protocol file between runs, because each run overwrites the previous results.

Updated!!! Please read post "What i really would like the testers to do..."

2) Possibly check some 24 Bit files. Not to urgent.

There is no need to systematically test the new options! If you would like to play with them, feel free to do so. But i don't think, that these results should be listed in the final public result of this test, because there would be too many possible combinations and therefore huge unreadable result tables.

Main reason for the unlocking of the individual options are the strange results of one tester. I will ask him via EMail, to check some specific settings.

Some words about speed

I didn't do any optimization of the encoder or decoder, although i was very tempted to do. Nevertheless there will be changes of the speed results.

This is caused by some limitation of my compiler. For optimum performance, some parts of the code have to be aligned to memory adresses, which are an integer multiple of 16. But my compiler doesn't do this. So every time i change something –maybe the GUI- code is beeing moved around and speed varies within a range of about 5 – 10 %. This is totally random.

Close the test

After the new test runs i have asked for, we should bring this first reality check test to an end. We possibly should discuss the best way to publish the results here:

1) Every tester posts his results in his individual format.
2) I post them in some standard format and ask the testers for confirmation.

I think 1) would be ok.

My tester list

I will send the new version to any tester on my list within the next hours:

benski
boombaard
Destroid
guruboolez
Josef Pohm
Shade[ST]
Skymmer
Synthetic Soul

Please notify me, if i forgot one. There is a bit confusion between forum and email identies on my side. Sorry...

Again, many many thanks to the testers!

  Thomas

Yalac - Need some testing

Reply #33 –
Important note for the testers!

The encoder option 'Apply window' definitely hurts on some files! It is beeing automatically activated with the presets High and Insane. This regards to V0.01 and V0.02.

One tester reported files which compressed over 3 percent worse with this option activated! I could verify this on some test file, he sent me.

V0.02 allows disabling of this option. You should possibly disable it, especially when High or Insane are giving you worse results than Estimate.

I'm not sure, what goes wrong. Need some time for an analysis.

But it shows, how useful this evaluation test will be for the optimization of my encoder.

  Thomas

Yalac - Need some testing

Reply #34 –
Quote from: TBeck on
I'm not sure, what goes wrong. Need some time for an analysis.

But it shows, how useful this evaluation test will be for the optimization of my encoder.

  Thomas


Yeah, really useful!

Possibly some good news.

Here some results for the critical Test file:

Code: [Select]
Encoder options                     Ratio
NORMAL 128                          65.88
NORMAL 128 + Optimize Quantization  65.74
NORMAL 128 + Apply Window           68.68  !!!


But now something really interesting. I allready wrote about one inactive encoder option, which on my test corpus gives about 0.35 better compression. Let's see, how this baby performs on this critical file. General setting is NORMAL + Optimize Quantization.

Code: [Select]
Predictors    Without   With hidden option
128           65.74     64.27
256           63.90     62.40
384           62.79     61.44


Looks promising. 

Hard to predict, on how many files this will help, but this definitely should be evaluated.


  Thomas

Yalac - Need some testing

Reply #35 –
What i really would like the testers to do...

Sorry for another change!

But i didn't have enough time, to analyze enough incoming data early enough. This will be the last change.

It seems, as if the activation of the frame partition validator, which is part of HIGH and INSANE modes, not only gives a too small increase in compression efficiency in ralation to it's speed penality, but on average even hurts!

Hence i would like to redifine the Presets as follows:

Code: [Select]
FAST   = no change
NORMAL = no change
HIGH   = NORMAL + Optimize Quantization + 256 Predictors
INSANE = NORMAL + Optimize Quantization + 384 Predictors


If you would like to do some more tests, those should be the most interesting settings.

Again sorry. I have to do to many things simultaneously. And i didn't expect so many results so different to my test corpus.

  Thomas

Yalac - Need some testing

Reply #36 –
Stop the confusion!

You possibly can see from my last posts, that i am getting a bit confused from the results of the testers, that are sometimes so different from my test corpus.

I think, i should perform some deeper analysis of the surprising findings, before i ask the testers for specific evaluations. Otherwise there would be a chance, that the testers waste their time.

What i would like to do now:

1) Close the official test within the next days.

2) Open a new thread 1, where testers should post comparisons of the presets of yalac with other compressors. This possibly would be the most interesting for other forum readers.

3) Open a new thread 2, where testers can post about the effects of special encoder parameter variations and crazy findings. This would be useful for my next encoder improvements. And this specific tests can go on.

What do you think?

One further question: Is it ok, to use this forum for discussion with the testers?

  Thomas

Yalac - Need some testing

Reply #37 –
Quote from: TBeck on
2) Open a new thread 1, where testers should post comparisons of the presets of yalac with other compressors. This possibly would be the most interesting for other forum readers.
Would the preset values be the standard preset buttons of 0.02, or the presets as you list above (i.e. HIGH  = NORMAL + Optimize Quantization + 256 Predictors)?

I am nearing the end of a 50 track comparison between Yalac and a few other encoders, and am just beginning to test Yalac.  Can I continue as per your instructions above (i.e.: adapted values for Extra and Insane)?  I'm keen to see my test completed, and was hoping to undertake the Yalac processing tonight.
I'm on a horse.

Yalac - Need some testing

Reply #38 –
Quote from: Synthetic Soul on
Quote from: TBeck on
2) Open a new thread 1, where testers should post comparisons of the presets of yalac with other compressors. This possibly would be the most interesting for other forum readers.
Would the preset values be the standard preset buttons of 0.02, or the presets as you list above (i.e. HIGH  = NORMAL + Optimize Quantization + 256 Predictors)?


I would use the original (standard) presets, beacuse probably most testing done before my confusing posts might have used them.

  Thomas

Yalac - Need some testing

Reply #39 –
New ULTRA FAST preset

Would you think, it could be useful to test some new ULTRA FAST mode? My latest version (0.03, not released) allows the use of smaller Frames, which makes the FAST preset about 50 % faster at encoding without significantly affecting compression efficiency.

Maybe it's not really useful, because encoder speed could allreday be limited by disk IO at the FAST preset.

Not urgent. If one should like to test it, it could be added to the results later.

  Thomas

Yalac - Need some testing

Reply #40 –
This could be interesting for streaming purposes.  If you add it, I'll test it.  (if you build it, they will come!)

Yalac - Need some testing

Reply #41 –
Quote
' date='Apr 11 2006, 02:20 PM' post='381222']
This could be interesting for streaming purposes.  If you add it, I'll test it.  (if you build it, they will come!)


If they come, i am happy 

Ok, i will try to complete it until tomorrow.

But i have to correct me. The speed advantage seems to be CPU dependend. Another machine gave me only 30 %.

But there is potential. The fast presets are suffering from the fact, that there still is many unoptimized and debug code left, which doesn't contribute much to the calculation time of the modes with high predictor orders, but slows the fast modes down.

  Thomas

Yalac - Need some testing

Reply #42 –
I have published the results from my encoder comparison on the Comparison Thread.

I now hope to perform some more varied tests with 24bit files; mono files; and bespoke encoder settings.

I may wait for the command line version before I undertake anything else too strenuous though.  I guess this depends whether I can free up some time (which is in short supply at the moment), or how long it will be before a command line version can be released.

NB: I also hope to document my test system, as I spent a reasonable while creating some batch and Windows Script files to automate the process of running encoding and decoding tests on a test corpus and entering those results into a relational database (to a degree that it just takes a couple of double-clicks).  I think this system could be of use to some other people, but I don't really know how others approach this; I may have simply re-invented the wheel, or over-complicated things!
I'm on a horse.

Yalac - Need some testing

Reply #43 –
Quote from: Synthetic Soul on
I have published the results from my encoder comparison on the Comparison Thread.

I may wait for the command line version before I undertake anything else too strenuous though.  I guess this depends whether I can free up some time (which is in short supply at the moment), or how long it will be before a command line version can be released.

NB: I also hope to document my test system, as I spent a reasonable while creating some batch and Windows Script files to automate the process of running encoding and decoding tests on a test corpus and entering those results into a relational database (to a degree that it just takes a couple of double-clicks).  I think this system could be of use to some other people, but I don't really know how others approach this; I may have simply re-invented the wheel, or over-complicated things!



Thanks for the results!

Yes, please wait for the command line version. I know, that testing is quite uncomfortable with the odd GUI.

And i myself tend to forget, that i called this test "reality check". It has not necessary to be too detailed yet.

But you may get some other impression because i can't stop myself posting my new ideas, findings and optimizations every day! I'm a bit out of control... Working on that now... 

It think that your test setup could be helpful for others. No, i won't tell you about my primitive way...

Do you have a tool, that automatically compares the files sizes to get the compression ratio?

  Thomas

Yalac - Need some testing

Reply #45 –
Quote from: TBeck on
Thanks for the results!

Yes, please wait for the command line version. I know, that testing is quite uncomfortable with the odd GUI.
No problem.  I may well continue testing before you release a command line version.  I'm not sure I can stop myself.

Quote from: TBeck on
And i myself tend to forget, that i called this test "reality check". It has not necessary to be too detailed yet.

But you may get some other impression because i can't stop myself posting my new ideas, findings and optimizations every day! I'm a bit out of control... Working on that now... crying.gif
It's hardly surprising.  It seems as though you have something here that puts you in the big league of lossless codecs.  I'm sure you must have put in a lot of work to get to this point.

Quote from: TBeck on
It think that your test setup could be helpful for others. No, i won't tell you about my primitive way...

Do you have a tool, that automatically compares the files sizes to get the compression ratio?
The ASP does that at the moment.  Just the raw data (durations in seconds and file sizes in bytes) is recorded in the database.  I have a table with a record for each source file that records the source file size (and duration), and a link table that links a file to an encoder setting, which records the file size of the encoded file (and the en-/decode times).

I used a simple batch file to list the filesize of the sources files, and the batch file that encodes the files records the times and also the generated file size.  The decode batch file also records the times.  A Windows Script file then scrapes the encode/decode times and file sizes from these text files and inserts them into the database (which is MS Access for ease - I also thought that I may let people download it).

Quote from: TBeck on
Wow! Really great and useful presentation! Many many thanks again! Must be some very useful testing tools.
I really am glad to be of help.

Are there any other views that you think would be useful?  It would be very easy for me to knock up another page to display the info in another way, if you think that some more useful stats could be detailed.
I'm on a horse.

Yalac - Need some testing

Reply #46 –
Quote from: Synthetic Soul on
Are there any other views that you think would be useful?  It would be very easy for me to knock up another page to display the info in another way, if you think that some more useful stats could be detailed.


Tomorrow i will sent a new version with the new FASTEST preset to the testers. That could be interesting.

What could be helpful for analysis would be a test run of the wole file set with the protocol function enabled for NORMAL and HIGH. You have to move or rename the protocol file between the runs, because it's always been overwritten.

I would suspect, that the files use low predictor numbers. That's usually the case, if HIGH is only so little bettter than NORMAL. And really strange that HIGH is faster on decoding than FAST!

Yes, my test corpus isn't representative. I have just downloaded the whole test file set from rarewares.org, to get more variety.

  Thomas

Yalac - Need some testing

Reply #47 –
Can you make the protocol (log) file append outputs?  That would make it easier.  You could even add a seperator each time you write to it, like a 30 char long line of '.' or '*' or '-', to make reading back entries faster.

Yalac - Need some testing

Reply #48 –
Quote
' date='Apr 11 2006, 10:05 PM' post='381381']
Can you make the protocol (log) file append outputs?  That would make it easier.  You could even add a seperator each time you write to it, like a 30 char long line of '.' or '*' or '-', to make reading back entries faster.


Good idea!

Done:

- Option to append protocol
- Store encoder options into protocol
- Store results into protocol
- Justify result columns

Yalac - Need some testing

Reply #49 –
Probably a dumb question but does this support .cue's? Can you email me a copy to hand.of.omega, it's a @gmail.com address.