Falcosoft wrote on 2024-08-05, 15:53:

Hi, […]
Show full quote

Hi,

Spesek wrote on 2024-08-05, 14:25:

Can't say that about saving though.
The bad
First, the format is saved as .mid instead of .rmi. But this is a minor issue.

This is simply not true. When you change the file type in the Save As dialog it always changes the extension accordingly (.mid, .kar, .rmi). Of course if you forcefully change the extension manually it will be saved as you set.

Spesek wrote on 2024-08-05, 14:25:

Second, the soundfont just gets copied into the file which results in this: SpessaSynth trims it to only use the samples in the […]
Show full quote

Second, the soundfont just gets copied into the file which results in this:
SpessaSynth trims it to only use the samples in the MIDI. (It finds every key-velocity combo for each used program (on each track and each port if multiport) and removes every unused preset and every unused sample in the used presets)
Third, the banks are not shifted. I've specified an offset of 2 and put a gm midi in, and it also was copied without change. This results in fsmp6 using the main bank instead of the embedded one.
Spessa does alter the bank selects for the offset (it doesn't just blidnly add offset though. It checks if the preset exists in the given soundfont then adds offset to it. For example original calls 50:16 because it was made for some specific soundfont. spessa then checks for this preset. Let's say that the only preset with program 16 is 0:16. So it adds offset to that which for offset of 2 becomes bank select 2 and program 16. Same with programs, except for adding the offset)
Lastly, spessa just... doesn't see the embedded soundfont from files exported by fsmp6, like, at all. But that might be spessa's issue, not yours because fsmp6 detects it fine. I'll look into it.

This is all intentional. It's not supposed to overthink the user and make changes to either the Midi or the SF2 file. I do not know why you chose the path you chose but I would not like to follow you on this way.
I would like to add both the mid and the SF2 file to the riff file exactly the way as the user made/edited them.
BTW, the automatic shifting is simply wrong in some situations. You should not suppose that all presets in the Midi file would like to use the same bank and thus only the embedded soundfont (and thus making changes to bank select messages in Midi file arbitrarily).
Maybe that's why you have not understood the original concept behind the +1 offset. I always wanted that .rmi files like the attached below to be valid the same way as similar Mid+SF2 pairs are valid

The attachment Rock_test.zip is no longer available

Hi again,
You're right about soundfont trimming. It is optional. Spessa does it to shrink the file size, as the RMI file is something like an XM file: necessary samples (soundfont) and pattern data (midi) used to play the file. For example take a typical user who has a cool sounding gm soundfont and a midi file that they want to bundle together. Pasting the raw soundfont into the file will result in a ton of unused samples and taking a ton of space (exactly what the 1GB rmi file i sent is). But that's just my personal opinion. Pasting the entire soundfont into the rmi doesn't violate the rmi spec so it's perfectly fine.

About the bank shifting:
RMI files should be self contained (in my opinion). The soundfont in the file should contain all presets used in the file. Other than the very specific Creative! demos you've mentioned before, I don't think any regular midi file is specifically made to use more than 1 soundfont. And even if, what's the point of bundling an rmi + gm sf2? If it uses 2 soundfonts, why not just merge them into one and bundle that as rmi?
Let's assume that Joe downloaded a cool soundfont and a cool midi. He wants to share it as a single file, so others won't be forced to download an entire gm soundfont just to listen to a single MID. Joe leaves bank offset at the default 1, not knowing what it is. Spessa shifts the midi file's banks to correctly match with the new offset, while FSMP6 expects the user to modify the MIDI manually.
TLDR; spessa modifies mid to work with sf2, FSMP6 expects the user to do so. Both approaches are fine.
But again, this is opinionated. All I care about is that the format is somewhat standardized and it works on both FSMP6 and SS!

About the wrong bank offsets:
I don't think that's the case with spessasynth. it correctly shifts the banks for each program, taking the real bank into account. For example in Flowering night rmi i've sent before, stereo strings is on bank 16, coupled harprischord is on bank 8, etc. And they all are shifted by 1. Not all set to 1.
I've tested it with multiple MIDIs and it seems to work fine.

PS: Looks like the MS riff chunk is defined differently than the soundfont riff chunk. SF RIFF expects the size to be even (so it takes the pad byte into the total size), while MS also pads, but the size may be odd. After adding a quick fix, it works fine on my end. And also: it takes a ton of time to load that 1GB soundfont there!

zaphod77 wrote on 2024-08-05, 15:21:

AS near as i can tell, sf2pack should be very similar to sf3, as both have the exact same goal of ".sf2 but the samples are comp […]
Show full quote

AS near as i can tell, sf2pack should be very similar to sf3, as both have the exact same goal of ".sf2 but the samples are compressed". i'm actually curious what the heck the incompatibility is.

