TAK 2.2.0 Options

[boombaard]

If you used a recent version of foobar2000 (v1.1.6 or later) to calculate the replaygain values, a new algorithm is used which results in slightly different values. You can double check this by recalculating the replaygain of the original files using the latest version of foobar2000.
Anish

much obliged; that seems to explain it. Though the difference can be quite stark (2-4dB is not uncommon for my classical collection)

This post has been edited by boombaard: Sep 26 2011, 09:05

[boombaard]

It appears as though the encoder refuses to encode when it has to output a file with non-western unicode characters somewhere in the file path. (e.g. Прокофьев, Сергей Сергеевич). It works fine when the input filenames have such chars, but it bugs when it has to output to them.

(Dubravka Tomšič Srebotnjak isn't accepted either )

[TBeck]

Seem like now takc works fine with HyperThreading.
...
So, there is a speed improvement with -tn4 compared to -tn2 and lower, -tn2 with HT off/on is equal, and by default encoder uses only one thread. Everything is quite good. Thank you, TBeck

Fine! But i don't deserve any credit, because i haven't modified the multi-threading code... Maybe your system configuration has changed a bit and windows now makes more clever choices regarding the cpu assignment.

But you can always update tak_deco_lib.dll yourself.

If the whole point of foosions plugin is only link to tak_deco_lib.dll to use all of its functions, then yes.

That's the way it works.

Otherwise, i don't know if it makes sense, coz there could be e.g. some new decoding functions in the library, which will not be used with old plugin. Simply i thought Mr. Beckers plugin would be handier solution IMHO, with only one library (maybe). Don't want to discuss much about current plugin here, this was only my "small" (but maybe reasonless) request.

I don't think it's reasonless. But it's a lot easier for me to test and provide only one universal library and leave the interfacing to people who know more about the specific application. I remember it' took me quite long to make the winamp plugin work well.

Indeed there are some new functions in the latest library (get the MD5, get the channel assignment of multi-channel-audio) which have not been documented yet. Too little time.

It appears as though the encoder refuses to encode when it has to output a file with non-western unicode characters somewhere in the file path. (e.g. Прокофьев, Сергей Сергеевич). It works fine when the input filenames have such chars, but it bugs when it has to output to them.

I am surprised that it works for the input file. Did you read from a pipe?

Unicode support is on my todo list, but unfortunately i can't make any promises. Now and then i have a bit of time to work on TAK, but it's not calculable.

[TBeck]

Have you tried to compile it with 64bit Delphi or 64bit FreePascal? Would be interesting to see the results and a 64bit library would be nice as well

Well, a 64-bit version could be a bit slower... 64-bit code can be less efficient, for instance because it's bigger and may not fit as well into the cpu's code cache. Some instructions may be slower. It's faster when performing 64-bit arithmetic (especially multiplications) but TAK has been designed to work with 32-bit arithmetic (it doesn't need more). The only advantage i could think of is the doubling of the register count. This could help some of my assembler optimizations and possibly yield 5 to 10 percent faster encoding if i am lucky.

Mpeg4Als probably would benefit a lot from 64-bit arithmetic because it makes heavy use of it.

[boombaard]

Yes, the fact that piping worked got me confused. Anyway, love what you're doing with the codec, so please don't worry about the unicode support more just because I mentioned it..

[boombaard]

