Yalac - Need some testing, (Yet another lossless audio comprossor) Options

[Shade[ST]]

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.

It's still in testing, and you can compress the wav file with it. It doesn't support ANY tagging format yet -- including embedded cuesheets -- dev' version makes it so -- and it's only in a closed distribution circle.

[Synthetic Soul]

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.

Files can be found here.

CODE

Yalac_diag_high.txt      Log for High compression
Yalac_diag_normal.txt    Log for Normal compression
dec_high.txt             GUI output for decoding of High encode
dec_normal.txt           GUI output for decoding of Normal encode
enc_high.txt             GUI output for encoding using High
enc_normal.txt           GUI output for encoding using Normal

Please bear in mind these stats are for trials I performed last night/this morning - not the trials listed in my comparison. Obviously the timings should tie up approximately, but they are never going to be exactly the same.

If you would like to see the full stats on these files I could add them to my comparison data this evening (10 hours time). The data already includes a few trials that I have not included in the core data. These can be viewed by appending all=1 to the querystring in the summary or file listing pages (use all=0 to remove them), e.g.:

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

The current data additional to the core settings includes Garf's optimised FLAC at default and -8, Yalac Normal + Optimize Quantization + 256 Predictors ("High (adapted)"), and Garf's optimised MP4ALS.

In fact, looking now, this shows that High (default) produced better results for me than High (adapted) [Normal + Optimize Quantization + 256 Predictors] in my test.

This post has been edited by Synthetic Soul: Apr 12 2006, 10:20

[Synthetic Soul]

Thomas,

Also, if it's not too late, could you add the actual time taken to the output, as well as compression and rate?

I had to calculate my times using the file's duration and rate (en-/decode duration = file duration / rate) - but it would be a bit easier, and slightly more accurate, to have to times output by Yalac.

E.g.:

CODE

00.yaa   73.11 % -  18.3 * -  3.279
01.yaa   50.09 % -  20.1 * -  1.964
02.yaa   52.51 % -  19.4 * -  4.782

When I get a command line version I'll use TIMETHIS, as using times reported by the de-/encoder itself is not quite right. However, at these early stages, with the GUI app, it is necessary.

[TBeck]

Please bear in mind these stats are for trials I performed last night/this morning - not the trials listed in my comparison. Obviously the timings should tie up approximately, but they are never going to be exactly the same.

If you would like to see the full stats on these files I could add them to my comparison data this evening (10 hours time). The data already includes a few trials that I have not included in the core data. These can be viewed by appending all=1 to the querystring in the summary or file listing pages (use all=0 to remove them), e.g.:

In fact, looking now, this shows that High (default) produced better results for me than High (adapted) [Normal + Optimize Quantization + 256 Predictors] in my test.

Thanks.

Accuracy of the timings is not so important for my actual analysis. And i don't need stats for the single files, because the sum statistic doesn't show much variance.

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!

The statistics confirm my hypothesis. Mean is 37 for NORMAL and 39 for HIGH.

CODE

Distrtibution of Subframes per frame

NORMAL
     1                                   33.848 %  (32240)
     2                                   14.713 %  (14014)
     3                                   25.350 %  (24146)
     4                                   16.350 %  (15573)
     5                                    9.740 %  (9277)

HIGH
     1                                   20.324 %  (19359)
     2                                   16.417 %  (15637)
     3                                   21.931 %  (20889)
     4                                   20.026 %  (19075)
     5                                   21.302 %  (20290)

That's interesting. Seems as if there is some ceiling effect (right english?). Possibly your files have many fast changes in signal characteristics and could benefit from more than 5 sub frames, which is the actual limit of my implementation. On my test corpus 5 sub frames are very rare.

Could you please generate a protocol file for HIGH without "Apply window"? It's not urgent.

Thomas

Thomas,

Also, if it's not too late, could you add the actual time taken to the output, as well as compression and rate?

I had to calculate my times using the file's duration and rate (en-/decode duration = file duration / rate) - but it would be a bit easier, and slightly more accurate, to have to times output by Yalac.

E.g.:

CODE

00.yaa   73.11 % -  18.3 * -  3.279
01.yaa   50.09 % -  20.1 * -  1.964
02.yaa   52.51 % -  19.4 * -  4.782