as i understand it, the sf2 format does NOT specify the actual format of te compressed sample data in any way. you just replace the uncompressed sample with the compressed sample and edi th e size.

the limitations of what compressions can be used are that
1) the program must be able to understand it.
2) the program must be able to identify it from the bitstream
3) the compression format must support seeking to specific points in the decoded waveform.

as near as i can tell, the only difference between sf3 and sf2pack is that sf3 has a sampletype flag to say if the sample is compressed or not, and what sort of compression, and sf2pack does not, and just expects the program to figure it out on it's own. this is because sf2pack was no intended to be read directly. you were expected to uncompress the non lossy compressed samples, and then save the new uncompressed one so you could load it into your awe32.

yes, this means that "sf2pack not being open source" is FUD. it's literally a .sf2 file (which is open source) but instead of an uncompressed wav with size info, it has a compressed waveform with size info for it's compressed length. literally nothing is added to the format.

Sf3 has changed sample and loop offsets with clear documentation on how they work.

If sfpack is just sf2 with samples replaced with compressed versions, how does that work? How do sample loop points work? In sf2, loopStart is relative to start of the SDTA chunk, how would that work with ogg vorbis where the length isn't the actual length of the sample? There's no explanation in the bass docs about this.
And also, does the synth have to assume that every sample in the sfpk soundfont has compression?

Fortunately, identifying what encoding it is is rather easy since every compressed sample (at least in sf3) is in the ogg container with a full ogg header (OggS...Vorbis)

it's all on the program loading the .sf2pack to fix things.

all the offsets point at the decoded waveforms.

again, it was not originally created for actual loading. just compress better than zip, upload, download, uncompress, and then load.

Falcosoft wrote on 2024-08-05, 15:53:

Hi, […]
Show full quote

Hi,

One problem: it straight up ignores the name (INAM). The shift_jis kanji test I've made was exactly for this. The IENC uses "Shift_JIS" encoding and the INAM is encoded as such. It should display "恋色マジック from 東方萃夢想" but it displays the file name.

MidiPlayer x86 works even on Win9x so it is not unicode aware. Thus it can handle only the current system's ANSI code page. So do not expect it to display arbitrary unicode encodings like kanji.
Enabling unicode in the specification was your idea alone, but unfortunatly FSMP cannot implement it this way.

Sorry, I didn't notice this while reading the first post.
If FSMP6 is win95 compatible, then that's fair. Kanji might be ignored.

What about ASCII though? The IENC might be simply ignored and ASCII assumed.
The atttack_gs_sf3_offset_... files all have the name "ATTACK ACTUAL" which is ASCII but it still shows "attack_gs_sf3_offset_0.rmi":

What about simply attempting to decode with ascii, and if there are some invalid characters, use the file name.

But if you don't want to add INAM at all, that's fine too 😀.

zaphod77 wrote on 2024-08-05, 17:06:

it's all on the program loading the .sf2pack to fix things.

all the offsets point at the decoded waveforms.

again, it was not originally created for actual loading. just compress better than zip, upload, download, uncompress, and then load.

So the entire SDTA is compressed as big single vorbis file? And once you decompress the sdta and put the decompressed sdta there, it's just a regular sf2?

@zaphod77 and @Spesek

I feel there is a misunderstanding here. SFPack and SF2Pack are NOT the same formats. SFPack is an older format that is similar to SFArk. SFPack files are compressed whole soundfonts for easier distribution. They were never meant to be used for real-time playing. First you need to decompress SFPack files to get the orioginal SF2. I think @zaphod77 is talking about this format.
SF2Pack is a different format that is used in Bassmidi and created by Ian Luck. It is meant to be used for real-time palying. It can use many different compressed formats besides ogg/vorbis. In Bassmidi you can get the id of the used compression with simple function calls.

Spesek wrote on 2024-08-05, 16:49:

Hi again, You're right about soundfont trimming. It is optional. Spessa does it to shrink the file size, as the RMI file is some […]
Show full quote

Hi again,
You're right about soundfont trimming. It is optional. Spessa does it to shrink the file size, as the RMI file is something like an XM file: necessary samples (soundfont) and pattern data (midi) used to play the file. For example take a typical user who has a cool sounding gm soundfont and a midi file that they want to bundle together. Pasting the raw soundfont into the file will result in a ton of unused samples and taking a ton of space (exactly what the 1GB rmi file i sent is). But that's just my personal opinion. Pasting the entire soundfont into the rmi doesn't violate the rmi spec so it's perfectly fine.

