[vorbis] Ogg FLAC

[Kenneth Arnold]

On Tue, Oct 16, 2001 at 07:48:46PM -0600, Jack Moffitt wrote:
> > Just for the heck of it I have added an option to the
> > flac encoder to use ogg as the transport stream, based
> > on an earlier patch.  It basically just wraps a native
> > FLAC stream in ogg pages.
> 
> Is there two sets of transport information now? Or did flac not have the
> seeking/etc infrastructure?  Is there a case to be made for all flac
> files to be oggs ? :)

FLAC has a seeking system I believe.

> Yes.  People have been wanting lossless ogg for some time.
> 
> It will be even more useful when we have MNG (ie, lossless video) for
> storage of raw movies maybe.  Ralph?

I'm not Ralph of course, but I'll chime in anyway. First, why not add
a FLAC inporter to oggmerge? If FLAC were to start exporting Ogg
streams this would be much easier, but I don't recall FLAC's file
format being very complex anyway. But the major point I bring up is
that Ogg in its present state isn't really designed for storage -- if
you need to store video, you will want a good standardized metadata
format so you can know what it is ten years from now (I have been
assured that this is coming, but have seen absolutely nothing --
status?), and also an organized system for identifying clips that are
different parts of a larger work, and tagging segments of a clip and
giving them names. As I understand Quicktime has these (though I may
be wrong), and I'm not saying Ogg wouldn't work for these situations
(for metadata the comment header or some global header that will come
to replace it would do the job well, and you can just cat oggs
together to combine subparts, which is nice), just that it isn't
really designed for those things. Okay, so maybe what I'm trying to
say works better for editing raw video (which is what you'd probably
do with it once you store it anyway), in which case the editor should
be able to tag exact positions in clips to seek to, etc. -- no use
repeating it all here; the concerns are all brought up in the recent
Quicktime thread. For all that verbosity, my proposition is a simple
question: what is the mimimum set of changes needed to make a killer
editing format out of Ogg, and are those modifications small enough
that streaming-Ogg and editing-Ogg can be unified such that one is
just a special case of another? I think this is an important concern
that is best addressed early if Ogg is to take over the world, i.e. if
adding editing capabilities requires a minor change to the bitstream
format for the streaming case (which ideally would be a simple result
of an editor splicing parts together on the fly), it's better to do it
now while we're still not locked into a bitstream (neither RC1 or RC2
will play anything but degenerate streams anyway AFAIK).

> Actually it will currently break them all.  But this is a good thing.
> One more reason to fix that problem :)

Exactly the point I re-made above.

Apologies for being so verbose just for one simple concern; I can't
write concisely after 10:00p (and not at all after 11:00p).


-- 
Kenneth Arnold <ken at arnoldnet.net>
- "Know thyself."



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 190 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis/attachments/20011016/553a6ae8/part.obj