Skip to main content

Topic: TAK 1.0.2 (Read 62379 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • --pv--
  • [*][*][*]
TAK 1.0.2
Reply #25
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar.

  • Alexxander
  • [*][*][*][*]
TAK 1.0.2
Reply #26
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar.

What you mean? It already is possible to encode to tak with foobar2000 (and all other commandline encoders for windows).

TAK 1.0.2
Reply #27
Hi there.

In the file access relation, when multibytes character is included in the filename and the pathname, etc. , it is likely to become an error in the file access relation.

It puts on Liisachan's post for this problem before and ..Liisachan's.. post.

It would be greatly appreciated when the part where the filename and the pathname are processed can be made unicode base as Liisachan's says, and the multibytes be supported.

  • JohanDeBock
  • [*][*][*][*]
  • Developer
TAK 1.0.2
Reply #28
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar.

What you mean? It already is possible to encode to tak with foobar2000 (and all other commandline encoders for windows).


Indeed just recoded my lossless lib from 1.0.1 -p4m to 1.0.2 -p5m without any problems.
foo_softplaylists: http://tiny.cc/kh9m9

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.2
Reply #29
The error in WinAmp plugin persists 

Good news: Seems as if i have found the bug. Well, it wasn't really a bug: If Winamp was calling the winampGetExtendedFileInfo()-function with a request for the LENGTH info, my plugin indicated, that this info isn't available.  That's no reason for Winamp to crash...

Hopefully i will release a new Winamp plugin in 1 or 2 days.

I have been playing around with this and I must say that I am impressed.  With TAK 1.0.2 I not only end up smaller files than my WavPack -hhx files with -p5m but the TAK files decode quite a bit faster.

I actually have a few of my CDs encoded as TAK with embedded cuesheets now and will probably have more soon.  Thank you for TAK, TBeck

Thank you for the encouragement! It's always a pleasure for me to hear that someone finds TAK useful. 

I have just uploaded a new version of foo_input_tak for foobar2000 0.9.x (does not require 0.9.5) that adds recognition for the "Insane" profile in TAK 1.0.2 (full change list).

I did some quick testing with the CPU optimization options:
Code: [Select]
Encoder: TAK 1.0.2
Profile: normal

Decoder: foo_input_tak 0.3.4 / tak_deco_lib 1.0.5

Decoding test settings (foo_benchmark):
  Buffer entire file into memory: yes
  High priority: yes
  Passes: 3
  
Desktop PC: AMD Athlon XP 2500+ (1.84 GHz)
Laptop PC:  AMD Turion64 MT30 (1.60 GHz)

Results:

Setting  | Desktop PC        | Laptop PC
==========================================
Any      | 134.264x realtime | 126.254x realtime
None     |  91.834x realtime | 104.393x realtime
ASM only |  91.834x realtime | 105.475x realtime
MMX only | 133.722x realtime | 128.006x realtime
SSE only |  91.959x realtime | 105.537x realtime


TBeck: Is SSE support implemented or is that flag only a placeholder?

Sorry, i should have written a bit more about this in the SDK documentation:

1) Currently i don't use SSE. I tried it, but it wasn't any faster than my MMX (integer) implementation.
2) ASM also has no effect. It should enable/disable non-MMX assembler optimizations, but there are very few and they mostly only compensate limitations of the delphi compiler (no code alignment, suboptimal floating point code generation, no arithmetic right shift operation). I think a well optimizing compiler would achieve similar results with plain Delphi or C code.

TBeck: Is SSE support implemented or is that flag only a placeholder?



Wow...  MMX is slower than none?  What was this compiled with?

[edit]
nevermind, i just answered my own question... Borland Delphi 6 or 7
[/edit]

You are wrong: The values in the table represent rates and not absolute time values. But the effect of MMX is  small for fast presets. The more demanding ones may be 2 to 3  times faster with MMX.

Hi there.

In the file access relation, when multibytes character is included in the filename and the pathname, etc. , it is likely to become an error in the file access relation.

It puts on Liisachan's post for this problem before and ..Liisachan's.. post.

It would be greatly appreciated when the part where the filename and the pathname are processed can be made unicode base as Liisachan's says, and the multibytes be supported.

It's on my todo list...


I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar.

What you mean? It already is possible to encode to tak with foobar2000 (and all other commandline encoders for windows).


Indeed just recoded my lossless lib from 1.0.1 -p4m to 1.0.2 -p5m without any problems.

Nice to hear... 

  Thomas

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.2
Reply #30