About the bank shifting:
RMI files should be self contained (in my opinion). The soundfont in the file should contain all presets used in the file. Other than the very specific Creative! demos you've mentioned before, I don't think any regular midi file is specifically made to use more than 1 soundfont. And even if, what's the point of bundling an rmi + gm sf2? If it uses 2 soundfonts, why not just merge them into one and bundle that as rmi?
Let's assume that Joe downloaded a cool soundfont and a cool midi. He wants to share it as a single file, so others won't be forced to download an entire gm soundfont just to listen to a single MID. Joe leaves bank offset at the default 1, not knowing what it is. Spessa shifts the midi file's banks to correctly match with the new offset, while FSMP6 expects the user to modify the MIDI manually.
TLDR; spessa modifies mid to work with sf2, FSMP6 expects the user to do so. Both approaches are fine.
But again, this is opinionated. All I care about is that the format is somewhat standardized and it works on both FSMP6 and SS!

About the wrong bank offsets:
I don't think that's the case with spessasynth. it correctly shifts the banks for each program, taking the real bank into account. For example in Flowering night rmi i've sent before, stereo strings is on bank 16, coupled harprischord is on bank 8, etc. And they all are shifted by 1. Not all set to 1.
I've tested it with multiple MIDIs and it seems to work fine.

PS: Looks like the MS riff chunk is defined differently than the soundfont riff chunk. SF RIFF expects the size to be even (so it takes the pad byte into the total size), while MS also pads, but the size may be odd. After adding a quick fix, it works fine on my end. And also: it takes a ton of time to load that 1GB soundfont there!

Hi,
1. It seems we do not agree here (about RMI files should be always self contained). I would like to preserve the philosophy of the original SB demo files that was about variation/user banks. In this sense for me there is no fundamental difference between Mid+SF2 pairs and rmi files with embedded Mid + SF2 pairs. For me It's only a container thing. I consider the rmi (Mid+SF2) format to be completely valid for only variation banks that rely on a preloaded full GM bank at bank 0.

2. If you consider the above described (not fully self contained) RMI files valid, then you should realize where is the problem with automatic bank shifting. You cannot know what presets are aiming the default GM bank and what presets the user/variation bank. Look at the previously attached Rock_test.rmi to see what I'm talking about:
download/file.php?id=198637

3. Further problem with the automatic bank shifting concept that (as you previously could experience) both Bank Select and Program Change messages could also be set with the help of SysEx messages. This is true for both GS and XG. So you should write a complete XG/GS SysEx interpreter to capture and edit all SysEx based bank select messages.

What about simply attempting to decode with ascii, and if there are some invalid characters, use the file name.
But if you don't want to add INAM at all, that's fine too 😀.

On the playlist always the real path + file names are listed regardless of formats. I would not like to change this. I think metadata does not belong here. So most likely I skip implementing this here.

Falcosoft wrote on 2024-08-05, 17:36:

Hi, 1. It seems we do not agree here (about RMI files should be always self contained). I would like to preserve the philosophy […]
Show full quote

Spesek wrote on 2024-08-05, 16:49:

Hi again, You're right about soundfont trimming. It is optional. Spessa does it to shrink the file size, as the RMI file is some […]
Show full quote

Hi again,
You're right about soundfont trimming. It is optional. Spessa does it to shrink the file size, as the RMI file is something like an XM file: necessary samples (soundfont) and pattern data (midi) used to play the file. For example take a typical user who has a cool sounding gm soundfont and a midi file that they want to bundle together. Pasting the raw soundfont into the file will result in a ton of unused samples and taking a ton of space (exactly what the 1GB rmi file i sent is). But that's just my personal opinion. Pasting the entire soundfont into the rmi doesn't violate the rmi spec so it's perfectly fine.

About the bank shifting:
RMI files should be self contained (in my opinion). The soundfont in the file should contain all presets used in the file. Other than the very specific Creative! demos you've mentioned before, I don't think any regular midi file is specifically made to use more than 1 soundfont. And even if, what's the point of bundling an rmi + gm sf2? If it uses 2 soundfonts, why not just merge them into one and bundle that as rmi?
Let's assume that Joe downloaded a cool soundfont and a cool midi. He wants to share it as a single file, so others won't be forced to download an entire gm soundfont just to listen to a single MID. Joe leaves bank offset at the default 1, not knowing what it is. Spessa shifts the midi file's banks to correctly match with the new offset, while FSMP6 expects the user to modify the MIDI manually.
TLDR; spessa modifies mid to work with sf2, FSMP6 expects the user to do so. Both approaches are fine.
But again, this is opinionated. All I care about is that the format is somewhat standardized and it works on both FSMP6 and SS!

About the wrong bank offsets:
I don't think that's the case with spessasynth. it correctly shifts the banks for each program, taking the real bank into account. For example in Flowering night rmi i've sent before, stereo strings is on bank 16, coupled harprischord is on bank 8, etc. And they all are shifted by 1. Not all set to 1.
I've tested it with multiple MIDIs and it seems to work fine.

PS: Looks like the MS riff chunk is defined differently than the soundfont riff chunk. SF RIFF expects the size to be even (so it takes the pad byte into the total size), while MS also pads, but the size may be odd. After adding a quick fix, it works fine on my end. And also: it takes a ton of time to load that 1GB soundfont there!

