I hope this is the right place for this post.

I wrote a DirectShow filter for TAK, called dsfTAKSource.
You can download it here: http://home.tele2.it/LivioCavallo/

It's the first version, so please warn me of any problem.
This filter should allow any directshow player to open, decode and play .tak audio files.

Well, I hope you'll like it.

---
HorsePower73

On installation I get the error message:Checked the directory and file is indeed available. Maybe this is because I tried on machine using Windows 2000. Is there any Visual C dependencies?

edit: Yes, needed MSVCP90.DLL and MSVCR90.DLL.
Can play TAK files in Media Player Classic with seeking working ok.

Thanks for testing the filter.
effectively it is better to avoid additional dependencies. I removed that 2 dependencies and linked statically with CRT libs.
Version 0.0.1.1, now online, has not these dependencies.

Nice! Works without those .DLL's.

(I can't wait to try the TAK .FLT you mentioned a while back )

Well, really that FLT filter is ready and working: I've been using it for some weeks...
I wrote a Nero input filter too.

The problem with Audition filters (FLT) and Nero filters is licensing policy: so far I have not had time to read thier licences and I do not know whether I can put such filters online.
Can someone help me about this?

There's only one problem I encountered. It doesn't play tak files with unicode filename.

I could not find any specifics, but it would appear that non-profit filters are ok. If you start making a retirement fund with plug-ins then that's different

Seriously, I have not heard of any restrictions on free plug-ins but that does not mean there is not a conflict between the different software licenses. All the different software license carp is very confusing and with all the patent suits going on it might be worth contacting the developers. :shrug:

Yes, I know.
The problem here is that tac_deco_lib does not accept UNICODE filenames.

<brainstorming mode on>
I could try to work around this problem rewriting part of the filter to use tac-deco_lib streaming interface instead of file functions.
But now I'm considering rewriting my filter as a parser filter with support to IAsyncReader, in next major version.
<brainstorming mode off>

Maybe I'll work on it.

You can convert widechar to multibyte, I think TAK accept multibyte filenames? I never checked

If you use Visual Studio:
char mbMultiByteFilename[_MAX_PATH];
WideCharToMultiByte(CP_UTF8, 0, szWideCharFilename, -1, mbMultiByteFilename, _MAX_PATH, 0, 0);
tak_SSD_Create_FromFile (mbMultiByteFilename, &Options, NULL, NULL);

[Are these programming details in topic?]

<Programming details START>
WideCharToMultiByte is a system function accessible using Kernel32.lib starting from WinNT, it's not a VisualStudio exclusive.
Filename string conversion in dsfTAKSource is already done using WideCharToMultiByte.
Some unicode characters does not have any MB equivalent (this is a reason unicode exists!), so conversion is sometimes impossible.
Also using best_fit_conversion on conversion exception (with system default character, the '?' wilcard used in place of not convertible characters) tak_SSD_Create_FromFile cannot open the file.
<Programming details END>

I compiled a new dsfTAKSource build which returns a better error code on filename conversion error.
Now players should detect and report it in a better way.
I'll put last build on dsfTAKSource site.

P.S.: as some of you may have noticed, site has moved. Now it is here:
http://liviocavallo.altervista.org/

Wow, that's really cool! Thank you very much!

i will try it as soon as i have a bit more time.


Yes, unfortunately. I will put it on my todo list.

Thomas

Ah, was that the problem? I'll be so happy once that's fixed.

dsfTAKSource v 0.0.1.2 is out (http://liviocavallo.altervista.org/)

ChangeLog
------------------------------------------------------------------------------------

v 0.0.1.2 (25.09.2009)

• Partially rewritten STR_Converter helper functions to return better error codes and to throw standard exceptions on filename conversion errors so that DirechShow players can detect and report correctly.
• Checked and updated every error code returned and every exception thrown by functions, for correct error detection and reporting by DirechShow players (checked WMP11 and MPC 6.4.9.1).
• Fixed a subtle bug (a multi-thread sync error really...) discovered in Microsoft DirectShow SDK's CSourceStream Base Class and relative documentation, which causates a deadlock when failing to create a filter's working thread.

v 0.0.1.1 (21.09.2009)

• Removed MSVCP90.DLL and MSVCR90.DLL dependencies - libraries are now statically linked.

v 0.0.1.0 (21.09.2009)

• First release.

Code has been updated (http://liviocavallo.altervista.org/)
dsfTAKSource 0.0.1.3 is now supporting UNICODE.

ChangeLog
----------------------------------------------------------------------------------------

v 0.0.1.3 (25.09.2009)

• Added UNICODE files support. Now dsfTAKSource supports takStreamIoInterface too, so file I/O is done by native Windows functions (supporting UNICODE), no more using tak_SSD_Create_FromFile (ASCII aonly).

Please let me know if it works for you.

It works great Thank you very much for adding unicode support.

I thought UTF8 was full unicode for the sake of what people call "unicode" and is multibyte. What Chars dont convert? Widechar is just less efficient storage, handy that the char size is a constant but it offers no extra support over multibyte(UTF8). Normally problems only arise when the codepage non widechar things were encoded in is unknown and it has to be guessed.

Maybe TAK just doesnt support multibyte correctly? You really dont need widechar to support unicode!(more obvious when you realize widechar is really a Microsoft thing only, most everything else uses UTF8)

First: Tks for commenting.

<short answer begin>
YES, maybe you are right: I think tak_deco_lib doesnt support multibyte correctly; and
almost NO, maybe you are wrong: I think tak_deco_lib doesnt support multibyte at all.
<short answer end>

I naturally agree with you about MBCS, UNICODE and UTF-8 relationships. I agree with this too: it's a problem guessing code pages from unicode, and moreover I doubt that even so it would work due to FS implications.
It seems easier using tak_SSD_Create_FromStream.

Just note:

CODE

char fileName [MAX_PATH];
const wchar_t wFilename[] = L"C:\\TestFile_\x0107.tak";  // N.B.: \x0171 is 'ć'
WideCharToMultiByte(CP_UTF8, 0, wFilename, -1, fileName, MAX_PATH, 0, 0);

fileName will be "C:\TestFile_ć.tak", shown as char string, not MB, where 'Ä' is 0xc4 and '‡' is 0x87.

Using above code you'll get the right MB string, but passing it to tak_SSD_Create_FromFile you'll get an invalid stream decoder.
As tak docs say and as tak behaves, it really seems TAK wants a simple char (not MB) string.
Naturally using CP_ACP (current system Windows ANSI code page) does not help; on my system (Italy) it converts 'ć' to 'c' and tak_SSD_Create_FromFile won't find the file.
You can play with WC_NO_BEST_FIT_CHARS flag (leading to this substitution 'ć' -> '?') but tak_SSD_Create_FromFile refuses to open.

Thanks HorsePower73, though I didn't convert all my works to TAK yet, but thanks for your work.

UNICODE (usually refer to UTF-8) is a standard for OSX, and widely use on Windows, I have a Mac and I'm using it together with Windows, I got many Chinese and Japanese song name (and ID3v2 tag), can't live without it. Also it's time to get rid of the multiple standard (GB, BIG5, SHIFT-JIS, UHC) and everyone switch to UNICODE.

And I think Thomas already know many people around the world HAVE to use UNICODE, when TAK can take care the UTF-8 native, it'll be more popular.