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

[Josh Coalson]

> > 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.

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?

Josh


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/