Author Topic: XMPlay MIDI plugin  (Read 640220 times)

Nukkels

  • Posts: 47
Re: XMPlay MIDI plugin
« Reply #1000 on: 1 May '21 - 06:15 »
I'm not sure how the soundfonts got removed initially, but it's most likely something I did. They seem to have stuck since I re-added them, so everything in XMPlay seems to be working as intended.

saga

  • Posts: 2526
Re: XMPlay MIDI plugin
« Reply #1001 on: 16 Aug '21 - 15:29 »
Quick question on the loopStart/loopEnd cue markers - as far as I'm aware those are not standardized, so I'm not exactly sure how loopEnd is defined - is the tick on which the loopEnd marker occurs inclusive or exclusive, i.e. should it be placed on the last tick to be played as part of the loop, or one tick after that?

Ian @ un4seen

  • Administrator
  • Posts: 23889
Re: XMPlay MIDI plugin
« Reply #1002 on: 16 Aug '21 - 17:20 »
The XMPlay MIDI plugin treats it as exclusive, ie. the end tick is not played.

saga

  • Posts: 2526
Re: XMPlay MIDI plugin
« Reply #1003 on: 24 Aug '21 - 22:39 »
Some non-standard updates have been made to the SF2 format by various tools to support compressed samples. I know there's already sf2pack, but that requires the entire sample stream to be compressed as one long sample, and this new "SF3" format has the advantage that samples are compressed individually, allowing for easier partial extraction. The changes to the format have been documented here: https://github.com/FluidSynth/fluidsynth/wiki/SoundFont3Format
In summary:
- ifil chunk major version bumped from 2 to 3
- Sample data chunk no longer padded to even size (including the LIST chunk it's contained in)
- Sample type 0x10 indicates a compressed sample
- Currently supported are Vorbis and FLAC samples (the latter obviously being more interesting).

Here's a tool that can write these files: https://github.com/KKQ-KKQ/sf2convert/releases/tag/v2.0.1
Note that there's also an "SF4" option in that tool, which is probably not too important and should be ignored. Initially SF3 only supported Vorbis, so someone went ahead and added FLAC support by bumping the major version to 4. Obviously that's not a very nice solution, so as documented on the FluidSynth wiki, it's preferable to use SF3 for FLAC samples instead.

Would it be possible to add support to xmp-midi (and BASSMIDI) for SF3? As BASSMIDI already supports arbitrary codecs through sf2pack, I suppose there's not much holding back this integration on the technical side.

Ian @ un4seen

  • Administrator
  • Posts: 23889
Re: XMPlay MIDI plugin
« Reply #1004 on: 25 Aug '21 - 15:20 »
There would be a few things to work out regarding decoder initialization but it seems like it should be possible. I'll look into it.

Ian @ un4seen

  • Administrator
  • Posts: 23889
Re: XMPlay MIDI plugin
« Reply #1005 on: 30 Aug '21 - 16:12 »
I started working on this but then I remembered that XMP-MIDI doesn't have access to XMPlay's Ogg Vorbis decoder. Unlike BASS, XMPlay doesn't currently have a centralised decoder system that plugins can use to access the decoders in XMPlay and other plugins, so XMP-MIDI instead has a hardcoded list of plugins (XMP-FLAC/WV/MPC/OPUS) that provide access to their decoders via a private extension to the XMPIN_GetInterface function. So XMP-MIDI would need to include its own Ogg Vorbis decoder, which isn't ideal and I'm not sure it's really worth adding that (and the other changes) for SF3 support. It looks like the sf2convert tool can be used to convert SF3 files back to SF2, so any such soundfonts could be used with XMPlay that way?

saga

  • Posts: 2526
Re: XMPlay MIDI plugin
« Reply #1006 on: 30 Aug '21 - 17:58 »
Personally I'd like to save some space and keep the larger soundfonts compressed as FLAC. They do add up quickly in size. :) I think FLAC is much more relevant here, so even though SF3 was initially Ogg only I'd be perfectly happy with an XMP-MIDI version that only supports FLAC.

Ian @ un4seen

  • Administrator
  • Posts: 23889
Re: XMPlay MIDI plugin
« Reply #1007 on: 31 Aug '21 - 17:30 »
Using SF2PACK instead will reduce the size even more :)

The only significant difference between SF3 and SF2PACK is that SF3 compresses the samples individually, while SF2PACK compresses them all as one. The advantage of compressing individually is that it technically permits mixing different compression (inc. no compression), which could be useful when using a lossy codec if it makes some samples sound bad, but that's not a concern when using a lossless codec like FLAC. The disadvantage of compressing individually is that each compressed sample will have its own headers, which means a larger end result. That's less of a disadvantage with FLAC than Ogg Vorbis (which has larger headers) but still some.

saga

  • Posts: 2526
Re: XMPlay MIDI plugin
« Reply #1008 on: 31 Aug '21 - 17:45 »
Well, in the interoperability is also an important point here, not just getting the file size down. :) SF2PACK mostly seems to be supported by BASS-based software, but I would like to be able to keep using those compressed soundfonts also in other softsynths that already support SF3. SFZ would be the only other option supported by all software that I want to use those soundfonts with, but it's a bit unwieldly for storing complete GM-compatible soundfonts.
I did in fact try to add SF2PACK support to OpenMPT a while ago, but the main challenge - not making the decoder always decompress the single, very large waveform but rather just small chunks required to extract a single region - turned out to be rather complex, considering that the FLAC decompression code in OpenMPT was never designed for this. SF3 on the other hand was very simple to implement, so in the end that's what I went with in OpenMPT.

Ian @ un4seen

  • Administrator
  • Posts: 23889
Re: XMPlay MIDI plugin
« Reply #1009 on: 1 Sep '21 - 17:40 »
OK, here's something for you to try:

   www.un4seen.com/stuff/xmp-midi.dll

It still only supports the codecs/plugins mentioned earlier (FLAC/WV/MPC/OPUS), so no Ogg Vorbis currently. Let me know if you encounter any other issues.

Regarding SF2PACK sample decoding, what XMP-MIDI/BASSMIDI does is initialize the required decoder once (with the file's "smpl" chunk content) and then use that for all decoding: loading a sample involves seeking to the sfSample dwStart position (eg. via FLAC__stream_decoder_seek_absolute in the case of FLAC) and decoding up to the dwEnd position. Unlike SF3, no changes are required to the sfSample values, so they are the same as in the original SF2 file.

saga

  • Posts: 2526
Re: XMPlay MIDI plugin
« Reply #1010 on: 1 Sep '21 - 18:15 »
Thanks, I've tested it a bit and it's working without any issues so far with my FLAC-based test SF3s. :) I guess the only obvious thing missing right now would to add the .sf3 extension to the file browser extensions.

Ian @ un4seen

  • Administrator
  • Posts: 23889
Re: XMPlay MIDI plugin
« Reply #1011 on: 2 Sep '21 - 13:00 »
Because Ogg Vorbis isn't currently supported, I thought it best not to add the SF3 extension to the soundfont file selector, to avoid confusion. It's just a secret bonus feature for now :)

saga

  • Posts: 2526
Re: XMPlay MIDI plugin
« Reply #1012 on: 2 Sep '21 - 21:45 »
Alright then. :) I'll report back if I see any issues coming up with the FLAC-based SF3s.