4.0.11
Pre-release
SFe 4.0.11 (Draft Specification) - December 2024
The specification is stable now
This is the eleventh draft milestone of the SFe 4 specification, for December 2024.
After making some style improvements, and defining some new concepts, we are confident that this will be the final draft version of SFe 4 before the final version.
This release candidate quality specification will only differ from the final specification by the presentation. The sections may be changed, the program and compatibility specifications will be included directly into the specification, and the specification won't be in Markdown (.MD) but rather in .PDF. (A machine-readable version in Markdown will also be made available.)
No new illustrations were required for 4.0, but they may be for future versions, especially because 4.1 is planned to be the modulator update, and the majority of the illustrations in SFSPEC21.PDF and SFSPEC24.PDF refer to the modulator system.
Splitting parts of the introduction
In preparation for the final specification, we've split the copyright/trademark and draft disclaimer. The final version of the specification won't include the equivalent of section 0.2b.
While the number of members in the SFe team is the same as it was in 4.0.10, we've split the special thanks part from the SFe Team part in case more people are added to each of these sections. We've also corrected a name in the special thanks section.
More definitions
We've added a lot of definitions which cover many of the new features that will be introduced in SFe. These include:
- "branch", "leaf" and "tree structure"
- used in the feature flags system
- section 5.12.3 was clarified using these definitions
- "dynamic RIFF", "RIFD", "RIFF-type format" and "static RIFF"
- for file chunk headers
- section 3.1 and 3.1a were rewritten using these definitions
- "Cognitone SF4", "FLAC", "OGG", "Opus", "proprietary compression", "SFe Compression", "Vorbis" and "Werner SF3"
- for file compression
- "SFe", "SFe 4" and "SFe-compatible"
- for SFe versioning
- "legacy sound card" and "SB"
- for compatibility
A few changes were also made.
8-bit sample changes
From suggestions I saw on GitHub relating to the 8-bit sample playback mode, we've made changes to the format to ensure that SFe players don't attempt to play a corrupted legacy SF2.04 bank with a missing smpl sub-chunk but with a present sm24 sub-chunk from attempting to load the bank as an bank that uses 8-bit samples.
This is implemented by using a new SFty sub-chunk value. If this value matches SFe-static (8-bit) or SFe-static (8-bit) with TSC, then it will ignore the smpl sub-chunk and just play the sm24 sub-chunk instead. However, if the value doesn't match, the player should think that it is just a corrupted bank that was intended to have an smpl sub-chunk but doesn't.
Section 6.2c was also added, which also defines sm24 and sm32 sub-chunks without a matching smpl sub-chunk as "orphaned", and describes how orphaned sm24 and sm32 sub-chunks shall be handled.
Introducing SFe Compression
After communication with FluidSynth, we decided to standardise on the August 2021 draft specification of Werner SF3, and we've included the contents of the specification into SFe. This standardised version of Werner SF3 is called SFe Compression 1.0, and SFe compliant programs will be required to implement it.
Because programs that implement Werner SF3 may add their own features to the format (MuseScore's sftools programs are seen as the reference implementation), we aim to include as many of these extensions to SF3 inside SFe Compression. If you are developing a program that uses SFe with extensions to SFe Compression, we would rather you share a specification to your changes so everyone can benefit.
SFe Compression requires OGG support, because OGG is the most common compression format used by Werner SF3 players, but more compression formats (most notably FLAC) will need to be supported in later versions of SFe Compression.
Versioning changes for the final time
When E-mu released the legacy SF standard to the public for the first time with version 2.00, the first public version was referred to as 2.00a. Shortly after, an update called 2.00b was released. However, E-mu never used a letter after the version number after that.
Because this was how E-mu versioned their standard, we attempted to adopt this naming ourselves. However, this resulted in the downside that first versions of a draft specification would retroactively have an "a" added to their version number, causing all sorts of confusion. Versions that never got a revision before being replaced by another version would never get the letter "a".
This was way too confusing, so we simplified the versioning system to start without any letters, and then when a version gets a revision, letters are included, starting with "a" instead of "b".
Making the specification consistent
The specification often used different names for the legacy SoundFont 2.04 specification, but this was confusing. So, we decided to standardise on the term "legacy SF2.04" when used to describe it, with "SF2.04" being replaced by "SF2.01" or "SF2.0x" as needed. Similar modifications were made to references to different SFe versions. We've standardised on "SFe [VersionNumber]" - for example, "SFe 4" or "SFe 4.0".
Additionally, we've decided to make all chunk names, variables and similar things use in-line code.
Version 4.0.11a also makes sure that all mentions of the word "sub-chunk" are hyphenated.
Introducing SiliconSFe
In SFSPEC24.PDF there is a section about what E-mu termed "Silicon SoundFonts". These were basically ROM chips that contained samples that would be used by legacy SF2.04; there is a header with information about the ROM, and the header includes the start address of the SoundFont bank.
Because the SFe feature set is a strict subset of the legacy SF2.04 feature set, it follows that there is a version of SiliconSF that supports SFe. The starter specification included in 4.0.11 simply states that the SiliconSF specification as in legacy SF2.04 is usable in SFe.
Eventually, we will adapt the SiliconSFe system for SFe-AL3, the system that allows "blobs" of samples to be present away from the instruments and presets. After SFe-AL3 is implemented, we will then include subtractive synthesis, one of the long term goals that we had for SFe. That being said, it is very unlikely that we will implement it in SFe 4.
About future plans
Now with development of SFe 4.0 nearing the end, we can start thinking about future versions. The text for 4.0.11a is generally "frozen", which means that we won't make major changes to the contents of the specification. SFe 4.0 is now for the most part a non-moving specification that Polyphone 3 can target. If the specification keeps changing, then it can be very difficult for it to be implemented.
Generally, when a version is finalised, we aim to have drafts of the components of version n+1, and then to start thinking of the components included in version n+2. The feature freeze only happens after the previous version has been completely finalised (a final specification has been released).
The status of 4.1 is that it remains the modulator update, with its two main features being the DMOD (default modulators) and PNMM (parameter-number-modulator-map) chunks, both of which have a significantly advanced draft specification by Spessasus, the person who came up with these ideas. We've got space for a large number of features in 4.1, but all other features are planned for a later version.
After 4.1 comes 4.2. Generally, 4.2 is a player update that also implements the first of the new generator enums. The player features planned for 4.2 include a standardised feature set for MIDI lyrics, as well as the integration of Spessasus/Falcosoft RMIDI into SFe, and the generator enum features currently planned are round-robin sample playback, more sample modes, exclusive class release and initial attenuation modes. It will also integrate SFCF (SynthFont Custom Features).
After that, each version from 4.3 to 4.7 has at least one feature planned:
4.3- independent envelopes/filters and filter controls,prswsub-chunk with XG/GS/GM2 reset support4.4- preset library management system with theplmssub-chunk anddwLibrary/dwGenre/dwMorphologyplus the first of the remaining DLS features4.5- dynamic RIFF file format scaling from 32-bit to 64-bit and beyond4.6- SFe-AL3 using SiliconSFe, and SFe-AL4, SFe-AL5 and SFe-AL6 using SFZ, with compilation between SFe and SFZ4.7- Conditional start and key switching
What's Changed
- 4.0.11 pull request by @sylvia-leaf in #59
Full Changelog: 4.0.10...4.0.11