When I get a command line version I'll use TIMETHIS, as using times reported by the de-/encoder itself is not quite right. However, at these early stages, with the GUI app, it is necessary.

It's allready in V0.03, which i will release this day. List of encoder options and content of the result window are beeing written to the protocol.

Thomas

[Garf]

If you would like to see the full stats on these files I could add them to my comparison data this evening (10 hours time). The data already includes a few trials that I have not included in the core data. These can be viewed by appending all=1 to the querystring in the summary or file listing pages (use all=0 to remove them), e.g.:

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

The current data additional to the core settings includes Garf's optimised FLAC at default and -8, Yalac Normal + Optimize Quantization + 256 Predictors ("High (adapted)"), and Garf's optimised MP4ALS.

It looks like the FLAC+ data is wrong. Exactly the same compression as the original wouldn't only be bad, it would also be very unlikely

[TBeck]

It looks like the FLAC+ data is wrong. Exactly the same compression as the original wouldn't only be bad, it would also be very unlikely

I was surprised about this to. Unpublished results of one tester have shown FLAC+ performing up to 1 percent better than FLAC standard.

Very good work, Garf!

Thomas

This post has been edited by TBeck: Apr 12 2006, 11:12

[Synthetic Soul]

Could you please generate a protocol file for HIGH without "Apply window"? It's not urgent.

Of course. I'll do it this evening, when I get back from work (approx. 9 hours time).

I don't mean to be pushy, but I wonder whether the time you spend working on this meant you missed my subsequent post in which I asked for the GUI to report the encode and decode times as well as rate? If you want to ignore the request please do, but I just didn't want my request to be accidentally "skipped".

It looks like the FLAC+ data is wrong. Exactly the same compression as the original wouldn't only be bad, it would also be very unlikely

I did notice that, but (stupidly) assumed that your optimisation had only been in the en-/decode times, which do vary.

The sole reason I tested your optimisation is that I didn't realised that my "active" FLAC.EXE was actually your version. It wasn't until I went to record encoder versions that I noticed that it was 1.1.2.1. I therefore had to undertake the test again using 1.1.2. I don't know how this may have happened, but I suspect that possibly the file sizes have been appended to an existing text file, and therefore the top (previous) 50 results were just taken a second time. There shouldn't have been an existing file in the folder to begin, but due to the duplication it is possible I think.

Unfortunately I can't check this until I get home (see above) but I will remedy ASAP.

Thanks for picking that up.

BTW: If my suspicion is correct, the FLAC+ values will be correct (as they were recorded first) but the FLAC values are incorrect.

This post has been edited by Synthetic Soul: Apr 12 2006, 11:26

[TBeck]

Could you please generate a protocol file for HIGH without "Apply window"? It's not urgent.

Of course. I'll do it this evening, when I get back from work (approx. 9 hours time).

I don't mean to be pushy, but I wonder whether the time you spend working on this meant you missed my subsequent post in which I asked for the GUI to report the encode and decode times as well as rate? If you want to ignore the request please do, but I just didn't want my request to be accidentally "skipped".

Please be pushy! Would be bad if i had missed it!

But i didn't. My answer has been appended to my previous post. The forum software still seems to work a bit faulty.

Thomas

[TBeck]

Links to 24 bit files i have used

I think, they are hard to find.

CODE

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

[john33]

If you want files of varying bitwidths, you could process a 16 bit file through WaveGain and output in 8, 16, 24, 32 bit, or float.

[foosion]

Links to 24 bit files i have used

I think, they are hard to find.

You just have to know what to search for: flac 24bit "show details" site:archive.org.

[TBeck]

Links to 24 bit files i have used

I think, they are hard to find.

You just have to know what to search for: flac 24bit "show details" site:archive.org.

Hmpf...

Yes.

Makes me feel like an internet newbie. Have spent many hours without luck. But this one really works.

[Synthetic Soul]

It looks like the FLAC+ data is wrong. Exactly the same compression as the original wouldn't only be bad, it would also be very unlikely

I cannot for the life of me see what happened here. The error wasn't as I suspected. And, even more strangely, when I ran my FLAC.EXE and recently renamed FLAC-GARF.EXE they both reported themselves as 1.1.2!!

