[Flac-dev] FlacPak

[Josh Green]

On Mon, 2003-11-17 at 11:04, Josh Coalson wrote:
> could you clarify your plan... are you thinking about
> 1) encoding to a FLAC container and using metadata blocks
>    for everything that is not data?
> 2) writing your own container?
> 
> 1) seems kind of impractical to do in a general way.
> 

I'm starting to also think that 2) is the best route. I was originally
thinking that it would be nice to just have it look like a flac file, so
some extraction of audio could be done treating it generically, but I
realize that this isn't very useful to begin with (one would end up with
a chunk of sample audio, but no way to extract individual samples
without understanding the meta data chunk). There is also some little
hacks that would need to be done to compress the binary data into
multiple meta data chunks when it exceeds 16MB (probably not a likely
situation though, in the case of instrument banks).

> if you're talking about 2) then:
> you can't change encoding params on the fly (yet) but in this
> case I would advise against it even if you could, because you
> are storing to your own container, and each clip may not even
> be contiguous.  better to use a fresh stream encoder for
> each clip.  your decoder will be aware of the boundaries
> somehow and use fresh stream decoders for each clip.  (I'd
> advise against re-using the same stream decoder for the same
> reason).
> 

My previous thinking was of storing all the audio data together (so it
would be made contiguous). But with the thought of using my own
container, the encoded audio could in fact be stored serially with
individual compressed binary chunks. I should probably do a comparison
of header overhead between the two methods (its likely there isn't any
difference, or very minimal). In the case of split stereo sample data
one channel would still need to be relocated to another position in the
file, but I like the idea of most of the data being in sequential order.

Some of the samples might be quite small (like under 1k), from the
format it appears that there is only about 8 or so bytes overhead for a
single frame and sub frame header so I suppose there probably isn't
really an issue with the frame size becoming a significant overhead, but
I'm curious if combining small samples would make sense in that case.
Likely its more trouble than its worth.

> also, if using your own container, you don't really need the
> STREAMINFO block, might as well just throw away all metadata
> when encoding.
> 

Looking at the API, would the stream encoder/decoder be the option to
use for this? Or is there a more appropriate interface? Using that
interface I suppose I could ignore the "fLaC" signature (at least for
each sample) in the write callback, and I guess I would also need to
ignore the STREAMINFO meta data block as well. Will the stream
encoder/decoder still work in this regard? (The format specification
says that the STREAMINFO block is mandatory, but is that the case with
using the decoder as well?) I suppose it may also be necessary to have
the "read" callback in the stream decoder forge a fLaC signature and
STREAMINFO meta data block, but that seems a little hackish, but will do
this if necessary.

> Josh
> 

Thanks a lot for the information, I'm excited about working on this
project again. I'd like to try and make a campaign out of it, make a
nice logo and little banner icons that people can put on web sites and
the like. Its about time proprietary formats cease to be used for
instrument compression (especially those that don't write clients for
other operating systems). Even windows users have experienced this with
sfpack, since they recently stopped supporting it. Nothing more annoying
then downloading a zip or rar instrument file only to find it has also
been compressed with sfark or sfpack. I guess the sfark people deserve
some credit, they have at least been promising a Linux client for a few
years now (still no sign of it though).
I was thinking of making FlacPak associated with flac (seems appropriate
since flac will be the primary technology used in the format), so I was
wondering about basing the FlacPak logo on the one found on the flac web
site (with the green/yellow/red level meter bars). How do you feel about
this? Any graphics I come up with in this regard I would certainly clear
with you before using it. Thanks again.
	Josh Green