IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
TAK 2.3.0
ChronoSphere
post Jul 1 2013, 20:45
Post #51





Group: Members
Posts: 494
Joined: 11-March 07
Member No.: 41384



QUOTE (TBeck @ Jul 1 2013, 20:39) *
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.
Go to the top of the page
+Quote Post
boombaard
post Jul 2 2013, 10:53
Post #52





Group: Members
Posts: 336
Joined: 7-February 05
From: Local Cluster
Member No.: 19647



QUOTE (sajara @ Jul 1 2013, 13:23) *
QUOTE (marc2003 @ Jun 30 2013, 20:28) *
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.
Go to the top of the page
+Quote Post
d125q
post Jul 2 2013, 14:24
Post #53





Group: Members
Posts: 64
Joined: 4-May 13
Member No.: 107966



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).
Go to the top of the page
+Quote Post
db1989
post Jul 2 2013, 14:36
Post #54





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



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.
Go to the top of the page
+Quote Post
d125q
post Jul 2 2013, 14:40
Post #55





Group: Members
Posts: 64
Joined: 4-May 13
Member No.: 107966



I don't use CUETools much -- I find it hard 'pushing' my ideas into a developer whose software I don't even 'endorse.'
Go to the top of the page
+Quote Post
ChronoSphere
post Jul 2 2013, 19:49
Post #56





Group: Members
Posts: 494
Joined: 11-March 07
Member No.: 41384



QUOTE (d125q @ Jul 2 2013, 15:24) *
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)

This post has been edited by ChronoSphere: Jul 2 2013, 19:51
Go to the top of the page
+Quote Post
eternaleye
post Jul 13 2013, 11:03
Post #57





Group: Members
Posts: 3
Joined: 13-July 13
Member No.: 109094



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!
Go to the top of the page
+Quote Post
skamp
post Jul 13 2013, 11:14
Post #58





Group: Developer
Posts: 1444
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (eternaleye @ Jul 13 2013, 12:03) *
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.

This post has been edited by skamp: Jul 13 2013, 11:15


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
eternaleye
post Jul 13 2013, 11:48
Post #59





Group: Members
Posts: 3
Joined: 13-July 13
Member No.: 109094



QUOTE (skamp @ Jul 13 2013, 02:14) *
QUOTE (eternaleye @ Jul 13 2013, 12:03) *
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.

This post has been edited by eternaleye: Jul 13 2013, 11:54
Go to the top of the page
+Quote Post
Gottfried
post Aug 4 2013, 07:26
Post #60





Group: Members
Posts: 2
Joined: 4-August 13
Member No.: 109456



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?

This post has been edited by Gottfried: Aug 4 2013, 07:30
Go to the top of the page
+Quote Post
eternaleye
post Aug 24 2013, 18:11
Post #61





Group: Members
Posts: 3
Joined: 13-July 13
Member No.: 109094



QUOTE (Gottfried @ Aug 3 2013, 22:26) *
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.

This post has been edited by eternaleye: Aug 24 2013, 18:12
Go to the top of the page
+Quote Post
Igor_A
post Sep 21 2013, 06:49
Post #62





Group: Members
Posts: 1
Joined: 21-September 13
Member No.: 110196



TBeck

Thomas, please make a 64-bit version of the library tak_deco.lib.
Go to the top of the page
+Quote Post
kennedyb4
post Nov 23 2013, 20:37
Post #63





Group: Members
Posts: 772
Joined: 3-October 01
Member No.: 180



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?
Go to the top of the page
+Quote Post
TBeck
post Nov 25 2013, 01:06
Post #64


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Igor_A @ Sep 21 2013, 07:49) *
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.

QUOTE (kennedyb4 @ Nov 23 2013, 21:37) *
I love this programme, thanks you much.

Thank you!

QUOTE (kennedyb4 @ Nov 23 2013, 21:37) *
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
Go to the top of the page
+Quote Post
ChronoSphere
post Jan 16 2014, 13:15
Post #65





Group: Members
Posts: 494
Joined: 11-March 07
Member No.: 41384



Any estimate when we might see a new beta?
Go to the top of the page
+Quote Post
ChronoSphere
post Feb 5 2014, 23:00
Post #66





Group: Members
Posts: 494
Joined: 11-March 07
Member No.: 41384



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. laugh.gif
Go to the top of the page
+Quote Post
d125q
post Feb 5 2014, 23:34
Post #67





Group: Members
Posts: 64
Joined: 4-May 13
Member No.: 107966



QUOTE (ChronoSphere @ Feb 5 2014, 23:00) *
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. laugh.gif

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.
Go to the top of the page
+Quote Post
ChronoSphere
post Feb 6 2014, 00:32
Post #68





Group: Members
Posts: 494
Joined: 11-March 07
Member No.: 41384



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.
Go to the top of the page
+Quote Post
nu774
post Feb 6 2014, 02:48
Post #69





Group: Developer
Posts: 528
Joined: 22-November 10
From: Japan
Member No.: 85902



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.
Go to the top of the page
+Quote Post
themanintheshado...
post Feb 13 2014, 00:04
Post #70





Group: Members
Posts: 28
Joined: 31-October 12
Member No.: 104212



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
Go to the top of the page
+Quote Post
Studio 308
post May 17 2014, 13:19
Post #71





Group: Members
Posts: 12
Joined: 7-August 07
From: Russia
Member No.: 45976



QUOTE (ChronoSphere @ Feb 6 2014, 02:00) *
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... laugh.gif

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.

This post has been edited by Studio 308: May 17 2014, 13:26


--------------------
Listen to WMRI...
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd September 2014 - 10:56