Hello everyone

I have allmost all my CD's in a lossless FLAC collection.

Now I'm thinking of switching to TAK, is it time?

I will probably use 4 Extra (-p4) compression and in FLAC I use 6.
When and if TAK will be released for portable devices.
How is TAK compared FLAC in resource usage, will it require the same amount of power or more?

How could I in a simple way convert all FLAC to TAK with the same folder layout ?

I'm sure it will be, but since the format is very new and is still being actively developed, i wouldn't hold my breath. If at all, i think Rockbox support will be the first to come. If portable support is THAT important to you, you might want to hold off converting because TBeck might come up with something tailored specifically for the portable use. In any case, -p4 will probably not be the compression standard supported in portable. Tbeck has mentioned that -p0, -p1 are the leading candidates.

Long story short: if you're interested in portable playback, don't convert now unless you don't have problem re-converting later.


Decompressing is nearly identical to Flac. Synthetic Soul has done extensive comparisons between TAK and other codecs. Check it out.


Using foobar. Check out the wiki for directions.

Thanx for the info, better to wait a while.


Do you mean normal, high and extra won't be supported?


TAK sure has nice compression and speed in perfect mix.
Thanx Tbeck!

It's pure speculation, but in one of the threads, tbeck has hinted at that.

Depends on what you're gonna do with these files. If it was mainly about backing up your collection, TAK might be worth becoming a replacement for your FLAC archive, since to average it offers better compression at comparable encoding/decoding speeds. Concerning portables, kanak should've already said everything 'bout that. I for my part can't see any serious reason for using lossless codecs on portable devices, hence I'll abstain from going any deeper into this matter.

But one important thing wasn't mentioned in this discussion yet: You shouldn't forget FLAC's supreme software compatibility, most audio applications support it either out of the box or via easily to install plug-ins. At least for me this compatibility is extremely important, since I use both Windows and Linux on this machine, resulting in lots of different applications being used to process the archive.

Windows: Winamp for listening; foobar2000 for transcoding to lossy, ReplayGain scanning as well as tagging; Nero Wave Editor for audio processing; Nero Burning ROM for burning to CD/DVD.

Linux: Amarok for listening; Audacity for editing; K3B for burning to CD/DVD

All of these applications offer flawless support for FLAC, while using TAK in conjunction with most of them could be rather troublesome. Except Winamp and foobar2000 every single one of them would require me to extract the archive to WAV first (as far as I know, please correct me in case I'm partially wrong here). In my opinion the gain in free storage space isn't really worth the effort, and I don't even know if decoding TAK to WAV is already possible under Linux, at least without having to rely on WINE.

During its testing stage and while FLAC 1.1.2 was still the current version I've been thinking about transcoding the archive to TAK as well, but for the above reason and the fact that lately Josh's been doing a great job at improving FLAC I banished the thought of doing so. Compared to 1.1.2 the 1.1.4 version is much better, offering both improved compression speeds and ratios. The comparably improved compression ratios of TAK aren't of much concern to me, just like the OP I even keep sticking to FLAC -6 since it works much faster than -8 and in my opinion the additional compression gain is completely negligible. The additional new opportunity to store album art inside the files is an interesting feature, but of no serious importance... yet.


Who knows? TAK will need a large user base in order to become interesting for the industry. At the moment it's still in its very early stages, hence it's unlikely that native hardware support might arise in the near future. But custom support shouldn't be much of a problem ---> http://rockbox.org could support the codec soon, as mentioned by kanak.


Foobar's converter. "Convert to same directory", after the processing will have been completed, you'll just have to make Windows conduct a search for all FLAC files in your audio directory (search for *.flac). Simply delete them afterwards.


Could be good decision concerning your personal needs... could, because the fewer people use the codec, the longer it will take until its software and hardware support is gonna become better. Thomas is just about creating a great lossless codec, but his baby will still need some time to grow up. It needs much more people who care about it, only then chances are given that it'll become a respected adult someday.

only tbeck can do this as long as it is both closed source and proprietary. the current tak lib cannot be used on any h/w devices.


not exactly. pretty much all comparisons are using flac.exe to decode, which includes md5sum calculations that tak does not support. in flac playback applications this is turned off.

for an apples-to-apples comparison see the FLAC comparison. you will see flac 1.1.4 decoding is actually 15-20% faster than even tak turbo and the upcoming version will be a little faster still.

Nothing to add until here...

TAK's Turbo is still compressing about 4 times (depending on the speed of your io system) faster than FLAC -8 while providing better compression. The advantage is smaller when using foobar for transcoding, because TAK currently does not support piping and foobar therefore has to create an intermediate file.


As the rest of your post, very thoughtful. Nothing to add.



That's not to say that i am not already in contact with some hardware developers... But you are right, it will take some time.


And then look at Synthetic soul's comparison and find TAK Turbo decoding faster... At the very high decoding speeds both TAK and FLAC are achieving, the speed of for instance your io sub system or properties of your cpu (for instance cache sizes and speeds) can have a big effect on your results.

You are right about MD5, although i doubt that it will have a big effect (but i may be wrong). On the other hand TAK already provides very strong error detection capabilities with it's per frame checksums of 24 bit (compared to FLAC's 16 bit). I personally would only add MD5's for finger printing purposes. I don't see a significant advantage reagarding error detection.