Hi,
1. It seems we do not agree here (about RMI files should be always self contained). I would like to preserve the philosophy of the original SB demo files that was about variation/user banks. In this sense for me there is no fundamental difference between Mid+SF2 pairs and rmi files with embedded Mid + SF2 pairs. For me It's only a container thing. I consider the rmi (Mid+SF2) format to be completely valid for only variation banks that rely on a preloaded full GM bank at bank 0.

2. If you consider the above described (not fully self contained) RMI files valid, then you should realize where is the problem with automatic bank shifting. You cannot know what presets are aiming the default GM bank and what presets the user/variation bank. Look at the previously attached Rock_test.rmi to see what I'm talking about:
download/file.php?id=198637

3. Further problem with the automatic bank shifting concept that (as you previously could experience) both Bank Select and Program Change messages could also be set with the help of SysEx messages. This true for both GS and XG. So you should write a complete XG/GS SysEx interpreter to capture and edit all SysEx based bank select messages.

Hi.
1. I understand your idea about the custom sounds specific for a given midi file and a full gm soundfont as a fallback. That's another completely valid use for RMI! But I don't see a problem with combining the special sfx soundfont with the GM one and putting that into the rmi. That way the song sounds the same everywhere. (What if someone used a different gm soundfont?) Your version (2 soundfonts) is fine with the RMI standard too, it just won't work on spessasynth. (Or fluidsynth either I think if it ever will support RMID)

2. By valid, I mean that it's a valid RMI file (that doesn't violate the spec). Technically, a 4GB soundfont with a midi that plays a single C on piano is also valid. Same with an orchestral composition and soundfont that has a single square wave. This is also valid. SpessaSynth only accepts one soundfont by design, so it always creates self-contained RMI files, hence the bank shift is always on. Technically, the mid can be left unchanged if dbank is 0, because we don't shift anything. And also the preset validating is a result of FSMP6 only using the embedded soundfont when the program and bank match exactly.

3. I understand. I've added code to sanitize XG part param sysExes when I found out about them. But I was not aware of that same functionality in GS. could you give me a hint on finding more info about this? Or link to the program that reads sysExes and explains them which you took a screenshot of earlier. It would really help!

PS: Why does FSMP6 still support win95? (Just curious)

@Edit (woohoo, i can edit now!)

About the title, I don't mean it in the playlist but rather in the black display (seen on the screenshot)

Spesek wrote on 2024-08-05, 17:54:

Hi. 1. I understand your idea about the custom sounds specific for a given midi file and a full gm soundfont as a fallback. That […]
Show full quote

Falcosoft wrote on 2024-08-05, 17:36:

Hi, 1. It seems we do not agree here (about RMI files should be always self contained). I would like to preserve the philosophy […]
Show full quote

Spesek wrote on 2024-08-05, 16:49:

Hi again, You're right about soundfont trimming. It is optional. Spessa does it to shrink the file size, as the RMI file is some […]
Show full quote

Hi again,
You're right about soundfont trimming. It is optional. Spessa does it to shrink the file size, as the RMI file is something like an XM file: necessary samples (soundfont) and pattern data (midi) used to play the file. For example take a typical user who has a cool sounding gm soundfont and a midi file that they want to bundle together. Pasting the raw soundfont into the file will result in a ton of unused samples and taking a ton of space (exactly what the 1GB rmi file i sent is). But that's just my personal opinion. Pasting the entire soundfont into the rmi doesn't violate the rmi spec so it's perfectly fine.

About the bank shifting:
RMI files should be self contained (in my opinion). The soundfont in the file should contain all presets used in the file. Other than the very specific Creative! demos you've mentioned before, I don't think any regular midi file is specifically made to use more than 1 soundfont. And even if, what's the point of bundling an rmi + gm sf2? If it uses 2 soundfonts, why not just merge them into one and bundle that as rmi?
Let's assume that Joe downloaded a cool soundfont and a cool midi. He wants to share it as a single file, so others won't be forced to download an entire gm soundfont just to listen to a single MID. Joe leaves bank offset at the default 1, not knowing what it is. Spessa shifts the midi file's banks to correctly match with the new offset, while FSMP6 expects the user to modify the MIDI manually.
TLDR; spessa modifies mid to work with sf2, FSMP6 expects the user to do so. Both approaches are fine.
But again, this is opinionated. All I care about is that the format is somewhat standardized and it works on both FSMP6 and SS!

About the wrong bank offsets:
I don't think that's the case with spessasynth. it correctly shifts the banks for each program, taking the real bank into account. For example in Flowering night rmi i've sent before, stereo strings is on bank 16, coupled harprischord is on bank 8, etc. And they all are shifted by 1. Not all set to 1.
I've tested it with multiple MIDIs and it seems to work fine.

