Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: TAK 1.0.2 (Read 77379 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.0.2

Reply #50 –
Quote from: TBeck on
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 that flac provides a significant decoding speed increase when it doesn't have to calculate an md5 hash.

TAK 1.0.2

Reply #51 –
Quote from: TBeck on
Quote from: TBeck on

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
 

TAK 1.0.2

Reply #52 –
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!)