Puh, should i really have to implement a new Turbo mode which is both stronger and considerably faster than FLAC? It might look great in comparisons, but i doubt, that anyone would use it... Seems to be a waste of time.

Thomas

I would venture to say that the flac, tak, and wavpack decoders are all getting very close to fundamental limits determined by their inherent algorithmic complexity. wavpack and tak are very efficient but fundamentally more complex than flac. wavpack has more complex entropy coding and tak uses much higher order filters even for turbo. the fact that it can be done with narrower multiplies makes very little practical difference for most hardware with 16 bit samples. (for righer res it can be an advantage.)

the ultimate goal of the decoder timings in my comparison is to accurately measure the runtime typical in playback. currenlly i/o factors in to the time but after the next flac release I am going to redo everything based on cpu time. since libFLAC is not optimized around any particular i/o subsystem I doubt it's speed margin will narrow.

P.S.
as I said that's because he's testing with the default behavior of flac.exe which does md5 checking on decoding. this costs 15-20% of the overall time. wavpack and tak do not do this so that's why I said it's not apples-to-apples.

Much higher order filters? Turbo is using 16 compared to 12 used by FLAC -8 (correct?). On average a modified TAK Turbo which is using only 8 predictors but adding 1 multiplication for another (new) filter would still significantly surpass FLAC -8. But as i wrote, i don't know how much sense this all makes. Is there really a significant amount of hardware players which will fail at maybe 20 percent higher cpu demands? Your latest FLAC version has improved the decoding speed. Doesn't this mean, that there is now also more cpu time left for slightly higher filter orders?


Good idea!


You are right.

Thomas

my mistake, I thought turbo used 32.

Could you please elaborate this (or provide reading links)? What are the limits for lossless compression of audio?

I suppose, Josh is regarding to speed and not compression limits.

I applaud what TBeck has done with TAK, but until:

1) There is an open source version of TAK
or
2) There is enought open documentation to create alternative encoder/decoder.

i won't be touching TAK.

Also, i wish TAK and FLAC somehow merge one day.

Hmm... anyway, is there a compression limit? Are we near the limit?

> I have allmost all my CD's in a lossless FLAC collection.
> Now I'm thinking of switching to TAK, is it time?

NO. Reasons:

- Premature, author probably will change the format
- Not yet open source
- No player support so far

> Hmm... anyway, is there a compression limit? Are we near the limit?

YES. YES.

> I suppose, Josh is regarding to speed and not compression limits.

FLAC DID impressively improve from 1.1.2 to 1.1.4 ;-)

> I applaud what TBeck has done with TAK, but until:
> 1) There is an open source version of TAK
> i won't be touching TAK.

This is critical for me as well ... a minimal decoder under BSD license and full fileformat docs ;-)

> Also, i wish TAK and FLAC somehow merge one day.

I don't think this is possible ... it would kill existing FLAC standard

TAK looks very promising :-) to me ... but came a bit late - it might be difficult to collect much sympathy when there are that many other codes around by now ...

I think apples to apples comparisons are very difficult to ascertain when using completely different enc/decoders. For example, a test could time encoders encoding and tagging a file, or even encoding, tagging and verifying. None of them do the same thing in any situation. Of course, timing decompression speed for playback is one useful test, which I will be interested to see - I wouldn't say that it was the only test though. If I wished to compare 'apples to apples' considering compression rate it would be impossible with my corpus, as even FLAC -8 Ax2 does not surpass TAK Turbo. 'Apples to apples' seems to me to be subjective.

