XMF uses DLS. At one time, you could easily get DLS sound sources to use and now you can't. SoundFont on the other hand, has quietly lingered on - as a cult classic of sorts - and has broad support on Linux and Windows because of FluidSynth and the synth community, so it makes sense to move forward with that and do something new, since XMF is essentially dead, unless all the DLS sound-bank stuff that was once available in the early 2000's magically reappears.

zaphod77 wrote on 2024-08-04, 18:25:

My point is that the .xmf format was specifically designed for just this exact purpose, and the correct thing to do is either make a new extension, or add it as an extension to .xmf, instead of suborn the existing one.

Hi,
I do not think this is true. The first riff Midi files (with .rmi extension) as released by Microsoft in the Win3.x/Win9x era did not contain any DLS soundfonts. They were only Midi files in a RIFF container. So even riff Midi files with embedded DLS were the result of a later extension. I do not think this was much different from what we would like to do now. Both rmi files with embedded DLS extension and the new with embedded SF2 extension are fully compatible with the very first format (that was defined without any soundfont extension). The good thing about RIFF formats in general is that any consuming software can ignore the chunks that are not known by them.

Falcosoft wrote on 2024-08-04, 19:04:

zaphod77 wrote on 2024-08-04, 18:25:

My point is that the .xmf format was specifically designed for just this exact purpose, and the correct thing to do is either make a new extension, or add it as an extension to .xmf, instead of suborn the existing one.

Hi,
I do not think this is true. The first riff Midi files (with .rmi extension) as released by Microsoft in the Win3.x/Win9x era did not contain any DLS soundfonts. They were only Midi files in a RIFF container. So even riff Midi files with embedded DLS were the result of a later extension. I do not think this were much different from what we would like to do now. Both rmi files with embedded DLS extension and the new with embedded SF2 extension are fully compatible with the very first format (that was defined without any soundfont extension). The good thing about RIFF formats in general that any consuming software can ignore the chunks that are not known by them.

