New unit test to check libsndfile output file name

[pedrolcl]

One of the claims in #1411 was that when rendering audio to a .wav file in Windows, libsndfile does not support utf-8 file names.

Here is a new unit test that renders a MIDI file to .wav to check if the claim is true. The relevant check is disabled in Windows, because it turns out to be true. Some workaround or upstream fix would be needed.

Also, a new test MIDI file ("original" composition) named "ⓉⒺⓈⓉ.mid" has been added, replacing the old "èmpty.mid" in the unit tests.

[derselbst]

Thanks for looking into this Pedro! Would it make sense to adopt the proposed workaround for fluid_filerenderer.c by #1411 rather than commenting out the unit test?

[pedrolcl]

Thanks for looking into this Pedro! Would it make sense to adopt the proposed workaround for fluid_filerenderer.c by #1411 rather than commenting out the unit test?

Some workaround in fluid_filerenderer.c like that would be needed, yes, but it is not enough. The fluidsynth CLI program's argument of the -F option is not converted to UTF-8 in Windows, so another conversion/workaround would be needed there. Frankly, I'm not happy converting arguments to UTF-8 and then converting the equivalent setting to UTF16-BE.

I'm converting this PR to draft, until a decision is made.

[derselbst]

The fluidsynth CLI program's argument of the -F option is not converted to UTF-8 in Windows, so another conversion/workaround would be needed there.

Good point. So how about flushing the -F optarg trough win32_ansi_to_utf8()?

[pedrolcl]

So how about flushing the -F optarg trough win32_ansi_to_utf8()?

I would instead create a win32_ansi_to_wchar() conditioned to _WIN32 and LIBSNDFILE_SUPPORT. But this is also ugly.

[derselbst]

I would instead create a win32_ansi_to_wchar() conditioned to _WIN32 and LIBSNDFILE_SUPPORT. But this is also ugly.

Wouldn't this make the encoding used for audio.file.name dependent on the platform and on whether compiled with LIBSNDFILE_SUPPORT? I'd prefer to have the settings UTF8 only. So I'd prefer:

optarg > win32_ansi_to_utf8() > audio.file.name > filerenderer > conditional UTF8 to wide char conversion.

[pedrolcl]

optarg > win32_ansi_to_utf8() > audio.file.name > filerenderer > conditional UTF8 to wide char conversion.

OK. Let's try this way

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[pedrolcl]

optarg > win32_ansi_to_utf8() > audio.file.name

OK. Let's try this way

Unfortunately, win32_ansi_to_utf8() doesn't work. It outputs garbage.

$ src/fluidsynth.exe -F ⓉⒺⓈⓉ.wav ~/fluidsynth-git/sf2/VintageDreamsWaves-v2.sf2 ~/test.mid
fluidsynth: debug: adding audio.dsound.device=Controlador primario de sonido
fluidsynth: debug: adding audio.dsound.device=GroßeStraßenlautsprecher (HDMI) (2- High Definition Au
dio Device)
fluidsynth: debug: Testing audio device: GroßeStraßenlautsprecher (HDMI)
FluidSynth runtime version 2.4.0
Copyright (C) 2000-2024 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of Creative Technology Ltd.

fluidsynth: warning: Sample 'SineWave': ROM sample ignored
Rendering audio to file '????.wav'..
fluidsynth: error: Failed to open audio file '????.wav' for writing

[derselbst]

Unfortunately, win32_ansi_to_utf8() doesn't work. It outputs garbage.

Hm, just a wild guess: Is it correct for win32_ansi_to_utf8 to always assume CP_ACP rather than asking GetACP()?

[pedrolcl]

Unfortunately, win32_ansi_to_utf8() doesn't work. It outputs garbage.

Hm, just a wild guess: Is it correct for win32_ansi_to_utf8 to always assume CP_ACP rather than asking GetACP()?

Doesn't change anything

[pedrolcl]

Well, the unit test does its job. I suggest that another PR should take care of #1388 and related issues.

[derselbst]

Agreed & LGTM, thanks!