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 2.3.0 (Read 137858 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 2.3.0

Reply #50
But i wouldn't expect a similar compression advantage of a more extensive evaluation of compression parameters as FLAC achieves. Im most of my evaluations TAK's fast heuristics came very close to a brute force approach which tries most of the possible parameter combinations.

Well IMHO, TAK already compresses more than enough, way better than FLAC on some albums (413 vs 479MB for example), so my main interest would be encoding speed gained by making use of the GPU.  Your current multithreading is still inferior to foobar starting 4x encoders for my setup, tn4 is around 90x, 4x tn1 is 125x (FlacCL: 200x), so maybe using the GPU would boost that.

Also as Destroid said, increasing encoding speed by changing format specifications is fine as long as backwards compatibility is kept. Since you said the feature you could optimize would go from 0.1x to 250x, it should be a nice boost even if it doesn't translate to decoding speed directly.

I'll continue keeping an eye on TAK for now.

TAK 2.3.0

Reply #51
try foobar instead? that uses temporary filenames when encoding and then renames them when done. so it really doesn't matter whether the encoders support unicode or not.


Just to note that i've converted from FLAC over 60 albums with Foobar till now and haven't experienced any problems with filenames using lots of (´ ` ~ ^ ç ...and so on) on the filename characters, it converts everything flawlessly. So maybe it really depends how the applications pass the original names to the *.tak destination file or how they use the pipe for that matter.

Those are supported yes, but middle-european diacriticals (such as in e.g. Mata?i?) are not, and if you try to convert files that are in folders with e.g. Cyrillic characters in them, the encoder will immediately exit (in foobar), regardless of output directory name choice.

 

TAK 2.3.0

Reply #52
You guys should tell the author of CUETools to start using tak_deco_lib.dll instead of piping Takc.exe's decoded output; that way, at least its verification features will not be hindered by TAK's inability to handle Unicode characters (the decoding library should have no problems handling them so long as CUETools doesn't -- this can also be observed with foobar2000's playback component).

TAK 2.3.0

Reply #53
Can I ask why other people should tell the author when it is your idea? The thread in CD Hardware/Software is likely to get your request viewed by Gregory, so I see no reason why you cannot post it there yourself.

TAK 2.3.0

Reply #54
I don't use CUETools much -- I find it hard 'pushing' my ideas into a developer whose software I don't even 'endorse.'

TAK 2.3.0

Reply #55
You guys should tell the author of CUETools to start using tak_deco_lib.dll instead of piping Takc.exe's decoded output; that way, at least its verification features will not be hindered by TAK's inability to handle Unicode characters (the decoding library should have no problems handling them so long as CUETools doesn't -- this can also be observed with foobar2000's playback component).
It's a possible workaround, yes. But to be honest, I'd rather see TBeck implement unicode, especially since using tak_deco_lib.dll still won't solve the inability to (batch) encode unicode filenames.

One of the few reasons I'm not migrating to TAK is because I can't convert my ~300GB library in one go - even on fast presets it takes about 8 hours, and if I have to mess around with my filenames, it adds a lot of unnecessary work. So I'd rather wait. (Another is lack of rockbox support)

TAK 2.3.0

Reply #56
I apologize if this skirts the line, but (at least in my case) I'm less concerned with open-sourcing in the short term, and more with the fact that Wine is a *really* heavy dependency to run takc (since I only use Linux). My concern is convenience, rather than ideology.

Because of that, I'd like to ask if you've tried http://www.lazarus.freepascal.org/ - it claims to be "a Delphi compatible cross-platform IDE for Rapid Application Development," and can convert Delphi projects in what seems to be a mostly-automated manner: http://wiki.freepascal.org/Delphi_Converter_in_Lazarus

One nice thing is that it has a conversion mode that attempts to support both Lazarus and Delphi in the same project, but what I find most interesting is that it can compile for Linux. Doing so requires a Linux system, but that can be done in VirtualBox or VMWare and isn't hugely difficult to set up.

Thanks for your time and the awesome codec, TBeck!

TAK 2.3.0

Reply #57
Wine is a *really* heavy dependency to run takc (since I only use Linux). My concern is convenience, rather than ideology.


Heavy, how? Sure, the Arch Linux package is about 33MiB, but my ADSL line is fast enough that it doesn't bother me. It runs fast too, and doesn't seem to use too much RAM. With caudec, convenience is one of the things that I was aiming at. It makes encoding and decoding TAK files very fast and easy.

TAK 2.3.0

Reply #58
Wine is a *really* heavy dependency to run takc (since I only use Linux). My concern is convenience, rather than ideology.


Heavy, how? Sure, the Arch Linux package is about 33MiB, but my ADSL line is fast enough that it doesn't bother me. It runs fast too, and doesn't seem to use too much RAM. With caudec, convenience is one of the things that I was aiming at. It makes encoding and decoding TAK files very fast and easy.


I run a source distro, and wine itself has some heavy deps. I don't necessarily want X on every system I want to be able to transcode files to TAK on. Also, 32/64 bit multilib (required for wine) means that I basically have *every* package in wine's entire dep tree installed twice because my system is 64-bit native. If not for wine, my system could be pure 64-bit.

Caudec does help a great deal, and it's how I've been using TAK, but there are other wrinkles as well. For instance, I need to run takc once, then when it crashes on startup (consistent across multiple wine versions here) kill all wine processes including winedbg. After that, takc will run without any problems until next reboot.

TAK 2.3.0

Reply #59
I want to thank the author, TBeck for his great work!

On the Linux question, I can suggest something, yes?

Has anyone tried if foobar with the the latest 2.3.0 tak decoding AND encoding work without error in Crossover 12 instead of Wine on Linux Mint or Ubuntu?

That may be a way to run Tak in 64-bit Linux with least amount of unnecessary dependencies.

Ive switched to Linux, too on almost all my computers but I haven't tried audacity or foobar on Linux in this way because I am still using an XP computer for audio. Perhaps somebody here has done this?

TAK 2.3.0

Reply #60
I want to thank the author, TBeck for his great work!

On the Linux question, I can suggest something, yes?

Has anyone tried if foobar with the the latest 2.3.0 tak decoding AND encoding work without error in Crossover 12 instead of Wine on Linux Mint or Ubuntu?

That may be a way to run Tak in 64-bit Linux with least amount of unnecessary dependencies.

Ive switched to Linux, too on almost all my computers but I haven't tried audacity or foobar on Linux in this way because I am still using an XP computer for audio. Perhaps somebody here has done this?


Sorry I took so long for this, but Crossover *is* Wine, with some additions. Codeweavers are a major contributor to Wine upstream. In order to run 32-bit Windows programs, you need 32-bit Wine/Crossover; that means you need a great deal of 32-bit libraries. On a native 64-bit system, that can be a hassle.

TAK 2.3.0

Reply #61
TBeck

Thomas, please make a 64-bit version of the library tak_deco.lib.

TAK 2.3.0

Reply #62
I love this programme, thanks you much.

I just installed on Windows7 latest 64 build and it only uses 4 cores and 8 threads where 6 cores and 12 threads are available. Is there an adjustment I can make, or a programme default?

TAK 2.3.0

Reply #63
TBeck

Thomas, please make a 64-bit version of the library tak_deco.lib.

Did you also send me an email i didn't reply to? Sorry...

I really want to go 64 bit. Because it's getting standard and i am also interested into possible performance improvements. Not necessarily because of the 64-bit-integer arithmetic. TAK has been designed to rely on 32 bit arithmetic. But the 8 additional registers for the SSEx-optimizations could help a bit.

But first i have to perform some preparations:

- Install an OS with 64 bit. I am a bit behind...
- Choose an development platform which supports 64-bit compiles.

Although it was my intention to switch from my good old Delphi 6 to C++, i am currently thinking about an upgrade to Delphi XE5. For a limited time Embarcadero is offering an affordable upgrade path from my old Delphi. I haven't deceided on it.

I love this programme, thanks you much.

Thank you!

I just installed on Windows7 latest 64 build and it only uses 4 cores and 8 threads where 6 cores and 12 threads are available. Is there an adjustment I can make, or a programme default?

Sorry, no. I tend to be a bit conservative reagarding features i can't test myself. But there is no technical reason why TAK's multi-threading-code shouldn't work with more than 4 cores. I will remove this restriction in the next version.

  Thomas

TAK 2.3.0

Reply #64
Any estimate when we might see a new beta?

TAK 2.3.0

Reply #65
I just finished moving my audio library (~20k files, 254GB in flac + metadata) to tak. Using the maximum preset, TAK was able to shave off 12GB!
Some might say it's pretty insignificant if you look at HDD prices, but for me it's more than enough to justify moving to it as my archiving/pc listening format.

One major annoyance is still present though - lack of unicode support. foobar2000/TAC/CUETools did work around filenames with foreign characters by using temporary filenames, but they can't do anything about paths with foreign characters (I'm actually surprised playback works). Those albums had to be handled manually, of course. And will have to every time I attempt to i.e. verify their integrity against CTDB.

I'd be really, really, really grateful, if unicode support became a priority for the next release. 

TAK 2.3.0

Reply #66
I just finished moving my audio library (~20k files, 254GB in flac + metadata) to tak. Using the maximum preset, TAK was able to shave off 12GB!
Some might say it's pretty insignificant if you look at HDD prices, but for me it's more than enough to justify moving to it as my archiving/pc listening format.

One major annoyance is still present though - lack of unicode support. foobar2000/TAC/CUETools did work around filenames with foreign characters by using temporary filenames, but they can't do anything about paths with foreign characters (I'm actually surprised playback works). Those albums had to be handled manually, of course. And will have to every time I attempt to i.e. verify their integrity against CTDB.

I'd be really, really, really grateful, if unicode support became a priority for the next release. 

It is the command-line tool which cannot handle Unicode paths (Takc.exe); tak_deco_lib.dll (which foobar2000's decoding component uses) has no problems whatsoever.

TAK 2.3.0

Reply #67
I am aware of that. tak_deco_lib probably passes the tak file as a pipe or something, avoiding paths altogether, as tak's code itself is not unicode-capable.

TAK 2.3.0

Reply #68
tak_deco_lib provides a way of callback based I/O that is similar to fmemopen(3) on Linux or funopen(3) on BSD, where I/O is done on the caller/application side. This allows the caller to open the file and provides functions for reading/seeking the file, that enables application to take care of OS specific file handling when library itself does not.
Similar style API has also been available on libFLAC, libwavpack or something, and that is why you could play FLAC files having Unicode file name through libFLAC, when libFLAC and it's CLI frontend didn't support Unicode file name on MS Windows.

TAK 2.3.0

Reply #69
For users of dBpoweramp:

If you want to use TAK with that program, you'll have to use a modified command line with it's CLI encoder extension to get it to work. Here's an example:

-e -p4m -overwrite -ihs -md5 -tt "Artist=[Artist]" -tt "Title=[Title]" -tt "Album=[Album]" -tt "Year=[year]" -tt "Track=[Track]" -tt "Genre=[Genre]" - "[outfile]"

The explanation for this is here
ghostman

TAK 2.3.0

Reply #70
One major annoyance is still present though - lack of unicode support.

Same for me. Started moving to TAK some years ago, but I make it manually mostly. My collection is over 150.000 tracks. Support for Unicode is essential, because it is impossible to check TAK files in Cue Tools in AR/CTDB without first making safe titles - a lot of useless manipulation. It is of course possible to encode them, check by DBs only once, then add all those special characters and leave it alone forever. But I like to make fresh checks by databases, also because most rips are not there on first checks.

Just curious how the ripping behaviour changed these years comparing to 10 years ago. I just stupidly recheck albums by AccurateRip / CueTools DB and feel pleasure...

Also lack of 32-bit support makes me use WavPack for studio masters in this quality, but most others including FLAC doesn't support either. TAK also has very nice breakaway from others on high samplerate. May save up to 100-200MB on some material, not 20-30MB as on 44/16. I use TAK for studio masters archive and it would be nice if it could be used smoothly with Cockos REAPER without need to encode WAV or FLAC to work with.
Listen to WMRI...

TAK 2.3.0

Reply #71
Can we maybe have unicode file support as a Christmas present? Pretty please?

I'm running into unicode problems much more often nowadays thanks to some weird naming sense of the artists, and having a rip suddenly cancel itself in the middle of the disc because tak chokes on an unicode is rather aggravating.

TAK 2.3.0

Reply #72
Hi Thomas,

hope you're doing well. I was wondering if you would be willing to tell us how your work on the next version of TAK is progressing. I appreciate that you're busy, so I don't mind much either way if it's still a long ways out or not; but I'm curious as to how far you are from reaching the goals you set for the next release.

TAK 2.3.0

Reply #73
hope you're doing well.

Thank you. I really want to work on the next release, but my paid job is taking up a lot of time. While i intended to port TAK to C, this looks unrealistic at the moment. Therefore the next version still has to be written in Delphi. Since my Delphi 6 ist lacking a lot required for the planned features, i finally bought an upgrade to Delphi XE 7 (There was a time limited offer for users of very old versions).

Planned features in order of current priority:

1. Unicode support
2. An 64 bit version especially of the decoder library.
3. Optimizations for the AVX2 instruction set.
4. Optimizations for multithreading.
5. An encoder library.

But to be honest, i really can't tell you when i will have more time to work on TAK. In the worst case it could be June (then a demanding project is completed). I hope to start earlier.

And i still have to answer a couple of mails...

  Thomas

TAK 2.3.0

Reply #74
Thank you Thomas!
I appreciate the update and the knowledge that a x64 TAK is coming.