Hi again,
I've updated the wiki page with the new draft.
In addition to the DBNK chunk (as a 16-bit LE offset), I've added INAM (name) IENG (engineer/creator) and IENC (encoding for the info chunk).
Also I've described the behavior of the DBNK chunk and other chunks in the file. The default is still 1, as you've mentioned earlier.
But a value of 0 is described as allowed, because:
Since most RMIDIs will use the sf3 (ogg vorbis compressed) format to save space, the issue with Creative cards shouldn't be a problem as they don't support sf3 anyways. (Not to mention that uncompressed versions of the RMIDIs weight around 50MB which is too much for the earlier cards which face the bank 0 issue. (Wikipedia says that AWE64 only has 4MB of RAM)

Let me know what you think and I'll also get to writing the code for writing the new files.

PS: I just realized that DBNK of 0 will make GM MIDIs work!

Spesek wrote on 2024-08-04, 19:43:

Hi again, I've updated the wiki page with the new draft. In addition to the DBNK chunk (as a 16-bit LE offset), I've added INAM […]
Show full quote

Falcosoft wrote on 2024-08-04, 19:04:

zaphod77 wrote on 2024-08-04, 18:25:

My point is that the .xmf format was specifically designed for just this exact purpose, and the correct thing to do is either make a new extension, or add it as an extension to .xmf, instead of suborn the existing one.

Hi,
I do not think this is true. The first riff Midi files (with .rmi extension) as released by Microsoft in the Win3.x/Win9x era did not contain any DLS soundfonts. They were only Midi files in a RIFF container. So even riff Midi files with embedded DLS were the result of a later extension. I do not think this were much different from what we would like to do now. Both rmi files with embedded DLS extension and the new with embedded SF2 extension are fully compatible with the very first format (that was defined without any soundfont extension). The good thing about RIFF formats in general that any consuming software can ignore the chunks that are not known by them.

Hi again,
I've updated the wiki page with the new draft.
In addition to the DBNK chunk (as a 16-bit LE offset), I've added INAM (name) IENG (engineer/creator) and IENC (encoding for the info chunk).
Also I've described the behavior of the DBNK chunk and other chunks in the file. The default is still 1, as you've mentioned earlier.
But a value of 0 is described as allowed, because:
Since most RMIDIs will use the sf3 (ogg vorbis compressed) format to save space, the issue with Creative cards shouldn't be a problem as they don't support sf3 anyways. (Not to mention that uncompressed versions of the RMIDIs weight around 50MB which is too much for the earlier cards which face the bank 0 issue. (Wikipedia says that AWE64 only has 4MB of RAM)

Let me know what you think and I'll also get to writing the code for writing the new files.

PS: I just realized that DBNK of 0 will make GM MIDIs work!

Thanks,
it seems OK for me. Only 1 correction if possible in the 'Bank offset' section that currently says:

In MidiPlayer6, all banks seem to be offset by 1.

to
In MidiPlayer6, all banks seem to be offset by 1 by default. It can be set to 0 by altering the 'Real Time Loaded SF2 Default Bank' value to 0 in 'Device Settings' dialog.

neat idea.

it's silly to include instruments that are not needed to playback the midi file, though.

the entire point of combined formats is to only include what is needed to perform the playback.

So I wouldn't make one of these with an entire 50 meg gm bank included. i'd just include the instruments used by the file, which is likely to be much smaller.

Falcosoft wrote on 2024-08-04, 20:14:

Thanks, it seems OK for me. Only 1 correction if possible in the 'Bank offset' section that currently says: […]
Show full quote

Spesek wrote on 2024-08-04, 19:43:

Hi again, I've updated the wiki page with the new draft. In addition to the DBNK chunk (as a 16-bit LE offset), I've added INAM […]
Show full quote

Falcosoft wrote on 2024-08-04, 19:04:

Hi,
I do not think this is true. The first riff Midi files (with .rmi extension) as released by Microsoft in the Win3.x/Win9x era did not contain any DLS soundfonts. They were only Midi files in a RIFF container. So even riff Midi files with embedded DLS were the result of a later extension. I do not think this were much different from what we would like to do now. Both rmi files with embedded DLS extension and the new with embedded SF2 extension are fully compatible with the very first format (that was defined without any soundfont extension). The good thing about RIFF formats in general that any consuming software can ignore the chunks that are not known by them.

Hi again,
I've updated the wiki page with the new draft.
In addition to the DBNK chunk (as a 16-bit LE offset), I've added INAM (name) IENG (engineer/creator) and IENC (encoding for the info chunk).
Also I've described the behavior of the DBNK chunk and other chunks in the file. The default is still 1, as you've mentioned earlier.
But a value of 0 is described as allowed, because:
Since most RMIDIs will use the sf3 (ogg vorbis compressed) format to save space, the issue with Creative cards shouldn't be a problem as they don't support sf3 anyways. (Not to mention that uncompressed versions of the RMIDIs weight around 50MB which is too much for the earlier cards which face the bank 0 issue. (Wikipedia says that AWE64 only has 4MB of RAM)

Let me know what you think and I'll also get to writing the code for writing the new files.

PS: I just realized that DBNK of 0 will make GM MIDIs work!

Thanks,
it seems OK for me. Only 1 correction if possible in the 'Bank offset' section that currently says:

In MidiPlayer6, all banks seem to be offset by 1.

to
In MidiPlayer6, all banks seem to be offset by 1 by default. It can be set to 0 by altering the 'Real Time Loaded SF2 Default Bank' value to 0 in 'Device Settings' dialog.

Alright, added. I'll finish the code for the new format and send you a few dbnk RMID files to test with!

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

neat idea. […]
Show full quote

neat idea.

it's silly to include instruments that are not needed to playback the midi file, though.

the entire point of combined formats is to only include what is needed to perform the playback.

So I wouldn't make one of these with an entire 50 meg gm bank included. i'd just include the instruments used by the file, which is likely to be much smaller.

I have a 65MB midi with only the samples used included. The soundfont I created it from weights 1GB and has some very high quality (and size) samples. That's why it's this big.

Spesek wrote on 2024-08-04, 20:22:

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

neat idea. […]
Show full quote

neat idea.

it's silly to include instruments that are not needed to playback the midi file, though.

the entire point of combined formats is to only include what is needed to perform the playback.

So I wouldn't make one of these with an entire 50 meg gm bank included. i'd just include the instruments used by the file, which is likely to be much smaller.

I have a 65MB midi with only the samples used included. The soundfont I created it from weights 1GB and has some very high quality (and size) samples. That's why it's this big.

If you can talk with Ian about the SF2Pack format then the description should be extended with the possibility of an 'sfpk' chunk instead of 'sfbk'. FSMP6 currently also allows and can create rmi files with embedded SF2Pack format soundfonts.

Falcosoft wrote on 2024-08-04, 20:28:

Spesek wrote on 2024-08-04, 20:22:

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

neat idea. […]
Show full quote

neat idea.

it's silly to include instruments that are not needed to playback the midi file, though.

the entire point of combined formats is to only include what is needed to perform the playback.

So I wouldn't make one of these with an entire 50 meg gm bank included. i'd just include the instruments used by the file, which is likely to be much smaller.

I have a 65MB midi with only the samples used included. The soundfont I created it from weights 1GB and has some very high quality (and size) samples. That's why it's this big.

If you can talk with Ian about the SF2Pack format then the description should be extended with the possibility of an 'sfpk' chunk instead of 'sfbk'. FSMP6 currently also allows and can create rmi files with embedded SF2Pack format soundfonts.

I know about that. I specified in the specification that SF3 is also supported.
In fact, the files I've sent before (Koishi, flowering night, deltarune) all used sf3. SF3 is supported in FSMP6 and spessa so it's fine.

Spesek wrote on 2024-08-04, 20:33:

Falcosoft wrote on 2024-08-04, 20:28:

Spesek wrote on 2024-08-04, 20:22:

I have a 65MB midi with only the samples used included. The soundfont I created it from weights 1GB and has some very high quality (and size) samples. That's why it's this big.

If you can talk with Ian about the SF2Pack format then the description should be extended with the possibility of an 'sfpk' chunk instead of 'sfbk'. FSMP6 currently also allows and can create rmi files with embedded SF2Pack format soundfonts.

I know about that. I specified in the specification that SF3 is also supported.
In fact, the files I've sent before (Koishi, flowering night, deltarune) all used sf3. SF3 is supported in FSMP6 and spessa so it's fine.

Hi,
I'm not talking about SF3 format but SF2Pack format. They are not compatible. E.g. the Soundfont chunk in case of SF3 format is still 'sfbk' but in case of SF2Pack format the chunk name is 'sfpk' not 'sfbk'.
Reality_GMGS_falcomod.sfogg is an example for SF2Pack format.
But of course it can be an optional extension since SF2Pack is not restricted to ogg/vorbis compression but also supports lossless codecs like FLAC or WavPack.

Falcosoft wrote on 2024-08-04, 21:05:

Hi, I'm not talking about SF3 format but SF2Pack format. They are not compatible. E.g. the Soundfont chunk in case of SF3 forma […]
Show full quote

Spesek wrote on 2024-08-04, 20:33:

Falcosoft wrote on 2024-08-04, 20:28:

If you can talk with Ian about the SF2Pack format then the description should be extended with the possibility of an 'sfpk' chunk instead of 'sfbk'. FSMP6 currently also allows and can create rmi files with embedded SF2Pack format soundfonts.

I know about that. I specified in the specification that SF3 is also supported.
In fact, the files I've sent before (Koishi, flowering night, deltarune) all used sf3. SF3 is supported in FSMP6 and spessa so it's fine.

Hi,
I'm not talking about SF3 format but SF2Pack format. They are not compatible. E.g. the Soundfont chunk in case of SF3 format is still 'sfbk' but in case of SF2Pack chunk name is 'sfpk' not 'sfbk'.
Reality_GMGS_falcomod.sfogg is an example for SF2Pack format.

Hi,
I implemented the specification described.
The files are here:
https://filetransfer.io/data-package/4q7wpCVl#link
I've included multiple bank offsets, all generated with spessasynth. Also kanji encoding test and an xg file.
Source code for the RMIDI writing logic
Happy coding!

PS: I understand, but given how the two are almost the same (both use ogg vorbis) and sf3 is widely supported (think fluidsynth, polyphone, musescore) and is already supported by spessa and FSMP6, I think it is fine to use that. But if I manage to get in touch with Ian, I see no problem with adding it (the decoder is already there)

Spesek wrote on 2024-08-04, 23:06:

Hi, I implemented the specification described. The files are here: https://filetransfer.io/data-package/4q7wpCVl#link I've inclu […]
Show full quote

Falcosoft wrote on 2024-08-04, 21:05:

Hi, I'm not talking about SF3 format but SF2Pack format. They are not compatible. E.g. the Soundfont chunk in case of SF3 forma […]
Show full quote

Spesek wrote on 2024-08-04, 20:33:

I know about that. I specified in the specification that SF3 is also supported.
In fact, the files I've sent before (Koishi, flowering night, deltarune) all used sf3. SF3 is supported in FSMP6 and spessa so it's fine.

Hi,
I'm not talking about SF3 format but SF2Pack format. They are not compatible. E.g. the Soundfont chunk in case of SF3 format is still 'sfbk' but in case of SF2Pack chunk name is 'sfpk' not 'sfbk'.
Reality_GMGS_falcomod.sfogg is an example for SF2Pack format.

Hi,
I implemented the specification described.
The files are here:
https://filetransfer.io/data-package/4q7wpCVl#link
I've included multiple bank offsets, all generated with spessasynth. Also kanji encoding test and an xg file.
Source code for the RMIDI writing logic
Happy coding!

PS: I understand, but given how the two are almost the same (both use ogg vorbis) and sf3 is widely supported (think fluidsynth, polyphone, musescore) and is already supported by spessa and FSMP6, I think it is fine to use that. But if I manage to get in touch with Ian, I see no problem with adding it (the decoder is already there)

Thanks!

PS: I understand, but given how the two are almost the same (both use ogg vorbis)

As I said in the previous post this is not 100% true since SF2Pack is not restricted to ogg/vorbis compression but also supports lossless codecs like FLAC or WavPack.

BTW, here is an FSMP test version that already supports the 'DBNK' chunk for both reading and writing:
https://falcosoft.hu/midiplayer_65_test.zip

In Event Viewer/Debugger dialog's 'File menu -> Save File As' you should select 'Riff Midi + Embedded SF2' type. Then after you have set the rmidi file name it asks for a 'Destination bank for SF2 soundfont'. You can select a value between 0-127. If you press Cancel in this dialog the 'DBNK' chunk is NOT saved into the the rmi file else the given value is saved. Finally you have to select the soundfont to be embedded.

Falcosoft wrote on 2024-08-05, 00:12:

Thanks! […]
Show full quote

Spesek wrote on 2024-08-04, 23:06:

Hi, I implemented the specification described. The files are here: https://filetransfer.io/data-package/4q7wpCVl#link I've inclu […]
Show full quote

Falcosoft wrote on 2024-08-04, 21:05:

Hi,
I'm not talking about SF3 format but SF2Pack format. They are not compatible. E.g. the Soundfont chunk in case of SF3 format is still 'sfbk' but in case of SF2Pack chunk name is 'sfpk' not 'sfbk'.
Reality_GMGS_falcomod.sfogg is an example for SF2Pack format.

Hi,
I implemented the specification described.
The files are here:
https://filetransfer.io/data-package/4q7wpCVl#link
I've included multiple bank offsets, all generated with spessasynth. Also kanji encoding test and an xg file.
Source code for the RMIDI writing logic
Happy coding!

PS: I understand, but given how the two are almost the same (both use ogg vorbis) and sf3 is widely supported (think fluidsynth, polyphone, musescore) and is already supported by spessa and FSMP6, I think it is fine to use that. But if I manage to get in touch with Ian, I see no problem with adding it (the decoder is already there)

Thanks!

PS: I understand, but given how the two are almost the same (both use ogg vorbis)

As I said in the previous post this is not 100% true since SF2Pack is not restricted to ogg/vorbis compression but also supports lossless codecs like FLAC or WavPack.

BTW, here is an FSMP test version that already supports the 'DBNK' chunk for both reading and writing:
https://falcosoft.hu/midiplayer_65_test.zip

In Event Viewer/Debugger dialog's 'File menu -> Save File As' you should select 'Riff Midi + Embedded SF2' type. Then after you have set the rmidi file name it asks for a 'Destination bank for SF2 soundfont'. You can select a value between 0-127. If you press Cancel in this dialog the 'DBNK' chunk is NOT saved into the the rmi file else the given value is saved. Finally you have to select the soundfont to be embedded.

The attachment rmi1.png is no longer available

The attachment rmi2.png is no longer available

Hi again Falco,
I can't get the FSMP 6.5 to work.
The test zip you've provided only contains the executable. It said that the bass.dll is missing so i copied it from FSMP 6.4 there but it still doesn't work:

Let me know what should I do to make it work.

PS: I understand that SFPack is not restricted to ogg, but sf3 isn't either. But even then, it won't be as easy for me to implement other codecs:
The JavaScript problem
You see, normal executables such as BASS or fluidsynth can essentially tell the system to decode stuff for them. For example, fluidsynth calls "libsndfile" which uses the system's ogg vorbis decoder to decode the sample.
And it would be relatively easy to add support for other compression types. Unfortunately, it's not that easy for javascript, which spessa runs on.
This is the vorbis decoder for spessasynth. It is essentially C recompiled to javascript.
The encoder is even larger, weighing 1.5MB(!) which is very large for a minified text file. If I wanted to add another encoder or decoder, that means yet another huge file with the code.
There's also another concern:
The standard problem
The most supported sf standard is the stock sf2 standard. Then there's sf3, which is also supported by all major players (Fluid which means VLC, BASS which means FSMP6 and VirtualMIDISynth, musescore, timidity++)
These two standards have proper documentation. SF2 has the sfspec and SF3 has the wiki page on fluidsynth.

Then there are proprietary standards:
SynthFont's SoundFontKomPressd. Quote from the page:

This is the first program on the market that can use the new proprietary SoundFont format “SFKR” (“SoundFont KompRessd”) designed and developed by SynthFont in collaboration with GoldMidiSF2.

Sfpack. There's no specification and it's only supported by BASS. Looking at the standard, it seems that it's essentially SF3: compressed samples.
SF4: FLAC compression

What I'm trying to say is There are many non-standard soundfont standards, which effectively achieve exactly what SF3 does. Why not focus on the widely supported (and somewhat standardized) SF3 and expand upon it.
I'm not saying that SF2Pack is bad in any way, I just think it is a little unnecessary. I'll still add 'sfpk' as a valid soundfont chunk type in the spec if you want, though.

Relevant xkcd:

Wow, that was a long post scriptum.

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

Hi again Falco, I can't get the FSMP 6.5 to work. The test zip you've provided only contains the executable. It said that the ba […]
Show full quote

Falcosoft wrote on 2024-08-05, 00:12:

Thanks! […]
Show full quote

Spesek wrote on 2024-08-04, 23:06:

Hi, I implemented the specification described. The files are here: https://filetransfer.io/data-package/4q7wpCVl#link I've inclu […]
Show full quote

Hi,
I implemented the specification described.
The files are here:
https://filetransfer.io/data-package/4q7wpCVl#link
I've included multiple bank offsets, all generated with spessasynth. Also kanji encoding test and an xg file.
Source code for the RMIDI writing logic
Happy coding!

PS: I understand, but given how the two are almost the same (both use ogg vorbis) and sf3 is widely supported (think fluidsynth, polyphone, musescore) and is already supported by spessa and FSMP6, I think it is fine to use that. But if I manage to get in touch with Ian, I see no problem with adding it (the decoder is already there)

Thanks!

PS: I understand, but given how the two are almost the same (both use ogg vorbis)

As I said in the previous post this is not 100% true since SF2Pack is not restricted to ogg/vorbis compression but also supports lossless codecs like FLAC or WavPack.

BTW, here is an FSMP test version that already supports the 'DBNK' chunk for both reading and writing:
https://falcosoft.hu/midiplayer_65_test.zip

In Event Viewer/Debugger dialog's 'File menu -> Save File As' you should select 'Riff Midi + Embedded SF2' type. Then after you have set the rmidi file name it asks for a 'Destination bank for SF2 soundfont'. You can select a value between 0-127. If you press Cancel in this dialog the 'DBNK' chunk is NOT saved into the the rmi file else the given value is saved. Finally you have to select the soundfont to be embedded.

The attachment rmi1.png is no longer available

The attachment rmi2.png is no longer available

Hi again Falco,
I can't get the FSMP 6.5 to work.
The test zip you've provided only contains the executable. It said that the bass.dll is missing so i copied it from FSMP 6.4 there but it still doesn't work:

The attachment no_bass.png is no longer available

Let me know what should I do to make it work.

PS: I understand that SFPack is not restricted to ogg, but sf3 isn't either. But even then, it won't be as easy for me to implement other codecs:
The JavaScript problem
You see, normal executables such as BASS or fluidsynth can essentially tell the system to decode stuff for them. For example, fluidsynth calls "libsndfile" which uses the system's ogg vorbis decoder to decode the sample.
And it would be relatively easy to add support for other compression types. Unfortunately, it's not that easy for javascript, which spessa runs on.
This is the vorbis decoder for spessasynth. It is essentially C recompiled to javascript.
The encoder is even larger, weighing 1.5MB(!) which is very large for a minified text file. If I wanted to add another encoder or decoder, that means yet another huge file with the code.
There's also another concern:
The standard problem
The most supported sf standard is the stock sf2 standard. Then there's sf3, which is also supported by all major players (Fluid which means VLC, BASS which means FSMP6 and VirtualMIDISynth, musescore, timidity++)
These two standards have proper documentation. SF2 has the sfspec and SF3 has the wiki page on fluidsynth.

Then there are proprietary standards:
SynthFont's SoundFontKomPressd. Quote from the page:

This is the first program on the market that can use the new proprietary SoundFont format “SFKR” (“SoundFont KompRessd”) designed and developed by SynthFont in collaboration with GoldMidiSF2.

Sfpack. There's no specification and it's only supported by BASS. Looking at the standard, it seems that it's essentially SF3: compressed samples.
SF4: FLAC compression

What I'm trying to say is There are many non-standard soundfont standards, which effectively achieve exactly what SF3 does. Why not focus on the widely supported (and somewhat standardized) SF3 and expand upon it.
I'm not saying that SF2Pack is bad in any way, I just think it is a little unnecessary. I'll still add 'sfpk' as a valid soundfont chunk type in the spec if you want, though.

Relevant xkcd:

Wow, that was a long post scriptum.

Hi,
1. You should simply overwrite midiplayer.exe in the existing MidiPlayer6 folder with the new test exe file. But make sure that if you downloaded the 32-bit version of MidiPlayer 6.4 then copy the new executable from the x86 folder and if you downloaded the 64-bit version then copy the new exe from the x64 folder.
The error on your screenshot can be reproduced exactly if you use the exe with the wrong bitness 😀

2. OK, I have understood and I partly agree. I have just mentioned that 'sfpk' support exists in my code (that is the 1st implementation of the standard 😀 )

Falcosoft wrote on 2024-08-05, 13:45:

Hi, 1. You should simply overwrite midiplayer.exe in the existing MidiPlayer6 folder with the new test exe file. But make sure […]
Show full quote

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

Hi again Falco, I can't get the FSMP 6.5 to work. The test zip you've provided only contains the executable. It said that the ba […]
Show full quote

Falcosoft wrote on 2024-08-05, 00:12:

Thanks! […]
Show full quote

Thanks!

As I said in the previous post this is not 100% true since SF2Pack is not restricted to ogg/vorbis compression but also supports lossless codecs like FLAC or WavPack.

BTW, here is an FSMP test version that already supports the 'DBNK' chunk for both reading and writing:
https://falcosoft.hu/midiplayer_65_test.zip

In Event Viewer/Debugger dialog's 'File menu -> Save File As' you should select 'Riff Midi + Embedded SF2' type. Then after you have set the rmidi file name it asks for a 'Destination bank for SF2 soundfont'. You can select a value between 0-127. If you press Cancel in this dialog the 'DBNK' chunk is NOT saved into the the rmi file else the given value is saved. Finally you have to select the soundfont to be embedded.

The attachment rmi1.png is no longer available

The attachment rmi2.png is no longer available

Hi again Falco,
I can't get the FSMP 6.5 to work.
The test zip you've provided only contains the executable. It said that the bass.dll is missing so i copied it from FSMP 6.4 there but it still doesn't work:

The attachment no_bass.png is no longer available

Let me know what should I do to make it work.

PS: I understand that SFPack is not restricted to ogg, but sf3 isn't either. But even then, it won't be as easy for me to implement other codecs:
The JavaScript problem
You see, normal executables such as BASS or fluidsynth can essentially tell the system to decode stuff for them. For example, fluidsynth calls "libsndfile" which uses the system's ogg vorbis decoder to decode the sample.
And it would be relatively easy to add support for other compression types. Unfortunately, it's not that easy for javascript, which spessa runs on.
This is the vorbis decoder for spessasynth. It is essentially C recompiled to javascript.
The encoder is even larger, weighing 1.5MB(!) which is very large for a minified text file. If I wanted to add another encoder or decoder, that means yet another huge file with the code.
There's also another concern:
The standard problem
The most supported sf standard is the stock sf2 standard. Then there's sf3, which is also supported by all major players (Fluid which means VLC, BASS which means FSMP6 and VirtualMIDISynth, musescore, timidity++)
These two standards have proper documentation. SF2 has the sfspec and SF3 has the wiki page on fluidsynth.

Then there are proprietary standards:
SynthFont's SoundFontKomPressd. Quote from the page:

This is the first program on the market that can use the new proprietary SoundFont format “SFKR” (“SoundFont KompRessd”) designed and developed by SynthFont in collaboration with GoldMidiSF2.

Sfpack. There's no specification and it's only supported by BASS. Looking at the standard, it seems that it's essentially SF3: compressed samples.
SF4: FLAC compression

What I'm trying to say is There are many non-standard soundfont standards, which effectively achieve exactly what SF3 does. Why not focus on the widely supported (and somewhat standardized) SF3 and expand upon it.
I'm not saying that SF2Pack is bad in any way, I just think it is a little unnecessary. I'll still add 'sfpk' as a valid soundfont chunk type in the spec if you want, though.

Relevant xkcd:

Wow, that was a long post scriptum.

Hi,
1. You should simply overwrite midiplayer.exe in the existing MidiPlayer6 folder with the new test exe file. But make sure that if you downloaded the 32-bit version of MidiPlayer 6.4 then copy the new executable from the x86 folder and if you downloaded the 64-bit version then copy the new exe from the x64 folder.
The error on your screenshot can be reproduced exactly if you use the exe with the wrong bitness 😀

2. OK, I have understood and I partly agree. I have just mentioned that 'sfpk' support exists in my code (that is the 1st implementation of the standard 😀 )

Alright, that works! I've extracted the x64 version but the dlls were for x86. My bad 😀

Here are some of my tests:
The good
Works great! Bank 0, 1, 2 5 all work fine! Also an XG multi-drum midi with bank 0 works fine which is also great!
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.
Other than that small thing, it works great.

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.

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.

PS: I also have a feature request: can you allow me to go past channel 16 in the GUI for multi port midis? Currently it's not possible.

Edit (well, a new post since I can't edit.

The Riff chunks in the RMID exported by FSMP6 appear to have wrong size. I think the issue is that the pad byte is not taken into the size in the header. I'll update spec to make it clear.

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.

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

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.

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

Edit (well, a new post since I can't edit.

The Riff chunks in the RMID exported by FSMP6 appear to have wrong size. I think the issue is that the pad byte is not taken into the size in the header. I'll update spec to make it clear.

The attachment riff-error.png is no longer available

May I suggest not to use Linux tools for Microsoft specific formats (that are also defined by Microsoft) to check the format's validity?
FSMP does not use hand wtitten routines to make/edit Riff Midi files but uses the Win32 mmio functions that are targeted specifically for Riff format files. Thus the proper alignment is always assured by the functions and the file always saved according to RIFF file specification. Used functions:
mmioDescend()
mmioAscend()
mmioCreateChunk()
mmioWrite()
mmioOpen()
mmioClose()
https://learn.microsoft.com/en-us/windows/win … e-i-o-reference

Here is a Win32 Riff viewer utility that also uses Win32 mmio functions:

AFAIK, All information in a RIFF file must be word aligned. If a chunk has an odd number of bytes, then it will be padded. Although this padding byte should NOT be counted in the size of the chunk.

rmi+dls was always intended to supplement general midi, and not to provide all of the instruments unless they are all needed. it's expected that you only provide the ones that aren't already there.

The not overthinking does the right thing for converting a mid+sf2 pair, when the sf2 is a user bank.

But when using a main bank, the correct thing to do is to trim all unused instruments and samples from the file to save space.

Both approaches are valid in my opinion.