To save any confusion I have simply re-run the test for both FLAC 1.1.2 and 1.1.2.1.

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

[Synthetic Soul]

Could you please generate a protocol file for HIGH without "Apply window"? It's not urgent.

Of course. I'll do it this evening, when I get back from work (approx. 9 hours time).

OK, file can be found in the same place. Direct link here.

Edit: Fastest has now been added to my comparison.

Protocol file from second run (didn't want to slow down comparison run) with the others. Direct link here.

This post has been edited by Synthetic Soul: Apr 12 2006, 22:18

[TBeck]

Could you please generate a protocol file for HIGH without "Apply window"? It's not urgent.

Of course. I'll do it this evening, when I get back from work (approx. 9 hours time).

OK, file can be found in the same place. Direct link here.

Edit: Fastest has now been added to my comparison.

Protocol file from second run (didn't want to slow down comparison run) with the others. Direct link here.

Can not stop thanking you!

I think, FASTEST could be useful. So i will optimize it for more speed.

Thomas

[Shade[ST]]

That's what I was saying! Fastest is Da BOMB!

You should make a program which automatically parses your log files and gives back the important values, eg. the optimal number of predictors, etc.

I think high could be useful, too, but it needs to get closer to optimfrog...

PS / Edit : you should take a look at optimfrog, maybe contact the developper : maybe he has ideas to improve the compression in YALAC;

Also, perhaps you should make a changelog, somewhere. Another also, if you want to get started on that documentation, I'm here for you. You can PM me to get my IM client details.

Peace,
Tristan.

This post has been edited by Shade[ST]: Apr 12 2006, 23:46

[TBeck]

' date='Apr 13 2006, 12:41 AM' post='381803']
That's what I was saying! Fastest is Da BOMB!

You should make a program which automatically parses your log files and gives back the important values, eg. the optimal number of predictors, etc.

I think high could be useful, too, but it needs to get closer to optimfrog...

And FASTEST isn't fully optimized yet (for speed)...

To be on par with the better modes of optimfrog seems impossible to me (at least with my assymmetric approch). On files, which can take advantage of higher predictor orders, YALAC seems to compare well to OptimFrog default.

But i will try my very best!

Thomas

[Synthetic Soul]

I created some MD5 digests for my source waves and the Yalac decoded waves.

I have just got around to comparing the hashes on the files, and there are a few discrepancies:

FAST
36.wav; 44.wav
2/50, or 4% of test corpus

HIGH
5.wav; 9.wav; 12.wav; 30.wav; 36.wav; 40.wav; 41.wav; 44.wav
8/50, or 16% of test corpus

HIGH (Adapted) - Normal + Optimize Quantization + 256 Predictors
12.wav; 15.wav; 30.wav; 36.wav; 44.wav
5/50, or 10% of test corpus

NORMAL
5.wav; 9.wav; 12.wav; 13.wav; 15.wav; 30.wav; 31.wav; 34.wav; 36.wav; 44.wav
10/50, or 20% of test corpus

I have two versions of the HIGH and NORMAL files and both sets have identical hashes to each other, which I assume means that this is not an IO issue, but a decoder/encoder issue.

I have used foobar to bit compare a few files and they all report sample differences.

I am wondering a. has anyone else experienced this, and b. Thomas, what information can I provide about these files to help you?

[Shade[ST]]

I had not checked, really, except with one file, and foobar2000's bitcompare, but it didn't pop up a screen saying "no differences" or anything... Can you post the link to your md5 summer (and does it only check the audio data, or RIFF / date / etc too?) please?

Also, if you can reproduce this with a file encoded then decoded, try to get a non-matching md5, then compare in eac, to see if they're in fact matching or not, in audio data (maybe it just appended a different header)

[TBeck]

I created some MD5 digests for my source waves and the Yalac decoded waves.

I have just got around to comparing the hashes on the files, and there are a few discrepancies:

I have two versions of the HIGH and NORMAL files and both sets have identical hashes to each other, which I assume means that this is not an IO issue, but a decoder/encoder issue.

I have used foobar to bit compare a few files and they all report sample differences.

I am wondering a. has anyone else experienced this, and b. Thomas, what information can I provide about these files to help you?

There have been some reports, but not so many!

You are right, it's not in the wave io. Good thinking!

Im quite sure that it has to do with the frame partitioning. Did you get errors with FASTEST too, which doesn't use partitioning? I am doing something wrong at the partition boundaries. Or i write wrong info about the position of the boundaries into the file. A fix will not affect compression efficiency!

One other possibilitiy would be, that i sometimes use one bit less than needed to store the first sample of a frame or subframe. This could affect FASTEST to.

I didn't correct this until now, because

1) there haven't been many reports

2) i allready think about a new (simplier) way to store the partition info into the stream. So it didn't want to debug the old one.

