sfArk support

[tresf]

There seems to be a popular variant of SF2 called sfArk. The source code seems to be open and relatively small in size. Could we consider patching this into our SF2 plugin so that our users have a higher compatibility rate with soundfonts they download on the internet?

The site says free for non-commercial use, but that clearly applies to the binary version as the GPL license does not restrict commercial use.

https://github.com/raboof/sfArkLib

Related:

https://github.com/raboof/sfarkxtc

[unfa]

I wonder if this is based upon FLAC? Anyway - I never heard if that, but I never used Soundfonts much.

[tresf]

It appears to be ZLIB. P.S. the author of this sfArkLib code is @raboof (#954) :smiling_imp:

[diizy]

On 10/23/2014 03:27 PM, Tres Finocchiaro wrote:

There seems to be a popular variant of |SF2| called |sfArk|. The source code seems to be open and relatively small in size. Could we consider patching this into our |SF2| support so that our users have a higher compatiblity rate with soundfonts they download on the internet?

http://linuxmusicians.com/viewtopic.php?f=24&t=9854

Some words about the sfArk format. It really is awful, and needs to be removed from the universe. First, it breaks up a soundfont into its non-audio data, and audio data. The non-audio data is zip compressed. The audio data is compressed using one of several 16-bit delta compression schemes, depending upon which "compression level" the musician chose when he created his sfark using Melody Machine's atrocious windows utility. At the highest compression level (which is the utility's default setting, so most sfark files use it) the totally archiac LPC compression is added (in addition to the delta compression). The inept scheme this guy came up with uses integer to float conversion, float calculations, and convert float back to int. Hello, can you say "rounding errors"?? And then this bozo actually does a checksum based on those rounding errors. In effect, those errors are in the sfark file itself. Here's the horrible implication: if you don't perform the exact same rounding errors when you extract the soundfont from the sfark, THEN THE SOUNDFONT WILL BE CORRUPT. And what are the details of those rounding errors? That bozo compiled his software specifically to run on the old 80387 math coprocessor for Intel's ancient 80386 CPU (before the Pentium even). If you don't use the 80387 float format with its internal 20-bit precision, then you won't get the same rounding errors when you extract the soundfont from the sfark, AND THE SOUNDFONT WILL BE CORRUPT. If you compile my utility to use your Intel Core2 or i7's modern, fast SSE instructions, or AMD's 3dnow, etc, THEN THE SOUNDFONT WILL BE CORRUPT. Fortunately, the gnu C compiler has an option (-mfpmath=387) that says "Don't use newer floating point instructions. If the CPU supports old 80387 instructions (and the current Intel CPUs still do), use those. If the CPU doesn't, compile an entire 80387 software emulation into this program". Now I don't how well, or even if, gnu's emulation works on CPUs other than intel/AMD. For example, if it doesn't work on ARM, then if you compile my utility on an ARM CPU, it will not produce an error-free soundfont. (It will actually produce a legitimate soundfont file, despite reporting a checksum error. But the soundfont's waveforms will not be identical to the original. The sound will be altered). This is because the sfark format is technically flawed. It was written by a programmer who didn't know what he was doing, and didn't know that one doesn't use floating point calcs, with int conversions, in a supposedly lossless format. That's inept. Oh yeah, after the zip, delta, and LPC compression schemes are applied, then the resulting mess is run through a bit-packing compression scheme, a checksum is calculated and stored in a truly dreadful 300 byte header that is slapped onto the start of the sfark file. Atrocious.

And that's why sfark must be removed from the universe.

[diizy]

On 10/23/2014 03:32 PM, Tres Finocchiaro wrote:

It appears to be ZLIB. P.S. the author of this sfArk code is @raboof https://github.com/raboof (#954 https://github.com/LMMS/lmms/issues/954) :smiling_imp:

Nope, he just developed/helped release the open-sourced unpacking utility for sfArk files, but is not the original developer of the sfArk format.

Besides, IIRC raboof's utility is GPL3 so we can't use it in LMMS.

I think sfArk is fairly pointless at this point. The only use for it is decompressing legacy sfArk files, and even then, I've had mixed success

• seems to me 50% of all sfArk files just inexplicably corrupt or refuse to unpack.

[tresf]

seems to me 50% of all sfArk files just inexplicably corrupt or refuse to unpack.

Good to know.

I think sfArk is fairly pointless at this point. The only use for it is decompressing legacy sfArk files, and even then, I've had mixed success

Until the sites that host these sfArk files (and there are many) take the time to decompress, our users will be faced with this problem.

IIRC raboof's utility is GPL3 so we can't use it in LMMS.

Unless he's the sole author and allows other licensing options.

P.S. the author of this sfArk code is @raboof

Nope, he just developed/helped release the open-sourced unpacking utility for sfArk files

I had edited that statement in GitHub to say sfArkLib immediately after typing it... :speak_no_evil: The pros/cons of a bugtracker with email reply support built-in. :smile_cat:

-Tres

[raboof]

P.S. the author of this sfArkLib code is @raboof (#954) :smiling_imp:

In fact even the sfArkLib code was originally written by Andy Inman, the original format designer.

http://linuxmusicians.com/viewtopic.php?f=24&t=9854

AFAICS that rant is almost entirely inaccurate. It appears j_e_f_f_g took the old MelodyMachine Windows binary, decompiled it, and drew all kinds of crazy conclusions from that.

sfArkLib is entirely different: it is based on some original MelodyMachine source code generously open-sourced by Andy (MelodyMachine is just his domain, not a company). It needed a some tweaking to work reliably on modern compilers/machines (and some code had been lost to history), but nothing too major. I do have a report that it doesn't always work correctly when compiled on Windows, but haven't been able to reproduce that. Help welcome :).

Besides, IIRC raboof's utility is GPL3 so we can't use it in LMMS

We could ask Andy if he'd be OK with GPLv2 - I certainly would have no problems supporting that and we're the only 2 contributors.

I think sfArk is fairly pointless at this point. The only use for it is decompressing legacy sfArk files

I tend to agree. The sfArk format is no longer useful itself, and sfarkxtc can be used to convert legacy files. It might be nice to support it directly from LMMS, but I wouldn't place it high on the priority list if I were you.

50% of all sfArk files just inexplicably corrupt or refuse to unpack.

There is a difference between 'sfArk v1' and 'sfArk v2'. The former is not supported (and should generate a proper error message). The latter should basically work. If you have some examples I'd be happy to see if they're really corrupt, or that it's something that can be fixed in sfArkLib.

[zonkmachine]

+1 on exstracting sfArk in lmms. The files are out there and people have asked for the functionality.

The sfArk format is no longer useful itself, and sfarkxtc can be used to convert legacy files.

sfarkxtc is in Ubuntu from 16.04

In the program Polyphone there is sfArk extraction support. It is GPL3 and it looks like it supports both sfArk v1 and v2. It also converts some other file formats to sf2, like sfz, but it doesn't look like it's in any repository. https://github.com/davy7125/polyphone/tree/master/trunk/sfark

Edit: Added link to Polyphone sfark utility