TAK 1.1.0 Options

[TBeck]

> Could you please send
Done !

Thank you!

I have tested it with TAK 1.1.0 and TAK 1.1.1 Alpha. Here are the compression results:

CODE

Preset    V1.1.0    V1.1.1    Option
------------------------------------
-p2        20.85     20.85     off
-p2e       19.36     19.30     on
-p2m       19.15     19.07     on

-p3        22.83     22.83     off
-p3e       22.71     19.48     on
-p3m       22.68     19.40     on

-p4        22.77     19.61     on
-p4e       22.74     19.49     on
-p4m       22.73     19.43     on
------------------------------------

As you can see, the presets with the new encoder option activated are performing much better.

Surely a "severe problem" would be near-zero percent compression, lossy encoding, or a complete lack of error tolerance?

A few more MiB in your collection... "severe"? I suppose it depends on how rare "rare" is.

Edit: FYI I Just checked my comparison and none of the fifty files suffer from this. Obviously this doesn't prove a whole lot, but it does indicate to me that the issue is not normal.

It's indeed a very rare problem. The file DOS386 sent me definitely comes from a heavily lossy compressed source. You can easily hear some flanging artifacts.

Because the new encoder option on average does not improve the compression by more than about 0.05 percent (zero for some file sets and probably your one will be among them...), i would usually activate it only in the maximum evaluation levels (-pXm), but since it is operating quite fast, it seemed to be sensible to add it also to the extra evaluation levels (-pXe) of the higher presets.

Fixed a bug in the encoder that resulted in suboptimal compression of some loud files and especially high resolution audio. Some files may gain about 0.05 percent of compression. Not much, but it comes without any speed penality.

Thomas, is this issue related to the above, or is it something totally unrelated? Apologies if this has been done a thousand times before.

Thank you for reading my release notes!

No, it has to do with the PreFilter option introduced in YALAC 0.07 or so. You may remember...

Sometimes the PreFilter is beeing used although it does badly affect the compression efficiency. The new encoder option can prevent this most of the time. It also helps a bit outside of the PreFilter issues.

Thomas

[TBeck]

Fixed a bug in the encoder that resulted in suboptimal compression of some loud files and especially high resolution audio. Some files may gain about 0.05 percent of compression. Not much, but it comes without any speed penality.

Thomas, is this issue related to the above, or is it something totally unrelated? Apologies if this has been done a thousand times before.

Thank you for reading my release notes!

I hope, you didn't get this wrong. It was only meant as a compliment!

Thomas

[Synthetic Soul]

I hope, you didn't get this wrong. It was only meant as a compliment!

No, not at all Thomas; I understood your meaning.

No, it has to do with the PreFilter option introduced in YALAC 0.07 or so. You may remember...

Sometimes the PreFilter is beeing used although it does badly affect the compression efficiency. The new encoder option can prevent this most of the time. It also helps a bit outside of the PreFilter issues.

Actually I do have a very vague recollection of your pre-filter testing. It seems so long ago...

Thanks for the explanation.

[TBeck]

New Features:

- Support for 192 Khz Audio.

Many thanks to Stephan Busch for testing TAK 1.1.0 in his Squeeze Chart 2009!

Here an excerpt of his 24 Bit / 192 KHz Comparison:

CODE

Codec                                                 Compression %
-------------------------------------------------------------------      
OptimFrog v4.600ex (26.06.'06) -max. -experimental     33,20
TAK 1.1.0 (04.01.2009) -p5m Thomas Becker              34,18
WAVPACK v4.42a (08.09.'07) -HHX6                       34,29
Monkey's Audio v4.01b2 (GUI) (28.04.06) (insane)       34,49
TTA TrueAudio 3.4.1 (27.07.'07) Alexander Djourik      36,14
FLAC 1.2.1 (17.09.07) Josh Coalson -8 -b 4096          39,14
-------------------------------------------------------------------

Not too bad for TAK

This post has been edited by TBeck: Jan 22 2009, 00:37

[Alexxander]

-p5m ? Must be -p4m I suppose.

[TBeck]

-p5m ? Must be -p4m I suppose.

You are right. But for backwards compatibility V1.1.0 will map -p5x to -p4x. Therefore -p5m and -p4m are identical.

[DOS386]

Surely a "severe problem" would be near-zero percent compression, lossy encoding, or a complete lack of error tolerance? A few more MiB in your collection... "severe"? I suppose it depends on how rare "rare" is.

Tested 2 files a one gave a very bad result.

I have tested it with TAK 1.1.0 and TAK 1.1.1 Alpha. Here are the compression results:
As you can see, the presets with the new encoder option activated are performing much better.

I see ... much better, still the higher compression effort gives (now marginally) worse compression success.

It's indeed a very rare problem. The file definitely comes from a heavily lossy compressed source. You can easily hear some flanging artifacts.

1.3 MiB OGG Vorbis, but probably irrelevant: the thing is cca 80 years old so cca 75 of them it most likely spent on a black PVC disk, and captured the artifacts there

[Synthetic Soul]

Surely a "severe problem" would be near-zero percent compression, lossy encoding, or a complete lack of error tolerance? A few more MiB in your collection... "severe"? I suppose it depends on how rare "rare" is.

Tested 2 files a one gave a very bad result.

Are you suggesting that this will occur 50% of the time with your collection? Do you think it may be prudent to test a larger corpus and report some figures from that?

I'll admit that your limited results look concerning, but personally I would have been very keen to try to gauge a more accurate percentage from a decent selection of my collection. Your findings may be very useful to Thomas, and other TAK users.

This post has been edited by Synthetic Soul: Jan 24 2009, 10:00