[Flac-dev] Compressing sound fonts with FLAC

[Josh Green]

Josh Coalson wrote:

> yeah, flac doesn't have a 'gzip' fallback method
> so any non-audio data will probably get stored
> verbatim.  I'm kind of reluctant to add a generic
> compressor.  If you wan't, you could come up with a
> FLAC metadata block to store a gzip'ed chunk and I
> could add that to the format.
> 

I had the same thought when I was looking over the FLAC format and saw
the META data stuff. Is there anything that needs to be added in order
to take advantage of this? Why not just a binary META data block that
has some sort of identifier (a string maybe). That would allow arbitrary
data to be stored.
My other option (which I was originally thinking of) would be to use
FLAC on the audio stuff, and zlib for the non-audio data, then just
write my own custom format file which would basically just have a simple
header and the two compressed blocks appended onto it.
I'm not sure what would make the most sense. Should FLAC try to
encorporate compression of sound fonts? This might not be that hard
actually. If it had the capability of concatenating gzip/bzip compressed
blocks with FLAC compressed blocks it would not really need to know too
much of the internals of a sound font (nothing on the decoding side),
just where the sample data begins and ends and I guess perhaps on a per
sample basis when variable block length compression is available.
iirc FLAC treats WAV files specially, and doesn't store some types of
WAV information blocks. If arbitrary gzip/bzip compressed blocks could
be inserted into the stream then any portion of a WAV file that isn't
audio could be retained. Does this fit into FLAC's purpose?

> >
> the best thing would be to try and set the blocksize
> to match the length of the individual 'sample'.  if
> each sample is much shorter than the blocksize then
> the encoder may not be able to generate an efficient
> model of the signal.  if the samples within the
> soundfont vary greatly in length that also makes
> it harder because right now flac only supports a
> fixed blocksize (even though the format allows for a
> varying blocksize).
> 

I noticed that the max block size is 65535. Sample sizes in sound fonts
can be of fairly arbitrary length (32 bit length), and many would exceed
64k, although many would be much smaller too. So breaking them into
smaller blocks would be necessary for many samples. I guess varying
blocksize compression is really what would be the best. Any ideas of
when this might be available? Compression is good as things stand now,
although not optimal. I compressed a 118MB sound font to 64MB with FLAC
which was only 3MB difference to sfArk (only 170k of this is non-audio
data which would be more significant with smaller sound fonts). Lates..
	Josh Green