p0 : test=219x encode=131x, size=100.96%p0e: test=153x encode=89x, size=100.94%p0m: test=86x encode=69x, size=100.50%p1 : test=159x encode=83x, size=100.51%p1e: test=92x encode=69x, size=100.52%p1m: test=60x encode=52x, size=100.27% p2 : test=113x encode=79x, size=100.30%p2e: test=62x encode=51x, size=100.29% p2m: test=34x encode=31x, size=100.15% p4: test=38x encode=36x size=99.92%p4e: test=31x encode=29x, size=100.04% p4m: test=17x encode=17x, size=100.04%
Glorious Times-p0.tak 170* OkGlorious Times-p0e.tak 134* OkGlorious Times-p0m.tak 165* OkGlorious Times-p1.tak 92* OkGlorious Times-p1e.tak 147* OkGlorious Times-p1m.tak 168* OkGlorious Times-p2.tak 121* OkGlorious Times-p2e.tak 140* OkGlorious Times-p2m.tak 177* OkGlorious Times-p4.tak 180* OkGlorious Times-p4e.tak 173* OkGlorious Times-p4m.tak 141* Ok
Glorious Times-p0.tak 83* OkGlorious Times-p0e.tak 69* OkGlorious Times-p0m.tak 70* OkGlorious Times-p1.tak 58* OkGlorious Times-p1e.tak 77* OkGlorious Times-p1m.tak 58* OkGlorious Times-p2.tak 64* OkGlorious Times-p2e.tak 73* OkGlorious Times-p2m.tak 58* OkGlorious Times-p4.tak 48* OkGlorious Times-p4e.tak 72* OkGlorious Times-p4m.tak 60* Ok
I noticed that the encoder fails to work for regular ansi filenames if path happens to contain unicode characters. For example open command prompt in dir called "Po?ród kwiatów i cieni" and try to encode a simple "test.wav" there. Usually encoders, even if they don't support unicode, have no problems doing this.
Hey I just wanted to say that TAK now is faster than ever and I love it ! My music playlist which consists of 2300+ songs is all in TAK because it's much faster than FLAC both when encoding and decoding. (I use OGG on my DAP, which is a Sansa ClipZip).So thanks TBeck ! I wish the best for this format's future.
This is not by any means a neutral test, it is the least-FLACable piece of music from my collection, and it is the least flattering for TAK that I have ever come across (it is WavPack-friendly as long as time is no object ...). Consider it a worst-case test.
Continue the good work!
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.
I will! Well, if time permits... I've just optimized a new compression technique, which was encoding far too slow: 0.1 * realtime on my PC. Now it's more than 250 * realtime and therefore practicable. But it's integration would require a format change and the compression improvement isn't big enough to justify it. So i will have to look for more tuning oppurtunities. At some point the sum of improvements may be sufficient.It's simply getting more and more difficult to squeeze out some more compression without significantly affecting the decoding speed.
I want to venture that most TAK users do not have a major issue with a format change, as longs as: that it is accompanied by a major revision number (i.e. TAK 3.xx); and, backwards compatibility for decoding previous versions exists.
I'm not that knowledgeable about it, but why didn't you include support for unicode right from the start?
Of course, I expect you (the developer) already knows this. I merely state in public that fears over 'format change' might be exaggerated (unless *somehow* the reverse-engineered TAK decoder gained a lot of traction :shrug:). Looking at all the other lossless codecs, changing the format seems to derive from necessity and evolution via accumulative enhancements.
Quote from: Destroid on 01 July, 2013, 05:09:31 AMI want to venture that most TAK users do not have a major issue with a format change, as longs as: that it is accompanied by a major revision number (i.e. TAK 3.xx); and, backwards compatibility for decoding previous versions exists.I wholeheartedly agree with this.
unless *somehow* the reverse-engineered TAK decoder gained a lot of traction
But it does imply upgrading decoders for playing the new files.
Filename is taken care by fb2k, so you should have no problem if path to the destination directory doesn't contain Unicode characters not present in your code page. Otherwise it will fail.If you don't get it, try encoding to C:\?\?\ or something.
1 out of 1 tracks converted with major problems.Source: "D:\WAV Audio\02 Éàçãô.wav" An error occurred while writing to file (The encoder has terminated prematurely with code 2 (0x00000002); please re-check parameters) : "D:\?\02 Éàçãô.tak" Additional information: Encoder stream format: 44100Hz / 2ch / 16bps Command line: "C:\Users\Main\AppData\Roaming\foobar2000\encoders\Takc.exe" -e -p4m -tn4 -ihs - "temp-A849E32B71D002A5CD61CFDEA5B46919.tak" Working folder: D:\?\ Conversion failed: The encoder has terminated prematurely with code 2 (0x00000002); please re-check parameters
Source: "\\server\music\Sawano Hiroyuki\Shingeki no Kyojin OST\01. ???? - ?t?æk 0N t??tn.flac" An error occurred while finalizing the encoding process (Object not found) : "R:\01. ???? - ?t?æk 0N t??tn.tak"
1 out of 1 tracks converted with major problems.Source: "\\server\music\Sawano Hiroyuki\Shingeki no Kyojin OST\07. Cyua - Vogel im Käfig.flac" An error occurred while finalizing the encoding process (Object not found) : "R:\07. Cyua - Vogel im Käfig.tak" Conversion failed: Object not found
1 out of 1 tracks converted with major problems.Source: "\\server\music\01. 戦場ヶ原ひたぎ（斎藤千和） - 二言目.flac" An error occurred while finalizing the encoding process (Object not found) : "R:\01. 戦場ヶ原ひたぎ（斎藤千和） - 二言目.tak" Conversion failed: Object not found
Adding -ihs fixes that, indeed. I did read the takc help, but it wasn't clear the -ihs parameter is mandatory when piping to me.Why not make it set the parameter automatically? Or is it something specific to the way foobar is piping the file?
One more thing, is the way TAK works suitable for a (future) GPU implementation? I remember bryant saying that wavpack, for example, isn't.