PS: Looks like the MS riff chunk is defined differently than the soundfont riff chunk. SF RIFF expects the size to be even (so it takes the pad byte into the total size), while MS also pads, but the size may be odd. After adding a quick fix, it works fine on my end. And also: it takes a ton of time to load that 1GB soundfont there!

Hi,
1. It seems we do not agree here (about RMI files should be always self contained). I would like to preserve the philosophy of the original SB demo files that was about variation/user banks. In this sense for me there is no fundamental difference between Mid+SF2 pairs and rmi files with embedded Mid + SF2 pairs. For me It's only a container thing. I consider the rmi (Mid+SF2) format to be completely valid for only variation banks that rely on a preloaded full GM bank at bank 0.

2. If you consider the above described (not fully self contained) RMI files valid, then you should realize where is the problem with automatic bank shifting. You cannot know what presets are aiming the default GM bank and what presets the user/variation bank. Look at the previously attached Rock_test.rmi to see what I'm talking about:
download/file.php?id=198637

3. Further problem with the automatic bank shifting concept that (as you previously could experience) both Bank Select and Program Change messages could also be set with the help of SysEx messages. This true for both GS and XG. So you should write a complete XG/GS SysEx interpreter to capture and edit all SysEx based bank select messages.

Hi.
1. I understand your idea about the custom sounds specific for a given midi file and a full gm soundfont as a fallback. That's another completely valid use for RMI! But I don't see a problem with combining the special sfx soundfont with the GM one and putting that into the rmi. That way the song sounds the same everywhere. (What if someone used a different gm soundfont?)

2. By valid, I mean that it's a valid RMI file (that doesn't violate the spec). Technically, a 4GB soundfont with a midi that plays a single C on piano is also valid. Same with an orchestral composition and soundfont that has a single square wave. This is also valid. SpessaSynth only accepts one soundfont by design, so it always creates self-contained RMI files, hence the bank shift is always on. Technically, the mid can be left unchanged if dbank is 0, because we don't shift anything. And also the preset validating is a result of FSMP6 only using the embedded soundfont when the program and bank match exactly.

3. I understand. I've added code to sanitize XG part param sysExes when I found out about them. But I was not aware of that same functionality in GS. could you give me a hint on finding more info about this? Or link to the program that reads sysExes and explains them which you took a screenshot of earlier. It would really help!

PS: Why does FSMP6 still support win95? (Just curious)

@Edit (woohoo, i can edit now!)

About the title, I don't mean it in the playlist but rather in the black display (seen on the screenshot)

Hi,
For me embedding GB sized full banks into rmi sounds completely irrational. Not to mention GB sized compressed full soundfonts that have to be decompressed all the time when the rmi is loaded...
If you ask me I would always distribute full GM/GS/XG banks separately. What if you would like to distribute more rmi files that would use the same base soundfont most of the time and only use some different variations?
Would you embed the GB sized base soundfont into each rmi file? I would not. I would provide the big base soundfont as a separate file in the package and the rmi files would only contain the midi files and the variation SF2 files.

FSMP supports Win9x (mainly Win98+ is relevant) since this is a retro oriented community and you have not many choices if you want to use soundfonts/VSTi plugins for Midi playing/games in Win9x world besides FSMP.
e.g. Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

The title also follows the same logic: always the real file name is used. For metadata (track names, other meta texts etc.) the Meta Text/Lyrics dialog is used. So maybe this would be the best place to display rmi related meta info.

Finally I have created a pack for you. It includes the requested program (vbsyx.exe). Unfortunately the installer is lost long time ago so you have to manually register some ocx files.
I have also attached some Yamaha/Roland pdf files where you can find the required info at the system parameters section at the end of the documents.

BTW, this caution part should be corrected/removed from your documentation since it does not adhere to RIFF specification (the padding byte should NOT be counted in the size of the chunk).

Caution
The chunk's size MUST BE even. If the initial chunk data is odd, a pad byte of 0 must be added at the end. The the chunk's size also MUST include the pad byte.

