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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58784&view=findpost&p=527889)
wow nice...awesome work will check out the new version...thanks TBeck
Thank you very much, Thomas. Your work is appreciated.
Good one. I like tak.
Very nice speed increase when encoding into -p4 and only a small increase to the total file size. Great work!
The error in WinAmp plugin persists
I'll use it from now on.
Thanks heaps
Any chance to get update for foobar decoder? http://foosion.foobar2000.org/0.9/ (http://foosion.foobar2000.org/0.9/)
Any chance to get update for foobar decoder? http://foosion.foobar2000.org/0.9/ (http://foosion.foobar2000.org/0.9/)
no point. you can just replace tak_deco_lib.dll with the newest one.
Any chance to get update for foobar decoder? http://foosion.foobar2000.org/0.9/ (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.
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".
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.
Hi, TBeck:
About the C header file "tak_deco_lib.h"
I think you should add
#ifndef _TAK_DECO_LIB
#define _TAK_DECO_LIB
...
#endif
otherwise, the head will be included more than once in a project.
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?
..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).
Hmm... I see now that it wouldn't help.
First, thanks for the encouraging words!
The error in WinAmp plugin persists
Until know i haven't dealt with it...
Hi, TBeck:
About the C header file "tak_deco_lib.h"
I think you should add
#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!
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
Ive asked Cog developer if he could implement TAK into Cog. The short answer:
Neither of these formats seem to have an open source decoder.
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.
Ive asked Cog developer if he could implement TAK into Cog. The short answer:
Neither of these formats seem to have an open source decoder.
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
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?
Tom, youve made a good work, thanks.
EDIT: Irrelevant, Ive find the answer in the wiki (http://wiki.hydrogenaudio.org/index.php?title=TAK#TAK_Performance_Graph) .
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:(
#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;
}
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...
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);
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
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=54087&view=findpost&p=528592)).
I did some quick testing with the CPU optimization options:
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?
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]
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.
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar.
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 (http://wiki.hydrogenaudio.org/index.php?title=TAK#TAK_with_foobar2000) (and all other commandline encoders for windows).
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=43179&st=0&p=378222&#entry378222) 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.
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 (http://wiki.hydrogenaudio.org/index.php?title=TAK#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.
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=54087&view=findpost&p=528592)).
I did some quick testing with the CPU optimization options:
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=43179&st=0&p=378222&#entry378222) 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 (http://wiki.hydrogenaudio.org/index.php?title=TAK#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
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) (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58784&view=findpost&p=527889)
Please tell me, if it works now...
Thomas
I have just uploaded the Winamp plugin 1.0.6: TAK 1.0.2 Final (Uploads) (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58784&view=findpost&p=527889)
Please tell me, if it works now...
Thomas
Works fine... thanx Thomas
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=43179&st=0&p=378222&#entry378222) 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.
What you mean? It already is possible to encode to tak with foobar2000 (http://wiki.hydrogenaudio.org/index.php?title=TAK#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
-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.
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...
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.
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 (http://synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=Compression&Desc=0) confirms your impression.
There is nothing to fix (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58382&view=findpost&p=524635): -p4 and -p5 already use the options that Extra uses by default.
There is nothing to fix (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58382&view=findpost&p=524635): -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.
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!
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.
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...
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
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?
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 ).
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:
-pMax
Thomas
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.
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.
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
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
I vote for an update! Thank you in advance.
It's done. I was going to change what was said about the external return code, but figured I'd better leave it since I don't know the full story about wapet returning errors under various circumstances. Personally I use a batch script which does pass error information along and have the setting in EAC enabled.
As for the main TAK article, I left it alone, though I do have reservations about the comparisons made with other encoders since they seem to be very dependent on system and sample; not to mention that Josh recently reported (http://www.hydrogenaudio.org/forums/index.php?showtopic=58850&st=0&p=531840&#entry531840) that flac provides a significant decoding speed increase when it doesn't have to calculate an md5 hash.
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?
Can someone please help me with this question? I really don't know what would be the best (meet the average user's expectations)...
Thomas
When it has finished working and I already closed the encoding window I would expect it to unlock the folder/files. For example I'm often working with a whole bunch of programs on an album's folder (ripper, wav trimmer, compressor, tagger, replay gain scanner, ...) and now renaming fails and you don't know which program caused the lock - can be confusing or stressful to close them one by one trying to unlock your folder again...
I think a program should only lock files/folders if it needs to because it's currently working with them. And for a user without further insight I think it's quite logical that you can't work on the file while another program is processing it - but afterwards?
Also it seems unnecessarily stressful if I have to close the tool, because it thinks it is the only thing in the world just to open it again the next minute to encode the next album and therefore again having to set all my desired options, select the whole path, that is just little different... -
Oh, by the way: maybe it would be handy if tak.exe stores the last settings..?
So far on what I'm thinking about it...
Regards from the Speckmade
(I like your baby - lookin forward to welcome it in the world of free software, on linux, in rockbox, ... Thanks so far, man!)