IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
libopusfile and Unicode names., Unicode
thinktink
post Jul 16 2013, 16:39
Post #1





Group: Members
Posts: 12
Joined: 14-November 12
Member No.: 104501



I'm in a bit of a bind at the moment. I've developed a Winamp input plugin to play .opus files but I had to do it by converting long file names to the 8dot3 short names so that I could pass them on to the libopusfile library functions that do not support unicode file names. Little did I know however that people can actually disable 8dot3 file name support.

Apparently, once 8dot3 file name support is disabled on a volume it is impossible for unicode incompatible functions to reference a unicode named file with international characters in the file name.

Or is there an alternative, or if not, who do I contact to get the libopusfile libraries updated to support unicode files?

tia.
Go to the top of the page
+Quote Post
bryant
post Jul 16 2013, 17:57
Post #2


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



I have not looked at the API for libopusfile, but does it provide the ability to access files with I/O callbacks rather than using filenames? Libwavpack provides these as an option, and I used them for my winamp plugin.
Go to the top of the page
+Quote Post
embryonic
post Jul 16 2013, 18:27
Post #3





Group: Members
Posts: 1
Joined: 16-July 13
Member No.: 109138



Looking at the docs for libopusfile, it does seem to.

4.5.2.6 OP_WARN_UNUSED_RESULT OggOpusFile ∗ op_open_callbacks (void ∗_source, const OpusFileCallbacks ∗_cb, const unsigned char ∗_initial_data, size_t _initial_bytes, int ∗_error)
Open a stream using the given set of callbacks to access it.
Go to the top of the page
+Quote Post
thinktink
post Jul 16 2013, 19:40
Post #4





Group: Members
Posts: 12
Joined: 14-November 12
Member No.: 104501



I thought I set a subscription for instant e-mail notification?! mad.gif

Anyways, thanks, I'll look at the callback functions later on. Although I think the original reason why I didn't use them was because they didn't support multichannel re-multiplexing. I'll look again.
Go to the top of the page
+Quote Post
derf_
post Jul 31 2013, 12:36
Post #5





Group: Developer
Posts: 9
Joined: 5-December 12
Member No.: 104986



QUOTE (thinktink @ Jul 16 2013, 19:40) *
Anyways, thanks, I'll look at the callback functions later on. Although I think the original reason why I didn't use them was because they didn't support multichannel re-multiplexing. I'll look again.


Normal place for opusfile discussion is the mailing list: <http://lists.xiph.org/mailman/listinfo/opus>.

All of the other I/O backends are implemented via the callbacks API, so it supports all the same things.

What needs to be done to add unicode support for Windows?
Go to the top of the page
+Quote Post
Peter Harris
post Jul 31 2013, 16:31
Post #6





Group: Members
Posts: 93
Joined: 17-October 01
Member No.: 310



QUOTE (derf_ @ Jul 31 2013, 07:36) *
What needs to be done to add unicode support for Windows?


It's a pain.

Windows prefers to operate in UTF16, so a parallel API that takes wchar_t (and calls _wfopen instead of fopen) would be the Windows thing to do, although it messes up the API.

The other alternative is to keep everything in UTF8 and do all the conversions at the last second.

See https://trac.xiph.org/ticket/268 for the vorbisenc patch set.

I suspect "provide an I/O callback interface and let the caller deal with it" is about the best a cross-platform C library can do.
Go to the top of the page
+Quote Post
derf_
post Jul 31 2013, 17:40
Post #7





Group: Developer
Posts: 9
Joined: 5-December 12
Member No.: 104986



QUOTE (Peter Harris @ Jul 31 2013, 16:31) *
The other alternative is to keep everything in UTF8 and do all the conversions at the last second.

See https://trac.xiph.org/ticket/268 for the vorbisenc patch set.


Thanks for the pointer. Keeping things in UTF-8 would be my preference, as that is, you know, what a sane API would do. Not sure when I'll get to this, but you're right, callbacks would certainly work in the mean time.
Go to the top of the page
+Quote Post
derf_
post Aug 6 2013, 22:30
Post #8





Group: Developer
Posts: 9
Joined: 5-December 12
Member No.: 104986



Support committed in http://git.xiph.org/?p=opusfile.git;a=comm...;h=f65dab6f653a.
Go to the top of the page
+Quote Post
thinktink
post Aug 7 2013, 03:55
Post #9





Group: Members
Posts: 12
Joined: 14-November 12
Member No.: 104501



QUOTE (derf_ @ Aug 6 2013, 14:30) *


Looks nice.

Two things however (1 question and 1 statement.)

Question:
I dropped that utf16_to_utf8 function into a dummy project and compared it to ::WideCharToMultiByte(CP_UTF8,...); and so far all of the Unicode strings I have compared between the two have exactly matched. Would it be safe to assume that if this gets implemented in the next compiled and official release of the libopusfile library that all I will need to do is to convert the filename by a call to ::WideCharToMultiByte(CP_UTF8,...)? I'm not uber familiar with unicode strings, utf8, utf16, or whatnot and just want to confirm.

Statement:
Me personally, as an active Windows developer, I would prefer a separate op_open_fileW (while retaining the above changed functionality on the original op_open_file function) since right now all my internal string references to filenames are all unicode anyway and maybe possibly save time and resources having to convert filenames all the time. At the moment, I have internally implemented an op_open_fileW function which uses op_open_callbacks although I'd prefer native support so that I get consistency. So far it's working though.
Go to the top of the page
+Quote Post
derf_
post Aug 10 2013, 01:27
Post #10





Group: Developer
Posts: 9
Joined: 5-December 12
Member No.: 104986



QUOTE (thinktink @ Aug 7 2013, 03:55) *
Would it be safe to assume that if this gets implemented in the next compiled and official release of the libopusfile library that all I will need to do is to convert the filename by a call to ::WideCharToMultiByte(CP_UTF8,...)?


Yes, that should work fine.

QUOTE (thinktink @ Aug 7 2013, 03:55) *
Me personally, as an active Windows developer, I would prefer a separate op_open_fileW (while retaining the above changed functionality on the original op_open_file function)


The problem is that then I have to provide this UTF-16<->local character set conversion for all other platforms. There are a number of reasons why this is a pain to do, and it provides no benefit, since unlike Windows, other platforms can generally access all of the files on the disk using char strings, without resorting to wchar_t.
Go to the top of the page
+Quote Post

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: 19th April 2014 - 15:49