Here is an example from here (https://wavefilegem.com/how_wave_files_work.html):

Important! If a chunk body has an odd number of bytes, it must be followed by a padding byte with value 0. In other words, a chunk must always occupy an even number of bytes in the file. The padding byte should not be counted in the chunk header’s size field. For example, if a chunk body is 17 bytes in size, the header’s size field should be set to 17, even though the chunk body occupies 18 bytes (17 bytes of data followed by the padding byte).

Falcosoft wrote on 2024-08-05, 18:41:

Hi, For me embedding GB sized full banks into rmi sounds completely irrational. Not to mention GB sized compressed full soundfon […]
Show full quote

Spesek wrote on 2024-08-05, 17:54:

Hi. 1. I understand your idea about the custom sounds specific for a given midi file and a full gm soundfont as a fallback. That […]
Show full quote

Falcosoft wrote on 2024-08-05, 17:36:

Hi, 1. It seems we do not agree here (about RMI files should be always self contained). I would like to preserve the philosophy […]
Show full quote

Hi,
1. It seems we do not agree here (about RMI files should be always self contained). I would like to preserve the philosophy of the original SB demo files that was about variation/user banks. In this sense for me there is no fundamental difference between Mid+SF2 pairs and rmi files with embedded Mid + SF2 pairs. For me It's only a container thing. I consider the rmi (Mid+SF2) format to be completely valid for only variation banks that rely on a preloaded full GM bank at bank 0.

2. If you consider the above described (not fully self contained) RMI files valid, then you should realize where is the problem with automatic bank shifting. You cannot know what presets are aiming the default GM bank and what presets the user/variation bank. Look at the previously attached Rock_test.rmi to see what I'm talking about:
download/file.php?id=198637

3. Further problem with the automatic bank shifting concept that (as you previously could experience) both Bank Select and Program Change messages could also be set with the help of SysEx messages. This true for both GS and XG. So you should write a complete XG/GS SysEx interpreter to capture and edit all SysEx based bank select messages.

Hi.
1. I understand your idea about the custom sounds specific for a given midi file and a full gm soundfont as a fallback. That's another completely valid use for RMI! But I don't see a problem with combining the special sfx soundfont with the GM one and putting that into the rmi. That way the song sounds the same everywhere. (What if someone used a different gm soundfont?)

2. By valid, I mean that it's a valid RMI file (that doesn't violate the spec). Technically, a 4GB soundfont with a midi that plays a single C on piano is also valid. Same with an orchestral composition and soundfont that has a single square wave. This is also valid. SpessaSynth only accepts one soundfont by design, so it always creates self-contained RMI files, hence the bank shift is always on. Technically, the mid can be left unchanged if dbank is 0, because we don't shift anything. And also the preset validating is a result of FSMP6 only using the embedded soundfont when the program and bank match exactly.

3. I understand. I've added code to sanitize XG part param sysExes when I found out about them. But I was not aware of that same functionality in GS. could you give me a hint on finding more info about this? Or link to the program that reads sysExes and explains them which you took a screenshot of earlier. It would really help!

PS: Why does FSMP6 still support win95? (Just curious)

@Edit (woohoo, i can edit now!)

About the title, I don't mean it in the playlist but rather in the black display (seen on the screenshot)

Hi,
For me embedding GB sized full banks into rmi sounds completely irrational. Not to mention GB sized compressed full soundfonts that have to be decompressed all the time when the rmi is loaded...
If you ask me I would always distribute full GM/GS/XG banks separately. What if you would like to distribute more rmi files that would use the same base soundfont most of the time and only use some different variations?
Would you embed the GB sized base soundfont into each rmi file? I would not. I would provide the big base soundfont as a separate file in the package and the rmi files would only contain the midi files and the variation SF2 files.

FSMP supports Win9x (mainly Win98+ is relevant) since this is a retro oriented community and you have not many choices if you want to use soundfonts/VSTi plugins for Midi playing/games in Win9x world besides FSMP.
e.g. Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

The title also follows the same logic: always the real file name is used. For metadata (track names, other meta texts etc.) the Meta Text/Lyrics dialog is used. So maybe this would be the best place to display rmi related meta info.

Finally I have created a pack for you. It includes the requested program (vbsyx.exe). Unfortunately the installer is lost long time ago so you have to manually register some ocx files.
I have also attached some Yamaha/Roland pdf files where you can find the required info at the system parameters section at the end of the documents.

The attachment XG-GS Utilities.zip is no longer available

The attachment xg_spec.pdf is no longer available

The attachment SC-88PRO_OM.pdf is no longer available

Hi,
Thanks so much for these utilities! They will help me a ton.
However, I've tried AMIX95 and got this:

The folder doesn't contain this OCX file. Where can I get it?

Also a different OCX for vbsyx:

Maybe this is wine's fault. I'll try with a windows VM and correct the post if it works there.

PS: The metadata sounds good! Maybe even add a way to edit it there?

PS PS: The GM soundfont would be trimmed to only use the necessary samples, not the entire soundfont (and the entire thing would get compressed to sf3). But I agree with one soundfont base for many RMI files idea.

@Edit:
About the spec: that's how sf2 riff works. The size takes the pad byte into account (at least the sf2 files i have work like that)

@Edit 2: the chnuk reads 30, not 20.

Here are the ocx files I have found in my XP's System32 folder. I do not know which one is relevant for the program. Most likely you do not need to register all.

About the spec: that's how sf2 riff works. The size takes the pad byte into account (at least the sf2 files i have work like that)
pad_byte.png