After some recent WavPack testing, where my PC showed very little improvement even though newer PCs showed dramatic improvement, I have considered removing my comparison, as I have realised that showing results for one system is a little misleading. I think your point is just more proof of this.

This is what I have discussed previously. It may just be a silly marketing exercise, but people like to pick what they perceive to be the fastest and/or strongest.

Open source? Yawn. Player support? No support so far. Oh, except those unknowns foobar and Winamp.

Coincidentally, yes.

I don't believe that this is the case, or at least it is still open to discussion.

It will be interesting to see.

The simple elegance of a lossless codec is that at some point in the not too distant future when the "latest & greatest" lossless audio codec is released you will be able to transcode to it, probably using Foobar, and then ditch the previous data.

What I need now though, is a TaK plugin for GSPlayer..... I mean, I have a spiritual need to see if it plays better than FLAC on my iPAQ.

Premature? Depends on which features you are focussing. As a general statement i consider this as wrong.

Format change? Yes. To make it even better. It's a vivid format.

Let's see if FLAC will continue without a format change when 24 Bit audio is more often beeing used and FLAC's 24-bit compression limitation caused by a design flaw becomes obvious.

Please don't remove your great comparison! Where are the alternatives? I know of no comparison comparing different platforms. And you know, there are other limitations, for instance the effect of the test file selection on the compression results. It's never perfect (unless you are doing nothing else).


Ok. You are right. Possibly this will have to wait until the format change (actually it's rather a tiny modification of the current format).

Ok, I have done some thinking

I only use FLAC as backup of all my CD's, that I keep in the basement.
Portable support isn't important coz my portable player does not support any lossless format.
I asked for portable support because maybe I'll buy a portable player that supports FLAC or TAK in the future but thats in a distant future

For portable I use mp3.


Thomas, how often will you update TAK, is it worth waiting for the next version?

If you're waiting for the next update you'll be waiting forever... Because every format gets better with every update, and with lossless formats as competitively close to each other as they are today every format seems to get slightly ahead of the others for every new update.

So basically, if TAKs current features appeals to you... go for it... you can always convert it to a newer version or some completely other format in the future if you feel like it. Lossless is lossless is lossless.

Ye I know, but I am askin if a update will come any time soon....

I don't want to convert 170GB lossless frequently

I know that feeling... I have like 300-400GB of lossless in various versions of FLAC between 1.1.0 and 1.1.4, just converting it all to 1.1.4 would probably be a huge improvement... but somehow it just feels like too much work. To continuously convert it whenever a better format shows up would probably drive me crazy as well.

Using Synthetic Soul's script it's an automatic, painless job: http://www.synthetic-soul.co.uk/files/flac-113.bat

Despite its name this batch file also works flawlessly in conjunction with FLAC 1.1.4. I used it myself to update a 80 GB archive overnight, without encountering any problems. Of course, in your case the conversion would take a lot more time, but since the script kept doing its job in the background, this shouldn't be much of a hindrance in practice. In conjunction with gharris999's FLACGetV script it even skips the already 1.1.4-compressed data, saving some time.

Edit:

No real disadvantage of TAK, due to foobar2000 creating an excessive amount of seeking points via piping anyway. At least that's what I read somewhere around here a couple of times. Haven't encountered this issue myself so far, because I compress to FLAC through EAC+REACT2 instead, updating the archive is done using the script mentioned above.

This seems to happen only when you transcode from FLAC to FLAC with piping within foobar. When you use an intermediate WAV file or Synthetic Soul's script no additional seek points are added. (IIRC this has no negative effect other than being ugly to look at )

Frankly, if you think about recompressing your archive, why not take some albums and convert them with some recent codecs? If you select your albums well you can estimate how big your gain will be. Might help making a decision...

Yes. IIRC it is recommended to use a temporary WAVE file when converting to FLAC with foobar, as a conflict between the way that Peter and Josh see STDIN working means that piping to FLAC results in an inordinate number of seek points being created.

TBeck, don't take it as a criticism, he is just saying what you are replying, it is changing for the better, and because it is too new, is a good moment to do "non-backwards-compatible" changes.


I think again, that he is asking for short term changes that would render the previous format not-compatible.

Well, possibly i am a bit too sensitive here. I tend to associate "premature" with "unreliable" and "not trustworthy". I never would deny the fact, that TAK is missing some features, which are important for some people.

Honestly, i don't like to have to perform a bit as a marketing guy ("My dingeling is longer than your dingeling"). But since the publication of TAK i have to. Well, others are doing the same, but possibly a bit more decent. But now stopping whining....

Thomas

The next version will not change the format, but add some tiny compatible improvements and some new functionality. On average you will not experience a significant compression advantage.

I can not tell you, when i will perform a format change, because i want to collect all new format-breaking ideas and then release them at once. The optimization of those new methods will take some time, therefore it's quite possible to take maybe 3 to 6 months.

But expect nothing ground breaking compression wise. The expected advantage will be quite small compared to the advantage TAK already has compared to FLAC.

One improvement is intended for high sampling rate files (96 Khz and more) and will not affect the efficiency of CD audio compression at all.

Thomas

I meant the decoding speed. once 2 different algorithms are completely optimized (cannot be made any faster) then the runtime will reflect fundamental differences in complexity. I think these 3 codecs approaching that point for decoding.

it's possible to add things to FLAC in a backward-compatible way. the difficulty is getting it to the hardware makers in a way that doesn't cause problems for users, but this has already been done twice for FLAC.

once TAK is open source, all the other codecs will be free to pick and choose techniques that can improve them.

ok, I'm just saying if a comparison is only showing one decoding time as "the" decoding time for a codec, the most representative one is the one I described. that doesn't preclude a comparison showing more than one that includes tagging or verifying or something else.

BTW for comparison-testing purposes, to disable md5sum checking for flac decoding you can run "metaflac --set-md5sum=00000000000000000000000000000000 file.flac" on the file after it is encoded. that will clear the md5 and the decoder will not do md5 checking on the file.

this is due to all comparisons being done on x86 where there is so much variation in the hardware and optimizations. that's partly why I do my comparison on a primitive machine.

on modern PCs, where all the time variation is, decoding time is almost a moot point since most codecs are already decoding at high multiples of realtime.

Thomas, you don't have to, your codec is well regarded here. The prove is all the topics/questions/etc. And people asking to open it (either the sources or the specification) are prove to it.

YES. But then existing "old" players won't play "new" TAK-FLAC



Format stability. This is not criticism, it's because TAK is NEW



Did not know ... then FLAC should either keep the format ... or change AND add TAK algorithm at this occasion

no worries, I have a good relationship with the various hardware makers and we make sure that doesn't happen.

WinAmp ? Then QCD and 1by1 will also support it on my win98 multimedia monster

humm... the standard format should stay FLAC, cuz there is already more hardware and software support than any other lossless format. So, if it's possible, the different developers of the codecs, especially TAK and WavPack (when I'm thinking of hybrid and lossy mode), should work together with FLAC developers or get their technologies together. Developing his own format will result in the end to a confusing format world for users! TAK is a the moment a strong codec, but I think it won't survive or will be the standard... well, we will see what the future will bring us!

