SFe 4.0

[sylvia-leaf]

After almost five years of development, we are releasing the first version of the SF-enhanced (SFe) specification, the one unofficial extension of the SF2 format to rule them all.

Life before SFe

For a long time, the SF2 (SoundFont*) format served as an way of creating sample libraries that were not only easy to use, but also intuitive to create. However, as the SF2 format was originally designed to be used with sound cards of the 1990s, it lacked many features that musicians wanted to make the libraries that they wanted to.

In response, many SF2 program developers made their own proprietary, incompatible extensions to the format. The most prominent example was compression - at one point there were five different versions of compressed SF2 banks in use! This was a problem until SF3, the de facto standard for open source SF2 players, took over. Some people have even extended the SF2 synthesis model itself, adding features from the less popular DLS (downloadable sounds) format.

However, an even bigger problem was that many players simply didn't implement the entire SF2 specification. For example, they may have omitted the modulators system introduced in SF2.01, or support for 24-bit samples introduced in SF2.04. The result was that sample libraries often worked only with the programs that were used to create them, as well as the programs that they were designed for.

Break past the two gigabyte barrier

With SF2, it was a gamble that the program would work with file sizes larger than 2GB. Some programs used signed integers for file sizes, others didn't. And the SF2 specification didn't mention anything. The SFe specification does. Unsigned integer file sizes are a requirement for SFe compatibility, so the vast majority of players support 4GB. You can stretch out while you make your banks as realistic or as flexible as you want.

Not only that, but we're going beyond 32-bit completely. With the ability to choose different RIFF chunk header types in future SFe 4 versions[2], you will be able to take advantage of 64-bit technology available on almost all of today's computers, with file sizes above 4GB.[1] Imagine turning your large split bank into one large file with everything that you could ever think of.

More banks mean greater compatibility

One of the biggest limitations of SF2 was its limitation to bank select MSB instructions. And with the increasing demand for XG* and GM2-compatible MIDI instrument banks, this just wasn't acceptable. SF2 also was limited to just one bank of percussion kits for general MIDI usage.

SFe is the first SF2 extension to include support for bank select LSB, for a total of 2 million different locations for melodic instruments and 2 million more for percussion kits. While you're never going to be able to use every space, what you do get is increased flexibility, so you can say goodbye to "XG* hacks" and hello to MIDI files that play flawlessly without needing to do anything more.

And with future versions of SFe[1], you will be able to make your banks respond to reset commands to prevent your pianos from becoming guitars that don't work properly, or your muted guitar from becoming a brass sound. The possibilities are almost endless with all the space you get.

Does this player support this feature?

Inside every SFe bank, the feature flags chunk lists every feature that the bank uses. You don't need to load the entire bank just to be disappointed - the program does the checking for you. And the program can warn you if the bank you created won't work properly, so you don't have to test on every player or warn people that you only tested it on one synthesiser.

Developers also benefit from this. You can implement all of the features, or just some of them, and tell users which features you support or don't. You can spend as much or as little time as you want to add the features that you care about.

In the future[2], bank developers can also provide different pathways for different programs that support different feature sets. So, if one SFe player doesn't include specific features that another one does have, you will be able to add a different set of parameters that make your bank continue to work properly, even if the program only supports old SFe versions.

Introducing the ISFe-list chunk

This chunk found inside all SFe banks contains not only the feature flags, but also detailed version information, and the type of bank that is used. This assists you in determining what version of the SFe specification that the bank works with. And future versions[2] add more and more features inside this chunk.

And to legacy players, the metadata interface remains almost identical to legacy SF2, so your banks still work with old players.[3]

SFe Compression

SFe also integrates the Werner SF3 compression format, the standard in SF2 compression technologies selected by leading open source SF2 editors and players. Any existing SF3 players won't have to add any more code to support SFe Compression.

More of a wider range of words

The world is getting smaller, and ASCII isn't getting larger. In fact, pure ASCII is slowly becoming obsolete in favour of Unicode.