We are talking about the main Riff Midi file which is a regular RIFF file. It does not matter if the included SF2 is not RIFF comformant, we do not edit the SF2 content here but the main RMIDI file which should be RIFF conformant (just like the original rmi files without SF2 are).

Falcosoft wrote on 2024-08-05, 19:17:

Here are the ocx files I have found in my XP's System32 folder. I do not know which one is relevant for the program. Most likely […]
Show full quote

Here are the ocx files I have found in my XP's System32 folder. I do not know which one is relevant for the program. Most likely you do not need to register all.

The attachment OCX_Files.zip is no longer available

About the spec: that's how sf2 riff works. The size takes the pad byte into account (at least the sf2 files i have work like that)
pad_byte.png

We are talking about the main Riff Midi file which is a regular RIFF file. It does not matter if the included SF2 is not RIFF comformant, we do not edit the SF2 content here but the main RMIDI file which should be RIFF conformant (just like the original rmi files without SF2 are).

Sure, I've added that it may be taken into account. The RMI files I sent do take it into account and your program reads them fine.

Spesek wrote on 2024-08-05, 19:31:

Falcosoft wrote on 2024-08-05, 19:17:

Here are the ocx files I have found in my XP's System32 folder. I do not know which one is relevant for the program. Most likely […]
Show full quote

Here are the ocx files I have found in my XP's System32 folder. I do not know which one is relevant for the program. Most likely you do not need to register all.

The attachment OCX_Files.zip is no longer available

About the spec: that's how sf2 riff works. The size takes the pad byte into account (at least the sf2 files i have work like that)
pad_byte.png

We are talking about the main Riff Midi file which is a regular RIFF file. It does not matter if the included SF2 is not RIFF comformant, we do not edit the SF2 content here but the main RMIDI file which should be RIFF conformant (just like the original rmi files without SF2 are).

Sure, I've added that it may be taken into account. The RMI files I sent do take it into account and your program reads them fine.

Hi,
Here is an example original rmi file from Microsoft. As you can see the padding byte is not included in the size of the 'data' and 'INFO' -> 'ICOP' chunks.
I still do not think that the right size calculation of a chunk should be 'optional'.

Falcosoft wrote on 2024-08-05, 17:20:

@zaphod77 and @Spesek

I feel there is a misunderstanding here. SFPack and SF2Pack are NOT the same formats. SFPack is an older format that is similar to SFArk. SFPack files are compressed whole soundfonts for easier distribution. They were never meant to be used for real-time playing. First you need to decompress SFPack files to get the orioginal SF2. I think @zaphod77 is talking about this format.
SF2Pack is a different format that is used in Bassmidi and created by Ian Luck. It is meant to be used for real-time palying. It can use many different compressed formats besides ogg/vorbis. In Bassmidi you can get the id of the used compression with simple function calls.

i based my statment og this post at un4seen.com

http://www.un4seen.com/forum/?topic=15871.0

and it literally states that sf2pack is just sf2 but with a compressed sample chunk and the size updated.

Falcosoft wrote on 2024-08-05, 19:44:

Hi, Here is an example original rmi file from Microsoft. As you can see the padding byte is not included in the size of the 'dat […]
Show full quote

Spesek wrote on 2024-08-05, 19:31:

Falcosoft wrote on 2024-08-05, 19:17:

Here are the ocx files I have found in my XP's System32 folder. I do not know which one is relevant for the program. Most likely you do not need to register all.

The attachment OCX_Files.zip is no longer available

We are talking about the main Riff Midi file which is a regular RIFF file. It does not matter if the included SF2 is not RIFF comformant, we do not edit the SF2 content here but the main RMIDI file which should be RIFF conformant (just like the original rmi files without SF2 are).

Sure, I've added that it may be taken into account. The RMI files I sent do take it into account and your program reads them fine.

Hi,
Here is an example original rmi file from Microsoft. As you can see the padding byte is not included in the size of the 'data' and 'INFO' -> 'ICOP' chunks.
I still do not think that the right size calculation of a chunk should be 'optional'.

The attachment bachsb.zip is no longer available

Hi Falco,
Alright, I've changed it to "must not be taken into account".
Also, I have an idea for new chunks (similar to WAV):
IPRD: Album title
IART: Artist (IENG could be the creator of the soundfont and IART could be the creator of the midi)
IGNR: Song's genre
IPIC: Album cover image (or any image). Only PNG or JPEG allowed and the chunk's data is the binary of the image

All of these are optional, of course.
What do you think?

and here ian notes that lossy compression can mess up loops with .sf2pack

http://www.un4seen.com/forum/?topic=18778.0

sf2pack.exe only does FLAC and wavpack, because they are lossless so the loops will remain seamless and not have popping.

and there he states that any audio format understood by BASS can be read out of a .sf2pack

in this case, bass is doing the needed processing to work out what the compressed format is.

