View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001673||OpenMPT||Feature Request||public||2023-03-04 22:48||2023-03-04 23:20|
|Product Version||OpenMPT 1.30.10.00 / libopenmpt 0.6.8 (upgrade first)|
|Summary||0001673: [SF2] Add Bank Select LSB Support via other byte of wBank, as well as other features later|
So according to the SoundFont standard, the value (known as wBank) normally used to store Controller Change 0 (Bank Select MSB) is actually a 16-bit value. If we use the OTHER byte to store the Controller Change 32 (Bank Select LSB) value, we can support Bank Se]ect LSB in SF2, thus proper Yamaha XG SoundFonts, and proper DLS-to-SF2 conversions can be made. The spec says to preserve (but not play) these values should the other byte than MSB be used. Also, the second percussion toggle is a bit that OpenMPT 1.30 will respond to as a percussion toggle. I have a test-of-LSB SF2 here: https://drive.google.com/file/d/1cerpko6kL4SctyHG9ozYFtwePmbHX7CW/view as well as an attached diagram of the bits for wBank with LSB support.
Also, I have some further feature requests in a similar vein that also consist of relying on what the SoundFont specification does not explicitly say to reject. One of these was brought up by Saga Musix on Un4seen:
Basically, the SoundFont specification for all of its defining the sample data chunks to be in the middle of the SoundFont file does not say to actually reject SoundFonts in which that chunk is at the end. According to Saga Musix on the Un4seen Forums, having that chunk at the end and ignoring the size value would allow for 8 gigabyte SoundFonts.
Furthermore, the SoundFont specification says to not play SoundFonts which have the sm24 chunk (used to store the upper 8 bits of a 24-bit sample) but not the regular 16-bit sample chunk underneath. However, it does NOT tell us to reject these. So 8 bits-per-sample samples in SF2 are possible. Meaning that MOD samples-to-SF2-conversions could be outright 1:1.
In terms of priority, I would say that the 16-bit wBank part would be the best to support first.
These three features are part of a project me and a collaborator have to improve the SF2 format via taking the standard completely literally. We also rely on the spec not explicitly defining the RIFF used as 32-bit RIFF, so we have devised a RIFF64 extension, but given the differences between RIFF and RIFF64, there are some significant reworks needed, giving us room to add in features not possible on 32-bit RIFF. This 64-bit RIFF SF2 format is in its infancy and is not part of this present request.
The wBank LSB use is the feature we feel is the one that is of current most importance. The test SF2 was made by my collaborator via hex editing the wBank values in some XG-mapped patches to put them on their LSBs (Yamaha XG uses Bank Select LSB for its patch variations outside General MIDI rather than Bank Select MSB as is done in Roland GS) as is proper, while following the attached bit diagram of wBank.
This whole proposal has been in the works for months.
I know that it might seem a bit wild to do this, but having Bank Select LSB also opens the doors to more SoundFonts of other synthesizers, because a no-LSB beyond-GM synth outside Roland SoundCanvas lines in native mode is extremely rare. Furthermore, I have pitched the proposal to other people in the SoundFont player and editor community, such as FluidSynth on Github, and also on Un4seen. Since OpenMPT supports Bank Select LSB in DLS soundbanks, we felt that the LSB-in-wBank feature would actually be quickest to implement into OpenMPT. Also, since Saga Musix is the one who best knows how the 8 gigabyte size for SF2 is possible due to the post on Un4seen that gave us the idea to include it into our planned ways to improve SF2, we felt even more compelled to include OpenMPT in the parties we are helping enhance SF2 with who we have given the plans to, with the infographic and test SF2 included.
The gist of this proposal is that wBank LSB use is what we find to be of current most importance, but we have additional plans for later. Best wishes to everyone involved!
|Steps To Reproduce|
This is a feature request that we hope will help benefit the SoundFont community as a whole, in addition to OpenMPT. I am a huge fan of OpenMPT. It is such an amazing program. Many thanks to those making it!
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Yes|
|Tested code revision (in case you know it)|
There is absolutely no point in doing any of this as long as popular authoring software (first and foremost Viena, probably) doesn't support it. I will not add support for non-standard SF2 features to OpenMPT before developers of authoring tools have agreed on them. I don't want OpenMPT to be used as an example à la "but look, other software already supports these hacks" as an argument to be presented to those developers. We've got enough bad rap in the past for doing stuff like that to module formats (and rightfully so).
PS: That post on the un4seen forum on how SF2 files could hypothetically address 8GB of samples is exactly that: hypothetical. Please don't pitch this idea to other developers giving them the impression that I think it's good idea. I absolutely think the opposite is true. Doing that would imply that any SF2 reader cannot be based on a standard IFF parser anymore, because it has to support non-standard IFF extensions.
I do apologize for this whole thing.
|2023-03-04 22:48||stgiga||New Issue|
|2023-03-04 22:48||stgiga||File Added: lsb_on_soundfont_3.png|
|2023-03-04 23:11||Saga Musix||Note Added: 0005578|
|2023-03-04 23:13||Saga Musix||Note Added: 0005579|
|2023-03-04 23:18||Saga Musix||Note Edited: 0005579|
|2023-03-04 23:20||stgiga||Note Added: 0005580|