4.00.7
Pre-release
SFe Version 4.00.7 (Draft Specification) - October 2024
Getting Some Help
This is the 7th draft milestone of the SFe specification. Sorry that we forgot to make a pre-packaged release of the 6th milestone; we will try not to forget again.
This release of the specification does not include new features in the format spec itself, as there has been a feature freeze for SFe version 4.00, but focuses on fixing the small issues. We thank @spessasus for taking the time to fix some issues that were in 4.00.6.
In this announcement, we will also include changes that were included in 4.00.6 for the sake of completeness.
Significant structural changes
We've split the SFe specification into three different smaller specifications:
- SFe32 for full 32-bit compatibility
- SFe64L for a 64-bit format that is mostly similar to SFe32 to help users move to 64 bits more easily
- SFe64 for the more divergent 64-bit specification
Currently, there are two specifications released, SFe32 and SFe64. However, SFe64 will have structural changes that break backwards compatibility starting with version 5.00, so the first version of SFe64L, 5.00, will be based on the structure of SFe64 4.x.
Additionally, a pull request by @spessasus was merged by team member @stgiga, merging the admittedly hard-to-read separated sections of the format specification into just one document. This pull request also adds for the first time, a table of contents.
Section 7.1a was removed, because it will only be relevant when SFe64 version 5.00 is released.
Versioning system changes
Yes, we've changed the versioning system again. However, this time it is just the naming. Now, because SFe development is done on a rolling basis, and any update to the specification can be considered a draft, we've renamed the SFe drafts to draft milestones to make the purpose of these releases more clear.
Initially, we planned the file repair specification for 4.00.6. However, 4.00.6 was the version which we split SFe32 from SFe64. It was then moved to 4.00.7. However, when we decided to merge the aforementioned pull request, the structural change meant that we could no longer refer to the specification as 4.00.6a-1, so we renamed this update to 4.00.7. Now, the file repair specification is planned for version 4.00.8.
Modulators
The modulator system that we originally planned for SFe was scrapped. Instead, we will implement spessasus's DMOD sub-chunk for 4.01, and add back some of the features that were planned in this update.
Right now, discussions have been made about designing the new modulator system around the CC94 (InsertionEFX) format as used by Roland in the SC-88Pro and SC-8850.
About the ISFe sub-chunk
The ISFe sub-chunk will be used by the SFe format for SFe-specific metadata. Currently, no data is defined, and there will likely be no definitions in 4.00, however we've started to formulate plans for how we can use this sub-chunk.
As every soundfont developer knows, each soundfont player supports a different amount of the 2.04 spec, and few soundfont players support everything. Therefore, a few soundfonts (most notably GeneralUserGS by S. Christian Collins) include a built-in player test (in the case of GUGS, it is the GUTest preset).
Therefore, the plan is to use part of the ISFe sub-chunk as a sort of "feature flags" system. The SFe editor program will add the feature flags that are used by the bank to ISFe. Once the bank is played by software that doesn't support all of the features, the software can then read the ISFe sub-chunk, figure out what features are being used, and then give a warning if the bank is trying to use an SFe feature that isn't supported by the software.
Currently, we plan on developing one or two features at once, and then release a new version of the format. However, if we use ISFe to implement feature flags, then we can add many different features with each format update, and then allow the SFe program developers to implement features at their own pace. Just using the ifil version to communicate available features has the disadvantage of being unable to clearly mention which of the features are supported.
The feature flags that we plan on adding would also include features included in the base SF 2.04 format, because there are still problems with certain soundfont players not supporting soundfonts that were written to legacy SF standards.
Arguably, we could make programs reject any structures that they don't recognise. However, this would severely affect compatibility, as newer SFe files would simply not run on older players.
The ISFe sub-chunk will eventually do way more than just be a feature flags system, but this is the first idea that we are going to try to implement.
About future plans
We are planning the next few draft milestones of the SFe specification:
- 4.00.8: Redo the RIFF structure and program repair specification
- 4.00.9: SFe SDK release, start to solve the TSC implementation problem
- 4.00.10: Update the SDK with a few more things
Program specification
The program specification is mostly the same as previous versions, but has changes that correspond to the changes in 4.00.7. Namely, TSC mode support is no longer required, as it is now a separate specification to SFe itself.
Compatibility specification
In the compatibility spec, we've added information on how to handle proprietary compression formats, and we fixed a mistake in the INFO chunk information.
Where is TSC mode?
We've had some discussion about TSC mode, where the sdta chunk is placed last to extend the maximum SFe32 file size to 8 GiB. However, it's been determined that TSC mode was obviously not compatible with legacy sound card hardware, so it has been removed. Instead, TSC is now available as a separate specification: https://github.com/SFe-Team-was-taken/TSC
We will bring it back once we have the original documentation about TSC mode, we can test it on legacy sound card hardware and we can create test SFe files implementing TSC. After that, it is likely to be moved into SFe64(L) or included as a separate specification. If TSC mode is a separate specification, then we'll just implement it into SFe as a feature flag. Then, if developers don't feel like rewriting their code, then they can just detect the feature flag in TSC banks and then reject the bank.
What's coming up?
For 4.00.8, we plan on providing an SFe file repair specification for development of programs. This is to be released in late 2024 or early 2025. After that, 4.00.9 will be the first version with an implementation of SFe, based on SpessaSynth, and 4.00.10 will introduce the feature flags system implementation. If you have any suggestions for other features that we could add, or additional information that we could include in future specs, then please open an issue and describe what you would like to see.
New Contributors
- @spessasus made their first contribution in #14
Full Changelog: 4.00.5...4.00.7
