Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Yes please!

10 (66.7%)

No, FLAC is good enough

4 (26.7%)

No, Other (please explain) is good enough

1 (6.7%)

Total Members Voted: 15

[BryanC]

I'm trying to convince Thomas (TBeck) over at hydrogenaudio to make a JRiver plugin for his lossless TAK format. It is just about superior to FLAC in every way, aside from hardware support. If we show some interest, I think he might do it.

TAK 2.0 link: http://www.hydrogenaudio.org/forums/index.php?s=74e60bd636536a73126d482af5884b66&showtopic=77604

The format is still closed-source, although Tom has plans to open it up once initial development is completed.

He does provide a decoding library, however, I don't know if this is all that is needed to make a JRiver input plug-in. Can anyone provide some insight on how difficult it would be to create with VS 2003?

If he doesn't feel like it is worthwhile, I may tackle the project if there is enough support.

[gappie]

It is just about superior to FLAC in every way, aside from hardware support.

i use ape, which is also superior to FLAC in every way. 
could you explain why TAK is 'superior' to FLAC?

(voted other)

 
gab

[Daydream]

i use ape, which is also superior to FLAC in every way. 

Yeah, right (goes for TAK too, pre-2.0.1). Like multichannel support.

[gappie]

Yeah, right (goes for TAK too, pre-2.0.1). Like multichannel support.

you forgot to vote..

[Daydream]

I'm still thinking, give me a second...

Ok, I'll go yes for 1) increased versatility, appeal and multitude of options in MC and 2) interested in (lossless) codecs actively developed. I don't see though anything replacing Flac in mkv anytime soon.

[Matt]

I wrote him an email to congratulate him on TAK and asked him to consider writing a plugin. 

So that's one vote from me, although I'm a little partial to Monkey's Audio

[BryanC]

i use ape, which is also superior to FLAC in every way. 
could you explain why TAK is 'superior' to FLAC?

(voted other)

 
gab

MUCH faster encoding. Higher compression. Very active development. About equal across the board on other factors. Multi-channel support is coming soon...

[JimH]

MUCH faster encoding. Higher compression.

Any data?  Have you compared it to APE?  I'm guessing it's not significantly faster or higher compression.

[BryanC]

Any data?  Have you compared it to APE?  I'm guessing it's not significantly faster or higher compression.

Ape's decoding speed isn't even in the realm of FLAC/TAK. To me, this is the most important thing I look for in a lossless codec.

http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison#Comparison_Table

As for compression considerations:

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)

[HiFiTubes]

I was a big user and support of .ape but reluctantly switched to FLAC because it has better hardware support (like streaming to my iphone with Simplify).

I didn't see any stats on decoding speeds. It's nice to have a faster encode/decode I guess but not something that makes me fall over these days honestly. Saving a few kbps would be nice for Library Server, but will it make much difference?

However, I don't transcode a lot of stuff to my portable any more given the hoops of Apple/MC integration, and I know others do so this could be a real benefit. It sounds exciting but I always end finding that my files need to be more compatible with friends' uses, for my own audio projects. Using an esoteric format, no matter how good, is somewhat of a dealbreaker.

I miss the monkey.

[JimH]

http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison#Comparison_Table

I just looked at the encoding, decoding, and compression in the first three lines of the table.

First of all, "fast" vs "very fast" isn't "data".  Maybe the actual numbers are there somewhere....

What you see is what you would expect.  APE was third best compression out of fourteen formats in that test.  The higher the compression, the longer it will take to both encode and decode.  This is an apples and oranges comparison, since the compression ratios are different.

In any case, why should I care about decoding speed?  Unless I'm converting to something else, playback speed is the bottleneck.

I'm not saying that TAK isn't better.  It may be.  I just don't see it yet.  But Matt is the expert in this area.  He wrote APE almost a decade ago.

[Mr ChriZ]

I'm considering moving away from APE, which is a shame as it's a great format.
Unfortunately the licensing holds it back in my opinion.  I know why Matt chose the license he has, and I completely agree with it.  The fact remains however that many people just won't touch it because it's not an officially recognised license.

[JimH]

