New version of the TTA free lossless audio compressor has been released. New in this release are speed optimization; code changes necessary to support 64bit architectures, e.t.c.. Windows executables compiled with MinGW gcc-3.4.2.

TTA compressor for Windows: ttaenc-3.4.zip
TTA compressor for Linux: ttaenc-3.4.tgz

For more info please visit the project homepage

thanks for the update -

does this version incorporate the shntool patch?

found here:
http://etree.org/shnutils/shntool/
http://etree.org/shnutils/shntool/support/...3-shntool.patch

...essentially providing piped input/output and moving stdout to stderr.


later

Thanks for your comment. This patch not yet incorporated, because I did not know about it. I will test this patch. I think it can be incorporated in the code at soon.

Aleksander

FYI, I have a newer patch up for ttaenc 3.4. It requires even fewer changes (just stdout -> stderr, and writing WAVE data to stdout when the output filename is "-").

I'm curious about this stdout -> stderr thing. I'm learning programming and was wondering why sderr should be used? I've seen it used in Lame also, but what is gained by using it?

Sorry for the off topic post.

Read some unix basics, you will figure it out.

wow that was fast - thanks, jason

and thanks, ald, imho you should incorporate jason's patch for sure. (3.4.1?)


later

I tried this encoder with only an album (~47 min) and it turned out pretty well, with the encoded file getting 51,5% of the original. The speed was pretty good, about 70 sec, what accounts for 40x encoding.
Wish it had more options, though...

TTA: 70 sec (40x), 51,5%.
Wavpack normal: 57 sec (49x), 52,1%.
Wavpack high: 98 sec (29x) , 51,5%.
Wavpack highest x6 (1x), 51%.

I haven't tried decoding, but at least encoding seems twice Wavpack's speed, for the same final size.
Since I mainly use Wavpack, I can see none of these encoders can fully use a dual-core processor, which is too bad...

i'm not sure what author meant for stdout->stderr, however, stderr output is used for sending informations about the process: errors, warnings. so for example when decoding some damaged file you will get the output file from stdout, and messages from stderr about missing samples, incorrect CRC's, broken frames, etc. u should always check stderr pipe.

TTA compressor v.3.4.1 released (I hope..)

Shntool patch is not included.. but some things from this path have been incorporated.
Thanks to author of this patch! I think it should work )

ChangeLog:

* added support for standard input/output interface
* minor changes in command line options and error messages

TTA compressor v.3.4.1 for Windows: ttaenc-3.4.1.zip
TTA compressor v.3.4.1 for Linux: ttaenc-3.4.1.tgz
TTA compressor v.3.4.1 (Source code): ttaenc-3.4.1-src.tgz

Some of usage examples:

ttaenc *.wav
ttaenc file.tta /audio
ttaenc file.tta -do file.wav
ttaenc -e - < file.wav > file.tta
ttaenc - < file.tta -do file.wav
ttaenc file.tta -do - > file.wav
ttaenc -e *.wav; ttaenc -d *.tta /audio

Aleksander

Thank you for incorporating the changes! I have a request:



In order to support TTA output in shntool, I need a way to specify a) the output filename, and b) stdin input.

For decoding to stdout, the following works:



But I can't make this work for encoding from stdin. I've tried:



I don't know if it's possible, but if you could add this functionality (preferably the first form above), I would be happy to announce support for TTA output in shntool!

Thanks,
Jason

Thank you for testing! You can make this work by changing the arguments order in following manner:
or


I have fixed this small bug without changing the version number. With a new build 20070727 you can place these arguments in any order (I hope )).

TTA compressor v3.4.1 for Windows: ttaenc-3.4.1.zip
TTA compressor v3.4.1 for Linux: ttaenc-3.4.1.tgz

Best wishes!

Aleksander

Aleksander,

Thanks for the quick reply! I can get your command lines to work, but only with redirected input (as opposed to piped input). The problem is that you can't fseek() backwards on a piped input stream, which your compress() routine relies upon.

For example, the following command works:



while this command fails:



The second form is what needs to work before ttaenc can be used by shntool (or other programs) to create TTA files. Anyway, this is not a big deal... you can file this request under the "it would be nice if..." heading. :-)

Thanks,
Jason

When an apology appoints an option and carried it out, a prompt is not displayed.

D:\ttaenc>ttaenc - d:\aaa.tta -do d:\arg.wav
TTA1 lossless audio encoder/decoder, release 3.4.1
Copyright © 2007 Aleksander Djuric. All rights reserved.
For more information see http://tta.sourceforge.net
------------------------------------------------------------
File: [-]
Decode: ..

WAV of 0byte is made, but ttaenc just hopes because processing is stopping so that I display an error and do it, and it is recurred by a prompt.

My tests show a 20% increase in encoding speed, and a 30% increase in decoding speed (3.3 vs 3.4.1).

imho, piped input/output is a *nix "requirement".


later

I agree... so I went ahead and patched ttaenc to support piped input of WAVE data. This allows full read/write support under shntool (I will need to make a new release for this). The patch is here: http://www.etree.org/shnutils/shntool/supp...c-shntool.patch

Aleksandar: This patch was tested for proper encoding/decoding of both regular files, as well as files with an ID3v2 tag. Feel free to apply it if you like!

Thanks,
Jason

I think it's not required to fix, because it's not a correct test. I can to show the usage information in this case.. Is it will be correct?



Thank you for your tests. It's interesting.. It will be nice to find a chance to compile it on MSVC and Intel compilers... I think it will be interesting to compare with GCC results.

Thank you for made this patch, Jason. Once, I has used such technique.. I will think about that. Fseek() backwards is not required really, but it's required to rewrite some parts of the compressor code. Anyway, I think that the patch can be incorporated partially.

I'm sorry not to be able to explain successfully.

When such command is input, and it's carried out, ttaenc hangs and doesn't react any more.


Every time it doesn't react any more, it's troublesome to make them abort it in CTRL + C, so when the designation is wrong, an error message is indicated, and, in a prompt, they seem able to return, won't it be?

I'm sorry, I think that I don't understand what you want to do again..

You have specified decoding mode; 2 input files: standard input and d:\aaa.tta and one output file d:\arg.wav for both of the input files. Compressor will wait data on standard input in this case.