What "design flaw" would that be?

The allowed range of rice parameters is too limited. Big residuals can not be compressed efficiently. Josh told, that this may be cured by a later format change. It's less an issue on 24 bit samples with high sampling rates but the effect can be very obvious at for instance 24-Bit / 48 K.

Nobody is immune against such failures. I for example found some rare samples were TAK would benefit from a higher resolution of the filter coefficients as is supported by the current format.

Thomas

Totally disagree. The advantages of having a plurality of choices cannot be discounted. Since the audio IS lossless, we CAN always jump ships if another codec comes up with features more suited to our purposes. Each lossless codec is fulfilling a "niche" (e.g. LA/OptimFrog for ultra high compression, FLAC for hardware/software support, TAK for high compression w/o compromising decompression and so on). I hope that developers work towards making their codecs better performers in their niche than working to make some bland "standard" codec that attempts to be everything to everybody.

Hmm... Looks pretty handy. I'll take a look at it, thanks.

Here's what I did:

Instead of converting with foobar or any script, I choose to rename all my files and later convert to wav.
Some time ago when I converted from mixed lossless formats to latest FLAC I got 1 error on 4000 files.
So this time I choose to convert to wav, to be on the safe side.

I renamed all my lossless files to
Artist - Album [Year] Tracknumber Trackname
example:
Dark Empire - Distant Tides [2006] 03 A Soul Divided.tak

I used Rename Master
http://www.joejoesoft.com/vcms/108/
perfect

So no more need for folders when converting, just one plain simple folder.

I'm happy now, all TAK files.

And it keeps all the tags! It keeps all the tags! Oh that made me so happy when I saw that script when the new FLAC came out!

Thank FLAC 1.1.4 for that BTW, not my script; it's native to FLAC.EXE, when using a source FLAC.