But you just have changed my priorities!

Could you sent me a possibly shortened version of some of your error files (original wave)? Long enough to generate an error (possibly start of file to error position + 1 second).

Glad, that you checked it!

Thomas



Forgot this:

An easy way to find error files is the activation of the VERIFY option of the encoder. Unfortunately Verify sometimes reports an error, although the the file is intact (bit identical).

This post has been edited by TBeck: Apr 13 2006, 20:53

[TBeck]

Update for the error issue:

It's not necessary to send me error files now!

I did check my new (bigger) test corpus with different settings and have been able to generate enough errors, to give me some hint.

Thomas

[Synthetic Soul]

Did you get errors with FASTEST too, which doesn't use partitioning? I am doing something wrong at the partition boundaries. Or i write wrong info about the position of the boundaries into the file. A fix will not affect compression efficiency!

I got no errors with FASTEST, which considering the amount with the other presets does appear to suggest something. Still, I best leave the diagnostics to you! It's good to hear that a fix should not affect compression.

If you do decide that I can provide some useful info please just ask.

[Synthetic Soul]

I had not checked, really, except with one file, and foobar2000's bitcompare, but it didn't pop up a screen saying "no differences" or anything... Can you post the link to your md5 summer (and does it only check the audio data, or RIFF / date / etc too?) please?

Also, if you can reproduce this with a file encoded then decoded, try to get a non-matching md5, then compare in eac, to see if they're in fact matching or not, in audio data (maybe it just appended a different header)

I used my md5-create.bat batch file (which uses Slavasoft's FSUM) to create an MD5 file for each folder. I then did a find'n'replace to replace "_d.wav" with ".wav" to ensure the file names matched. I then used ExamDiff to do a simple text compare on the files - each file generated from decoded yaa files compared to the source MD5s. The mismatched lines are highlighted.

Obviously this method does not check only the audio data. Once I saw the mismatches I did a few binary compares in foobar 0.9 (remember, in my first test of 5 files all files were binary-comparable), and each compare reported sample errors. I did a couple of compares in a hex editor (mirkes.de tiny hexer) and the differences were too great to report here.

I assume EAC would report similarly to foobar's bit compare.

As an example though, for 36.wav and 36_d.wav decoded from a Fast encode:

foobar:

Comparing:
"M:\source\36.wav"
"M:\yaa\fast\36_d.wav"
differences found: 9648 sample(s), starting at 215.2812245 second(s), peak: 0.0000305 at 215.2812245 second(s), 1ch

EAC:
different samples 0:03:35.281 - 0:03:35.444
2298 missing samples 0:03:35.447 «-- this is reported for 36.wav

The file is 3:38.133 in duration.

[Shade[ST]]

EAC:
different samples 0:03:35.281 - 0:03:35.444
2298 missing samples 0:03:35.447 «-- this is reported for 36.wav

The file is 3:38.133 in duration.

In that case, it would seem it's the last partition, maybe that makes an error. Odd that it should only happen at the end of the file. I'm sure this is of grat use to Thomas.

[TBeck]

First findings:

7 of 44 files of my test corpus generated errors on one or more of the presets.

1 case is allready fixed.

The remaining errors seem to confirm my hypothesis, that the errors have to do with frame partitioning. Sub frames are beeing aligned to integer multiples of 8. Every error postion was at the first sample of a sub frame. For some reason, the reported (by Yalac) error position within the frame was 10681 for 5 files.

With some luck i will be able to fix that soon.

Thomas