With the completely backwards-compatible[3] UTF-8 format, you can use a wider range of characters in your bank's title, comments, sample names, instrument names, preset names etc. Internationalisation benefits are just the tip of the iceberg; you can use accented characters, different alphabets such as Greek or Cyrillic, the wide range of Kanji/CJK characters, and even emoji! (Please don't use emoji, but you could...)

Not only that, but we've removed the size limits for the metadata fields, so you can go on about everything that you want people to know about your banks. Developers of library management systems also benefit from the required use of ISO 8601 for bank creation dates and times.

Long support and constant updates

With SFe 4, we've committed to a long term support plan. After newer versions come out, we'll continue developing the SFe 4 specification with features that are easy to implement on your existing programs!

SFe will also get significant updates over time, further pushing the envelope of what is possible with open-source sample library development. We're always listening to your feature requests and always add these features to the best of our abilities. And even when SFe 4 is superseded by newer versions, we'll keep giving it features for those who want more time to migrate to later versions!

Logo and design of SFe documents

We've put so much care into making a logo that represents the spirit of the SFe format, and SFe 4 introduces a logo based on the motif of an eighth note.

Firstly, the eighth note expands out, symbolising the growth in features that SFe achieves, and will continue to achieve for the foreseeable future. The rotated version number included in the SFe icon makes the design more friendly. A monochrome version of the SFe 4 icon is also available and stands out. All icons are available in PNG and SVG format, so you can scale it as far as necessary.

The design of the SFe technical specification document is heavily inspired by the Frutiger Aero aesthetic, with a large, embossed logo illustrated in glass. The use of Frutiger Aero represents the vision of the future from the time that SF2.04 was published, because SFe 4 brings us one step closer to the utopia that we all hoped for.

The turquoise colour of the SFe 4 logo and documents also stands out from the red, yellow and blue used by the SoundFont* logo, with future versions of SFe likely to use different colours for their design.

---

[1] Requires a 64-bit chunk header that is not compatible with legacy SF2. [2] Future versions of SFe may not be compatible with SFe 4. [3] SFe 4 only.

SFe compatible software coming later, read the specification for information to develop/update your software.

The SFe Team is in no way sponsored by or otherwise affiliated with Creative Technology Ltd. or E-mu Systems, Inc.

*All trademarks are properties of their respective owners. XG is a registered trademark of Yamaha Corp. SoundFont is a registered trademark of Creative Technology Ltd.

---

What's Changed

• SFe 4.0 final version by @sylvia-leaf in SFe 4.0 final version #108
• Actual final SFe 4 release! by @sylvia-leaf in Actual final SFe 4 release! #110
• More branching shenanigans by @sylvia-leaf in More branching shenanigans #112

Full Changelog: 4.0-rc3...4.0

---

This discussion was created from the release SFe 4.0.

[stgiga]

@sylvia-leaf

Postmortem of spec:

Your logos are missing from the Discussion but the release is fine.

Also, it is VERY nice to see years of work finally paying off.

One thing to note is that I had said that the SF spec does not define RIFF as being 32-bit. Of all the players that would handle RIFF64 properly, currently it is BassMIDI and its derivatives, because its codependency BASS handles 64-bit RIFF whenever you get WAV involved.

The e-mail on my commits is my e-mail, and having something beyond Discord to reach me isn't a bad idea. Also the first letter of my handle isn't capital (as in maia arson crimew) unless it's the expanded form St. GIGA.

Filter Parameters might benefit from "cutoff" in the reserved sections. (Or is it already there?)

This link is dead:
https://github.com/mrbumpy409/SoundFont-Spec-Test

If you can, please mirror it.

[stgiga]

OK, so the PDF messed up the link

https://github.com/mrbumpy409/SoundFont-Spec-Test

[sylvia-leaf]

We've fixed these issues with the 4.0a update. Please read the new specification.

[stgiga]

Oh interestingly enough, I had a very interesting thought: what if InterleaveIndex, when not referring to bank fragments, can facilitate 256 banks, yet isn't the limit because of true multiple files as well as one SFe loading another?

@sylvia-leaf

Let's investigate this idea.

[stgiga]

Also I hope my links to 4.00 don't rot that I sent to everyone. Like, if it becomes obsolete, please put a "Look here for everything new"