And now that that is over and done, and for anybody that might find it interesting, here are a few actual
facts...
* The original version of sfArk was available in 1997 and generally released in 1998. It was intended as a fairly quick fix for a significant problem - large audio files and slow internet connections.
* Use of LSPACK was only in sfArk 1.x (1998) and dropped in 2.x (2001) specifically because LSPACK was only available for Windows. LSPACK was a commercially available ZLIB-style library. ZLIB itself was not in such wide use at that time either, but of course became something of a standard later, so switching to ZLIB for sfArk 2.x was a sensible move.
* The decision to use Intel floating point maths was reasonable at the time, based on the fact that even in 2001 SoundFonts were used almost exclusively on Intel/Windows. Their migration to Mac came later, and Linux later still. Nonetheless, there is no insurmountable problem with this approach, just additional complexity.
* "rounding errors" are
not present "in" the sfArk file. All the floating point calculations done by sfArk relate to making a
prediction of future values, which by definition, is
always "wrong" (it would still be
"wrong" even if integer calculations were used). However, the fact that different architectures do floating point maths differently is a complication, meaning that care is needed when coding a compatible decompresser. Now with the benefit of 20/20 hindsight it would probably have been a good idea to develop integer versions of the relevant algorithms, scaling up intermediate values to avoid loss of precision, especially now that 64-bit machines are available. In fact, sfArk 3 (never released) did just that - it used improved prediction algorithms (faster and more accurate) and pure integer calculations.
* The sfArk compression algorithm, even when floating-point calculations are used
is lossless - all relevant information needed to regenerate the original data is included in the output .sfArk file. If your decompression program doesn't decode it properly, then that's because of bugs or limitations in your decompression program (or possibly an unreported bug in the original sfArk compression program). If you have a .sfArk file that decompresses properly under sfArk for Windows but not with some third-party decompression program then clearly that third party program is not properly replicating the behaviour of the original sfArk utility. QED.
* sfArk was not "written by a programmer who didn't know what he was doing". Oh wait, I'm not sure about that one
But seriously, it was just a tool to do a job, one that was state-of-the-art at its time and the result of a lot of original research. Newer developments such as Monkey's Audio and more recent versions of FLAC can produce better results, but only by a small margin. Josh Green, who wrote FLAC said back in 2003 "I'd love to beat sfArk" -
http://lists.xiph.org/pipermail/flac-de ... 01463.html . A while ago (March 2011) I asked Josh if he would like take on support for sfArk decompression in FLAC, but he was too busy.
* A short while ago (and prior to having found this thread here) I posted a comment at
https://aur.archlinux.org/packages/sfarkxtc/ asking for anybody interested in maintaining sfArk support under Linux to get in touch. That offer is still very much open (a couple of people have expressed an interest so far.) Anybody here interested, who has both the programming skills AND adequate emotional intelligence (hint) please PM me.