IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
TAK 2.2.0 development
TBeck
post May 23 2011, 18:08
Post #51


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (marc2003 @ May 23 2011, 15:47) *
read the thread? dry.gif

QUOTE (TBeck @ May 18 2011, 03:29) *
Then i will perform a lot of testing and finally prepare an alpha release of TAK 2.2. I can't tell you, how long this will take. Maybe 2 weeks.


Indeed.

I just started the first test runs. Even without the new multi channel audio tests the whole validation process already took more than a day. The tests are running on my primary PC (it's my fastest one). Since i also need it for other purposes, i often have to interrupt the tests. There is also a chance that i find bugs in the new code.

Therefore i still can't tell you an exact release date.
Go to the top of the page
+Quote Post
_mē_
post May 23 2011, 22:13
Post #52





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



QUOTE
- Mpeg4Als -7 is doing the above. Furthermore it uses higher bit resolution multiplications for the filters. This may bring an advantage of about 0.3 to 0.4 percent, but at the cost of also much slower processing. I wouldn't want to sacrifice most of TAK's speed advantages for this little. Ok, i am sure i could write an ALS-encoder which is a lot faster than the reference implementation, but still significantly slower than TAK.

Out of curiosity, increased complexity of both encoding and decoding or only encoding?

This post has been edited by _mē_: May 23 2011, 22:13
Go to the top of the page
+Quote Post
TBeck
post May 23 2011, 23:05
Post #53


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (_mē_ @ May 23 2011, 23:13) *
QUOTE
- Mpeg4Als -7 is doing the above. Furthermore it uses higher bit resolution multiplications for the filters. This may bring an advantage of about 0.3 to 0.4 percent, but at the cost of also much slower processing. I wouldn't want to sacrifice most of TAK's speed advantages for this little. Ok, i am sure i could write an ALS-encoder which is a lot faster than the reference implementation, but still significantly slower than TAK.

Out of curiosity, increased complexity of both encoding and decoding or only encoding?

Decoding too. If it was only for encoding, i would be far less hesistant.
Go to the top of the page
+Quote Post
TBeck
post May 27 2011, 17:43
Post #54


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (TBeck @ May 23 2011, 19:08) *
I just started the first test runs. Even without the new multi channel audio tests the whole validation process already took more than a day. The tests are running on my primary PC (it's my fastest one). Since i also need it for other purposes, i often have to interrupt the tests. There is also a chance that i find bugs in the new code.

No bugs found, but the tests indeed lasted until now. One of the tests took more than 24 hours! I just upgraded my RAM from 2 to 4 GB to have more space for file caching. This was definitely a bottleneck for the multi channel audio tests. Especially because my totally silent desktop PC has only a single 2.5 harddisk.

Ok, enough whining. I will now prepare an alpha release.
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th October 2014 - 10:33