Hydrogenaudio Forums

Lossless Audio Compression => Lossless / Other Codecs => Topic started by: TBeck on 2006-12-12 22:17:34

Title: TAK - Alpha testing
Post by: TBeck on 2006-12-12 22:17:34
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.
Title: TAK - Alpha testing
Post by: Fandango on 2006-12-12 22:21:12
Can you add a link to the binaries? That would come in handy at this place...

unEDIT: Didn't see your response in time.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-12 22:24:14
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
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-14 05:19:24
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
Title: TAK - Alpha testing
Post by: tempnegro on 2006-12-14 05:23:39
why don't you just join the FLAC team man.....you'd be a great asset helping them!!!
Title: TAK - Alpha testing
Post by: keytotime on 2006-12-15 02:48:41
Because this is his encoder and it is better.
Title: TAK - Alpha testing
Post by: tempnegro on 2006-12-16 03:12:19
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
Title: TAK - Alpha testing
Post by: ssjkakaroto on 2006-12-16 03:31:08
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-16 04:19:31
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.
Title: TAK - Alpha testing
Post by: skamp on 2006-12-16 10:01:25
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.
Title: TAK - Alpha testing
Post by: Gnerma on 2006-12-16 10:52:41
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-16 15:53:36
* 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
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-16 16:49:00

* 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...
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-16 17:32:50
[deleted]
Title: TAK - Alpha testing
Post by: Night Rain on 2006-12-16 18:50:04
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.
Title: TAK - Alpha testing
Post by: Qest on 2006-12-17 02:56:24
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-17 05:14:31
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
Title: TAK - Alpha testing
Post by: Gnerma on 2006-12-17 11:07:20
Quote
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-17 14:39:32
* 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.

Quote
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
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-17 17:31:03
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...
Title: TAK - Alpha testing
Post by: Fandango on 2006-12-17 19:44:04
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?
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-17 19:54:03
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.
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2006-12-17 20:57:42
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.
Title: TAK - Alpha testing
Post by: Omion on 2006-12-17 21:47:49
VERY nice.

I just encoded 58GB of music, and even preset 0 easily beats FLAC level 7.

Here's some compression results:
Code: [Select]
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-17 22:07:10
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:
Code: [Select]
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...
Title: TAK - Alpha testing
Post by: Omion on 2006-12-17 22:15:14
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.
Title: TAK - Alpha testing
Post by: kanak on 2006-12-17 22:39:36
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.
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-18 02:46:31
[deleted]
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-18 03:12:48
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
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-18 03:47:11
[deleted]
Title: TAK - Alpha testing
Post by: bryant on 2006-12-18 06:59:49
I've compressed Seabound - Double Crosser Limited Edition 2-CD:

Code: [Select]
     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... 
Title: TAK - Alpha testing
Post by: Destroid on 2006-12-18 09:15:27
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.
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-18 11:54:36
[deleted]
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-18 12:22:17
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
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-18 12:32:33
[deleted]
Title: TAK - Alpha testing
Post by: Night Rain on 2006-12-18 12:52:51
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-18 13:19:03
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?
Title: TAK - Alpha testing
Post by: Zergen on 2006-12-18 13:27:39
As for me, it's ok
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-18 14:14:31
[deleted]
Title: TAK - Alpha testing
Post by: db1989 on 2006-12-18 14:20:07
I'll be interested to try this codec once it enters the beta/stable stage!

Quote
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!
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2006-12-18 15:55:51
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.
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2006-12-18 18:35:42
Here's CPU-only results, showing the difference between using -v (verify) while encoding, and not.

Code: [Select]
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%.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-18 21:18:49

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:

Code: [Select]
          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:

Code: [Select]
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:

Code: [Select]
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-18 23:30:28
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
Title: TAK - Alpha testing
Post by: Gnerma on 2006-12-19 02:54:47
Thanks for the update Thomas. No change on the my greater than 2gb WAVs. The program still throws "Wave file not supported" for both.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-19 03:02:42
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.
Title: TAK - Alpha testing
Post by: kanak on 2006-12-19 07:01:32
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
Title: TAK - Alpha testing
Post by: bryant on 2006-12-19 14:37:50
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...
Title: TAK - Alpha testing
Post by: DARcode on 2006-12-19 15:10:36
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-19 22:04:29
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
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-20 02:30:51
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...
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-20 12:27:03

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
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2006-12-20 12:32:54
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.
Title: TAK - Alpha testing
Post by: Gnerma on 2006-12-20 13:00:43
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-20 13:03:49
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
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-20 14:18:58
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
Title: TAK - Alpha testing
Post by: Gnerma on 2006-12-20 14:23:21
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.
Title: TAK - Alpha testing
Post by: Fandango on 2006-12-20 16:28:38
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-20 16:57:33
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):

