Content
This thread should be used to discuss the first alpha release of my lossless audio compressor TAK (formerly known as YALAC):
1. Bug reports
That's the most important purpose of this alpha testing!
Please try to provide as many details as possible about the conditions which created the error. And please keep the affected files. I may ask you for them.
2. Compression results
They should no longer be posted in the "YALAC - Comparisons" - thread.
3. Ideas for improvements and feature requests
I am aware, that the first release is missing many important features, especially tagging and plugin support for media players. No need to tell me about this...
I will collect your ideas and requests and try to implement them in later releases.
Participiants
Primary the alpha testers, because only they will have the opportunity to test TAK...
This should be the last closed test, the beta will be a public release.
Can you add a link to the binaries? That would come in handy at this place...
unEDIT: Didn't see your response in time.
Request for testers
No, the alpha version isn't done yet, but nevertheless i wanted to start this thread, because
- i want to force myself to release the alpha. I am still not really happy with the design and code quality of some higher level parts of the compressor (especially streaming and file io, the encoder core itself looks quite good). But i know myself, if i try it longer, i tend to get more and more demanding.
- i need some more testers for the alpha.
I will sent the alpha to my core testers:
Destroid
JohanDeBock
Josef Pohm
Synthetic Soul
Other earlier testers may sent me a mail, if they want to try the alpha.
Then i would like to invite up to 10 new testers.
Formal qualification:
"Member of hydrogen since 3 months or more and at least 5 posts."
Take it as a simple "i am really interested into audio processing" indicator.
Please contact me via personal mail.
BTW: I hope to release the alpha until next monday (fingers crossed).
Thomas
New testers list
1. Thundik81
2. Qest
3. Gnerma
4. Omion
5. Zergen
6. Kanak
7. TrNSZ
8. Night Rain
9. audiofreak
edit: new tester added
V0.14 Alpha is done
Let's search for bugs!
The file format will no longer change after this release. Later versions will be backwards compatible.
Changes
Encoder:
- Frame partition resolution 256 is back. It still has a very bad speed/compression ratio, but i hope to improve it later.
Presets:
- Additional evaluation MAX now enables Frame partition resolution 256. A tiny bit better compression, but with a considerable speed penality for higher presets.
Functionality:
- Better error handling: The program should no longer be aborted, if a file io error occurs.
- Removed output of internal encoder diagnostics if "Protocol level" Results & Diagnostics is selected.
File format:
- Generally faster seeking, especially if the seek table can not be used.
- Stronger protection (CRC) of meta data structures. Depending on the frame size up to 0.01 percent compression penality (preset TURBO).
Command line:
- New switch to enable the Verify function for encoding.
- I finally managed to remove some modules which were only needed for the GUI version. The exe is much smaller now and it should take a bit less time to initialize the program. Possibly the processing of single small files will be a bit faster.
Other:
- Fixed the bug reported by Destroid for V0.13: Decoding of a big file (about 700 MB) gave the error "Meta data damaged". Nevertheless the audio data itself could be decoded without any errors.
- Some other bugs removed.
- Rework of the ReadmMe.
Release:
I hope to send the new version to the following testers within the next 24 hours:
Destroid
JohanDeBock
Josef Pohm
Synthetic Soul
Thundik81
Qest
Gnerma
Omion
Zergen
Kanak
Any of the earlier testers not listed here can sent me an email anytime, and i will send the current version.
P.S.: Possibly i will get a faster internet connection within the next 24 hours. If i should encounter technical difficulties, there could be some delay.
What should be tested:
This time i don't want to tell you in detail what to do... Try all the things i never thought of and find the bugs i could not find! That's the most important thing.
Less important:
- Comparisons with other compressors are always welcome...
- You could try some encoding with verify enabled, to check, if it throws false alarms.
Plans for V 0.15 Beta:
- Bug fixes, if neccessary.
I would be happy to release the public beta in early january.
Thomas
why don't you just join the FLAC team man.....you'd be a great asset helping them!!!
Because this is his encoder and it is better.
so instead of fighting an uphill battle it would be great for a merge! no need to add formats and such, FLAC is so popular anyway
I don't think he's competing with anyone, he just wants to make his own lossless codec. Besides, merging two completely different codecs is not as easy as you may think, even if they're both lossless.
so instead of fighting an uphill battle it would be great for a merge! no need to add formats and such, FLAC is so popular anyway
I don't think he's competing with anyone, he just wants to make his own lossless codec. Besides, merging two
I could not have said it better...
I always was primary interested into trying what i can achieve in lossless audio compression. For many years i did it just for my own fun without telling anyone about it! Now it's fun for me to make something usable of it.
Besides, merging two completely different codecs is not as easy as you may think, even if they're both lossless.
I totally agree.
There has been some conversation with Josh Coalson about an integration of Tak technology into FLAC. And i could imagine, that this will happen sometime in the future (if Josh still wants to and if he has not improved FLAC so much, that an integration of Tak would make no more sense...).
But i would not like to do this with the current implementation of Tak. Reasons:
1) The current codec is quite complex. There are about 600 KB of source code (core of the codec only) which had to be translated to C. This would be very much work (i am no wiz in C). I really don't like to spend so much of my free time for something so little interesting. I am in it for fun and would prefer to spend this time for codec improvements.
2) The code complexity is also a bad thing for the integration into FLAC or other open source projects. More code = more chances for bugs and more trouble with adaptions to other systems.
3) Tak is very fast on average, but the peak processing requirements can be quite high. In the discussion of Flake Josh warned Justin, that more than 12 predictors could increase the cpu requirements so much, that some hardware decoders were no longer able to play the files without stuttering. Hey, Tak is using up to 256 predictors! And even with only 12 predictors it's cpu requirements would be considerably higher than with FLAC.
After the public release of Tak i want to evaluate the possibility to build a new codec, based upon Tak technology but with far less code complexity and less cpu requirements. This could be a candidate for a inclusion into FLAC. But i have to try it, before i can say, if it is possible...
First i did not want to answer to this questions in this tread, but probably it was time for an update on this matter.
First i did not want to answer to this questions in this tread, but probably it was time for an update on this matter.
There is a lot of frustration among certain users regarding the sheer amount of competing projects in certain fields, with no single one doing everything they need. One of those fields is audio players under Unix, for instance. I can understand that some users can feel the same way about lossless codecs, with FLAC being well supported, but not so fast and not so efficient, others being almost not supported at all and even slower but much more efficient (OptimFROG [...]), others being faster and more efficient but more or less well supported (WavPack), etc... So, your explanation, for once, makes sense, explains a lot, and is very welcome as far as I'm concerned.
Gnerma checking in. I've just started toying with it and here are a few things:
* No hi-def support in this release? I tried a stereo 24/96 WAV and got an error. The file is 2.31 gb uncompressed.
* Also got an error trying to compress a 2.45 gb 16/44 WAV.
* UI is slow to respond when using slow compression levels.
* UI checks to see if file exists when "Test" is attempted.
I'm not exactly sure if things like this are what you're looking for but if I'll report everything I find to be even slightly off.
* No hi-def support in this release? I tried a stereo 24/96 WAV and got an error. The file is 2.31 gb uncompressed.
* Also got an error trying to compress a 2.45 gb 16/44 WAV.
The current implementation supports up to 24/96. But some parts of my code (file and wave io) are limited to file sizes up to 2 GB or exactly 2.147.483.647 Bytes. It's not a restriction of the encoder itself or my Tak container (supports up to more then 100 GB).
I hope, you got a somewhat senseful error message ("Wave file not supported") or did it simply crash?
To be honest, i didn't know that wave files can be bigger than 2 GB. I thought, there was the same restriction as with avi files...
Gnerma checking in. I've just started toying with it and here are a few things:
* UI is slow to respond when using slow compression levels.
You mean if you want to stop the process?
Well, i wanted it to be as fast as possible and therefore it checks not too often for input. If it's annoying, it should be changed.
* UI checks to see if file exists when "Test" is attempted.
I wanted "Test" to be an exact simulation of the real encode/decode process with file io. Wouldn't i be irritating for the user, if the test succeeds but the real processing gives an error ("file exists")?
After a bit of thinking: No, this check should be disabled. It could happen frequently that the user wants to check the just encoded files with the test option. Then it's quite probable to have both the source and the encoded files in the same folder. It would be annoying to always have to enable the overwrite option for the test...
I'm not exactly sure if things like this are what you're looking for but if I'll report everything I find to be even slightly off.
Not really. I wanted to hear that Tak is the greatest!
Seriously: Thanks! It's exactly what i wanted!
I really didn't know that the size limitation would become so soon relevant! This will be among the top items on my to do list!
Many thanks
Thomas
* No hi-def support in this release? I tried a stereo 24/96 WAV and got an error. The file is 2.31 gb uncompressed.
* Also got an error trying to compress a 2.45 gb 16/44 WAV.
The current implementation supports up to 24/96. But some parts of my code (file and wave io) are limited to file sizes up to 2 GB or exactly 2.147.483.647 Bytes. It's not a restriction of the encoder itself or my Tak container (supports up to more then 100 GB).
I hope, you got a somewhat senseful error message ("Wave file not supported") or did it simply crash?
To be honest, i didn't know that wave files can be bigger than 2 GB. I thought, there was the same restriction as with avi files...
Yes, 2 GB limit if you are too dumb to use an unsigned long for the size values... Forgive me, but when i started my work on Tak, the Delphi 3 compiler i was using did not support unsigned longs...
It should be quite easy to fix this and increase the size limit to 4 GB. Would this be sufficent for now?
(Currently i don't want to deal with wave files containing more than one audio data chunk.)
Well, looks as if there will be a second alpha release after this test...
[deleted]
Encoded 7 albums so far and found no issues at all. The speed and compression levels are astounding. This is a wonderful codec. Using a E6600 @ 4 GHZ.
I am simply dumbfounded. I expected good results, but this is outstanding. I've tested about 5 albums and everything has been consistantly impressive across the board.
No bugs to report so far.
It's beautiful, TBeck. Beautiful.
Full testing is coming soon, but I've not yet found any problems with any files; I compressed a few GB in different modes as well as my small standard test set here. Only 16-bit 44.1khz input was tested up to this point. I think a slower, higher compressing mode would be appropriate as well, considering the current performance. More work tomorrow, but so far, this is very nice.
Encoded 7 albums so far and found no issues at all. The speed and compression levels are astounding. This is a wonderful codec. Using a E6600 @ 4 GHZ.
I am simply dumbfounded. I expected good results, but this is outstanding. I've tested about 5 albums and everything has been consistantly impressive across the board.
No bugs to report so far.
It's beautiful, TBeck. Beautiful.
I am really grateful for this fast feedback! Thank you!
It's a very nice compensation for the many lonely nights with so little sleep...
BTW: Looks as if i have fixed the 2 GB bug. Now for the next two items on the new todo list...
Thomas
The current implementation supports up to 24/96. But some parts of my code (file and wave io) are limited to file sizes up to 2 GB or exactly 2.147.483.647 Bytes. It's not a restriction of the encoder itself or my Tak container (supports up to more then 100 GB). I hope, you got a somewhat senseful error message ("Wave file not supported") or did it simply crash?
Yes, the error in both instances was wave file not supported. The greater than 2gb 16/44 file is actually a 4 disc album that I'd spliced together because I'm weird like that. Not something too uncommon for people on forums like this though I'd wager.
I'm sure 4gb would be fine for most everybody but ideally the compressor should support any valid WAV file. If that is 400 tb then so be it.
* UI is slow to respond when using slow compression levels.
Well what seems to be happening is the UI is only getting updated when its absolutely necessary, or when the compressor finishes 1% of the operation. So if you're switching between windows you could end up getting a square with the dead image from the last window instead of the contents of the UI, until it updates anyway. I personally don't like this kind of behavior I suppose because it gives the user the impression that the program is unpolished. This is just me of course..
Stopping the process isn't a problem.
* UI checks to see if file exists when "Test" is attempted.
Modified. Both test modes (encoding/decoding) now ignore the presence of the destination files.
The current implementation supports up to 24/96. But some parts of my code (file and wave io) are limited to file sizes up to 2 GB or exactly 2.147.483.647 Bytes. It's not a restriction of the encoder itself or my Tak container (supports up to more then 100 GB). I hope, you got a somewhat senseful error message ("Wave file not supported") or did it simply crash?
Yes, the error in both instances was wave file not supported. The greater than 2gb 16/44 file is actually a 4 disc album that I'd spliced together because I'm weird like that. Not something too uncommon for people on forums like this though I'd wager.
I'm sure 4gb would be fine for most everybody but ideally the compressor should support any valid WAV file. If that is 400 tb then so be it.
Fixed. Now up to 4 GB should be supported.
Breaking this limit will need considerable more work. I don't want to do it for the first public release. Sorry...
* UI is slow to respond when using slow compression levels.
Well what seems to be happening is the UI is only getting updated when its absolutely necessary, or when the compressor finishes 1% of the operation. So if you're switching between windows you could end up getting a square with the dead image from the last window instead of the contents of the UI, until it updates anyway. I personally don't like this kind of behavior I suppose because it gives the user the impression that the program is unpolished. This is just me of course..
Stopping the process isn't a problem.
Improved. Window updates should now be performed at least once every second. Well, this is not really exact, because the update latency currently depends on the system speed. But if it's fast enough on my good old P3-800, it should be ok for now.
Later i will implement an option to let you control the task priority, but not for the first public release.
Thank you for all your findings!
Thomas
point. I think a slower, higher compressing mode would be appropriate as well, considering the current performance.
I agree. There are some optimizations possible for the current codec, but i wouln't expect more than an average improvement of about 0.3 percent.
Possibly i will work on a new codec similar to the current one but with more methods to improve the compression. I allready worked on it but there were some really complicated optimization problems which needed much evaluation, too much to perform it before this release.
But the file format is prepared for the addition of new codecs...
I'll just bump in with a few questions although I'm not an alpha tester...
Wouldn't it be better to use a seperate thread for the encoding so that the UI isn't affected by it in any way? I think there are many problems when both tasks are coupled.
It seems that so far there's only a GUI version, so is a CLI encoder/decoder planned?
Wouldn't it be better to use a seperate thread for the encoding so that the UI isn't affected by it in any way? I think there are many problems when both tasks are coupled.
I am always a bit hesitant to use multi threading, because i don't have a multi core system and therefore am not able to check for thread synchronisation issues. If this changes, i will care for it and also built a multicore encoder (should be easy with TAK's design).
It seems that so far there's only a GUI version, so is a CLI encoder/decoder planned?
There are TAK, the GUI version and TAKC, the command line version. But you are right, in the beginning there was only a GUI version.
TAK vs The Rest of The World:
http://www.synthetic-soul.co.uk/comparison/lossless/ (http://www.synthetic-soul.co.uk/comparison/lossless/)
TAK 0.14 vs TAK 0.13:
http://www.synthetic-soul.co.uk/comparison/tak/ (http://www.synthetic-soul.co.uk/comparison/tak/)
Sorry for the delay, I thought I better update to FLAC 1.1.3 and WavPack 4.40 at the same time, and those WavPack x modes take some time! Unfortunately it looks like I screwed them up somehow, so I'll have to spend a couple of days running them again! I have reverted back to 4.4a3 for now.
Once I've got decent WavPack 4.40 results, I will do some more timing tests with TAK, when verifying while encoding, as I think it will be interesting to compare to encoding with no verification. After that I'll try to find some time for damage.
VERY nice.
I just encoded 58GB of music, and even preset 0 easily beats FLAC level 7.
Here's some compression results:
Input: 61994308200
TAK 4: 31826185295 48.66% savings
TAK 0: 32927983729 46.89%
FLAC7: 33929274512 45.27%
I also tried to trip up the codec with strange signals like adding DC offset, extreme clipping, odd sample rates, etc. No problems whatsoever. This is looking really good!
I'll see if I can do some more tests soon.
Sorry for the delay,
Ok, for this time...
Thank you!
Sorry for the trouble.
Once I've got decent WavPack 4.40 results, I will do some more timing tests with TAK, when verifying while encoding, as I think it will be interesting to compare to encoding with no verification.
That's a very nice idea! I never really evaluated it.
I just encoded 58GB of music, and even preset 0 easily beats FLAC -7.
Here's some compression results:
Input: 61994308200
TAK 4: 31826185295 48.66% savings
TAK 0: 32927983729 46.89%
FLAC7: 33929274512 45.27%
Fine!
Although i have to admit, that i am not familar with FLAC -7.
I also tried to trip up the codec with strange signals like adding DC offset, extreme clipping, odd sample rates, etc. No problems whatsoever. This is looking really good!
That's really great! Thank you for such an exhaustive and creative testing!
This all really diminishes my fear to release a public version...
Although i have to admit, that i am not familar with FLAC -7.
Well, I meant FLAC preset level 7 (the command line is "flac -7", which is why I worded it that way)
I edited my previous post to clear up any misunderstanding.
Hmm. I've got a file that compresses better with Tak Normal than Tak High /Extra High.
The song i tried was "drug me" by Dead Kennedys. Here's the result:
Original Size: 20369896 (bytes)
Tak Turbo: 8743793
Tak Fast: 8732490
Tak Normal: 8500839
Tak High: 8666097
Tak Extra High: 8598122
More thorough testing coming soon.
[deleted]
Hope that is useful, funny to see how many times the max mode of a lower setting outperforms the next standard setting (and still decodes faster).
Oh yes.
What differentiates the higher from the lower presets?
1) A better evaluation of some compression parameters. The higher presets are adding more and more of the evaluation options. Max can do the same for the lower presets. If the compression advantage of a higher presets is caused by the better evaluation, then a lower preset + max can achieve the same.
2) Higher presets can use more predictors. But the usefullnes of more predictors varies very much depending on the files. Some are happy with 4 - 8 predictors, most like up to 32 (seems to be the sweet spot) and quite rare files benefit enormously from up to 256 (or more, earlier Tak used up to 512) predictors.
3) High and Extra can use the Prefilter. Very efficient on some files, small effect (0.1 to 0.2) percent most of the time, even can hurt sometimes. Unfortunately it is often beeing applied even if it's advantage isn't significant. But if applied, it will definitely reduce the decoding speed. Well, that's the price we have to pay for the very fast encoding: It's based upon fast estimations which work perfectly most of the time but sometimes fail. A very very slow insane mode could cure this.
Also funny to see how different the results are here than on the previous test I ran.
Yes, this is always a bit strange. It's really difficult to create a representative test set to judge codec performance.
Your first set was a very Tak friendly one. Only in rare cases it will outperform for instance Monkey's Extra High.
Your second set is closer to my average impression. Well, possibly a bit worse.
The truth may lie somewhere in between.
Thank you again!
Thomas
[deleted]
I've compressed Seabound - Double Crosser Limited Edition 2-CD:
548,423,733 OptimFROG 4.600ex extra high.ape
547,063,517 OptimFROG 4.600ex insane.ape
These two are a little confusing to me. I think I know what you mean, but it could be clearer...
BTW, the biggest part of the new WavPack release is the work I put into the -x modes levels 1-3 (which are now completely new) and I see you're not using any of them for your tests. The plain -x option (no param) is now completely usable in fast and normal mode. It gives a nice compression boost with not much of an encoding speed hit and (like before) no decoding speed hit. At this point I think that the only time it makes sense to
not use it is when you're really in a hurry to encode something, and I've thought of making it the standard operation.
Just a thought, and thanks for your testing...
BTW, the biggest part of the new WavPack release is the work I put into the -x modes levels 1-3 (which are now completely new) and I see you're not using any of them for your tests. The plain -x option (no param) is now completely usable in fast and normal mode. It gives a nice compression boost with not much of an encoding speed hit and (like before) no decoding speed hit. At this point I think that the only time it makes sense to not use it is when you're really in a hurry to encode something, and I've thought of making it the standard operation.
Just a thought, and thanks for your testing...
Thanks! I was just about to ask what to switches to recommend for the latest WavPack evaluation. I was just using: -f, [default] and -h. I think the faster-decoding modes are appropriate to use when comparing to TAK.
[deleted]
Hmm. I've got a file that compresses better with Tak Normal than Tak High /Extra High.
The song i tried was "drug me" by Dead Kennedys. Here's the result:
Original Size: 20369896 (bytes)
Tak Turbo: 8743793
Tak Fast: 8732490
Tak Normal: 8500839
Tak High: 8666097
Tak Extra High: 8598122
Interesting. Thank you!
This can happen, because the encoder only estimates the effect of some compression methods and sometimes this fails and it makes the wrong choice. Most probably it is applying the Prefilter although it hurts or it is using more predictors than neccessary.
I have one file in my test corpus with some similar failure.
Would it be possible to send me about 20 to 30 seconds (if it's legal in your country!) of this file which are able to reproduce this effect? I would like to look for the reason of this misbehaviour.
Thomas
[deleted]
I've now emcoded 29 albums and various "problem tracks" and I haven't found any anomalies whatsoever. This will be my codec of choice once a Foobar plugin is released. This is the biggest change in speed and compression I've seen in any lossless codec in years.
I'll do some 24/96 multichannel later.
Important question
I am tempted to release a second alpha until wednesday.
It fixes the 2 GB bug. For this i had to switch to Int64 types in several places of the code. Unfortunately the code parts where the default Int32 types and the Int64 types are mixed have some chance to create errors (i allready found some by myself). It is really neccessary to test this new version before the beta release.
I think it would be ok to use the new version for our testing,
- because anything else looks ok and i wouldn't expect to encounter more severe failures of the current alpha (V0.14)
- and because i don't want to ask you to repeat your testing for a new alpha released after christmas.
Compression and speed should not be affected by the bug fixes.
What do you think?
As for me, it's ok
[deleted]
I'll be interested to try this codec once it enters the beta/stable stage!
This will be my codec of choice once a Foobar plugin is released.
If I decide to use lossless compression again (i.e. weigh up the need for with a 279 GB disk and limited CD collection), I may be joining you!
TAK vs The Rest of The World:
http://www.synthetic-soul.co.uk/comparison/lossless/ (http://www.synthetic-soul.co.uk/comparison/lossless/)
TAK 0.14 vs TAK 0.13:
http://www.synthetic-soul.co.uk/comparison/tak/ (http://www.synthetic-soul.co.uk/comparison/tak/)
Sorry for the delay, I thought I better update to FLAC 1.1.3 and WavPack 4.40 at the same time, and those WavPack x modes take some time! Unfortunately it looks like I screwed them up somehow, so I'll have to spend a couple of days running them again! I have reverted back to 4.4a3 for now.
OK, comparison is showing WavPack 4.40 now.
I've run the -v tests today also, so hopefully tonight I'll get opportunity to collate and post figures.
Here's
CPU-only results, showing the difference between using -v (verify) while encoding, and not.
Preset No -v -v Diff
=================================
Turbo 98x 63x 156%
Turbo Max 39x 32x 123%
Fast 64x 45x 143%
Fast Max 28x 24x 117%
Normal 43x 34x 128%
Normal Max 24x 21x 115%
High 28x 23x 120%
High Max 15x 13x 110%
Extra 18x 16x 114%
Extra Max 7x 6x 105%
I may compile these for CPU+IO rates as well, but the obvious assumption is that my hard drive throttling will narrow those differences a fair bit. The fastest I seem to be able to get writing to disk is ~80x, so even with Turbo it should drop to around 130-140%.
Hmm. I've got a file that compresses better with Tak Normal than Tak High /Extra High.
...
Interesting. Thank you!
This can happen, because the encoder only estimates the effect of some compression methods and sometimes this fails and it makes the wrong choice. Most probably it is applying the Prefilter although it hurts or it is using more predictors than neccessary.
I had the opportunity to test (a part of) the file.
First the compression ratio for any preset, each with default and maximum evaluation:
Standard Max (Evaluation)
----------------------------------------
Turbo 42.93 41.99
Fast 42.87 41.55
Normal 41.73 41.37
High 42.54 42.34
Extra 42.21 42.06
There is something in Max evaluation which really helps Fast: 1.32 better compression. It is also present in Normal default, where the advantage of Max is much smaller.
Let's find out what in evaluation max is responsible. Try Fast with each single option that would be added by evaluation max:
Fast (default) 42.87
Channel decorr.: Check Both 42.87
Channel decorr.: Mid/Side 42.84
Bitcoder: Optimize choice 42.81
Partition resolution: 256 42.77
Partition Calc.: Validate 42.65
Optimize Quantization 41.98
Fast + Max 41.55
Sorted by compression.
Obviously "Optimize quantization" is the winner. That's very rare and therefore very interesting for me.
Now for High. Let's use maximum evaluation and play a bit with the PreFilter sensitivity:
High + Max 42.34 (Prefilter medium)
-Prefilter low 42.27
-Prefilter off 41.22
Huh, better disable the PreFilter for this file...
Well, sometimes my fast parameter estimation fails. I will evaluate this later.
V0.15 Alpha is done
Changes:
Improved:
- Support for wave files of up to 4 GB Size (2 GB before). To be exact: 4 GB - 15 Bytes...
- When test encoding/decoding files existing destination files are beeing ignored.
- GUI version responds faster when using slow presets.
And an update for the Damage tool (V1.02):
- Support for files of up to 32 GB Size (2 GB before).
Release:
I hope to send the new version to the alpha testers within the next hours.
What should be tested:
No changes. Keep on your good work!
Feedback of the two testers who found the 2 GB bug would be nice.
Thomas
Thanks for the update Thomas. No change on the my greater than 2gb WAVs. The program still throws "Wave file not supported" for both.
Thanks for the update Thomas. No change on the my greater than 2gb WAVs. The program still throws "Wave file not supported" for both.
Too bad...
Is there any meta data embedded?
Would it be possible to send me the first 100 KByte of the file?
Probably there is something in the file header that my very simple wave file reader can not handle.
Sorry...
P.S. Currently Tak is not able to handle files with more than two channels!
edit: P.S. added.
I've uploaded my test results for the Drug Me Sample.
Download Links:
HTM: http://www.freewebs.com/kanak/DrugMe.htm (http://www.freewebs.com/kanak/DrugMe.htm)
PDF: http://www.freewebs.com/kanak/DrugMe.pdf (http://www.freewebs.com/kanak/DrugMe.pdf)
XLS: http://www.freewebs.com/kanak/DrugMe.xls (http://www.freewebs.com/kanak/DrugMe.xls)
Song Details:
Song Tested: Drug Me by Dead Kennedys (Album: Fresh Fruit For Rotting Vegetables)
Song Length: 1:55
Uncompressed Size: 19.4 MB
Test Bed:
Dell e1505 Laptop: Intel Core 2 Duo T7200 @ 2 Ghz, 1 GB Ram, 120 GB HDD 5400 RPM
Purpose:
0. To see if I have configured Synthetic Soul's scripts properly by doing a "real world" test on a small file.
1. To test TAK
2. To see if the anomalous behavior of TAK on this file (compresses better with TAK Normal than TAK High or Tak Extra High (See Here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=50958&view=findpost&p=458025), and here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=50958&view=findpost&p=458230)) is also shown by other Encoders
3. To test the maximum compression + experimental option in the experimental version of OptimFrog (version 4.600ex)
4. To test the new -x switches in latest wavpack (version 4.40.0)
Encoders Versions and Switches Tested
1. TAK 0.15 Alpha: All Switches + Max for each
2. FLAC 1.1.3: -0 to -8
3. Wavpack 4.40.0: All Switches + (x1 through x6 for each)
4. Monkey's Audio 4.01: Fast through Insane
5. Optimfrog 4.600 ex: Default (no switches) and (--maximumcompression --experimental)
6. ALS RM18: Default (no switches), -7 ("maximum compression"), -a -o32
Remarks
1. The "anomalous behavior" is also shown by Monkey's Audio (the compressed size is smaller with Extra High than with Insane), also by FLAC (-1, and -2 compress better than -3), and by Wavpack (-fx5 and -fx6)
2. Decoding speed figures are pretty "unreliable" because the song is so short. It definitely can't be used to establish trends across different switch combinations for the same codec. But it's still somewhat valid across different codecs. Nevertheless, the TAK's decoding speed, especially at higher compressions, is unmatched by any other codec. Kudos to Thomas.
3. Tak specific comments:
Amazing Performance. TAK Turbo encodes faster AND compresses better AND has better decoding speed than FLAC-8. Similarly, TAK Normal trounces Wavpack even at -hhx6. However, there's still room for improvement at the maximum compression settings (TAK can't match OFR even at default OR monkey's at insane)
4. Wavpack switches
The -x1 to -x3 switches do seem more usable (i.e. don't have a significant performance hit) than before, although the performance with the -x4 to -x6 switches are pretty horrid (as warned).
Future Plans
- Test on larger files (album images for different albums across genres)
- (Hopefully) Include WMA Lossless/ALAC
- TAK Specific: Use Damage tool to test error resilience
Edit: Corrected some typos
I've uploaded my test results for the Drug Me Sample.
Thanks for having the patience for testing so many of the WavPack modes!
BTW, that is an interesting sample! Would it be possible for me to get a clip of it also for my test corpus? I would appreciate it...
I've uploaded my test results for the Drug Me Sample.
...
Wow, thanks for providing such a nice amount of extremely interesting data.
I'm a DK fan too (course talking about the Jello era), gonna fiddle with that track a bit myself.
Moderation: Edited quote.
I've uploaded my test results for the Drug Me Sample.
Very nice! Synthetic Soul's scripts seem to be really useful!
3. Tak specific comments:
Amazing Performance. TAK Turbo encodes faster AND compresses better AND has better decoding speed than FLAC-8. Similarly, TAK Normal trounces Wavpack even at -hhx6. However, there's still room for improvement at the maximum compression settings (TAK can't match OFR even at default OR monkey's at insane)
I'm glad that you are testing Mpeg4Als. I am always very interested into it's results because it is using similar methods as TAK (and FLAC).
From my experience Mpeg4Als -7 is on average only up to 0.3 percent better than TAK's strongest mode. But on this sample it really outperforms TAK by more than 4 percent!
I allready knew that such samples exists. I have an idea how i can tune TAK to perform much better on them. Unfortunately this would be incompatible with the current encoder.
But i anyhow want to add some more codecs to TAK in the future.
The current codec is an all in one solution. It has to cover the whole spectrum from highest speed to highest compression. Some compromises where necessary.
I will probably add two specialized codecs: One for an even higher (decoding) speed and one for higher compression. The latter will sacrifice some decoding speed for higher compression, but not too much. TAK has to be fast, otherwise it would be quite useless.
But now stop dreaming about the future and back to the work. There is still the bug in the handling of some large wave files...
Future Plans
- Test on larger files (album images for different albums across genres)
- (Hopefully) Include WMA Lossless/ALAC
- TAK Specific: Use Damage tool to test error resilience
Great!
Thomas
Thanks for the update Thomas. No change on the my greater than 2gb WAVs. The program still throws "Wave file not supported" for both.
I had the opportunity to examine the file headers.
First comes a valid RIFF structure indicating a size of 2 GB and containing about 2 GB of wave data.
I suppose, that the remaining audio data is embedded into another RIFF or data chunk following the first one. I could not verify this, because i only have the first 100 KB of the file.
Probably the application which generated this file has created this layout to make the file compatible to older applications, which are only able to read up to 2 GB. They may read the first chunk and ignore the remaining data.
But to my knowledge this file structure is definitely non-standard.
Gnerma told me, that this file could be compressed by WavPack. I have looked into it's source code and from my understanding WavPack will do this:
1) Read the first data chunk of 2GB and compress it.
2) Store the remaining (audio) data as uncompressed meta data.
If that's true, then TAK isn't behaving differently. But Tak currently limits the the size of wave file meta data to 1 MByte, not enough to store the remaining audio data.
For now i would not like to put too much effort into the support of such a non-standard format. Sorry.
But possibly someone more knowledgeable than myself will convince me, that this format is common practice...
Thanks for the update Thomas. No change on the my greater than 2gb WAVs. The program still throws "Wave file not supported" for both.
...
For now i would not like to put too much effort into the support of such a non-standard format. Sorry.
...
Well, Destroid's (the second tester with trouble compressing files bigger than 2 GB) files have the same structure...
Currently Tak is capable to compress files up to 4 GB if the whole audio data is contained in one data chunk. What would be neccessary:
1) Support for reading and writing multiple data chunks.
2) A new meta data structure to store not only the file header and the non-audio data following the last audio data chunk, but also the segmentation (partition into multiple audio data chunks) of the audio data.
Some problems:
1) My 40 GB hard drive is nearly filled.
2) I myself have no application which creates files with such a structure.
But possibly Destroid or Gnerma could create a special big file for me:
1) Create a file of more than 2 GB which contains only silence!
2) After compression this should be small enough to be sent to me (I hope so...).
Thomas
If I remember correctly the thread "The 2GB Wav-limit!? (http://www.hydrogenaudio.org/forums/index.php?showtopic=32422)" is a good read. It may be of some help, but it also may not be relevant here.
Thomas, you probably do have the tools necessary to create such a file. In my case the only things that could have done this we're foobar2000 when I used convert -> convert to single file. Or Wavpack when the file was compressed.
If I remember correctly the thread "The 2GB Wav-limit!? (http://www.hydrogenaudio.org/forums/index.php?showtopic=32422)" is a good read. It may be of some help, but it also may not be relevant here.
Thomas, you probably do have the tools necessary to create such a file. In my case the only things that could have done this we're foobar2000 when I used convert -> convert to single file. Or Wavpack when the file was compressed.
Thanks for the info!
Thomas
Thomas, you probably do have the tools necessary to create such a file. In my case the only things that could have done this we're foobar2000 when I used convert -> convert to single file. Or Wavpack when the file was compressed.
I will try this later.
Until now i have checked CoolEdit 2000 and Audacity. Both generated wave files bigger than 2 GB with only one audio data chunk, which could be read by TAK.
Off topic: I let Audacity generate 250 min of silence, compressed it with Tak and surprise: It could only be compressed to about 15 percent! Too much for silence. I examined the wave file and found, that Audacity had generated alternating sample values of -1 and +1 instead of all 0. Well, i am not familar with Audacity, possibly there is an option to create real silence...
Back to the topic:
I hope you don't mind, but i deceided not to deal with those specific big wave file issues for the first public release, because
- there are more important topics on my to do list (for instance tagging)
- the solution would involve much time consuming testing (processing of large wave files is rather slow on my good old system...)
I hope it's ok for now.
Nevertheless your findings are really helpful for future implemtations of Tak! Sooner or later i will deal with this problem.
Thomas
No problem TBeck. I agree that working on things related to getting the codec "usable" should get higher priority. Thanks for all the hard work.
Off topic: I let Audacity generate 250 min of silence, compressed it with Tak and surprise: It could only be compressed to about 15 percent! Too much for silence. I examined the wave file and found, that Audacity had generated alternating sample values of -1 and +1 instead of all 0. Well, i am not familar with Audacity, possibly there is an option to create real silence...
That's weird, here an "empty" file is created, zeros only. But I haven't tested it with such a big file. Are you sure you used the menu entry "Generate->Silence..."?
PS: It wouldn't surprise me though when Audicity produces such weird files after a certain file limit was exceeded. This program has some unfixed bugs, and maybe this is just one of them. Unfortunately I can't test it here, because I also got no HD space left at the moment.
Off topic: I let Audacity generate 250 min of silence, compressed it with Tak and surprise: It could only be compressed to about 15 percent! Too much for silence. I examined the wave file and found, that Audacity had generated alternating sample values of -1 and +1 instead of all 0. Well, i am not familar with Audacity, possibly there is an option to create real silence...
That's weird, here an "empty" file is created, zeros only. But I haven't tested it with such a big file. Are you sure you used the menu entry "Generate->Silence (process)..."?
That's what i did:
1) Start Audacity (V 1.2.4).
2) Project -> New stereo track (i am using a german version, translation may be different)
3) Generate -> Silence
4) File -> Export (Track) as wave (44 Khz, 16 bit, stereo)
Internal project sample format is 32 bit float, hence a sample conversion has to be performed.
Same happens with one second of silence.
My description of the sample values wasn't exact. Here a small part (of a 1 second file):
Left 0 0 1 0 0 -1 1 0
Right 0 -1 1 1 -1 1 -2 2
Possibly there is some dithering beeing performed when converting from 32 bit float to 16 bit int.
Yeah, most likely it's dithered silence.
It is dithering. If you disable it (under settings > quality (Einstellungen > Qualität, using German version as well)) it produces a file containing only zeroes (apart from the header of course).
[deleted]
uncompressed.wav 756,297,404
0.tak 459,680,772
0m.tak 457,282,414
1.tak 456,444,623
1m.tak 454,754,042
2.tak 454,146,970
2m.tak 453,596,130
3.tak 451,564,637
3m.tak 450,963,823
4.tak 449,585,555
4m.tak 449,183,998
fast.ape 460,594,920
normal.ape 454,237,188
high.ape 450,957,024
extra high.ape 445,940,648
insane.ape 441,223,400
0.flac 502,612,998
2.flac 491,362,729
3.flac 478,381,725
6.flac 467,162,472
7.flac 466,275,676
8.flac 465,710,069
uncompressed.wav 756,297,404
0.tak 459,680,772
...
8.flac 465,710,069
Thank you!
Could you please tell, what kind of music this is?
uncompressed.wav 756,297,404
I took the freedom to bring audiofreak's data into another form:
Size (MB) Ratio Diff Best Diff Tak 4m
uncompressed.wav 721,26 100,00 -41,66 -40,61
0.flac 479,33 66,46 -8,12 -7,06
2.flac 468,60 64,97 -6,63 -5,58
3.flac 456,22 63,25 -4,91 -3,86
6.flac 445,52 61,77 -3,43 -2,38
7.flac 444,68 61,65 -3,31 -2,26
8.flac 444,14 61,58 -3,24 -2,19
fast.ape 439,26 60,90 -2,56 -1,51
0.tak 438,39 60,78 -2,44 -1,39
0m.tak 436,10 60,46 -2,12 -1,07
1.tak 435,30 60,35 -2,01 -0,96
1m.tak 433,69 60,13 -1,79 -0,74
normal.ape 433,19 60,06 -1,72 -0,67
2.tak 433,11 60,05 -1,71 -0,66
2m.tak 432,58 59,98 -1,64 -0,58
3.tak 430,65 59,71 -1,37 -0,31
3m.tak 430,07 59,63 -1,29 -0,24
high.ape 430,07 59,63 -1,29 -0,23
4.tak 428,76 59,45 -1,11 -0,05
4m.tak 428,38 59,39 -1,05 0,00
extra high.ape 425,28 58,96 -0,62 0,43
insane.ape 420,78 58,34 0,00 1,05
Sorted by compression.
"Diff Best" is the difference between the row and the best result.
"Diff Tak 4m" is the difference between the row and Tak's strongest mode.
Currently Tak is capable to compress files up to 4 GB if the whole audio data is contained in one data chunk. What would be neccessary:
1) Support for reading and writing multiple data chunks.
2) A new meta data structure to store not only the file header and the non-audio data following the last audio data chunk, but also the segmentation (partition into multiple audio data chunks) of the audio data.
Some problems:
1) My 40 GB hard drive is nearly filled.
2) I myself have no application which creates files with such a structure.
But possibly Destroid or Gnerma could create a special big file for me:
1) Create a file of more than 2 GB which contains only silence!
2) After compression this should be small enough to be sent to me (I hope so...).
Thomas
I have another idea how you could create the file yourself: use a compressed folder. I hope you have a NTFS partition, then this should be possible without any problem. The tricky part is to make your audio editor "play along". In case it uses temp files (which I'm pretty sure of) you should compress the corresponding temp directories as well. Oh and be sure they are empty. In other words: no other files opened in the audio editor, because non silent audio data may slow down the computer tremendously when it is compressing those non-silent temp files.
I tested it with a WAV file filled with 6 hours of silence (16bit/44.1kHz of course), it compressed to aprox. 8.192 bytes! Uncompressed size is 3.810.242.762 bytes. I think testing TAK with
very big WAV files is no problem anymore... at least silent ones.
Some problems:
1) My 40 GB hard drive is nearly filled.
I have another idea how you could create the file yourself: use a compressed folder. I hope you have a NTFS partition, then this should be possible without any problem. The tricky part is to make your audio editor "play along". In case it uses temp files (which I'm pretty sure of) you should compress the corresponding temp directories as well. Oh and be sure they are empty. In other words: no other files opened in the audio editor, because non silent audio data may slow down the computer tremendously when it is compressing those non-silent temp files.
Nice idea! Well, unfortunately i am using Win 98... Probably i will buy Win XP and possibly a bigger hard disk next month.
Gnerma told me, that this file could be compressed by WavPack. I have looked into it's source code and from my understanding WavPack will do this:
1) Read the first data chunk of 2GB and compress it.
2) Store the remaining (audio) data as uncompressed meta data.
If that's true, then TAK isn't behaving differently. But Tak currently limits the the size of wave file meta data to 1 MByte, not enough to store the remaining audio data.
I'd like to add that Wavpack's WAV file limit is 4GB, which makes sense since the maximum size of one RIFF chunk seems to be 4GB*. So the size limit for all standard compliant WAV files is 4GB. I've just tested it right now (in a compressed folder ) and the limit is definitely 4GB, the rest is appended to the WV file, bloating it up. So the effective WAV size limit for Wavpack is also 4GB, compressing bigger files makes no sense. Btw, wavpack, will report the same compression ratio (99.96%) as before (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=50958&view=findpost&p=459173), but the compression takes longer since appending the additional chunk also takes quite some time.
I'd say stick to a 4GB limit for now. Any WAV file bigger than that is definitely not standard. (For example Adobe Audition warned before saving a WAV bigger than 4GB, telling me the file will only open in Audition.)
*=Quote from Wikipedia's IFF article:
An IFF file is built up from chunks. Each chunk begins with what the spec calls a "Type ID" (what the Macintosh called an OSType and Windows developers might call a FourCC). This is followed by a 32-bit unsigned integer (all integers in IFF files' structure are big-endian) specifying the size of the following data (the chunk content) in bytes.
Gnerma told me, that this file could be compressed by WavPack. I have looked into it's source code and from my understanding WavPack will do this:
1) Read the first data chunk of 2GB and compress it.
2) Store the remaining (audio) data as uncompressed meta data.
If that's true, then TAK isn't behaving differently. But Tak currently limits the the size of wave file meta data to 1 MByte, not enough to store the remaining audio data.
I'd like to add that Wavpack's WAV file limit is 4GB, which makes sense since the maximum size of one RIFF chunk seems to be 4GB*. So the size limit for all standard compliant WAV files is 4GB. I've just tested it right now (in a compressed folder ) and the limit is definitely 4GB, the rest is appended to the WV file, bloating it up. So the effective WAV size limit for Wavpack is also 4GB, compressing bigger files makes no sense. Btw, wavpack, will report the same compression ratio (99.96%) as before (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=50958&view=findpost&p=459173), but the compression takes longer since appending the additional chunk also takes quite some time.
Fine. This confirms my understanding of WavPacks source.
I'd say stick to a 4GB limit for now. Any WAV file bigger than that is definitely not standard. (For example Adobe Audition warned before saving a WAV bigger than 4GB, telling me the file will only open in Audition.)
The file i was talking about contained a valid standard conforming first data chunk of 2 GB. Then followed another data chunk of up to 2 GB. This is non standard. Probably the application which generated this file partitions bigger files into multiple data chunks of 2 GB.
This (non-standard) variation can not be read by TAK, even if the whole file size is less than 4 GB.
uncompressed.wav 756,297,404
0.tak 459,680,772
...
8.flac 465,710,069
Thank you!
Could you please tell, what kind of music this is?
Artist: Mostly Autumn
Album: The Last Bright Light
Genre: Progressive folk/celtic/symphonic rock
Time: 71:27
[deleted]
[deleted]
Edit 2: For the next "full" test (probably going to use a very wide eclectic mix of music, about 2.5GB of total samples), I would be in a position to include DTS-HD and Meridian MLP (Dolby TrueHD) results, if anyone is interested.
I would certainly be interested. I'd like to see more testing with files that aren't 16bit 44100Hz stereo, but personally I have no resources. Keep up the good work.
Here TrNSZ's latest results in the format i am used to:
Classical Test:
Dvorak: Silent Woods. Cello Concerto. Op. 104. in B Minor
Size (MB) Ratio Diff Best Diff Tak 4m
Image (original).wav 697.95 100.00 -64.02 -63.55
Flac (-8).flac 271.57 38.91 -2.93 -2.46
True Audio.tta 269.78 38.65 -2.67 -2.20
Flake r112 (-12 -v 1) 269.52 38.62 -2.64 -2.17
WavPack (hhx6).wv 266.65 38.20 -2.22 -1.75
Extra Maximum.tak 254.41 36.45 -0.47 0.00
Monkey Insane.ape 251.13 35.98 0.00 0.47
Some rock/New Wave comparing only the strongest WavPack mode to TAK.
Size (MB) Ratio Diff Best Diff Tak 4m
Senses-Working-Overtime.wav 720.86 100.00 -35.08 -35.08
0.tak 477.05 66.18 -1.26 -1.26
0m.tak 474.09 65.77 -0.85 -0.85
1.tak 471.85 65.46 -0.54 -0.54
wavpack-hhx6.wv 471.33 65.38 -0.47 -0.47
2.tak 469.94 65.19 -0.27 -0.27
1m.tak 469.75 65.17 -0.25 -0.25
2m.tak 469.37 65.11 -0.19 -0.19
3.tak 468.89 65.05 -0.13 -0.13
4.tak 468.37 64.97 -0.06 -0.06
3m.tak 468.36 64.97 -0.05 -0.05
4m.tak 467.96 64.92 0.00 0.00
TAK vs. MPEG-4 ALS and Flake -12 on more classical a very dynamic Telarc recording.
Size (MB) Ratio Diff Best Diff Tak 4m
Telarc.wav 595.86 100.00 -58.07 -58.07
Telarc.tta 274.26 46.03 -4.09 -4.09
flake-12.flac 272.75 45.77 -3.84 -3.84
ALS.mp4 271.58 45.58 -3.65 -3.65
ALS-p.mp4 267.92 44.96 -3.03 -3.03
0.tak 260.90 43.79 -1.85 -1.85
0m.tak 259.67 43.58 -1.65 -1.65
1.tak 258.56 43.39 -1.46 -1.46
1m.tak 257.27 43.18 -1.24 -1.24
2.tak 255.77 42.93 -0.99 -0.99
2m.tak 255.05 42.80 -0.87 -0.87
3.tak 252.10 42.31 -0.38 -0.38
3m.tak 251.37 42.19 -0.25 -0.25
4.tak 250.22 41.99 -0.06 -0.06
4m.tak 249.86 41.93 0.00 0.00
"Diff Best" is the difference of the best result and the row.
"Diff Tak 4m" is the difference of Tak's strongest mode and the row.
Thank you so much for all your interesting and helpful work! We may have to stop you sometime... But not yet.
Edit: Note: MPEG-4 ALS using -7 -p and even just -7 is really too slow to do routine testing, but I am interested to seeing if it performs better, but the encoding is really, REALLY slow. Slow enough to make WavPack -hhx6 or even OptimFROG look fast. I didn't test the ALS decoding speeds. I also experienced a few crashes using the latest MPEG-4 reference coder, mainly when enabling switches for extra compression. It took several hours before actually crashing too, which makes it really frustrating.
Too bad. Just to be sure: You know, that you are not allowed to use the z-options together with -7 ? MPEG-4 ALS should warn you, but it doesn't.
Edit 2: For the next "full" test (probably going to use a very wide eclectic mix of music, about 2.5GB of total samples), I would be in a position to include DTS-HD and Meridian MLP (Dolby TrueHD) results, if anyone is interested.
Wow, that would be something really new and absolutely interesting for me!
Again, thanks for all your hard work!
Thomas
[deleted]
I'll post a full report later, but this one is very interesting. I decided to throw away Sade, Dire Straits, Pink Floyd, Blue Nile, Cowboy Junkies, Police, Donald Fagen, Mina, etc. and all those other "audiophile" discs and go with a much more eclectic and hopefully more representive test set that will give better results. We'll call this the "A" test set. The selection was chosen to be diverse and have a wide variety of different mastering techniques and musical styles represented to give a fair mix. Hopefully a preview will be available tonight.
Very exciting! I hope i will have time to respond.
... and hopefully codecs don't update while I'm testing.
No changes for Tak before the first public release.
But then i will look for better compression...
Thomas
[deleted]
I've uploaded my test results for an album image.
Download Links:
Zip File Containing XLS, PDF (http://www.sendspace.com/file/055xt9)
Album Details:
Album Tested: Renegades by Rage Against the Machine (Genre: Metal/Rap/"electronic"/weird)
Album Length: ~60 minutes (3636 seconds)
Uncompressed Size: 611.69 MB (641402204 bytes)
Test Bed:
Dell e1505 Laptop: Intel Core 2 Duo T7200 @ 2 Ghz, 1 GB Ram, 120 GB HDD 5400 RPM
Purpose:
1. To test Tak vs other codecs in a more realistic setting than previous test: to compress an album image.
2. To test Wavpack's new switches in a more realistic setting.
Methodology:
A single wav file of the album was created using foobar. The timing of compression/decompression was done by Synthetic Soul's scripts.
Encoders Versions and Switches Tested
1. TAK 0.15 Alpha: All Switches + Max for each
2. FLAC 1.1.3: -0 to -8
3. Wavpack 4.40.0: All Switches + (x1 through x6 for each)
4. Monkey's Audio 4.01: Fast through Insane
5. Optimfrog 4.600 ex: Default (no switches) and (fast, seek fast)
6. ALS RM18: Default (no switches), -7 ("maximum compression"), -a -o32
7. LA 0.4b: Default
8. TTA 3.3: Default
Remarks
1. Encoding/Decoding Performance
- Tak has the fastest encoding speed (Tak0 encodes faster than even Flac0).
- Tak also has the fastest decoding speed (Tak4M decodes faster than Flac1, and wavpack Fast)
2. Compression
- Tak is able to beat Flac hands down (tak 0 compresses better than Flac 8), and also outperforms Wavpack (Wavpack HH x 6 is matched by TAK 1). The performance vs ALS is also quite commendable: only ALS at the maximum compression beats TAK Correction: In this data set, TAK does perform better than ALS
- However, Tak doesn't quite measure up to Monkey's audio. Monkey's Audio at Normal compressed better than Tak 4m. Similarly, it can't match up with Optimfrog even at the most lax setting i could think of (fast with fast seeking). Higher compression is something TAK could improve on
3. Wavpack specific observations
- x1, x2 and x3 are definitely usable and beneficial but x4, x5, x6 are very hard to justify... -hh x6 in particular encodes at 0.98X, which is slower than even LA or ALS at maximum (although the decoding speed is very good: 74x).
4. Weird Observations
- Flac1 seems to compress faster than Flac0. I noticed this in the drug me sample too.
Future Plans
- Test on a spoken/comedy album (Trsnz seems to have taken care of all other genres )
- Full swing damage test (i'm sure that will be loads of fun)
- Maybe a small scale test with Tak vs Flac optimized for P4 vs Wavpack optimized for MMX.
- Maybe test the same album with optimfrog maximum compression experimental to torture my computer (and to see if it can match LA).
PS: Sorry for the delay (i had my finals)
I've uploaded my test results for an album image.
Download Links:
Zip File Containing XLS, PDF (http://www.sendspace.com/file/055xt9)
Great presentation. Thank you!
2. Compression
- Tak is able to beat Flac hands down (tak 0 compresses better than Flac 8), and also outperforms Wavpack (Wavpack HH x 6 is matched by TAK 1). The performance vs ALS is also quite commendable: only ALS at the maximum compression beats TAK (although the compression time for ALS at maximum is abysmally slow)
Hm... From your data it looks as if Tak 1 already beats ALS -7 (The strongest mode of your results). Are you talking about ALS's z-modes?
Future Plans
- Test on a spoken/comedy album (Trsnz seems to have taken care of all other genres )
- Full swing damage test (i'm sure that will be loads of fun)
- Maybe a small scale test with Tak vs Flac optimized for P4 vs Wavpack optimized for MMX.
- Maybe test the same album with optimfrog maximum compression experimental to torture my computer (and to see if it can match LA).
Very impressive!
Nice that all this testing isn't only useful for TAK development. This thread for instance provides some good examples for the difficulty to judge a codecs performance by only limited file sets.
2. Compression
- Tak is able to beat Flac hands down (tak 0 compresses better than Flac 8), and also outperforms Wavpack (Wavpack HH x 6 is matched by TAK 1). The performance vs ALS is also quite commendable: only ALS at the maximum compression beats TAK (although the compression time for ALS at maximum is abysmally slow)
Hm... From your data it looks as if Tak 1 already beats ALS -7 (The strongest mode of your results). Are you talking about ALS's z-modes?
Oops. Corrected.
I've uploaded my test results for an album image (genre: spoken).
Download Links:
UPDATED: Zip File Containing XLS, PDF (http://www.sendspace.com/file/nwid00)
ORIGINAL: Zip File Containing XLS, PDF (http://www.sendspace.com/file/he2jkt)
Album Details:
Album Tested: People's History of the United States by Howard Zinn (Genre: Spoken Word)
Album Length: ~50 minutes (3030 seconds)
Uncompressed Size: ~510 MB (534521900 bytes)
Album is Stereo, but both sides contain nearly identical data
Test Bed:
Dell e1505 Laptop: Intel Core 2 Duo T7200 @ 2 Ghz, 1 GB Ram, 120 GB HDD 5400 RPM
Purpose:
1. To test the Tak on spoken albums. I thought it would be interesting to test codecs on audio samples which may be stereo but have identical data on both channels (like this one), and whose audio content is primarily human voice.
2. To test the (speed) optimized versions of FLAC and Wavpack as well, to see how much improvement can be expected.
Methodology:
A single wav file of the album was created using foobar. The timing of compression/decompression was done by Synthetic Soul's scripts.
Encoders Versions and Switches Tested
1. TAK 0.15 Alpha: All Switches + Max for each
2. FLAC 1.1.3: -0 , -1, -5, -8
3. P4 Optimized FLAC 1.1.3: -0 , -1, -5, -8
(available Here (http://www.hydrogenaudio.org/forums/index.php?showtopic=50917))
4. Wavpack 4.40.0: Fast, Normal, HH
5. MMX Optimized Wavpack build: Fast, Normal, High
(Available Here (http://www.hydrogenaudio.org/forums/index.php?showtopic=43731))
5. Monkey's Audio 4.01: Fast, Insane
6. Optimfrog 4.600 ex: Default (no switches) and (fast, seek fast)
7. ALS RM18: Default (no switches)
8. LA 0.4b: Default
9. TTA 3.3: Default
Note: Wavpack optimized build is based on Wavpack 4.31 while the "non-optimized" version i tested is version 4.40. Thus, there is a difference in resultant file size. Also, i've used the -HH switch for the official build because it is the "equivalent" of the old high.
Remarks
1. Compression
- This has got to be the first sample i've seen in which Monkey's audio performs better than both LA and OptimFrog AND more importantly, TAK at 4M is the best compression (i haven't tested it on OptimFrog --maximumcompression --experimental yet).
- the performance of Flac with switch -0 is pretty abysmal: double of Flac -1.
- 4.40 compresses better than 4.31, this is evident in the Fast and Default switches. No changes in the -HH setting (which is expected)
2. Encoding Speed
- Again, performance of TAK is pretty good, but TAK 4M compresses only about as fast as Monkey at Insane. (TAK 4M has always compressed faster than Monkey (even at Extra High; also see Synthetic Soul's tests)).
- The optimized builds are pretty impressive. In case of Flac, the improvement is very significant at -8 (~70 % faster). The performance is more subtle for Wavpack (~7 % at most)
- Once again, Flac -1 compresses Faster than Flac -0. Something fishy is going on with Flac -0.
just wanted to point out that TAK 4m should be 20.29, which would be TAK's best result instead of 21.72 which would be its worst.
[deleted]
I've uploaded my test results for an album image (genre: spoken).
Download Links:
Zip File Containing XLS, PDF (http://www.sendspace.com/file/he2jkt)
Album Details:
Album Tested: People's History of the United States by Howard Zinn (Genre: Spoken Word)
Album Length: ~50 minutes (3030 seconds)
Uncompressed Size: ~510 MB (534521900 bytes)
Album is Stereo, but both sides contain nearly identical data
Looking at these results makes me think that this is truly mono material (but in 2 channels, obviously). This would explain the very poor performance of WavPack (compared to the others). It also may explain the weird performance of flac -0. Josh (or someone else familar with the internals) would have to confirm, but perhaps the -0 option doesn't even include joint stereo so both channels are completely independent, and that would explain getting only about half the compression of -1.
I suspect that using the --optimize-mono option in WavPack would put in right back into the pack with the others.
Thanks again for your thorough testing.
David
just wanted to point out that TAK 4m should be 20.29, which would be TAK's best result instead of 21.72 which would be its worst.
Thank you. There was a problem with the formulas in excel. I've corrected it.
I suspect that using the --optimize-mono option in WavPack would put in right back into the pack with the others.
Updated the table. You were right, it does make a helluva difference. Would it be possible for you to make the encoder automatically use the optimize mono if the material is "pseudomono"?
Looking at these results makes me think that this is truly mono material (but in 2 channels, obviously). This would explain the very poor performance of WavPack (compared to the others). It also may explain the weird performance of flac -0. Josh (or someone else familar with the internals) would have to confirm, but perhaps the -0 option doesn't even include joint stereo so both channels are completely independent, and that would explain getting only about half the compression of -1.
yep, that's exactly right.
Josh
Josh, is there any reason why Flac -0 encodes slower than Flac -1 on my computer? All three samples i've tested so far exhibit this.
I suspect that using the --optimize-mono option in WavPack would put in right back into the pack with the others.
Updated the table. You were right, it does make a helluva difference. Would it be possible for you to make the encoder automatically use the optimize mono if the material is "pseudomono"?
I could, but the resulting files are not compatible with all decoders (specifically the current tiny_decoder and DirectShow filter). At some point in the future I will surely do this.
Anyway, thanks for trying that. I'm glad that it helped...
What's tiny_decoder?
What's tiny_decoder?
http://www.wavpack.com/downloads.html (http://www.wavpack.com/downloads.html)
3rd line in source code
Josh, is there any reason why Flac -0 encodes slower than Flac -1 on my computer? All three samples i've tested so far exhibit this.
I suspect for the same reason why the compression ratio is so bad compared to -1, which bryant has already explained. Since both channels are processed independently with -0, I suspect that the joint-stereo processing that takes place with -1 and onwards fastens things up tremedously for "true mono in 2 channel" material, whereas this j-s step would normally slow the encoding down for true stereo material compared to indepedent processing of both channels only.
Josh, is there any reason why Flac -0 encodes slower than Flac -1 on my computer? All three samples i've tested so far exhibit this.
not sure, depends on how much slower it is, but on this sample I would guess at least some is due to 2x the disk writes.
Preparing the public beta
That's what i would like to do know.
Please don't take me wrong: I don't want to stop you the alpha testing! Both can be done simultaneously.
Some questions:
Do you know any reason why i shouldn't release the beta soon?
If you have found any bugs, now it's really time to shout...
Is the documentation ok?
I know, it's really bad english, but is it still understandable? Would it be even sufficient for someone less familiar with lossless audio compression than you?
I definitely want to improve it in the future, but there will be only minor changes for the first public release:
1) Add disclaimer of warranty.
2) Very short description of the purpose of the software.
3) A list of important features which are missing put planned to be implemented into the next release (tagging, media player support).
Try tagging
While Tak does not support tagging on it's own, the current version should ignore any data appended to the end of the encoded file. Therefore it should be possible to use an external software to apply tags to the file end. The files should still be decodable without any problems. Could someone please try this?
It's different for tags inserted at the beginning of the file. The current decoder will give you an error message. No need to try this yet.
Thomas
Thomas. I'm of the opinion that a public beta shouldn't be released without a foobar2000 decoding plugin. Why? Well if you want your testers to truly test the codec they need to be able to use it in the real world environment they're familiar with. If you do the public beta as you did the alpha you'll probably get a lot of compression and speed comparisons (which is of course great) and maybe a few UI or general format issues like the 2gb thing that came up. But the test won't give you nearly the kind of mileage you'd get if the lossless codec could actually be used as a lossless codec. You'd want to put all kinds of warning about not to use it for anything but testing of course
I'm also wondering what you're going to do with the presets. Are you planning on making "Max" part of the public "final"? I ask because in my opinion the highest preset and the Max option are backwards. Max of course means maximum or the best or highest possible. And extra means a boost or something in addition that was perhaps not specifically planned for. It would make more sense if the Extra preset was called Max and vise versa.
Thomas. I'm of the opinion that a public beta shouldn't be released without a foobar2000 decoding plugin. Why? Well if you want your testers to truly test the codec they need to be able to use it in the real world environment they're familiar with. If you do the public beta as you did the alpha you'll probably get a lot of compression and speed comparisons (which is of course great) and maybe a few UI or general format issues like the 2gb thing that came up. But the test won't give you nearly the kind of mileage you'd get if the lossless codec could actually be used as a lossless codec. You'd want to put all kinds of warning about not to use it for anything but testing of course
I'm also wondering what you're going to do with the presets. Are you planning on making "Max" part of the public "final"? I ask because in my opinion the highest preset and the Max option are backwards. Max of course means maximum or the best or highest possible. And extra means a boost or something in addition that was perhaps not specifically planned for. It would make more sense if the Extra preset was called Max and vise versa.
I agree with Gnerma on both points.
I don't think any significant additional testing can be done unless there is a decoder for some audio program. If there were a decoder, we could actually compress albums with tags and see how TAK decodes in "real life" applications as opposed to how it decodes to wav. So please consider releasing a foobar plugin along with the public beta.
I too was confused initially by the Max option. I thought it was something like OFR's --maximumcompression option, and didn't pay much attention towards it (i only realized it was like wavpack's x option after looking at synthetic soul's comparison charts). To avoid this "confusion", i guess you could have an -x system like Wavpack's (x for extra); it's just a matter of calling it something different to avoid possible confusion.
I'm also wondering what you're going to do with the presets. Are you planning on making "Max" part of the public "final"? I ask because in my opinion the highest preset and the Max option are backwards. Max of course means maximum or the best or highest possible. And extra means a boost or something in addition that was perhaps not specifically planned for. It would make more sense if the Extra preset was called Max and vise versa.
I too was confused initially by the Max option. I thought it was something like OFR's --maximumcompression option, and didn't pay much attention towards it (i only realized it was like wavpack's x option after looking at synthetic soul's comparison charts). To avoid this "confusion", i guess you could have an -x system like Wavpack's (x for extra); it's just a matter of calling it something different to avoid possible confusion.
Thanks for telling me about this irritation. Possibly some of the confusion comes from the layout of the options dialog in the gui version, where "Additionally Evaluation - Max" is placed following the strongest preset. This might look as if the additional evaluation is another (the really strongest) preset.
But on the command line it should be quite clear.
I will think about a better solution. Indeed someting like -x (extra) would make more sense (especially for people familar with WavPack). There are historical reasons why it isn't called extra: Earlier there have been two levels of additional (extra) evaluation, "extra" and "max"...
Thomas. I'm of the opinion that a public beta shouldn't be released without a foobar2000 decoding plugin. Why? Well if you want your testers to truly test the codec they need to be able to use it in the real world environment they're familiar with. If you do the public beta as you did the alpha you'll probably get a lot of compression and speed comparisons (which is of course great) and maybe a few UI or general format issues like the 2gb thing that came up. But the test won't give you nearly the kind of mileage you'd get if the lossless codec could actually be used as a lossless codec. You'd want to put all kinds of warning about not to use it for anything but testing of course
I don't think any significant additional testing can be done unless there is a decoder for some audio program. If there were a decoder, we could actually compress albums with tags and see how TAK decodes in "real life" applications as opposed to how it decodes to wav. So please consider releasing a foobar plugin along with the public beta.
I agree that a foobar plugin would be neccessary for a comprehensive real life beta test. But unfortunately it will take quite much time for me to build one. Probably we will see a WinAmp plugin first.
To be honest, i definitely don't want to wait any longer with a public release, this simply because it would lighten me. Now it are nine month since my first post about Tak. People have often been asking for a release, have told, how excited they are. I really want to make Tak available.
Do you think it would severely hurt, if Tak's first release is missing some important features? People who are interested into Tak at least would be able to try it and judge, if it is worth to wait for a full blown release.
Well, Tak's development history may be a bit different: The first release will be enormously optimized performance wise, but lack some general features. Later releases will improve more the usability and less the performance.
Thomas
Do you know any reason why i shouldn't release the beta soon?
No. A foobar or Winamp component would be nice, but it isn't necessary to let more people start testing the codec. If users aren't happy with just encoding and decoding to WAVE then let them wait, they don't have to try it!
Is the documentation ok?
I need to scrutinise it further, but AFAIR it is absolutely fine. It's a very simple thing to improve in the future in any case.
Try tagging
I tagged a file with APEv2 tags using the following Tag command line:
TAG.EXE --ape2 --nocheck --artist "My Artist" --album "My Album" test.tak
... and it decoded fine, is the same size as the source, and is bit-identical according to foobar.
I think inbuilt tagging is desirable for the future, but some codecs can't tag themselves still, Monkey's Audio being one.
[deleted]
Do you think it would severely hurt, if Tak's first release is missing some important features? People who are interested into Tak at least would be able to try it and judge, if it is worth to wait for a full blown release.
Sorry for bumping in ...
I don't think Tak's reputation will hurt if the most simple compress or decompress function works fine.
People asking for features can wait and tolerate because features usually don't hurt the core functionality. I think if the coder fail the simplest function (CRC error, extremely slow, crashes) and the author [don't care] , that will surely hurt the reputation.
Well, Tak's development history may be a bit different: The first release will be enormously optimized performance wise, but lack some general features. Later releases will improve more the usability and less the performance.
I can understand you want to release a "bug free" and good performance binary. But without a large amount of testing in different combination, there may be hidden bugs or usage problems, so I think if the basic functions work fine, a BETA version can be release anytime.
Like LAME, without huge number of people testing, it won't be so good now, IMO the most difficult decision is "official release" because it MUST be completely bug free.
APEv2 tagging as an accepted standard would be ideal, IMHO.
Indeed. I will be disappointed if not. As TAK ignores anything stuck on the end I guess ID3v1 and APEv2 both would be valid, and easily implemented. I see from another thread this morning that WavPack is OK with both.
I'll create an Omni Encoder module for TAK once it goes public, so people will have a usable front-end. I know you people like foobar, but...
Is Tag.exe still being maintained by Case? I wonder if it will tag TAK files as-is? (I use Tag.exe in Omni Encoder for APE2 tagging).
I'll create an Omni Encoder module for TAK once it goes public, so people will have a usable front-end. I know you people like foobar, but...
Is Tag.exe still being maintained by Case? I wonder if it will tag TAK files as-is? (I use Tag.exe in Omni Encoder for APE2 tagging).
Cool. Thanks Jebus.
See my post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=50958&view=findpost&p=461273) RE: Tag command line. The
--nocheck switch is required as TAK is currently unrecognised by Tag. AFAIK, following my initial emails to Case, he has no interest in developing Tag. However, it is my intention to get Tag to recognise TAK files, just as I did with OptimFROG files in the very beginning (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=25921&view=findpost&p=235152)...
Hopefully I will release a new version of Tag over the weekend, when I can actually get on my PC (baby's asleep in the room at the moment).
Do you know any reason why i shouldn't release the beta soon?
No. A foobar or Winamp component would be nice, but it isn't necessary to let more people start testing the codec. If users aren't happy with just encoding and decoding to WAVE then let them wait, they don't have to try it!
Do you think it would severely hurt, if Tak's first release is missing some important features? People who are interested into Tak at least would be able to try it and judge, if it is worth to wait for a full blown release.
I don't think Tak's reputation will hurt if the most simple compress or decompress function works fine.
People asking for features can wait and tolerate because features usually don't hurt the core functionality. I think if the coder fail the simplest function (CRC error, extremely slow, crashes) and the author [don't care] , that will surely hurt the reputation.
Fine! I am quite confident to release the beta very soon.
Try tagging
I tagged a file with APEv2 tags using the following Tag command line:
TAG.EXE --ape2 --nocheck --artist "My Artist" --album "My Album" test.tak
... and it decoded fine, is the same size as the source, and is bit-identical according to foobar.
Thank you!
APEv2 tagging as an accepted standard would be ideal, IMHO.
Well, APEv2 looks quite good.
I'll create an Omni Encoder module for TAK once it goes public, so people will have a usable front-end. I know you people like foobar, but...
Great! Thank you.
...
Hopefully I will release a new version of Tag over the weekend, when I can actually get on my PC (baby's asleep in the room at the moment).
So many busy people...
I want to release the public beta...
I have just performed some minor modifications for Beta 1:
- The summary message displayed after decoding of damaged files has been changed from "x damaged files have been repaired." to "x damaged files have been decoded.". The former message was misleading, because Tak never will modify (or repair) the damaged file when decoding.
- Changed share mode for source files when compressing/decompressing. Now other applications have the permission to read the source file simultaneously.
- The Additional Evaluation button in the encoder options dialogue of the GUI version has been moved to a center position above the preset bar to avoid confusion of presets and evaluation levels.
I was tempted to first send the beta to the alpha testers and let them try it before making it publically available. But because i don't really expect problems caused by those tiny modifications above i would like to skip this. Possibly i am getting a bit careless...
But no, first i will try it on my test set.
Am i allowed to put the beta into the upload section? After all this work, is it really as simple as this?
I would suggest that Rarewares may be interested to host, but the site is currently having hosting issues.
Have you given any thought to creating a TAK website? Do you have provision to do so?
I know that you have your own site, which I have visited a while back. Maybe you would like to make the link between you and TAK, and maintain some control, by hosting the package there.
If not, maybe it would be worth checking with an HA admin (http://www.hydrogenaudio.org/forums/index.php?act=Stats&CODE=leaders) before uploading, as it is possible that the release may cause a stir... although I get the impression that the bandwidth requirements are already very high for the site, so I doubt that they'll show concern.
I would suggest that Rarewares may be interested to host, but the site is currently having hosting issues.
I read about it. Too bad...
Have you given any thought to creating a TAK website? Do you have provision to do so?
I know that you have your own site, which I have visited a while back. Maybe you would like to make the link between you and TAK, and maintain some control, by hosting the package there.
My home page is beeing hosted by my internet provider. Monthly limit = 5 GB, very very costly above! I will have to look for another hoster if i want to put the Tak binary on the page. Sooner or later i may have to switch.
Nevertheless i want to put some info material about Tak on my home page. But this first has to be written and has to be in correct english! I will ask a friend for a translation. This will take some time.
If not, maybe it would be worth checking with an HA admin (http://www.hydrogenaudio.org/forums/index.php?act=Stats&CODE=leaders) before uploading, as it is possible that the release may cause a stir... although I get the impression that the bandwidth requirements are already very high for the site, so I doubt that they'll show concern.
Good idea!
But wait a moment. I just got a revolutionary idea...
Would it be possible to use something like www.rapidshare.com for legal things? Has anyone tried this before?
Would it be possible to use something like www.rapidshare.com for legal things? Has anyone tried this before?
Please don't use rapidshare and the like; they're just too big a hassle to deal with (for the downloaders... watch some ads, wait for about 90 seconds, type the Captcha... just horrible).
If things don't work out with Rarewares/ HA Uploads, i could put the files on my university account (only disadvantage would be the slightly unwieldy URL, but tinyurl can fix that). AFAIK there isn't any bandwidth limit.
If things don't work out with Rarewares/ HA Uploads, i could put the files on my university account (only disadvantage would be the slightly unwieldy URL, but tinyurl can fix that). AFAIK there isn't any bandwidth limit.
Many thanks for the offer!
But i got the permission to use the upload section.
I just finished my usual test run performed before any release. No errors.
Last thing to do: Some corrections for my ReadMe. And a bit of sleeping.
I am very excited now...
Thomas
TAK 1.0 Beta 1 is out...This would not have happened without your thorough testing which gave me the confidence i needed to release a public version.
Many thanks to all the great testers!
I've completed all my testing and the decoding speed tests are finishining... I should have full results in the next day or two and TAK is clearly the efficiency winner, but full analysis should be posted soon.
I am still very curious...
Thomas