Help - Search - Members - Calendar
Full Version: TAK 1.0.2
Hydrogenaudio Forums > Hydrogenaudio Forum > Validated News
Pages: 1, 2
TBeck
Final release of TAK 1.0.2 ((T)om's lossless (A)udio (K)ompressor)

This version brings a new low complexity Turbo preset, a faster preset configuration, a significant encoding speedup of the strongest setting and support for the LossyWav/LossyFlac preprocessor.

It consists of:

- TAK Applications 1.0.2.
- TAK Winamp plugin 1.0.6 (Updated 2007-11-12).
- TAK SDK 1.0.4.
- TAK Decoding library 1.0.5.

Download and Changelog

Download the main archive and tools, and view the changelog, in the upload section: TAK 1.0.2 Final
ArtMustHurt
wow nice...awesome work smile.gif will check out the new version...thanks TBeck
hlloyge
Thank you very much, Thomas. Your work is appreciated.
shadowking
Good one. I like tak.
Gow
Very nice speed increase when encoding into -p4 and only a small increase to the total file size. Great work!
Dr. Oviri
The error in WinAmp plugin persists dry.gif
Pilzfuss
I'll use it from now on.



Thanks heaps smile.gif
IgorC
Any chance to get update for foobar decoder? http://foosion.foobar2000.org/0.9/
Mangix
QUOTE(IgorC @ Nov 5 2007, 18:15) *

Any chance to get update for foobar decoder? http://foosion.foobar2000.org/0.9/

no point. you can just replace tak_deco_lib.dll with the newest one.
IgorC
QUOTE(Mangix @ Nov 5 2007, 23:40) *

QUOTE(IgorC @ Nov 5 2007, 18:15) *

Any chance to get update for foobar decoder? http://foosion.foobar2000.org/0.9/

no point. you can just replace tak_deco_lib.dll with the newest one.

I didn't noticed that. Thanks.
AndersHu
I don't know if it is the foo_input_tak.dll or the tak_deco_lib.dll, but for the new Insane preset Foobar shows "Codec Profile : TAK 5 extra".
foosion
QUOTE(AndersHu @ Nov 7 2007, 00:06) *
I don't know if it is the foo_input_tak.dll or the tak_deco_lib.dll, but for the new Insane preset Foobar shows "Codec Profile : TAK 5 extra".

That is expected as the current version of foo_input_tak does not know about the Insane preset yet; tak_deco_lib only reports the numerical code.
shaohao
Hi, TBeck:
About the C header file "tak_deco_lib.h"
I think you should add
CODE

#ifndef _TAK_DECO_LIB
#define _TAK_DECO_LIB
...
#endif

otherwise, the head will be included more than once in a project.
shaohao
There is a deadly bug in your new SDK 1.0.4.
I've created a decoding plug-in for a player with your TAK v1.0.1 and it works fine.
But the .tak file CANNOT be decoded by your new tak_deco_lib.dll after I update it to your TAK v1.0.2.

I have tried to debug my programme and I found that A deadly bug will be caught after I invoked "tak_SSD_ReadAudio" 6-7 times.

Can you fix it?
GeSomeone
QUOTE(foosion @ Nov 7 2007, 13:59) *

QUOTE(AndersHu @ Nov 7 2007, 00:06) *
..but for the new Insane preset Foobar shows "Codec Profile : TAK 5 extra".

That is expected as the current version of foo_input_tak does not know about the Insane preset yet; tak_deco_lib only reports the numerical code.


How about having it always show the numeric value?
If I'm correct the old Normal is about the same as the new High
(Likewise the old -p2 is about the same as the new -p3).
unsure.gif Hmm... I see now that it wouldn't help.
TBeck
First, thanks for the encouraging words! smile.gif

QUOTE(Dr. Oviri @ Nov 5 2007, 19:13) *

The error in WinAmp plugin persists dry.gif

Until know i haven't dealt with it...

QUOTE(shaohao @ Nov 7 2007, 16:02) *

Hi, TBeck:
About the C header file "tak_deco_lib.h"
I think you should add
CODE

#ifndef _TAK_DECO_LIB
#define _TAK_DECO_LIB
...
#endif

otherwise, the head will be included more than once in a project.

Huh! I thought i had this done. Thanks for the hint!

QUOTE(shaohao @ Nov 7 2007, 17:20) *

There is a deadly bug in your new SDK 1.0.4.
I've created a decoding plug-in for a player with your TAK v1.0.1 and it works fine.
But the .tak file CANNOT be decoded by your new tak_deco_lib.dll after I update it to your TAK v1.0.2.

I have tried to debug my programme and I found that A deadly bug will be caught after I invoked "tak_SSD_ReadAudio" 6-7 times.

Can you fix it?

Not without further information. Of course i have checked the backwards compatibility before releasing V1.0.2. Ok, i only checked the applications but since they are using the same code as the library this should be sufficient.

Can you decode the file with the V1.0.2 applications?

Can you send me the affected file via email (see my profile)?

Thomas
RamonSalazar
Ive asked Cog developer if he could implement TAK into Cog. The short answer:

QUOTE

Neither of these formats seem to have an open source decoder. dry.gif

Without that, I'm not very interested in adding support for it. Plugins could be written for them, but I won't be including them in the main distribution and I won't be making them.
viktor
QUOTE(RamonSalazar @ Nov 8 2007, 00:19) *

Ive asked Cog developer if he could implement TAK into Cog. The short answer:

QUOTE

Neither of these formats seem to have an open source decoder. dry.gif

Without that, I'm not very interested in adding support for it. Plugins could be written for them, but I won't be including them in the main distribution and I won't be making them.


yeah i also wanted to say that tak cant expect to be spread till its closed source
RamonSalazar
Yes, i think the decoder part should be open source. I dont kow much about these algorithms, but if the decoding process is invertabe then it cant be done alone saflely (without the enc p.).

For OSX i dont know any other lossless audio player (even if it plays only a small part of the formats). Once i had to decode my albums before i played them in OSX. TAK is yet only for Win32? sad.gif

Tom, youve made a good work, thanks.

EDIT: Irrelevant, Ive find the answer in the wiki .
shaohao
QUOTE(TBeck @ Nov 7 2007, 22:19) *

Not without further information. Of course i have checked the backwards compatibility before releasing V1.0.2. Ok, i only checked the applications but since they are using the same code as the library this should be sufficient.

Can you decode the file with the V1.0.2 applications?

Can you send me the affected file via email (see my profile)?

Thomas


Hi, Thomas:
I use your new v1.0.2 to encode a new .tak file and decode it. Everything is OK.
But my code did not work.
Here is my sample code.
Can you help me to fix it? It only decode one frame and exit:(
CODE

#include <windows.h>
#include <stdio.h>
#include "tak_deco_lib.h"
#pragma comment( lib, "tak_deco_lib")

static TtakBool _CanRead(void * AUser) { return tak_True; }
static TtakBool _CanWrite(void * AUser) { return tak_False; }
static TtakBool _CanSeek(void * AUser) { return tak_True; }
static TtakBool _Read(void * AUser, void * ABuf, TtakInt32 ANum, TtakInt32 * AReadNum)
{
    FILE ** fp = (FILE **)AUser;
    *AReadNum = fread( (LPBYTE)ABuf, 1, ANum, *fp);
    if ( *AReadNum < ANum) {
        return tak_False;
    } else {
        return tak_True;
    }
}
static TtakBool _Seek(void * AUser, TtakInt64 APos)
{
    return (0 == _fseeki64( *(FILE **)AUser, APos, SEEK_SET)) ? tak_True : tak_False;
}
static TtakBool _GetLength(void * AUser, TtakInt64 * ALength)
{
    FILE ** fp = (FILE **)AUser;
    TtakInt64 pos = _ftelli64( *fp); // save it
    if ( 0 != _fseeki64( *fp, 0, SEEK_END)) return tak_False; // seek to end
    *ALength = _ftelli64( *fp); // get length
    if ( 0 != _fseeki64( *fp, pos, SEEK_SET)) return tak_False; // restore
    return tak_True;
}

int _tmain(int argc, _TCHAR* argv[])
{
    FILE * m_fp;
    m_fp = _tfopen( _T("test.tak"), _T("r"));

    TtakSeekableStreamDecoder m_Decoder;
    Ttak_str_StreamInfo       m_StreamInfo;

    LPBYTE m_TAKBuf; // decoded buffer

    // OPEN

    TtakSSDOptions            opt  = { tak_Cpu_Any, 0 };
    TtakStreamIoInterface     sioi = { _CanRead, _CanWrite, _CanSeek, _Read, NULL, NULL, NULL, _Seek, _GetLength };

    m_Decoder = tak_SSD_Create_FromStream( &sioi, &m_fp, &opt, NULL, NULL);

    int ret = 0;
    if ( (tak_True == tak_SSD_Valid( m_Decoder))
      && (tak_res_Ok == tak_SSD_GetStreamInfo( m_Decoder, &m_StreamInfo))
       )
    {
        // allocate decoding buffer
        m_TAKBuf = new BYTE[m_StreamInfo.Sizes.FrameSizeInSamples * m_StreamInfo.Audio.BlockSize];
    } else {
        tak_SSD_Destroy( m_Decoder);
        fclose( m_fp);
        return 0;
    }

    // DECODE
    TtakInt32 readNum;
    TtakResult takResult;
    do {
        takResult = tak_SSD_ReadAudio( m_Decoder, m_TAKBuf, m_StreamInfo.Sizes.FrameSizeInSamples, &readNum);
        Sleep( 10);
    } while ( (takResult == tak_res_Ok) || (takResult == tak_res_ssd_FrameDamaged));

    // DESTROY

    tak_SSD_Destroy( m_Decoder);

    fclose( m_fp);

    return 0;
}
TBeck
QUOTE(shaohao @ Nov 8 2007, 17:03) *

Hi, Thomas:
I use your new v1.0.2 to encode a new .tak file and decode it. Everything is OK.
But my code did not work.
Here is my sample code.
Can you help me to fix it? It only decode one frame and exit:(

At first sight your code looks ok.

I have to speculate a bit.

You don't check the success of _tfopen() before using the file with TAK. Possibly _tfopen() already fails...

QUOTE(shaohao @ Nov 8 2007, 17:03) *

CODE

int _tmain(int argc, _TCHAR* argv[])
{
    FILE * m_fp;
    m_fp = _tfopen( _T("test.tak"), _T("r"));

    TtakSeekableStreamDecoder m_Decoder;
    Ttak_str_StreamInfo       m_StreamInfo;

    LPBYTE m_TAKBuf; // decoded buffer

    // OPEN

    TtakSSDOptions            opt  = { tak_Cpu_Any, 0 };
    TtakStreamIoInterface     sioi = { _CanRead, _CanWrite, _CanSeek, _Read, NULL, NULL, NULL, _Seek, _GetLength };

    m_Decoder = tak_SSD_Create_FromStream( &sioi, &m_fp, &opt, NULL, NULL);


DreamTactix291
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 smile.gif
foosion
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
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?
jesseg
QUOTE(foosion @ Nov 8 2007, 18:05) *
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]
Spirit_of_the_ocean
If there would be more decoders may be there will be more users whowill use tak?
What I really miss is something to play Tak also in Linux systems.

Great work.
--pv--
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar. biggrin.gif
Alexxander
QUOTE(--pv-- @ Nov 11 2007, 11:01) *
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar. biggrin.gif

What you mean? It already is possible to encode to tak with foobar2000 (and all other commandline encoders for windows).
Alphaziel
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
QUOTE(Alexxander @ Nov 11 2007, 10:49) *

QUOTE(--pv-- @ Nov 11 2007, 11:01) *
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar. biggrin.gif

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.
TBeck
QUOTE(Dr. Oviri @ Nov 5 2007, 19:13) *

The error in WinAmp plugin persists dry.gif

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.

QUOTE(DreamTactix291 @ Nov 8 2007, 19:35) *

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 smile.gif

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

QUOTE(foosion @ Nov 9 2007, 01:05) *

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
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.

QUOTE(jesseg @ Nov 10 2007, 02:00) *

QUOTE(foosion @ Nov 8 2007, 18:05) *
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.

QUOTE(Alphaziel @ Nov 11 2007, 18:06) *

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...

QUOTE(JohanDeBock @ Nov 11 2007, 18:58) *

QUOTE(Alexxander @ Nov 11 2007, 10:49) *

QUOTE(--pv-- @ Nov 11 2007, 11:01) *
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar. biggrin.gif

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... rolleyes.gif

Thomas
TBeck
QUOTE(TBeck @ Nov 12 2007, 22:41) *

QUOTE(Dr. Oviri @ Nov 5 2007, 19:13) *

The error in WinAmp plugin persists dry.gif

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
QUOTE(TBeck @ Nov 12 2007, 23:52) *

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 smile.gif
Alphaziel
QUOTE(TBeck @ Nov 13 2007, 06:41) *

QUOTE(Alphaziel @ Nov 11 2007, 18:06) *

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--
QUOTE(Alexxander @ Nov 11 2007, 11:49) *

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
-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.
spockep
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... biggrin.gif
buktore
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.
Polar
QUOTE(buktore @ Nov 21 2007) *
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
There is nothing to fix: -p4 and -p5 already use the options that Extra uses by default.
Polar
QUOTE(Synthetic Soul @ Nov 21 2007) *
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
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!
Polar
QUOTE(Synthetic Soul @ Nov 22 2007) *
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 wink.gif
I realize it's just cosmetics of course.
Speckmade
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
QUOTE(Speckmade @ Dec 3 2007, 21:06) *

Some little things:

Thanks for the input!

QUOTE(Speckmade @ Dec 3 2007, 21:06) *

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.

QUOTE(Speckmade @ Dec 3 2007, 21:06) *

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
greynol
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?
kanak
QUOTE(TBeck @ Dec 3 2007, 15:30) *

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 laugh.gif).
TBeck
QUOTE(greynol @ Dec 3 2007, 23:03) *

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.

QUOTE(kanak @ Dec 3 2007, 23:29) *

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 laugh.gif).

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

-pMax


Thomas
Speckmade
QUOTE(TBeck @ Dec 3 2007, 21:30) *

QUOTE(Speckmade @ Dec 3 2007, 21:06) *

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
QUOTE(Speckmade @ Dec 4 2007, 16:06) *
QUOTE(TBeck @ Dec 3 2007, 21:30) *
QUOTE(Speckmade @ Dec 3 2007, 21:06) *
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.
TBeck
QUOTE(Speckmade @ Dec 4 2007, 17:06) *

Windows XP Professional Service Pack 2 in this case.

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

QUOTE(Nick.C @ Dec 4 2007, 17:28) *

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
QUOTE(TBeck @ Dec 4 2007, 17:47) *

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
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.