Code: [Select]
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.
Title: TAK - Alpha testing
Post by: Firon on 2006-12-20 19:23:10
Yeah, most likely it's dithered silence.
Title: TAK - Alpha testing
Post by: gaekwad2 on 2006-12-20 19:34:46
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).
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-21 03:35:00
[deleted]
Title: TAK - Alpha testing
Post by: audiofreak on 2006-12-22 22:54:37
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
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-22 23:04:38
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?
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-22 23:34:37
uncompressed.wav   756,297,404

I took the freedom to bring audiofreak's data into another form:
Code: [Select]
                   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.
Title: TAK - Alpha testing
Post by: Fandango on 2006-12-23 00:13:29
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-23 00:26:52

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.
Title: TAK - Alpha testing
Post by: Fandango on 2006-12-23 00:48:03
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:
Quote
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-23 01:27:11

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.
Title: TAK - Alpha testing
Post by: audiofreak on 2006-12-23 02:43:02

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
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-23 04:48:24
[deleted]
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-23 05:00:13
[deleted]
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2006-12-23 08:23:55
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.
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-23 13:04:12
Here TrNSZ's latest results in the format i am used to:

Classical Test:
Dvorak: Silent Woods. Cello Concerto. Op. 104. in B Minor
Code: [Select]
                      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.
Code: [Select]
                             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.
Code: [Select]
              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
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-23 23:29:17
[deleted]
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-24 00:05:31
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
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-25 05:40:35
[deleted]
Title: TAK - Alpha testing
Post by: kanak on 2006-12-25 06:56:40
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)
Title: TAK - Alpha testing
Post by: TBeck on 2006-12-28 20:43:49
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.
Title: TAK - Alpha testing
Post by: kanak on 2006-12-28 21:33:32

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.
Title: TAK - Alpha testing
Post by: kanak on 2006-12-29 04:16:37
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.
Title: TAK - Alpha testing
Post by: music_man_mpc on 2006-12-29 04:55:05
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.
Title: TAK - Alpha testing
Post by: TrNSZ on 2006-12-29 04:56:41
[deleted]
Title: TAK - Alpha testing
Post by: bryant on 2006-12-29 05:19:34
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
Title: TAK - Alpha testing
Post by: kanak on 2006-12-29 06:24:35
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"?
Title: TAK - Alpha testing
Post by: jcoalson on 2006-12-29 18:05:23
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
Title: TAK - Alpha testing
Post by: kanak on 2006-12-29 18:12:38
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.
Title: TAK - Alpha testing
Post by: bryant on 2006-12-30 04:16:03

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...
Title: TAK - Alpha testing
Post by: Firon on 2006-12-30 05:07:50
What's tiny_decoder?
Title: TAK - Alpha testing
Post by: Mangix on 2006-12-30 06:40:48
What's tiny_decoder?

http://www.wavpack.com/downloads.html (http://www.wavpack.com/downloads.html)

3rd line in source code
Title: TAK - Alpha testing
Post by: Fandango on 2006-12-30 10:53:46
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.
Title: TAK - Alpha testing
Post by: jcoalson on 2006-12-30 18:49:11
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.
Title: TAK - Alpha testing
Post by: TBeck on 2007-01-02 18:01:28
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
Title: TAK - Alpha testing
Post by: Gnerma on 2007-01-02 20:34:28
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.
Title: TAK - Alpha testing
Post by: kanak on 2007-01-02 21:24:34
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.
Title: TAK - Alpha testing
Post by: TBeck on 2007-01-02 22:42:38
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
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2007-01-02 23:13:12
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:

Code: [Select]
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.
Title: TAK - Alpha testing
Post by: TrNSZ on 2007-01-03 03:15:33
[deleted]
Title: TAK - Alpha testing
Post by: johnsonlam on 2007-01-03 05:00:08
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.

Quote
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.
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2007-01-03 07:59:02
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.
Title: TAK - Alpha testing
Post by: Jebus on 2007-01-03 19:57:59
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).
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2007-01-03 20:20:01
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).
Title: TAK - Alpha testing
Post by: TBeck on 2007-01-03 22:48:05
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:

Code: [Select]
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...
Title: TAK - Alpha testing
Post by: TBeck on 2007-01-03 23:03:10
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?
Title: TAK - Alpha testing
Post by: Synthetic Soul on 2007-01-03 23:12:20
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.
Title: TAK - Alpha testing
Post by: TBeck on 2007-01-03 23:42:43
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?
Title: TAK - Alpha testing
Post by: kanak on 2007-01-04 00:58:29
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.
Title: TAK - Alpha testing
Post by: TBeck on 2007-01-04 02:11:58
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
Title: TAK - Alpha testing
Post by: TBeck on 2007-01-04 03:50:39
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
SimplePortal 1.0.0 RC1 © 2008-2019