The error in WinAmp plugin persists 

Good news: Seems as if i have found the bug. Well, it wasn't really a bug: If Winamp was calling the winampGetExtendedFileInfo()-function with a request for the LENGTH info, my plugin indicated, that this info isn't available.  That's no reason for Winamp to crash...

Hopefully i will release a new Winamp plugin in 1 or 2 days.

I have just uploaded the Winamp plugin 1.0.6: TAK 1.0.2 Final (Uploads)

Please tell me, if it works now...

  Thomas

  • Dr. Oviri
  • [*][*][*]
  • Banned
TAK 1.0.2
Reply #31
I have just uploaded the Winamp plugin 1.0.6: TAK 1.0.2 Final (Uploads)

Please tell me, if it works now...

  Thomas


Works fine... thanx Thomas 

TAK 1.0.2
Reply #32

Hi there.

In the file access relation, when multibytes character is included in the filename and the pathname, etc. , it is likely to become an error in the file access relation.

It puts on Liisachan's post for this problem before and ..Liisachan's.. post.

It would be greatly appreciated when the part where the filename and the pathname are processed can be made unicode base as Liisachan's says, and the multibytes be supported.

It's on my todo list...
It consented. Thank you and. Can mounting be achieved by the following release?

Please hold out.

  • --pv--
  • [*][*][*]
TAK 1.0.2
Reply #33
What you mean? It already is possible to encode to tak with foobar2000 (and all other commandline encoders for windows).

hmm. I haven't noticed such a option when reading command-line arguments for takc. I have just figured it out. I am using this command-line
Code: [Select]
-e -p5 -v %s %d

Piping will remove the need for temporary files. It's not a big deal for me but now I can at least understand it now.
  • Last Edit: 13 November, 2007, 03:14:54 PM by --pv--

  • spockep
  • [*][*][*]
TAK 1.0.2
Reply #34
Sweet!!  I must say thank you for fixing the Winamp plugin.  Thomas, kudos and thanks for the constant improvement with TAK!!  I really like the new insane switch.  Keep it up...

  • buktore
  • [*][*][*][*][*]
TAK 1.0.2
Reply #35
Using 1.0.2 Final when i use foobar to converted TAK using

-e -p4 %s %d 

and

-e -p4e %s %d

I got exactly same result. (Both Extra/extra switch) I heard that in beta there is something like this. Is this still not fixed?

edit: Using TAK GUI. I see that it is the same as well. so i think it's not fix yet. so, you can ignore this post.
  • Last Edit: 21 November, 2007, 08:45:53 AM by buktore

  • Polar
  • [*][*][*][*]
TAK 1.0.2
Reply #36
Using 1.0.2 Final when i use foobar to converted TAK using

-e -p4 %s %d 

and

-e -p4e %s %d

I got exactly same result. (Both Extra/extra switch)
http://synthetic-soul.co.uk/comparison/los...sion&Desc=0 confirms your impression.

  • Synthetic Soul
  • [*][*][*][*][*]
  • Global Moderator
TAK 1.0.2
Reply #37
There is nothing to fix: -p4 and -p5 already use the options that Extra uses by default.
  • Last Edit: 21 November, 2007, 09:53:18 AM by Synthetic Soul
I'm on a horse.

  • Polar
  • [*][*][*][*]
TAK 1.0.2
Reply #38
There is nothing to fix: -p4 and -p5 already use the options that Extra uses by default.
Then why still list TAK insane extra and extra extra separately in your, that aside, fabulous comparison table?  That would help keeping the overview a little more accessible.

  • Synthetic Soul
  • [*][*][*][*][*]
  • Global Moderator
TAK 1.0.2
Reply #39
I guess you could say that it indicates to people that there is no point in using Extra, or that their results are not wrong: -p4e is the same as -p4 and -p5e is the same as -p5.

If I didn't have them there I'd probably get people asking me why I didn't test -p4e and -p5e!
I'm on a horse.

  • Polar
  • [*][*][*][*]
TAK 1.0.2
Reply #40
If I didn't have them there I'd probably get people asking me why I didn't test -p4e and -p5e!
Maybe.  Adding a little remark as to why they've been left out could solve that
I realize it's just cosmetics of course.

  • Speckmade
  • [*]
TAK 1.0.2
Reply #41
Some little things:
  • Could it be that your GUI encoder locks folders longer than needed? For a folder with some freshly encoded TAK's and Tak.exe still open but finished and even the encoding window closed renaming of the folder fails till the TAK GUI is closed.
  • Having a compression mode named the same as an additional evaluation switch ("Extra extra") can be confusing sometimes...

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.2
Reply #42
Some little things:

Thanks for the input!

Could it be that your GUI encoder locks folders longer than needed? For a folder with some freshly encoded TAK's and Tak.exe still open but finished and even the encoding window closed renaming of the folder fails till the TAK GUI is closed.

That's strange... What is your operating system? I can't reproduce this with win 98.

Having a compression mode named the same as an additional evaluation switch ("Extra extra") can be confusing sometimes...

Oh yes, you are right! Possibly i should only use numbered presets (0 to 5) like FLAC? This would also make the addition of further presets easier.

edit: I will do it... If someone knows good reasons against it, please tell me now. I am just preparing a beta release of TAK 1.0.3 (maybe in 1 to 3 days...).

  Thomas
  • Last Edit: 03 December, 2007, 03:36:23 PM by TBeck

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
TAK 1.0.2
Reply #43
All wiki articles should reflect this change as well.  I can go ahead and update the EAC/TAK guide so that it only references numbers.  The guide currently points to 1.0.1 and if there's some reason it should stay this way I can just call out -p0 through -p4; otherwise we can update to 1.0.2 and call out -p0 through -p5.

Thomas, Synthetic Soul, what do you think?  Anyone else?
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.

  • kanak
  • [*][*][*][*][*]
TAK 1.0.2
Reply #44
Oh yes, you are right! Possibly i should only use numbered presets (0 to 5) like FLAC? This would also make the addition of further presets easier.


Seconded. I'd propose that the "extra" and "max switch" be also changed to -x1 and -x2 (like in wavpack). This will make it easier for you to add further optimizations (no need to search for words  ).

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.2
Reply #45
All wiki articles should reflect this change as well.  I can go ahead and update the EAC/TAK guide so that it only references numbers.  The guide currently points to 1.0.1 and if there's some reason it should stay this way I can just call out -p0 through -p4; otherwise we can update to 1.0.2 and call out -p0 through -p5.

Thomas, Synthetic Soul, what do you think?  Anyone else?

I vote for an update! Thank you in advance.

Seconded. I'd propose that the "extra" and "max switch" be also changed to -x1 and -x2 (like in wavpack). This will make it easier for you to add further optimizations (no need to search for words  ).

You are right: It's always difficult to find more and especially the right words...

Unfortunately this syntax change would bring even more compatibility problems with already existing manuals.
And i really really really don't intend to add another evaluation level....

All i could think of would be extremely insane and only be selectable by a separate (possibly pseudo-secret) switch.

BTW: I think i should add a new switch to always select the strongest preset regardless of possibly added presets:

Code: [Select]
-pMax


  Thomas

  • Speckmade
  • [*]
TAK 1.0.2
Reply #46

Could it be that your GUI encoder locks folders longer than needed? For a folder with some freshly encoded TAK's and Tak.exe still open but finished and even the encoding window closed renaming of the folder fails till the TAK GUI is closed.

That's strange... What is your operating system? I can't reproduce this with win 98.

Windows XP Professional Service Pack 2 in this case.

  • Nick.C
  • [*][*][*][*][*]
  • Developer
TAK 1.0.2
Reply #47
Could it be that your GUI encoder locks folders longer than needed? For a folder with some freshly encoded TAK's and Tak.exe still open but finished and even the encoding window closed renaming of the folder fails till the TAK GUI is closed.

That's strange... What is your operating system? I can't reproduce this with win 98.
Windows XP Professional Service Pack 2 in this case.
If TAK has not released a file handle then the folder will not be able to be renamed as it has an open file in it.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.2
Reply #48
Windows XP Professional Service Pack 2 in this case.

Ah, thank you. Now i can reproduce the problem.

If TAK has not released a file handle then the folder will not be able to be renamed as it has an open file in it.

I think it has to do with the behaviour of Delphi's wrapper of the window's open file dialog. I will check it.

  Thomas

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.2
Reply #49
I think it has to do with the behaviour of Delphi's wrapper of the window's open file dialog. I will check it.

That it was...

But i don't know, if i should call this a bug.

Anytime you open files or choose an output directory in TAK (GUI version only), TAK will make the directory windows' current directory. Because windows does not allow you to modify any component of it's current directory path, you will see an error message.

I really don't know if i should change this behaviour. Does the average user expect something different?

  Thomas
  • Last Edit: 04 December, 2007, 12:22:17 PM by TBeck