TAK DirectShow Filter, a filter to enable any DirectShow Player (i.e. WMP) to play .tak files Options

[HorsePower73]

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

[zombiewerewolf]

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

[HorsePower73]

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.

[twistedddx]

The problem here is that tac_deco_lib does not accept UNICODE filenames.

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);

[HorsePower73]

[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/

[twistedddx]

Some unicode characters does not have any MB equivalent (this is a reason unicode exists!), so conversion is sometimes impossible.

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)

This post has been edited by twistedddx: Sep 27 2009, 14:58

[HorsePower73]

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.

This post has been edited by HorsePower73: Sep 27 2009, 23:33