Stereo sf2 importing as mono?

[Pencildragon]

Hello! I've recently been learning how to use OpenMPT and I found out it can import sf2 files. This is great because it speeds up my workflow significantly, I already have sf2's and many sfz's I could easily convert to sf2's so I don't have to spend time manually looping/sustaining/tuning/mapping samples(although the wiki says I should be able to import sfz's too? doesn't seem to be an option in the import dialogue for instruments, samples, or the tree- I get an error when I try). But it seems that the sf2 instruments I tried importing are only showing up as mono, when they are supposed to be stereo. 

Now obviously, the ultimate solution to this problem would simply be to load up sforzando as a VSTi and use that to play my sf2's and sfz's, however I'm looking into starting a project where I actually need to export my finished compositions as .it files, so VST's are a no-go. Is there a checkbox or something I missed somewhere? I searched through the settings and import dialogues, but I don't see anything about sf2 files. 

If it matters I am using OpenMPT 1.26.07 64bit on Windows 10.

[LPChip]

SF2 support is not that good in OpenMPT and it can indeed be the case that 2 mono samples are stored in the SF2, one for the left and one for the right channel. OpenMPT does not support overlapping samples.

That said, I know Awave Studio can edit SF2 and Sfz files and export the layers to .iti files which of course are natively supported by OpenMPT and will load correctly.

Awave Studio is not free though, but you can convert in the shareware version too. Its just limited to a 30-or so day trial.

[Saga Musix]

Please disregard LPChip's information, it's outdated.
SF2 does not support stereo samples (they are always stored as two mono samples), but recent OpenMPT versions are able to detect this and merge them into one stereo sample. If you have a soundfont where this does not happen, please provide it as an example (if you can edit the soundfont, please remove any unnecessary stuff to keep it small).