I'm considering moving away from APE, which is a shame as it's a great format.
Unfortunately the licensing holds it back in my opinion.  I know why Matt chose the license he has, and I completely agree with it.  The fact remains however that many people just won't touch it because it's not an officially recognised license.

Why does that matter?  He's been very generous in allowing people to use his work.

[Matt]

I'm considering moving away from APE, which is a shame as it's a great format.
Unfortunately the licensing holds it back in my opinion.  I know why Matt chose the license he has, and I completely agree with it.  The fact remains however that many people just won't touch it because it's not an officially recognised license.

Have you ever read the entirety of the licenses they're promoting?

I chose a simple license I can understand.  I've let anyone that want use Monkey's Audio any way they want for free.  I've never made any money from it.

To work hard on something, give it away, give the source away, and then be criticized for how you give it away is absurd.

[Mr ChriZ]

Have you ever read the entirety of the licenses they're promoting?

I chose a simple license I can understand.  I've let anyone that want use Monkey's Audio any way they want for free.  I've never made any money from it.

To work hard on something, give it away, give the source away, and then be criticized for how you give it away is absurd.

I agree on all accounts... but the fact is the amount of hardware and software that is out there that supports APE is sadly very low and I've read a fair number of posts from various projects indicating the reason they won't support it is the license.  Personally I wouldn't have a problem with it.... but sadly I'm not developing the next generation portable media players (If I were they'd be awesome (but only ever 60% complete  )).
I still believe that other than this lack of support from other hardware/software players APE is the best format for me, and can't believe how well it is standing the test of time.  Well done and Thanks Matt for creating such an awesome format.

Why does that matter?  He's been very generous in allowing people to use his work.

I know but still people won't use it.

[benn600]

All I've gathered from reading all of these posts and taking yet another look at the comparison article is how pleased I am for having chosen FLAC.  But I do like following all the discussion and debate on lossless codecs!

FLAC just has about the best mix of features in the lossless world--multichannel support, very fast decoding (which you appreciate time after time), and the hardware support!  That is definitely the most important aspect.  If something doesn't play your format it doesn't matter how great it is!  Competition is great but when everyone agrees on something, that gives another round of benefits to users.

[BryanC]

In any case, why should I care about decoding speed?  Unless I'm converting to something else, playback speed is the bottleneck.

Decoding speed is playback speed, if I understand your terminology. Decoding speed is important in order to minimize CPU cycles (especially important on portable devices and low-power HTPC's). You decode the file every time you play it.

[JimH]

Decoding speed is playback speed, if I understand your terminology. Decoding speed is important in order to minimize CPU cycles (especially important on portable devices and low-power HTPC's). You decode the file every time you play it.

A computer might decode a file into memory in a few seconds, but take several minutes to play it.

Decoding speed doesn't minimize CPU cycles.

[benn600]

Of course decoding speed would minimize CPU cycles.  That's the whole point of a faster decoding capability.  Compared on equivalent systems, decoding will be faster when more cycles are available on a faster system.

It would obviously be better to require fewer cycles because then with background audio playback, the CPU will not be as taxed during constant playback of audio, often for most or all of the time the computer is on.

[JimH]

Of course decoding speed would minimize CPU cycles.

Efficiency would reduce CPU usage.  Speed would not.  Imagine you have a race between a Toyota Corolla and a dragster.  The dragster is faster and wins every tiime, but the Toyota uses less gas every time.  The small "engine" uses less juice.

[Mr ChriZ]

I've just added FLAC to the JR Wiki as it wasn't in there.
http://wiki.jrmediacenter.com/index.php/Supported_File_Types

[BryanC]

Efficiency would reduce CPU usage.  Speed would not.  Imagine you have a race between a Toyota Corolla and a dragster.  The dragster is faster and wins every tiime, but the Toyota uses less gas every time.  The small "engine" uses less juice.

It is for this reason that most decoding/encoding tests are done on slower hardware (either single-core or simultaneous dual-core) in order to max out each processor. If the decoding speed is faster, it follows that it must be more efficient as well.

[Mr ChriZ]

Since my not far off credit card sized Cowon player (which is a 3 year old design) can happilly decode my APE files I'm not loosing any sleep about the fact that it is more intensive in the decoding stage
I don't think it's exactly taxing my desktop.

[glynor]

It is for this reason that most decoding/encoding tests are done on slower hardware (either single-core or simultaneous dual-core) in order to max out each processor. If the decoding speed is faster, it follows that it must be more efficient as well.

Exactly... The tests are completely artificial.  It's like using the old Winbench suite, or modern games set to high resolution, to try to test modern processors.  You just can't get anything usable out of them anymore (all games are GPU limited, not CPU limited, and productivity apps are limited much more by internal timers and user interaction than anything the CPU does).  You are forced to artificially limit the test parameters in order to even glean any information out of the test, which makes its relevance to practical applications shady at best.  Audio decode time differences, even on old and slow hardware, are measured in milliseconds.  In some applications, an extra handful of milliseconds matters.  In audio decoding, it does not.

On any modern hardware, audio decode performance is completely irrelevant.  Even for transcodes, as Jim mentioned above, the decode time is almost completely a non-factor.  You are going to be FAR more limited by disk throughput and RAM access latencies than by any microscopic difference in the CPU instruction set from a decode routine.  Heck, we're getting to the point where encode times are starting to become fairly irrelevant.

Also, if you look at those efficiency differences you listed above (compression size), most of the differences are measured in 10-20 kb out of a total of a few hundred thousand kb total.  Take the "Carlo Siliotto - The Punisher Score" example: the difference between APE and TAK (better) is 0.03% improvement.  When you can buy 3.5" 1TB hard drives for $80-90, and even for your laptop you can get 2.5" 500GB drives for $90, I hardly think a 0.03% compression improvement is relevant.  Heck, 0.03% is probably even within the margin of error for the testing procedure!  How did they get those results?  Are the repeatable?  Did they do a standard compliment of 5-10 tests and average the results, present the median, or something else?  And does it even matter since the block size of your hard drive will probably mask most of the differences in final file size?

In other words... P-L-A-C-E-B-O.  Just like reaction to Matt's license.

[JimH]

If the decoding speed is faster, it follows that it must be more efficient as well.

No.  It may just mean that the content is not as intensely compressed.  All lossless encoders I know about have several levels of compression, but all that means is that, for example, you might go from 58% of original size to 53% of original size by using the "extreme" compression setting.  The differences in file size are small, but the extra 5% of compression (from this example) can take significantly more time to do, both for encoding and decoding.

[gappie]

it is an interesting thread. i wonder how it would have developed if, instead of using terms like 'superiour' and 'not even in the realm', the op would have said that there is another codec that works very nicely and that it would be great if there was a plugin for it.

i guess it would be nice if mc could also play TAK, especially when this thread is about convincing the tak developers to write it.

 
gab

[glynor]

it is an interesting thread. i wonder how it would have developed if, instead of using terms like 'superiour' and 'not even in the realm', the op would have said that there is another codec that works very nicely and that it would be great if there was a plugin for it.

i guess it would be nice if mc could also play TAK, especially when this thread is about convincing the tak developers to write it.

I agree completely, and my comments weren't about the usefulness of MC being able to play back TAK files (wider file support is always welcome).  I just could care less about encoding to them, but to each their own.

I was only commenting about the OP's statements of superiority.  To me, the main factor determining the superiority of one lossless audio codec over now comes down to support (software and hardware), and FLAC seems to have mostly won that battle a long while ago.  I sure wouldn't spend time cross-converting my library over to TAK to save less than 0.1% in drive space, and some unquantifiable increase in "decode speed".

[gappie]

I agree completely, and my comments weren't about the usefulness of MC being able to play back TAK files (wider file support is always welcome).  I just could care less about encoding to them, but to each their own.

I was only commenting about the OP's statements of superiority.  To me, the main factor determining the superiority of one lossless audio codec over now comes down to support (software and hardware), and FLAC seems to have mostly won that battle a long while ago.  I sure wouldn't spend time cross-converting my library over to TAK to save less than 0.1% in drive space, and some unquantifiable increase in "decode speed".

i know, glynor, i agree. it was more a followup on my first post in this thread where i tried to do the same. there can be different factors why people choose a certain codec. i use ape because that was the best choice for me at that time and probably still is, mc did not support flac natively back then, and ape was and is a very good choice. others choose flac with good reason, and there might be others that want to use tak.

 
gab