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, this is the list of currently
supported sfz opcodes, which is subject to change. Some of them are just implemented "approximately", as exact implementations of all opcodes are not possible with OpenMPT's sampler.<control>
<global>, <master>, <group>, <region>
- bend_up / bendup
- loop_start / loopstart
- loop_end / loopend
- loop_mode / loopmode
- one_shot (treated like loop_continuous)
- loop_type / looptype
- fil_type / filtype
- lpf_1p / lpf_2p / lpf_4p / lpf_6p: All treated as internal low-pass filter
- hpf_1p / hpf_2p / hpf_4p / hpf_6p: All treated as internal high-pass filter
- Envelopes: ampeg_*, fileg_*, pitcheg_*:
- #define can be used for macros
- Sample files can be of any type supported by OpenMPT's sample editor (WAV, FLAC, Ogg, Opus, MediaFoundation codecs, etc.)
- Loops in sample files
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)