[Flac-dev] FlacPak

Josh Green jgreen at users.sourceforge.net
Sat Nov 15 18:07:04 PST 2003


I posted to this list a couple years back and then again sometime a year
ago about using Flac to compress SoundFont instrument files. I never got
around to finalizing the specification for that project, and I have
since realized that a more generic approach would be better. I
registered the "SFFL" Sound Font FLAC application meta data ID. I would
like to remove that, since it was never actually used, and create a new
one "FLPK" FlacPak.
This format will be a generic way to compress files containing audio and
binary data (files will be viewed as simply interleaved chunks of audio
and non-audio data with some extensions such as interleaved and
non-interleaved stereo streams, differing bit widths, etc). I will be
using this primarily for instrument patch formats (such as SoundFont,
DLS2, GigaSampler, etc), but it could be extended to other binary/audio
formats as well. The encoder for FlacPak will have knowledge of the
format it is compressing, the decoder on the other hand will be generic
and simply re-compose the file using a table to re-interleave the blocks
of audio and non audio data. Essentially all non-audio data will be
concatenated and compressed along with a relocation table in the
application meta data chunk (or perhaps multiple meta data chunks if it
exceeds 16MB meta data limit).
The audio data will be encoded with FLAC and thats where I have some
questions. My current thinking is to combine audio of the same type
together to minimize changing of parameters in the FLAC stream. Same
sample type being data that has the same number of channels and bit
width. There will also be cases where a pair of mono samples (in
separate locations in the original file) could be encoded as stereo
audio (and re-split on decode).

Last I posted to this list, there wasn't a way to change encoding
parameters on the fly with the current FLAC API, is this still the case?
If it is, would it be possible to add multiple separate (serial) streams
in the same file? In other words, if the current API doesn't allow
changing parameters on the fly, could the FLAC encoder instance be
closed and then re-opened with different parameters and the decoding
side still work?

Another question I have is about sample rate. Does this affect the
encoding/decoding process at all or is it mainly informational for
playback purposes? The samples in an instrument patch often differ in
sample rate.

I'm excited about finalizing this specification, since there is a real
need for an open standard for instrument patch compression (there are
already several proprietary formats out there that are a pain when it
comes to other operating systems, businesses going bankrupt, etc). Any
help anyone can give me would be greatly appreciated. Cheers!
	Josh Green





More information about the Flac-dev mailing list