Skip to main content
Topic: TAK 1.0 - Beta testing (Read 82488 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.0 - Beta testing

Reply #25
I thought I'd post some compression results I found interesting. From my tests, it seems that the higher the compressibility of a sample the more TAK outstrips other encoders. To demonstrate this, here are some results from the most compressible album in my collection. It's Autechre & The Halfer Trio's  "æo³ & ³hæ" album. Lots of silence, near silence, static and such on this one.

Code: [Select]
       enc     enct    dec      size
Turbo  209.9   274.1   294.73   240,020,885
Fast   172.7   187.5   277.82   237,073,503
Normal 107.2   112.2   266.09   234,668,207
High   66.40   68.38   206.81   232,370,112
Extra  39.54   40.23   186.40   229,728,913
ExtraM 12.54   xxxxx   187.28   229,502,965

flac8  18.55   xxxxx   316.43   256,086,154
WVh    104.8   xxxxx   141.73   267,167,826
WVhhx3 9.590   xxxxx   108.22   255,402,312


My CPU is an Opteron 165 overclocked to 2900 mhz. A lot of the numbers are there but notice how neither flac or wavpack can come anywhere close to even Turbo. Another thing you might notice is that Turbo mode is much too fast for my storage subsystem (enct is encode test mode).

TAK 1.0 - Beta testing

Reply #26
Thank you for the Damage Tool and the explanation as to why removing the header/footer causes a problem with the current decoder.

TAK 1.0 - Beta testing

Reply #27
...
Edit: "No one in future will judje your codec based in an early beta release" ... but will see with good eyes an developer that is so concerned with the problems in his codec and quicky in bug-fixes! That was fast! Thank you.

Thank you! A very nice point of view.

I thought I'd post some compression results I found interesting. From my tests, it seems that the higher the compressibility of a sample the more TAK outstrips other encoders. To demonstrate this, here are some results from the most compressible album in my collection. It's Autechre & The Halfer Trio's  "æo³ & ³hæ" album. Lots of silence, near silence, static and such on this one.
...

Fine. Tak is quite well optimized for very low amplitudes (within the possible limits of non arithmetic coding), because in it's early days i only had 8 Bit sample files.

And thanks for the kind words in your first post of this thread! And thanks for the congratualations of the other posters!

Thank you for the Damage Tool and the explanation as to why removing the header/footer causes a problem with the current decoder.

I hope, the documentation of the tool is sufficient.

And i hope, i could make it clear, that the header/feet problem should only be a problem, if both are beeing removed simultaneously. Otherwise the file should be decodable.

TAK 1.0 - Beta testing

Reply #28
@Gnerma: What was the total filesize? Only to have a idea about the compressibility. MAC comparison would also be nice to see the high compresion side.   
Quote
Fixed!
[...]
The fix was so simple, that this alone is no reason for a second beta. But let's see what comes next.

This may not be, but the anoying "verify" option could be. 

Anyways, I will try to use the comand-line for batch encode from now. There this problem will not apear. Too many beta releases can overload the file server and the beta-testers.

And about the undecodable files? I tested now cuting the first byte and the last 4 bytes. It tries to decode but when it finish it says that the file is undecodable. This behavior is slight diferent than when I cut 30 bytes from each end. In that case it stops imediatly and say that it is undecodable. Don't even try to decode the whole file.

TAK 1.0 - Beta testing

Reply #29
Quote
Fixed!
[...]
The fix was so simple, that this alone is no reason for a second beta. But let's see what comes next.

This may not be, but the anoying "verify" option could be. 

Both are easy fixes without the possibility of unpredictable side effects. Therefore i would risk to apply the patches to the final version without further beta testing.

I don't want to stress the testers too much and there already have been the two alpha versions. All this can get boaring for the testers and the audience... I assume, we are also here for some entertainment!

But maybe we will see a second beta.

For your great and dangerous (huh, what will this guy do next... i really appreciate your work!) testing it would be better to soon have a second beta with the fixes. But i want to wait some days for more bug reports before thinking about a second beta.

And about the undecodable files? I tested now cuting the first byte and the last 4 bytes. It tries to decode but when it finish it says that the file is undecodable. This behavior is slight diferent than when I cut 30 bytes from each end. In that case it stops imediatly and say that it is undecodable. Don't even try to decode the whole file.

If the error message comes at the end of the file, i suppose that you have not disabled the restore wave file meta data option. Otherwise i would be surprised.

TAK 1.0 - Beta testing

Reply #30
Quote
For your great and dangerous (huh, what will this guy do next... i really appreciate your work!) testing it would be better to soon have a second beta with the fixes. But i want to wait some days for more bug reports before thinking about a second beta.

No problems.
Quote
If the error message comes at the end of the file, i suppose that you have not disabled the restore wave file meta data option. Otherwise i would be surprised.

Ooops. I forgot to re-enable after the crashes.   

It decodes correctly and only the last sample is missed (if I understod correcly the log...). Great! But an more precise error message when the "restore wave file meta data" is enabled would be good... not every one will read the whole read-me file, or may forget it enabled, as me.

TAK 1.0 - Beta testing

Reply #31
Quote
If the error message comes at the end of the file, i suppose that you have not disabled the restore wave file meta data option. Otherwise i would be surprised.

Ooops. I forgot to re-enable after the crashes.   

It decodes correctly and only the last sample is missed (if I understod correcly the log...). Great! But an more precise error message when the "restore wave file meta data" is enabled would be good... not every one will read the whole read-me file, or may forget it enabled, as me.

Improved:

- If one file was undecodable, Tak shows the hint "Try disabling "Restore wave file meta data" (-wm0)."
- The state of the Verify-option is beeing preserved when changing presets in the GUI version.

EDIT: Probably there will be more then 1 lost sample at the end of your damaged file. An error in a frame will always make the whole (small) frame undecodable. Unfortunately the error log will always say 0 lost samples for the last frame, because earlier only the last frame itself contained info about it's sample count. If the last frame was damaged, the decoder could not tell how many samples it contained. This only regards to the last frame. And it could be done better now, because after the last modification of the stream format any stream info structure contains data from which the size of the last frame can be calculated. Sorry, i forgot to use this.

TAK 1.0 - Beta testing

Reply #32
Edit:  I have updated Tag to recognise TAK files (so you don't have to specify --ape2 --nocheck).  Download 2.0.49 if you want to tag using Case's Tag.  NB: 2.0.48 was a "silent" release that updated to libFLAC 1.1.3.

TAK Decoder Stub for foobar2000

I've made a simple component for foobar2000 that will allow you to use foobar2000 to tag your TAK files. It doesn't support playback for obvious reasons.  Perhaps some people will find it useful to manage their TAK files.

Thank you very much for making Tak more usable!

Sadly WAVE_FORMAT_EXTENSIBLE files are not supported, or are they?

They are not supported. Probably i will wait with this until i am implementing multi channel support.

TAK 1.0 - Beta testing

Reply #33
I would love to support TAK in shntool.  Are there plans to have TAKC read WAVE data from standard input when encoding and/or write WAVE data to standard output when decoding?

TAK 1.0 - Beta testing

Reply #34
I would love to support TAK in shntool.  Are there plans to have TAKC read WAVE data from standard input when encoding and/or write WAVE data to standard output when decoding?

Great!

It's among the items on my to do list, but has no top priority for me. Well, your post has just raised the priority... But first comes tagging and media player support.

TAK 1.0 - Beta testing

Reply #35
A very good point.

Being able to read from STDIN and write to STDOUT is very useful for those of us wishing to convert from our lossless source to lossy files.

It's also worth noting that some apps like FLAC and OptimFROG have issue with the way that foobar pipes to STDIN.  WavePack gets around it with the -i switch.

http://www.hydrogenaudio.org/forums/index....showtopic=43160
http://www.hydrogenaudio.org/forums/index....showtopic=41287

Definately worth taking the time to ensure that foobar can easily pipe to TAKC.EXE.
I'm on a horse.

TAK 1.0 - Beta testing

Reply #36
I would love to support TAK in shntool.  Are there plans to have TAKC read WAVE data from standard input when encoding and/or write WAVE data to standard output when decoding?

Have you tried to set the filename to "CON" yet? May just work.

TAK 1.0 - Beta testing

Reply #37
Have you tried to set the filename to "CON" yet? May just work.


Thanks for the suggestion.  I actually use that trick for other formats, but hadn't tried it for TAK.  Unfortunately, it doesn't seem to work:

Code: [Select]
C:\shnutils>takc -d test.tak CON
test.tak                            .......... Error writing destination

1 files with read/write errors.


Code: [Select]
C:\shnutils>type test.wav | takc -e CON test.tak
CON.wav                             .......... Allready exists

1 files allready existed.
The process tried to write to a nonexistent pipe.


I will wait patiently, as this is not a top priority for me either.  In the meantime, thank you Thomas for all of your hard work! 

TAK 1.0 - Beta testing

Reply #38
EDIT: Probably there will be more then 1 lost sample at the end of your damaged file. An error in a frame will always make the whole (small) frame undecodable. Unfortunately the error log will always say 0 lost samples for the last frame, because earlier only the last frame itself contained info about it's sample count. If the last frame was damaged, the decoder could not tell how many samples it contained. This only regards to the last frame. And it could be done better now, because after the last modification of the stream format any stream info structure contains data from which the size of the last frame can be calculated. Sorry, i forgot to use this.

Well, even reading the read-me I don't understand perfeclty this error log. Here it is:
Code: [Select]
--- 4.tak ---

Result: Frame(s) damaged

File-ID:         damaged
StreamInfo:      damaged
Meta data:       damaged
Header frames:       369
Valid  frames:       368
Skipped blocks:        0
Skipped end:           1

Skipped data blocks

No       Source pos  Size        Sample pos  Count
       1     6861140          29     4057200           0

TAK 1.0 - Beta testing

Reply #39
TAK 1.0 Beta 1

Have fun and thanks for testing!

  Thomas


Hi Thomas,

Thank you very much for the codec!

I pick a few digitized 48KHz vinyl WAV to test, the speed and compression rate was VERY impressive, also the GUI is clean and simple.

I think Foobar2000 can be helpful for the GUI, you can concentrate on the codec core and let Foobar2000 handles common operations.

Test sample:

---
a03-just the way you are.wav (56,217,644 bytes)

19 sec  - FLAC -7        - 23,517,400 bytes (with Foobar2000 plugin 1.1.3, estimate)
7.4 sec - TAK -3 (high) - 22,404,252 bytes (with TAK 1.0 beta1, builtin counter)
---
b03-she's always a woman.wav (38,592,044 bytes)

13 sec    - FLAC -7        - 16,248,229 bytes (with Foobar2000 plugin 1.1.3, estimate)
5.03 sec - TAK -3 (high) - 15,424,111 bytes (with TAK 1.0 beta1, builtin counter)
---

Of course, Josh did a great work, but without competition there won't be any fun and improvement, maybe TAK can also have FLAC features like "picture block", or even standize some common "must have" between codecs ... I can wait for your great work, too.
Hong Kong - International Joke Center (after 1997-06-30)

TAK 1.0 - Beta testing

Reply #40
Well, even reading the read-me I don't understand perfeclty this error log. Here it is:
Code: [Select]
--- 4.tak ---

Result: Frame(s) damaged

File-ID:         damaged
StreamInfo:      damaged
Meta data:       damaged
Header frames:       369
Valid  frames:       368
Skipped blocks:        0
Skipped end:           1

Skipped data blocks

No       Source pos  Size        Sample pos  Count
       1     6861140          29     4057200           0

The stream info (header) tells, that the file contains 369 frames. 368 frames were valid and could be decoded. Skipped block counts undecodable frames except the last one at the file end. Skipped end is 1, if the last frame could not be decoded, otherwise 0.

Skipped data blocks is a list of file parts containing frames which could not be decoded.

Most interesting maybe the value of SamplePos: You can open the decoded file with a wave editor and jump to this position to look at the damage. Count usually tells you, how many samples have been affected. But for the last frame this value is always 0 (i will change this later).

While damaged frames are usually beeing replaced with zeros (muted), a damaged last frame is simply beeing cut off.

I hope, this helps...

TAK 1.0 - Beta testing

Reply #41
Yes, it helped very much. You can improve the "Skiped End" and the "count" explanation in the readme, in the same way as you explaned here for me.

And now some compression results:

Code: [Select]
Tsubasa Chronicle - Original Sound Track - Future Soundscape 1

Original Size:   581.838.640 bytes
Total playing time:    54:58 min

Codec         Avg. Compression     Enc Time

Flac -0  :         (62,73%)        1:29 min
Flac -5  :         (59,76%)        2:39 min
Flac -8  :         (59,54%)       ~9:20 min

Flake -5  :        (58,72%)        2:28 min*
Flake -8  :        (58,42%)        5:12 min*
Flake -12 :        (57,77%)       31:40 min*

WV -fm:            (60,11%)        2:12 min*
WV -hm:            (58,06%)        3:18 min*
WV -hhx3m:         (57,38%)       22:39 min*

MAC fast:          (58,31%)        1:46 min
MAC normal:        (56,83%)        2:32 min
MAC high:          (56,09%)        3:00 min
MAC Extra high:    (54,98%)       ~5:30 min
MAC Insane:        (54,57%)       18:17 min

TAK turbo:         (57.46 %)       1:29 min
TAK fast:          (56.75 %)       1:50 min
TAK normal:        (56.19 %)       2:24 min
TAK normal max:    (56.08 %)       4:13 min
TAK high:          (55.48 %)       3:38 min
TAK extra:         (55.18 %)       5:15 min
TAK extra max:     (55.14 %)      12:03 min

Hardware: Celeron 1.7GHz (L2 cache of 128KB)
          512mb DDR-133
          Seagate 7200.7 80GB IDE
* the times marked this way may be wrong, encoding made by foobar.


From the total of 20 files compressed by TAK extra max, 7 were very compressible (35.20% ~ 49.68%), 11 not very compressible (60.42% ~ 71.79%) and only two were in the 50 ~ 60 range, only to show how averages can be misleading.

The "turbo" and "fast" modes from TAK doesn't have any competition! Flake slowest mode didn't compressed better than TAK's turbo, and WV hhx3 barely out performed it in compression, but coudn't reach the fast mode. MAC's fast is better, but not in TAK's level.

In normal and high MAC came closer, but not quite there yet. Finally, TAK can't compete with the compression of MAC's Extra high, nor Insane. But, on the other hand, the same is true for MAC when you compare the decoding speed, that I didn't mesured.

Overal, very impressive! Don't drop Turbo mode, as it is faster than fast any way, and can help with slower processors or when you want the minimum system usage (live video capture with audio, for example).

TAK 1.0 - Beta testing

Reply #42
[deleted]

TAK 1.0 - Beta testing

Reply #43
Here is the results of the mega-test, and the decoding speed for most codecs, however I didn't get to update the TAK results yet for the latest info or make this in any better format (I've been working 12+hrs a day).  Hopefully this is a nice start:

Absolutely! Thank you very much!

Again i took the freedom to put some (it's really much!) of the data into another form:
Code: [Select]
                    Size (MB) Ratio    Diff Best  Diff Tak 4m
Original             1307.29   100.00   -47.94     -46.47
MLP                   885.81    67.76   -15.70     -14.23
FLAC-0                785.29    60.07    -8.01      -6.54
WavPack-fast          748.42    57.25    -5.19      -3.72
FLAC-5                735.93    56.29    -4.23      -2.76
FLAC-8                731.44    55.95    -3.89      -2.42
WavPack-normal        729.37    55.79    -3.73      -2.26
Flake-12              725.01    55.46    -3.40      -1.93
WavPack-normal-x3     724.56    55.43    -3.36      -1.89
ALS                   723.40    55.34    -3.27      -1.80
APE-fast              722.21    55.24    -3.18      -1.71
WavPack-high          721.94    55.22    -3.16      -1.69
WavPack-normal-x6     721.37    55.18    -3.12      -1.65
TAK-0                 719.65    55.05    -2.99      -1.52
WavPack-high-x3       718.27    54.94    -2.88      -1.41
WavPack-hh            717.48    54.88    -2.82      -1.35
WavPack-high-x6       716.01    54.77    -2.71      -1.24
WavPack-hhx3          715.16    54.71    -2.64      -1.17
TAK-0m                715.05    54.70    -2.63      -1.16
WavPack-hhx6          713.96    54.61    -2.55      -1.08
TAK-1                 713.50    54.58    -2.52      -1.05
OptimFROG-fast        709.74    54.29    -2.23      -0.76
APE-normal            709.58    54.28    -2.22      -0.75
TAK-2                 708.31    54.18    -2.12      -0.65
APE-high              704.69    53.90    -1.84      -0.37
TAK-3                 703.73    53.83    -1.77      -0.30
OptimFROG-normal      702.40    53.73    -1.67      -0.20
TAK-4                 700.61    53.59    -1.53      -0.06
TAK-4m                699.84    53.53    -1.47       0.00
OptimFROG-high        699.60    53.52    -1.45       0.02
APE-extra             696.66    53.29    -1.23       0.24
ALS -7                696.46    53.27    -1.21       0.26
ALS-7-LTP             696.16    53.25    -1.19       0.28
APE-insane            693.59    53.06    -0.99       0.48
La-high               681.64    52.14    -0.08       1.39
OptimFROG-maximum-exp 680.62    52.06     0.00       1.47


Sorted by compression ratio.
"Diff Best"  is the difference of the best result and the row.
"Diff Tak 4m" is the difference of Tak's strongest mode and the row.

First time i see results for MLP. Is it really so weak?

Again, many thanks for this comprehensive testing! The table shows only a tiny part of the whole data...

TAK 1.0 - Beta testing

Reply #44
And now some compression results:
...

Thank you! Seems to be a Tak-friendly test set. There may be more of them than i expected...

Overal, very impressive! Don't drop Turbo mode, as it is faster than fast any way, and can help with slower processors or when you want the minimum system usage (live video capture with audio, for example).

Fine!

And no, i don't intend to drop the Turbo mode, exactly for the same reasons as you!

Maybe i will try to make it a bit faster sometime...

TAK 1.0 - Beta testing

Reply #45
[deleted]

TAK 1.0 - Beta testing

Reply #46
Ok, tak doesn't suport unicode yet. I tried an music with japanese characters in it's name and it don't worked. It loads the file, with ??? in the name, but in test mode the error message was: "Error reading source". In the compress mode the error is "Allready exists", if a file with an name close to the source name exist, even if the diference is made by normal characters. If the name is very diferent, or there is no .tak file in the folder, the error is the same as in test mode.

Note the typo in the "Allready exists". It shoud have only one L.

TAK 1.0 - Beta testing

Reply #47
I have just created a new def for TrID to recognize TAK compressed audio files!

Bye!

TAK 1.0 - Beta testing

Reply #48
I found an very interesting file, that answers in an almost linear way to the increase of compression time, in case of TAK and MAC, and in others it is an jump in compression in the very high setings:

Code: [Select]
Flyin' to Fly (source).wav

Mode         Compression     Speed

Turbo          72.42 %        55x
Turbo Max      71.78 %        21x
Fast           70.96 %        38x
Fast Max       70.41 %        16x
Normal         69.39 %        24x
Normal Max     69.19 %        11x
High           68.53 %        15x
High Max       68.18 %        7x
Extra          68.23 %        10x
Extra Max      67.77 %        4x

MAC fast       73.57 %        --
MAC normal     71.54 %        --
MAC high       69.59 %        --
MAC extra h.   66.79 %        --
MAC insane     65.83 %        --

LA normal      65,24 %        --
LA high        64.97 %        --
OptimFrog      64.53 %        --
(--maximumcompression --experimental --seek min)

WV -f          75.10 %        --
WV             74.31 %        --
WV -h          74.43 %        --
WV -hh         72.59 %        --
WV -hhx3       72.50 %        --

Flac -0        76.57 %        --
Flac -3        75.52 %        --
Flac -5        74.70 %        --
Flac -8        74.02 %        --

Flake -5       74.69 %        --
Flake -8       74.10 %        --
Flake -12      72.51 %        --

Hardware: Celeron 1.7GHz (L2 cache of 128KB)
          512mb DDR-133
          Seagate 7200.7 80GB IDE

The compression delta for TAK is 4.65 %, wich seems very high for TAK. And the compression delta between Flac -0 and this extreme mode in OptimFrog is 12.04 %. Flac is the "left zero", with an delta of only 2.55, but Flake got the trick somewere beteween -8 and -12.

Another thing intersting in this file is the "max" swich in TAK. Here the gains in compression with max for each preset:

Code: [Select]
Turbo Max over Turbo        0.64 %
Fast Max over Fast         0.55 %
Normal Max over Normal      0.20 %
High Max over High          0.35 %
Extra Max over Extra        0.46 %

It increases after "normal"! The High Max compress beter than extra simple!

I've upload this file sometime ago, as an SBR killer. You can get it here: http://www.hydrogenaudio.org/forums/index....533;entry363343

TAK 1.0 - Beta testing

Reply #49
A hybrid mode in the future would be quite a feat.

I am not sure, if this will happen... Very early versions contained something similar, but i wasn't too interested into it.

TBeck, have you looked into FreePascal to see about producing a DLL that might be able to be wrapped up with a foobar2000 decoder component?

Thank you, but it's no problem to create DLL's with my current Delphi compiler.

Ok, tak doesn't suport unicode yet. I tried an music with japanese characters in it's name and it don't

Definitely not...

Note the typo in the "Allready exists". It shoud have only one L.

Oh, it wasn't a typo... I thought, it was right. About a week ago one tester told me about my misconception, but i forgot to correct the source. Thanks for reminding me!

I have just created a new def for TrID to recognize TAK compressed audio files!

Great!

You found the secret String "tBaK"... I have to hide it better the next time...

 
SimplePortal 1.0.0 RC1 © 2008-2019