Purpose of this thread

- I will post news about the development of the next TAK version.
- I may ask you questions regarding new features.
- You may comment my work, ask for features and help me to do it right.

What i did until 2007-12-19

I have replaced some of the Delphi libraries with own code. This will help a later translation to standard C, which can't use delphi libraries.

A nice side effect: Most of the binaries are much smaller now.

Excellent work tomas. Now, why don't you move to freepascal/lazarus, instead of moving it to C code? I mean, it should be 90% compatible or more, and it is portable.

Hi Thomas... nice that you wrote that! It's good when developers are charismatic like this!

Three features I find handy that could come this time are:

1) Embedded albumart.
2) Unicode support.
3) Internal tagging.
4) I find the setting numbers funny (p5x, pm3, p0b..etc I know they're not like this but I never got hold of it), so I would think that friendly "human" switches would be added: --extreme, --insane, --normal, --fast kinda thing.

Multi-channel, MD5, embedded cuesheets could be added later!

Oh and the website of TAK - is there an english version? German is not a very friendly language to me... (I say that because I'm portuguese speaker).

-album art
-TOC file support!
-is lyrics time stamp and plain supported?

TAK seems to be a great codec and I wish there was more widespread support for it. I am not an OS nutjob and I know the issue has been raised but I couldn't help but wonder if there may not be more support if it was an OS project.

Tbeck, thanks for informing.

I don't know if it's actually feature but maybe enabling some settings like -x of Wavpack or -A function of Flac to maximize already max preset without decoding penalty.
It was already mentioned that 1.0.4 will have higher decoding speed. It's more than welcome.

Tbeck thanks for all your work on TAK... i can't thank you enough. Now that i'm moving my entire collection to lossless, TAK's excellent compression without sacrificing decode quality has been a godsend.

At this point the only thing i can ask for is more compression .

I was hoping you could add pipe support for decoding and a quick verify feature like what is included in Monkey's Audio 4.01 available to both takc as well as the GUI (MAC only offers quick verify from the GUI).

Using E or M does not affect decoding speed (my proof).

NB: I am part-way through testing 1.0.4. Give me a few days.

Hi Tom, IMHO anything tag related can wait as we already have external tools that can do this.
I'm in favor of fast seeking without seek table/put seeking information in the bitstream which would finally complete pipe encoding.
MD5/Verify stream for corruption would be a bonus.

according to synthetic soul page... FLAC 0 is still the fastest codec? Time to go after it!

Why would that be a priority? Especially since TAK Turbo's compression ration is better than the much slower FLAC 7. Oh and thats without the Extra switch. Turbo Extra has a better compression ratio than FLAC 8.

IMO native tagging support should be a high priority. As it would be another step in making TAK more user friendly. And that's what is holding me and many others back from using TAK as their primary Codec. Since TAK seeking already works great, that's something that could be done and is really only an annoyance to those that know what "seek tables" are.

Keep up the good work Thomas!!

+1 for the embedded album art & cuesheets

looks like

- seeking without seek table
- tags
- album art

are the most wanted features!

I mean extra time to spend for max preset. Maybe something like turbo insane-max preset. Not fast encoding but very fast decoding.


On average Tak turbo (p0 without extra or max) has better compression ratio than flac -8

- embedded cuesheets

How can it be easier than this?
You could have a million reasons not to switch to TAK but tags/cuesheet/album art/anything that can be stored in APEv2 tags shouldn't be it.
I really doubt that anyone that is currently using TAK are not tagging their files, even if they're not using foobar2000.

Well said!

One more vote for pipe decoding. :-)

(I did try to trick it by using an output file of "CON", but that didn't work...)

I think people mean APEv2 support in the encoder.

+1 for the embedded cuesheets and MD5

Btw, great work Thomas, many thanks.

I see people are pushing for MD5 support. If no work's been done yet, I suggest considering SHA-1. I know it's not necessary (MD5 is good enough), but the Via C7 CPU (featured in the $199 Wallmart gPC), for instance, supports SHA-1/256 hashing in hardware. On modern systems the difference would be minimal (slightly longer decoding), but on that platform it would save a few seconds of decoding per album.

I'm not pushing for it, merely saying that since you have the opportunity to think this through, you might want to consider it. Given its cheap price and extremely low power consumption, the C7 (and its successors) might become somewhat popular, future CPUs from Intel & AMD might support hardware SHA as well, etc... In any case, MD5 would be good enough.

My votes go for pipe decoding, unicode support and md5 of audio part (or other type of hash), in this priority order (from high to low).

If SHA-1 is so progressive, why not? In any case, lossless codec needs audio data crc-verification. I can't find true tests, but looks like SHA-1 is indeed faster (main difference sha-1 is crypto-reliability in compare with md5, but this should not concern us).

Just to clarify my request for quick verification, I'd like to see a checksum for the compressed audio data which can be used to verify against corruption without the need for decoding. The checksum should be generated after encoding and should not be affected by things not directly related to the audio data such as tags.

greynol: Do you mean something like the -m switch in wvunpack?

I'm asking for TAK to have the ability to perform an internal integrity check on the compressed audio data without having to perform a decode or test decode operation. I do acknowledge that unlike MAC, TAK does decode extremely fast, to the point where this might not make any difference @-p0, but can at higher compression levels.

I do think it's a good idea if TAK can provide a checksum for the decompressed PCM data as well. md5 would be nice (to be compatible with WavPack and flac), but standard CRC32 would be nice also since ripping programs like EAC and dBpoweramp generate these instead of md5 hashes.

On the topic of checksum integrity of the PCM data, it would be great if TAK didn't/doesn't have the vulnerabilities against hardware problems that have affected flac in the past. Perhaps the initial checksum was derived from the source data independent of the encoding process?

...just throwing out ideas.

Do you mean TAK's verify option (-v) ?

From the manual:

"With Verify enabled, any compressed frame is subsequently decompressed and then compared to the original data. This reduces encoding speed, but is useful for the more paranoid among us!"

It's not exactly the same as a test decode, because it doesn't check the container. But since the encoding of the audio data is the real number crunching process (with much hand optimized assembler code), it's to be expected that faulty hardware would fail here.

Thanks, Greynol. Good idea!

Thomas

The proposed internal integrity check I'm requesting would be like using -t from the user's perspective. The key difference is that it wouldn't try to decode the data rather it would just calculate a checksum from the compressed data and compare it to the one stored after the file was initially encoded. I hope this makes sense, like I said earlier, it's the same concept as the "Quick Verify" option in Monkey's Audio 4.01.

Regarding the md5/CRC32 checksum of the raw PCM data, I hope the idea of calculating it from the original source from a separate pass than the one used to encode makes sense. When a checksum generated this way is used to verify an already encoded file (like wvunpack's -m option) and aside from a collision, there would be no doubt that the decoded file was indeed identical to the original source.

Now clearly this type of checksum probably couldn't be calculated when encoding from stdin. Speaking of, does -v work when encoding from stdin? I haven't checked into it.

Anyhow, I'm not expressing any lack of faith in the way you've implemented -v, just wondering if it has the potential of better catering to the more ultra-paranoid among us.

I apologize if this was already discussed as you were developing TAK/YALAC.

I have 1 feature in my wishlist: simple, easy to understand presets like flac--0 for the fastest but weakest compression and 10 for maximum but slowest compression.

The only problem with this that you can't draw a monotonic curve depending on encoding speed and efficiency with the current TAK parameters - there are modes that probably compress slower but less efficiently (extra/max modes) than the next, 'higher number' mode (the plain ones) - but without the decrease of decoding speed (which is inevitable should we increase the number of predictors). In my opinion the right way to alleviate this contradiction is to define extra evaluation level(s) to the compression settings, and have parameters like 0..9 and 0e..9e. And current TAK implementations do exactly this
(But if you have some better idea how to distribute these parameters to make one quasi-linear parameter set, don't hesitate. After all, that would not be so bad )

I think I have said it before, but at the moment, playback compatibility in Linux is of high importance, since many use Linux. I am not asking that you will begin to rewrite that whole program to linux at the moment, the focous should be windows. But a playback codec for Linux is right now an important factor if I am going to switch from Flac to TAK, I wish you good luck and thanks for your great job!

Can you please explain what pipe decoding is good for?


Given TAK's high decoding speed i doubt that a checksum validation only integrity check would be much faster than a test decode. But i will keep it in my mind, although not with a top priority assigned.


Yes, a seperate pass does definitely make sense if you are worried about hardware problems and should make the more ultra-paranoid among us happy...


It should work.


Very well said

Transcoding from the command line (to lossy or other lossless formats). It will also provide more enhanced usage with shntool. As an aside to the author of shntool, will the len mode give proper information with tak files?

Understood. Thanks for the consideration.

I've been doing this via batch file when creating MAC files for a while now. Monkey's Audio has a notorious reputation for being susceptible to hardware problems and this method isn't much slower than using -v when done with the special build of mac.exe that provides pipe decoding.

I intend to ensure that the WAVE info is correct. The amount of effort required depends on whether the WAVE header piped from takc.exe is accurate.

Some formats (ape and aiff) do not have accurate WAVE chunk sizes, so shntool tries to figure them out based on my analysis of example files. For ape files, I believe the overall WAVE size is wrong, and the fix is relatively straightforward for shntool. For aiff files, the WAVE data size is wrong, and requires shntool to parse the AIFF header to figure out what the data size should be.

In both cases, mac.exe and sox.exe would have eventually written the correct values to the WAVE file, by fseek()'ing back to the WAVE header and writing new information. However, fseek() doesn't really work on stdout, which is why shntool has to do some extra work.

Long story short, if takc.exe writes a complete, correct WAVE header to stdout upon decoding, then shntool should work right out of the box (hint, hint, Thomas ). Otherwise, there will be some work required on my part to figure out the correct values.

Maybe I am a bit Offtopic but TAK know is available on Chip: German Chip

@TBeck: I wrote a few words about TAK because the description from Chip is really facile.

Hear, hear

Currently TAK will write a correct wave file header before sending the audio data if the file has been compressed with the wave file meta data option enabled (default). Otherwise it will try to seek back and update the wave header after sending all audio data. But i am sure i can make it always write a correct wave header first.

Currently my plans for new features in TAK 1.0.4 are:

- Pipe decoding.
- Seeking without seektable (IMHO not really important but some users seem to feel better with it implemented).


Thank you very much! This explains the increase of accesses to my homepage...

Thomas

Thomas,

I may be out of line, but as you have already expressed interest in the lossyWAV project, I thought that I might ask this question anyway:

As the codec_block_size used during lossyWAV processing is stored in the "fact" chunk contained immediately after the "fmt " chunk, would it be possible for you to utilise this to automatically set the TAK block size when encoding a lossyWAV file?

More user friendly. i.e. being able to not have to use a 3rd party program. That's not a good enough reason?? Yeah it's easy for us that are computer savy. But daunting enough for all the minions out there.

Surely. But i am not sure, if i would like to automatically modify the encoder setting (block size) without the user requesting it via the command line. Somehow this wouldn't be nice...

I totally understand your concern - I was thinking along the lines of seamless optimal encoding rather than having to add a parameter to the command line. However, for the user to add -fsl512 to the command line is not the most difficult thing to do after all

I thought they must ask the develloper for permission when they make programms available
But I am happy if TAK gets a bit attention.

I hope so...


TAK's license (in the readme) permits distribution:

"The Software may be freely distributed provided that it is not modified and the original archive remains intact with all accompanying files, and provided that no fee is charged (except for any reasonable fees necessary to cover costs of distribution media)."

And the polish section of CHIP has asked for permission...

Until now i haven't done anything to promote TAK outside of Hydrogen. I am still missing a logo i like!

The CHIP release has taught me one thing: Altough i gave permission to distribute all the TAK archives, they are only distributing the application archive. Not nice if a new user has to search for the winamp plugin and the other archives...

Therefore i will bundle the applications, the winamp plugin and the decoding library in one archive for the next release.

Thomas

Yes I agree-> That is a good idea. Because you need those plugins to play the music. Just tak-files without the ability to play them ist really useless.

I've been looking at hash functions lately, and it seems Tiger was tailor-made for 64-bit platforms, and can run even faster on modern hardware than MD5. Something to think about.

I don't think this would be a good choice...

Error detection in TAK is already very strong with it's 24-bit checksums per frame. Both md5 and SHA-1 wouldn't add much protection.

The main purpose seems to be file identification. But there md5 is the accepted standard. TAK with it's still relatively small user base definitely can't establish a new standard. Possibly widely used audio file management tools could promote SHA-1...

Thomas

will it be easy to port TAK to linux? there can be bundled klyx libraries with the pack.

I agree.


By that rationale, you can't innovate unless you're the first on any given market. Or if you work for Apple?

You've created a new codec from the ground up, you have the opportunity to do whatever you want without worrying about backward compatibility (I don't really care about the hashing algorithm, I'm talking in general). In other words, you have the opportunity to look forward to the future, with 64-bit platforms, multi-core CPUs, large amounts of RAM, increased bandwidth, Solid State Drives, etc... instead of looking back to the past. You have the opportunity to innovate where others can't afford it. Just a thought, anyway.

That said, I'm looking forward to TAK support under linux (someday, eh?)
On a side note: when you implement APEv2 tagging in the encoder, don't forget to support null-separated lists of values. Everybody seems to overlook that feature.

I've been making use of flac's --skip and --until options and was wondering if you could include similar features in a future version of TAK.

The ability to output raw PCM (as well as encode it) would be nice also.

Thanks for the input. I will put both items on my to do list.

With TPM devices already being included in laptops, and with Intel planning on integrating them to the southbridge this year, it looks like SHA-1 is getting more and more hardware support. MD5 and CRC32 belong to the past.