[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Supported Wave/Flac format other than SF2

From: Element Green
Subject: Re: [fluid-dev] Supported Wave/Flac format other than SF2
Date: Thu, 5 Feb 2015 08:39:28 -0700

Hello list,

Seems like an unnecessarily heated debate, however, I'll chime in on a few points.

On Thu, Feb 5, 2015 at 2:15 AM, BCA @ Free-Artists <address@hidden> wrote:
In certain points, I don't understand the initial posting. One thing is clear to me - he doesn't want to construct a soundfonts ("Going by SF2 is going to be hard for developer to implement new soundfont"). It appears he wants just to import sample files on button press, and start playing them. That means for FS, the sample player shall construct the soundfonts.

E. g., I'm not quite sure why *wave* support shall be added to FluidSynth. SF2 is based on wave data files. Nowadays, we're able to import 24bit wave samples into the soundfonts, so the sound quality as such cannot be the reason for that request. So that is an obvious misinterpretation.

I can understand the request for flac format, since it is lossless (compared with wave), and saves about the half of hard disk space. It might even be, once in future, FLAC will replace wave (if the CD industry allows for this ;-).

FluidSynth is soundfonts player only, so in regards of FS, a request can be only, to enable soundfonts contruction from native flac sample files (IIRC Swami has planned so for future). FluidSynth as such could be made fit for reading such soundfonts, indeed. But in that case, it would be at least frome equivalent interest (in my eyes), to support soundfonts files based on Ogg Vorbis or a similar HQ compression format. This would be a real improvement, since the soundfonts could be reduced impressively in file size, while keeping HQ sound.

I've brought up the subject before of adding support for libInstPatch, which is an instrument loading/saving/editing library that is at the heart of Swami.  Swami itself, utilizes FluidSynth to load formats supported by libInstPatch (currently SoundFont of course, including 24 bit, SLI, and to a limited extent DLS and Gigasampler).  Such a library would be perfect for adding additional formats such as SFZ and other applications which use libInstPatch could then benefit as well from this support.

Such support would be optional, so that FluidSynth wouldn't have to depend on libInstPatch, but could utilize it for additional formats.

David, does FS support playing soundfonts in a bit-ness higher than 16-bit? Another question in regards of FS, would be support for up to 96-bit soundfonts.

No, FluidSynth does not currently support anything above 16 bit.  This has also been discussed in the past.  The plan is to update FluidSynth's SoundFont API to handle 32 bit integer or floating point audio.  Thoughts have been kicked around too about having streaming based samples, where the application utilizing FluidSynth could provide a callback for reading the sample data, so that it does not need to be stored entirely in memory.  SoundFont uses a 32 bit integer for the sample rate of samples, so there is no practical limit to the sample rate, its just a matter of whether the target hardware supports it or not.  SoundFont files are limited to 4GB in total size as well, due to the underlying use of RIFF.

I've never seen any soundfonts where the constructor has has fully reached the sf2 format's potential, and my point of view is that soundfonts are future safe.

Its a fairly good format in my opinion as well and though perhaps outdated compared to some newer formats, it is open and describes a fairly flexible synthesis architecture without getting too complicated.  DLS had a chance to be better than SoundFont, but they chose to keep the specification something which had to be purchased, which detracted from the open nature of it.  It also didn't go that far above and beyond what SoundFont files can already do.


My 2 cents, you probably wont get more from me on this thread ;-)


Element Green

reply via email to

[Prev in Thread] Current Thread [Next in Thread]