[Flac-dev] FREEFORM metadata (was: Compressing sound fonts with FLAC)

[Josh Green]

Josh Coalson wrote:
> I've been thinking about this, and here's what I
> came up with.  This kind of dovetails into the
> discussion Mike Wren started about the etree
> header.
> 
> I was thinking about defining a FREEFORM metadata
> block which may be of arbitrary size.  The only
> mandatory field would be a (say, 32-bit) id of
> the owner.  In your case, you would request an
> id, then I would register you as the owner, then
> you could write as many FREEFORM blocks with your
> id as you wanted and the contents would be up to
> you.  The same could be done for the etree header.
> 
> Then I would have a registration section on the
> FLAC site with optional links to registered owners
> (for instance it could link to your page where you
> define the format of you block) and a registration
> form.  Each owner would maintain their own block
> type and applications could support any they knew
> about and ignore the rest.
> 
> What do you guys think?
> 

Sounds fine to me. I guess this would rely on an external program to
extract the special header data from the FLAC file?
I didn't quite get the answer to my question concerning whether the
design of the FLAC standard should directly support inserting arbitrary
data blocks which would be re-assembled with standard audio blocks on
extract, or should FLAC leave this up to other programs?
Adding zlib (bzlib too) support to FLAC and allowing for traditionally
compressed blocks to be re-assembled when the file is extracted, would
allow direct support of probably a lot of file formats that contain
audio, but also contain other fluff. Only the compressor would need to
know something about those special formats, and the files would stay
under the domain of FLAC. Lates..
	Josh Green