(although the wiki says I should be able to import sfz's too? doesn't seem to be an option in the import dialogue for instruments, samples, or the tree- I get an error when I try

This information has already been placed in the wiki for the upcoming OpenMPT version (1.27), OpenMPT 1.26 cannot import sfz files yet. You will notice that in  OpenMPT 1.26's help document, SFZ is not mentioned yet. If you are interested, you can grab a recent test build of OpenMPT 1.27 and try out SFZ import.

[Pencildragon]

Please disregard LPChip's information, it's outdated.
SF2 does not support stereo samples (they are always stored as two mono samples), but recent OpenMPT versions are able to detect this and merge them into one stereo sample. If you have a soundfont where this does not happen, please provide it as an example (if you can edit the soundfont, please remove any unnecessary stuff to keep it small).

(although the wiki says I should be able to import sfz's too? doesn't seem to be an option in the import dialogue for instruments, samples, or the tree- I get an error when I try

This information has already been placed in the wiki for the upcoming OpenMPT version (1.27), OpenMPT 1.26 cannot import sfz files yet. You will notice that in  OpenMPT 1.26's help document, SFZ is not mentioned yet. If you are interested, you can grab a recent test build of OpenMPT 1.27 and try out SFZ import.

So I did some testing, and I found that several soundfonts in sf2 format behaved oddly and sometimes differently no matter what I loaded them in. For instance, NTONYX's "32Mb GM Stereo Set" behaves exactly as expected when loaded into a midi player. However, when imported into OpenMPT it seems every instrument is converted to mono. Out of curiosity, I loaded up the sf2 in Plogue's sforzando and it converted it to mono as well, which is odd. I also tried something much simpler, an (warning: direct download link) acoustic grand piano based off the University of Iowa samples. In Plogue's sforzando it behaves exactly as intended, with stereo samples. But in OpenMPT it again converted it to mono, except for the last sample which for some reason is a stereo mismatch of two different pitches. I don't know how useful this information is, I'm beginning to think the sf2 format is just very poorly standardized. 

And I will try that test build! I suspect sfz will not encounter these issues as it seems to be a much more flexible format(and supports stereo samples natively).

[Saga Musix]

Thanks for the examples, I will look into them.

I'm beginning to think the sf2 format is just very poorly standardized.

The fun part is that it is in fact much better standardized than, say, sfz (which is not standardized at all, it's just several manufacturers loosely agreeing on some stuff), but the standard is overcomplicated so it is difficult to achieve a fully correct (and complete) sf2 implementation. Stereo samples are just one out of many examples. I guess they are implemented the way they are to be backward-compatible with soundcards that could only play mono samples, which was not an issue for e.g. the DLS format, which supports stereo samples out of the box.

And I will try that test build! I suspect sfz will not encounter these issues as it seems to be a much more flexible format(and supports stereo samples natively).

SFZ import should be hassle-free (especially compared to SF2) as long as you don't expect it to do wonders.
For what it's worth, the list of currently supported sfz opcodes can be found in the wiki. Some of them are just implemented "approximately", as exact implementations of all opcodes are not possible with OpenMPT's sampler.

Features that may or may not be implemented later: #include, effect plugins (not standardized so we'd have to come up with our own syntax for identifying effects, or cooperate with Plogue)

Edit: Moved SFZ opcode list to the wiki.

[Saga Musix]

I found some very silly typo that explains why some SF2 stereo samples turned up in completely wrong pairs, like that piano. A new test build, r7521, should be available on buildbot within the next few hours, so the piano soundfont will load correctly.

The problem with "32Mb GM Stereo Set" is that most instruments are not truly stereo - a fake stereo sound is achieved by duplicating layers and detuning the two copies slightly against each other, which creates a stereo chorus sound. OpenMPT cannot handle this because it's technically the same sample being loaded twice, but with two different tuning parameters. sforzando might have similar problems, e.g. not applying the detuning and hence playing the same sample twice with identical parameters (resulting in mono sound).
Edit: Another fix has been committed in r7522 which eliminates a few more stereo mismatches in "32Mb GM Stereo Set" (e.g. applause instrument).

[Pencildragon]

How interesting that something like sondfonts meant for midi could present such problems...

SFZ import should be hassle-free (especially compared to SF2) as long as you don't expect it to do wonders.

I downloaded build 1.27.00.29-r7526 today and SFZ import was silky smooth for the most part! Many worked without issue. There were some SFZ's that didn't seem to work however, I get a message reading "Unsupported file type." followed up by another reading "Unable to open file." I have suspicion about what could be causing it though, some of these sample may be in FLAC form, which I am unsure if OpenMPT can import. Others I think use multiple samples layered and timed differently(one for instance tries to make a realistic sounding bass by combining bass samples and fret noise samples, another is a cello made much the same way). It's not really an issue to copy the code out of the SFZ's and remove the parts which layer the samples however, one of the many perks of SFZ over SF2. 

I found some very silly typo that explains why some SF2 stereo samples turned up in completely wrong pairs, like that piano. A new test build, r7521, should be available on buildbot within the next few hours, so the piano soundfont will load correctly. 

I can confirm that soundfont does work perfectly now! 

The problem with "32Mb GM Stereo Set" is that most instruments are not truly stereo - a fake stereo sound is achieved by duplicating layers and detuning the two copies slightly against each other, which creates a stereo chorus sound.

I was starting to think something like that might the case. Silly soundfont creators. 

Thank you so much for looking into the issue! I hope this helps somebody other than me and doesn't just end up as a waste of your time. Looking forward to a 1.27 stable release in the future

[Saga Musix]

How interesting that something like sondfonts meant for midi could present such problems...

Well, a soundfont player can be just as simple or complicated as any other synthesizer that can be controlled via MIDI (such as any VST plugin)...

I downloaded build 1.27.00.29-r7526 today and SFZ import was silky smooth for the most part! Many worked without issue. There were some SFZ's that didn't seem to work however, I get a message reading "Unsupported file type." followed up by another reading "Unable to open file." I have suspicion about what could be causing it though, some of these sample may be in FLAC form, which I am unsure if OpenMPT can import. Others I think use multiple samples layered and timed differently(one for instance tries to make a realistic sounding bass by combining bass samples and fret noise samples, another is a cello made much the same way). It's not really an issue to copy the code out of the SFZ's and remove the parts which layer the samples however, one of the many perks of SFZ over SF2.

OpenMPT supports FLAC samples perfectly, and multi-layering is also not an issue in the sense that the file will still load (you will even notice that samples from all layers will load, but only one layer will be assigned to the instrument). If you get an error, then this means that OpenMPT was unable to parse the structure of the SFZ files (so it didn't even try to load the sample data), so please provide that SFZ file (the associated samples are not required) so that I can see what makes the parser trip. OpenMPT's SFZ parser is rather strict about the syntax of SFZ files since they have no "magic bytes" by which such a file could be identified, so maybe it doesn't like some specific line of the file that is ignored by other players.

[Pencildragon]

If you get an error, then this means that OpenMPT was unable to parse the structure of the SFZ files (so it didn't even try to load the sample data), so please provide that SFZ file (the associated samples are not required) so that I can see what makes the parser trip. OpenMPT's SFZ parser is rather strict about the syntax of SFZ files since they have no "magic bytes" by which such a file could be identified, so maybe it doesn't like some specific line of the file that is ignored by other players.

Sorry it took me this long to reply, real life got in the way. I've attached a few to this post, hopefully it is helpful. Do note that the cello was made to work with a .bank file for sforzando, but I have had success before in loading it as an individual sfz file without the .bank file. 

I did take a look at them in notepad just now, because for some reason I hadn't yet, and I think I'm beginning to see where the problem might lie... They seem to contain commands pointing to other files included with the samples. I have no idea what these other files do, but from the looks of the sfz's they act as some kind of middleman between the sfz file and the samples themselves. Perhaps they're something made specifically to work with sforzando? 

[Saga Musix]

The #include commands are indeed the problem here. As I noted above, this feature is currently not implemented, but implementing it would also only help you if you could locate the included files. I guess in this case the important files are the ones named "S1" and so on.