Just a heads-up: I haven't kept any statistics, but for most of my classical music collection, and especially for recordings from the 1940s-60s, tak -p4m actually performs on par with (within 2kbps), or better than, Monkey's Audio Extra High. In a number of cases, especially of piano and/or piano-violin recordings, this has meant a compression increase of 30-40kbps for ~400kbps recordings. (In certain recent recordings -- such as the Claude Frank or Badura-Skoda beethoven piano sonata sets -- this is notably untrue, though, with tak doing about 8kbps worse.

[tuxman]

Just out of curiousity: How far is Linux support for TAK? Would make using it with Android quite much easier.

[lvqcl]

Win32 binaries + WINE.

[tuxman]

Hmm, that would add quite some overhead ...

[Destroid]

Linux platform was touched on numerous times and the priority still remains rather low.

You do bring up a point, as the computer trends show that mobile market growth exploding. Makes me ponder a power laptop upgrade over another boxy desktop (except I still prefer the mechanical/optical mass storage options). At any rate, the issue of other platforms is heavily dependent on the developer and- in this case- how much a single developer can devote the time on this request. Also, I don't want to open the whole licensing thing, but I would imagine some headaches when dealing with a closed-source project and the Linux platform, so I'll just mention that and leave it there.

[tuxman]

Linux does not require its software to be open.

[viktor]

Linux does not require its software to be open.

that's only true if it's a standalone app. i don't think you'd want a standalone app for just tak. rather, you'll want a dynamically loaded (and previously linked) plugin for your existing app, which, along with the app it gets load into, form one software as a whole (in a legal sense at least). and in that case, the plugin must adhere to the app's license requirements. in the case of gpl, that means it has to be open source as well.

[tuxman]

My preferred Android media player is not open source either, so it should be fine...

[Anakunda]

Is there a Linux player support yet? Banshee or Amarok plugin would be nice..

[_m²_]

Linux does not require its software to be open.

that's only true if it's a standalone app. i don't think you'd want a standalone app for just tak. rather, you'll want a dynamically loaded (and previously linked) plugin for your existing app, which, along with the app it gets load into, form one software as a whole (in a legal sense at least). and in that case, the plugin must adhere to the app's license requirements. in the case of gpl, that means it has to be open source as well.

Not true.
If anybody was to distribute them together, that would be the case, but as long as user is the person bundling them together, there are no issues.


This post has been edited by _m²_: Oct 26 2011, 13:44

[PPeti66x]

Hi!
It is possible to decode multiple TAK files to single WAV? (For example for burning .CUE files with pregap information (index 00).)

[Anakunda]

Any chance to get decoding support for Banshee or Amarok ? Would be awesome!!

[pikashi]

I set my command-line options of EAC like this and test it:

-e -p0 -tn2 -l1 -fim0 -cpuSSSE3 -tt "ALBUM ARTIST=%albumartist%" -tt "ARTIST=%artist%" -tt "TITLE=%title%" -tt "ALBUM=%albumtitle%" -tt "DATE=%year%" -tt "tracknumber=%tracknr%" -tt "GENRE=%genre%" %source% %dest%

The test result seems to be no problems with my parameters, but when I rip my CDs, the popup window tells me that something is wrong.
Finally I found the Tag value of -tt should not be empty.

Just like this one:

takc.exe -e -p0 -tt "GENRE="

It tells me "Command line error: Tag: Invalid value"

I hope to get a small fix to make my parameters work correctly.
The wapet.exe seem to be too old to use.

[temp1]

any news about new version?

[TBeck]

Sorry for the lack of active participation. I have been and still am quite busy. Nevertheless i am checking this thread regulary. Just in case someone would report a severe bug...

Hi!
It is possible to decode multiple TAK files to single WAV? (For example for burning .CUE files with pregap information (index 00).)

It can't be done with the TAK applications. Maybe it's possible with foobar (for instance)? Hopefully someone else can provide you with more helpful information.

Any chance to get decoding support for Banshee or Amarok ? Would be awesome!!

I doubt this will happen unless i release an open source decoder. Unfortunately that's a topic i don't comment on (especially a release date), because of a remarkable history of me arousing wrong expactations and receiving rather fierce reactions (among them insults). I will release it, when it's done.

Finally I found the Tag value of -tt should not be empty.

Just like this one:

takc.exe -e -p0 -tt "GENRE="

It tells me "Command line error: Tag: Invalid value"

I hope to get a small fix to make my parameters work correctly.
The wapet.exe seem to be too old to use.

I checked it and indeed, my tag reader will reject empty item values. I put it on my to do list for the next release.

any news about new version?

No plans yet. I don't think i could improve TAK's speed significantly. An 64-Bit version could help a bit, not because of the 64-bit arithmetic, but because of twice as many registers available for my assembler routines. And SSE 4.1 instructions possibly could provide some opportunities. I will check this after an operating system and cpu update.

And i am still evaluating opportunities for compression improvements. Unfortunately they usually are quite slow in relation to the compression improvement and would require modifications of the file format and thus breaking compatibility.

Another relevant factor is lack of time. The last release brought you extremely efficient compression of multi channel files and this required nearly 2 months of full time work.

So i am hoping for a really good idea (what is sometimes sheer luck...) and sufficient time to realize it.

[Dario]

Tom,

could you please document the function that gets the MD5 of the audio? I would really, really like to be able to view it (the MD5 checksum) in my foobar2000. Of course, that would require an update to the foosion's decoding plug-in, but I don't think that'd be a problem.

Thanks.

[lvqcl]

About TAK and foobar2000... From http://www.foobar2000.org/changelog :

Fixed multi-channel FLAC encoding (channel mask now gets preserved).
Fixed multi-channel WavPack decoding (channel mask now gets preserved).

It seems that documenting tak_GetWaveExtensibleSpeakerMask is also a good idea

[CoRoNe]

Could someone who has access to TAK's Wiki page add dsfTAKSource and DC-Bass Source Mod, two DirectShow filters capable of decoding TAK audio, to the Software - Windows section? With TAK 1.1.0 still being mentioned as recommended encoder, the page needs an update anyhow!

[Dario]

Are there any updates regarding TAK?

[Mr.Duck]

How do you use the md5 data? It gets written into the TAK files somewhere?

The tak command line encoder can't read tak files! Is there any plan to change this?