zaphod77 wrote on 2024-08-05, 20:08:

i based my statment og this post at un4seen.com […]
Show full quote

Falcosoft wrote on 2024-08-05, 17:20:

@zaphod77 and @Spesek

I feel there is a misunderstanding here. SFPack and SF2Pack are NOT the same formats. SFPack is an older format that is similar to SFArk. SFPack files are compressed whole soundfonts for easier distribution. They were never meant to be used for real-time playing. First you need to decompress SFPack files to get the orioginal SF2. I think @zaphod77 is talking about this format.
SF2Pack is a different format that is used in Bassmidi and created by Ian Luck. It is meant to be used for real-time palying. It can use many different compressed formats besides ogg/vorbis. In Bassmidi you can get the id of the used compression with simple function calls.

i based my statment og this post at un4seen.com

http://www.un4seen.com/forum/?topic=15871.0

and it literally states that sf2pack is just sf2 but with a compressed sample chunk and the size updated.

You have written:

again, it was not originally created for actual loading. just compress better than zip, upload, download, uncompress, and then load.

This is true for the 'old' SFPack format but not for Bassmidi's SF2Pack format. That's why I thought there was a misunderstanding.

Also an Ian luck email confirms that there are other subtle difference betwen SF3 and SF2Pack:
My mail:

I have tested some SF3 files and they seem to be working. The only minor > problem is that BASS_MIDI_FontGetInfo() reports sampl […]
Show full quote

I have tested some SF3 files and they seem to be working. The only minor
> problem is that BASS_MIDI_FontGetInfo() reports sample size as
> compressed while in the case of SF2PACK format files sample size is
> reported as uncompressed size (info.samsize).

Ian's answer:

Yeah, the problem is that the SF3 format doesn't store the decompressed size (only the compressed size), so that info isn't know […]
Show full quote

Yeah, the problem is that the SF3 format doesn't store the decompressed
size (only the compressed size), so that info isn't known until each
sample is decoded. I'll update BASS_MIDI_FontGetInfo to count the known
samples (those that have been loaded at some point), like with SFZ.

zaphod77 wrote on 2024-08-05, 20:15:

and here ian notes that lossy compression can mess up loops with .sf2pack […]
Show full quote

and here ian notes that lossy compression can mess up loops with .sf2pack

http://www.un4seen.com/forum/?topic=18778.0

sf2pack.exe only does FLAC and wavpack, because they are lossless so the loops will remain seamless and not have popping.

and there he states that any audio format understood by BASS can be read out of a .sf2pack

in this case, bass is doing the needed processing to work out what the compressed format is.

Yep, these are all true.

Hi Zoltan )
I want understand something , for example , here discussing two methods numbering patches first method 000-127 , second method 001-128 , why here say about what in second method have drumsets in last bank , and in first method in last bank have MT-32 patches ? If think , both methods of numbering easy seme and diffirent only where start calculate )

Roland User wrote on 2024-08-05, 20:48:

Hi Zoltan )
I want understand something , for example , here discussing two methods numbering patches first method 000-127 , second method 001-128 , why here say about what in second method have drumsets in last bank , and in first method in last bank have MT-32 patches ? If think , both methods of numbering easy seme and diffirent only where start calculate )

Hi,
It seems you have mixed up 2 completely different things. The patch numbering system has nothing to do with the SF2 bank management logic and bank offsets we were talking about.

Spesek wrote on 2024-08-05, 20:12:

Hi Falco, Alright, I've changed it to "must not be taken into account". Also, I have an idea for new chunks (similar to WAV): IP […]
Show full quote

Falcosoft wrote on 2024-08-05, 19:44:

Hi, Here is an example original rmi file from Microsoft. As you can see the padding byte is not included in the size of the 'dat […]
Show full quote

Spesek wrote on 2024-08-05, 19:31:

Sure, I've added that it may be taken into account. The RMI files I sent do take it into account and your program reads them fine.

Hi,
Here is an example original rmi file from Microsoft. As you can see the padding byte is not included in the size of the 'data' and 'INFO' -> 'ICOP' chunks.
I still do not think that the right size calculation of a chunk should be 'optional'.

The attachment bachsb.zip is no longer available

Hi Falco,
Alright, I've changed it to "must not be taken into account".
Also, I have an idea for new chunks (similar to WAV):
IPRD: Album title
IART: Artist (IENG could be the creator of the soundfont and IART could be the creator of the midi)
IGNR: Song's genre
IPIC: Album cover image (or any image). Only PNG or JPEG allowed and the chunk's data is the binary of the image

All of these are optional, of course.
What do you think?

1. Thanks!
2. I do not mind but I'm not too much enthusiastic either. Personally I do not think that so many meta chunks are necessary but of course they cannot hurt anything either.
Most likey FSMP will not support these extended chunks 😀