[Win32] Scanning of files managed by libsndfile crash if ASCII char > 127 in the filename

[Michael Pujos]

On Windows, if your library has a file managed by libsndfile (WAV and FLAC even if FLAC are not supported under windows) and the full filename (including the path) has a character > ASCII code 127, it will crash in sf_open().

this happen in both SoundSourceSndFile::ParseHeader() and SoundSourceSndFile::SoundSourceSndFile().

sf_open() is passed an UTF-8 string which is invalid on Win32, as the filename is further passed to the win32 API CreateFile() which doesn't handle UTF-8 at all, just regular Extended ASCII.

So the fix is just to pass the non-UTF8 string to sf_open().
However that only work for filenames containing extended ascii chars - I don't know what happen with other language such as Japanese.

A better fix might be to recompile libsndfile with wide character support which means UTF-16 under windows. That way, CreateFileW is invoked instead of CreateFile.

I'm also trying to compile FLAC support into libsndfile.

[Albert Santoni (gamegod)]

Michael, is that new libsndfile DLL you contributed compiled with UTF-16 support?

Thanks,
Albert

[Michael Pujos (pujos-michael)]

libsndfile I provided is not compiled with UTF-16 support. I did it initially but had trouble converting an UTF-8 QString to UTF-16, so I kind of abandonned the idea. If you know how to do the convrsion I can try it agin and recompile libsndfile with UTF-16.
Otherwise the fix described in the initial message still applies

btw bug 267175 is a duplicate of this one.

[Albert Santoni (gamegod)]

Hmmm, yeah I think we're going to need to recompile libsndfile with UTF-16 support, although I'm also not sure how we're supposed to use UTF-16 strings.

I thought we were supposed to use QString::toWCharArray(...), which dumps a UTF-16 version of the string into a wchar_t array that we allocate beforehand. However, that wchar_t array won't be null-terminated, so I don't think we can pass it to libsndfile.

It looks like QString::utf16() does what we want though (null terminated utf16 string). So are there any objections if we change the two sf_open() calls in soundsourcesndfile.cpp to look like:

#ifdef __WIN32__
sf_open( ... using utf16 string)
#else
sf_open ( ... using utf8 string)

Is there some #define that we can use to check if libsndfile was compiled with utf-16 support? The pseudocode above will break unless it was compiled with it on, and at the very least, we'd need to try to document that well.

Thanks,
Albert

[Albert Santoni (gamegod)]

Err, I forgot to mention that, as radiomark pointed out on IRC, if we use the temporary workaround of passing an ascii string instead, it simply won't load/parse those songs. While it (hopefully) won't crash, it still won't load those files...

[Michael Pujos (pujos-michael)]

Attached is a libsnd.dll compiled with UTF-16 support.

On Win32 just use the code below to open files in SoundSourceSndFile::ParseHeader() and SoundSourceSndFile::SoundSourceSndFile():

SNDFILE *fh = sf_open( (const char *)location.utf16(), SFM_READ, &info );

I tested it and filenames with chars > 127 now load just fine.

[Sean M. Pappalardo (pegasus-renegadetech)]

Hello. We (finally) just tested the new dll and it apparently doesn't have FLAC support. Could you please possibly rebuild it with such support? Thanks so much for your time!

[Sean M. Pappalardo (pegasus-renegadetech)]

I guess I'm on crack. I just tested in Windows XP using 1.6.2 branch r2304. FLAC files and files with non-English characters display, load and play fine. (Though the characters don't render properly, but they look the same as in Firefox, so it must be my system.) Marking Fixed. Thanks!

[ironstorm (ironstorm-gmail)]

Mixxx 1.7.0 was released on Aug 6, 2009, so this fix would have gone out at that time.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5024