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: TAK 2.0.0 - Beta release (Read 51692 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 2.0.0 - Beta release

Reply #50 –
Quote from: Perun on
Is it possible to make TAK support wav-files bigger than 4 GB? I have a 66-minute two-channel 24-bit 192-kHz wav that TAK cannot compress. It can compress a slice of that file though, so the only reason I can think of for TAK not to be able to handle the entire file is its size.

Quote from: Nick.C on
That file would be 4,561,920,000 bytes long, whereas the limit for WAV is about 4,294,967,276 bytes of audio.

Exactly.

Quote from: Perun on
Quote from: Nick.C on
That file would be 4,561,920,000 bytes long, whereas the limit for WAV is about 4,294,967,276 bytes of audio.

Well, wavpack can handle such files if it is told to ignore the length of the file as specified in the header. I prefer TAK though, and I am sure that TAK could do the same.

I seem to remember that earlier versions of WavPack simply stored the data exceeding the 4 GB limit as uncompressed meta data, but i don't know, if this is still the case.

But ok, now that TAK also has been tuned for 192 Khz data, i see the need to support larger files. Probably i will go for the Wave64 format.

Quote from: _m²_ on
Quote from: TBeck on
Preparing the final release

I would like to release the final version this year. Please report any bugs you may have encountered with the beta version.

So how is it going?

Good question!

Unfortunately my secondary PC was blocked by some other tasks, therefore i couldn't run my comprehensive test and validation suite. But now it's available and i hope to release the final within the next 24 hours.

Quote from: Skymmer on
Somehow I missed the new TAK version, but no matter. TBeck, thanks for it.
I'm gonna try it in a next few days. Thanks once again and Happy New Year! 

Thank you!

TAK 2.0.0 - Beta release

Reply #51 –
I did some tests some time ago. I think it will be interested for people. 

Soundtracks (classical/ambient/rock):
Hans Zimmer - Pirates of the Caribbean, The Dead Man's Chest:
APE - 338 663 kbytes (694 kbps) Insane
APE - 339 966 kbytes (697 kbps) Extra
TAK - 341 254 kbytes (699 kbps) 2.0
WV  - 351 053 kbytes (719 kbps)

Joshua Ralph - Lucky Number Slevin Soundtrack:
TAK - 182 245 kbytes (551 kbps) 2.0, Better than APE-Insane!
APE - 182 297 kbytes (551 kbps) Insane
TAK - 183 061 kbytes (554 kbps) 1.04
APE - 183 720 kbytes (556 kbps) Extra
OFR - 185 336 kbytes (560 kbps) Experimental Normal

Carlo Siliotto - The Punisher Score:
TAK  - 260 052 kbytes (2.0) Better
APE  - 260 145 kbytes (ExtraHigh)
TAK  - 260 967 kbytes (1.12)

Nobuo Uematsu - Final Fantasy Piano Collections:
TAK 2.00 - 149 341 kbytes
FLAC 1.2 - 169 969 kbytes

The Graduate Soundtrack (1968)
TAK 1.04 - 180 062 kbytes (p5m) better
TAK 2.00 - 180 077 kbytes (p4m)
Difference is very small, but old tak still better.

Tangerine Dream - Sorcerer Soundtrack (1977):
TAK 1.04 - 443 kbps (p5max) Also Better
TAK 2.00 - 445 kbps (p4max)

Ladder 49 Score (lossy source)
TAK - 160 217 kbytes (2.0 )
TAK - 163 046 kbytes (1.12)
APE - 167 001 kbytes (Insane)
APE - 167 980 kbytes (Extra)
WAV- 480 082 kbytes

We Own the Night Soundtrack (some tracks are lossy):
LA    - 402 386 kb (high noseek)
TAK  - 403 855 kb (2.0) Better than APE-Insane
APE  - 405 079 kb (Insane)
APE  - 405 757 kb (Extra)
TAK  - 406 555 kb (1.12)
APE  - 412 250 kb (High)
FLAC - 423 510 kb (-8)
WAV  - 727 589 kb

Marco Beltrami - Resident Evil (Bootleg - some tracks were detected as lossy)
TAK 2.0 - 589 kbps Better
APExtra - 598 kbps

Marco Beltrami - I, Robot (Bootleg)
TAK 2.0 - 566 kbps Better
APExtra - 570 kbps

Marco Beltrami - Blade II Score
APE - 176 558 kbytes (Extra)
TAK - 177 075 kbytes (2.0) better than ape-high
APE - 178 979 kbytes (HIGH)

Kelly Bailey - Half Life Soundtrack:
LA  - 174 069 kb (665 kbps) HIGH
APE - 176 942 kb (677 kbps) Insane
TAK - 177 248 kb (678 kbps) 2.0
APE - 177 567 kb (679 kbps) Extra
APE - 178 401 kb (682 kbps) HIGH

John Williams - Theme From Schindler's List:
TAK 1.04 - 18.2MB (19 091 945 bytes) Better
TAK 2.00 - 18.2MB (19 104 913 bytes)

Stuart Chatwood - Time Only Knows:
TAK 1.04 - 22.3MB (23 400 199 bytes) Better
TAK 2.00 - 22.3MB (23 410 441 bytes)

Basil Poledouris - Robocop - Main Title (1987) (Varese Sarabande 2003):
OFR - 3.42MB (3 590 520 bytes) 728 kbps --maximumcompression --experimental --uselessoptimization
OFR - 3.42MB (3 591 522 bytes) 728 kbps --maximumcompression --experimental
LA  - 3.42MB (3 596 623 bytes) -high -noseek
LA  - 3.43MB (3 598 491 bytes) -high
APE - 3.47MB (3 641 444 bytes) 739 kbps Insane
TAK - 3.53MB (3 707 923 bytes) 752 kbps

Graeme Revell - Lara Croft Tomb Raider:
APE - 228MB (239 224 557 bytes) ExtraHigh
TAK - 228MB (239 270 826 bytes) 2.0
TAK - 228MB (239 922 625 bytes) 1.04

Classical:
Bach Oboenwerke, vol 1:
TAK 1.04 - 684 kbps (p5max) better
TAK 2.00 - 688 kbps (p4max)

Beethoven - Symphony No 7/8 (Used in "KNOWING" the movie)
TAK 2.00 - 412 kbps Better
TAK 1.04 - 413 kbps
TAK 1.12 - 415 kbps

Jazz:
Louis Armstong - The Great Chicago Concert:
DISC One
TAK 2.00 - 413 kbps Better
TAK 1.12 - 423 kbps

DISC Two
TAK 2.00 - 420 kbps Better
TAK 1.12 - 431 kbps

Rock:
Linkin Park - Hybrid Theory:
TAK 2.00  - 274 714 kbytes Better
TAK 1.12 - 275 365 kbytes

Linkin Park - Meteora:
TAK 2.0 - 1014 kbps Better
APExtra - 1016 kbps

Jay-Z vs. Linkin Park - Collision Course
TAK 2.00  - 993 kbps Better
APE HIGH  - 996 kbps

Jefferson Airplane - somebody to love:
TAK 1.04 - 25.6MB (26 889 379 bytes) Best edition
TAK 1.10 - 25.6MB (26 891 646 bytes)
TAk 1.12 - 25.6MB (26 892 582 bytes)
TAK 2.00 - 25.7MB (26 993 554 bytes)

Electro
Daft Punk Around The World (LP Version)
TAK 1.04 - 867 kbps (p5m) Better
TAK 1.04 - 869 kbps (p5 )  Also Better ;(
TAK 2.00 - 873 kbps (p4m)
TAK 1.12 - 875 kbps (p4m)

From the Games:
Scary Zone (Ambient stereo track from the "HITMAN Blood Money" game)

OFR 4.6 - 13 927 kbytes (--experimental highnew) 285 kbps, Awesome Results!

OFR 4.6 - 14 118 kbytes (--experimental --maximumcompression )
OFR 4.6 - 14 238 kbytes (--experimental normal)
OFR 4.6 - 14 427 kbytes (--experimental fast)

OFR 4.6 - 31 087 kbytes (normal)
APExtra - 31 044 kbytes

TAK 1.04- 31 130 kbytes
TAK 2.0 - 31 162 kbytes

OFR 4.6 - 31 299 kbytes (fast)

FLAC 1.2- 31 876 kbytes (-8)
WAV      - 68 903 kbytes (16bit/44khz) 1411 kbps

Tosca (Stereo track from the same game)
OFR 4.6 - 459 kbps (normal --experimental)
TAK 2.0 - 496 kbps
OFR 4.6 - 529 kbps (fast)

8bit solid file from the game
OFR  - 57 432 kbytes (4.6, highnew --experimental --optimize best) better than bestnew
TAK  - 61 013 kbytes (2.0) better than excepts
TAK  - 62 433 kbytes (1.12)

TAK 2.0.0 - Beta release

Reply #52 –
Interesting, but maybe to make the results more useful you may want to add speed measurements. I'm sure OFR and LA are capable at high compression, but what decade will it take to finish?  (Not to mention most OFR LA decode speeds are just as heavy as encoding speeds.)

edit: hint - if posts are insanely long, try "codebox"-ing in order to make mods happier
"Something bothering you, Mister Spock?"

TAK 2.0.0 - Beta release

Reply #53 –
Quote from: TBeck on
I seem to remember that earlier versions of WavPack simply stored the data exceeding the 4 GB limit as uncompressed meta data, but i don't know, if this is still the case.

But ok, now that TAK also has been tuned for 192 Khz data, i see the need to support larger files. Probably i will go for the Wave64 format.


I have just compressed a 12.8-GB 5.1 24/192 *.wav to a 5.55-GB *.wv, so there seems to be no room for any uncompressed data. I should once again note, however, that WavPack is an interim solution for me, even though this codec is really good, which I am glad to admit; my ultimate goal is TAK. Therefore, support for Wave64 would really be very, very nice.

Thank you.

TAK 2.0.0 - Beta release

Reply #54 –
Those are some smashing figures, Thomas.  Congratulations!

Too bad there hasn't been much movement lately amongst some of the higher-scale lossless codecs.  Monkey's Audio's compression scheme hasn't improved for 6 years, La's for 7 years, OptimFROG's for almost 4.  TAK seems to be the only codec at this end of the compression percentages that's actively being developed.  Good for you, and for the rest of us ;-)

Wouldn't it be nice if we could cajole Synthetic Soul, Josef Pohm, Speek, Hans Heijden, and some of the other folks who've produced some interesting comparison tables, to test TAK 2.0 on their corpus and update their tables consequently?  Do you think there's any reason to wait until 2.0 goes final before benchmarking?

TAK 2.0.0 - Beta release

Reply #55 –
Quote from: Polar on
Do you think there's any reason to wait until 2.0 goes final before benchmarking?


Yes, Thomas said that there are codec changes.

TAK 2.0.0 - Beta release

Reply #56 –
Quote from: Polar on
Those are some smashing figures, Thomas.  Congratulations!

Too bad there hasn't been much movement lately amongst some of the higher-scale lossless codecs.  Monkey's Audio's compression scheme hasn't improved for 6 years, La's for 7 years, OptimFROG's for almost 4.  TAK seems to be the only codec at this end of the compression percentages that's actively being developed.  Good for you, and for the rest of us ;-)

WavPack is being developed actively enough, and FLAC too, I believe. The point is it is not the compression scheme that developers do (and probably should) focus on, but rather the various features that make life easier for the user and increase the number of applications of a codec. After all, there, apparently, is a limit to the degree of compression that can practicably be achieved.

The same, by the way, is happening in the field of general-purpose archivers like RAR or 7-zip, to the best of my knowledge.

TAK 2.0.0 - Beta release

Reply #57 –
Quote from: Perun on
After all, there, apparently, is a limit to the degree of compression that can practicably be achieved.

Certainly, though we don't know where it is. There might be still a lot to be saved.

Quote from: Perun on
The same, by the way, is happening in the field of general-purpose archivers like RAR or 7-zip, to the best of my knowledge.


You're wrong. 7-zip puts a lot of effort to LZMA2, it's next generation codec.

TAK 2.0.0 - Beta release

Reply #58 –
I just wanted to release the final version. All validation procedures were successful. Then i checked the decoding speed of the new binary and bang! More than 5 percent slower decoding of p2 to p4 on my AMD sempron (all is fine on my Pentium dual core). There must be some cache trashing going on, caused by a slightly different data or code alignment of the new build. Strange.

The correction may delay the release by some hours.

TAK 2.0.0 - Beta release

Reply #59 –
Fixed. Really strange. It probably had to do with the branch prediction: Some jumps were possibly competing for the same entry in the branch history table. I never before encountered something like this.

Although i have only changed some code alignment, i will now repeat at least a part of my validation procedures.

TAK 2.0.0 - Beta release

Reply #60 –
I have just released the final version. 

TAK 2.0.0 - Beta release

Reply #61 –
NICE!!!

TAK 2.0.0 - Beta release

Reply #62 –
Quote from: _m²_ on
Certainly, though we don't know where it is. There might be still a lot to be saved.

At present, there doesn't seem to be a lot to be saved. Some is much more likely.

Quote from: _m²_ on
You're wrong. 7-zip puts a lot of effort to LZMA2, it's next generation codec.

OK, let's see what improvement it gets, eventually. Now, there's hardly any.

TAK 2.0.0 - Beta release

Reply #63 –
Quote from: Perun on
Quote from: _m²_ on
Certainly, though we don't know where it is. There might be still a lot to be saved.

At present, there doesn't seem to be a lot to be saved. Some is much more likely.

Quote from: _m²_ on
You're wrong. 7-zip puts a lot of effort to LZMA2, it's next generation codec.

OK, let's see what improvement it gets, eventually. Now, there's hardly any.


I said there might be a lot. Yes, all current codecs are relatively close to each other, but Kolmogorov complexity of any (or sepecifically: audio) data is not computable. We don't know and we'll never know how close or how far we are.

LZMA2 is not supposed to improve strength but efficiency. It's little stronger and much more parallel. Parallelism actually makes it somewhat weaker, but much faster. Therefore I can't agree there's "hardly any" improvement. OTOH lack of improvement in strength doesn't mean there's little to gain. See PAQ8.

TAK 2.0.0 - Beta release

Reply #64 –
Hello Tbeck as my first post here I'd like to tell you my appreciation for you working on such a great project that is TAK !
I'm spreading love for that format everytime I talk to a friend about digital audio, they always get exited when they see the compression ratios o_O

I've been crawling in here (HydrogenAudio) for quite a while, only reading what gurus/wizards have to say and taking advice

Anyway, I've been using your latest beta and have a few remarks to make :3

- Could you increase the size of the "filename buffer" ? At the moment i'm having quite a hard time shortening paths just for takc to be willing to encode my files !
256 or even 512x(sizeof (char)) would be enough XD

Or keep it variable length ( like argv[] ?)

- One other thing I'd like to ask is what you think of adding a --remove-input-file command ( that would break in case of error ofcourse :3)

- What about handling japanese characters (extended charsets ?) I don't have that much knowledge about those but I never had any problem handling ANY printable character when outputting to a file or internally. Ofcourse win32 commandline will show question marks instead of those characters, but argv[] still contains them ... right ?

- Lastly, the frontend could need a "config file" that saves last path used (at the moment you have to EXIT for the path handle to be destroyed and the folder to be modified/renamed, and when running it again path is lost!)


PS: Is it a "feature" that "Verify" is always unticked ?

PPS: Do you have a Bugzilla or other bug/feature tracking host? that would be very handy and probably make the only dev (you) less closed.
Not criticizing your choice for non-opensourceness (even if I don't see any point in being close-sourced) but surely one person can only do so much and us reporting bugs in a proper format (with no BLA BLA BLA etc) would lessen your time spent on reading posts and logging.
 

TAK 2.0.0 - Beta release

Reply #65 –
does TAK provide static library?
because I want to compile it into my project without any dll library. does someone tell me?