[vorbis] Ogg FLAC
rillian at telus.net
Tue Oct 16 21:15:24 PDT 2001
On Tuesday, October 16, 2001, at 07:25 , Kenneth Arnold wrote:
> 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.
Whew! Learn to use paragraphs.
I'm not sure metadata is *required*...generally the vorbiscomment-level
stuff ought to be good enough for figuring out what it is. That said, no
one's stopping you from writing a proposal? "We use musicbrainz
RDF-over-XML" is the default.
> 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).
Well, I think it's too late to change the bitstream format itself, and
as was pointed out on the quicktime thread, ogg isn't very strong in
I happen to think this is fine, and the answer to your question is
'none'. Ogg is very good at what it was designed to do, which is to be a
transport stream. And we do have some wiggle room in terms of what we do
But really, I think non-linear stuff belongs at a level above ogg. Monty
once stated that nonlinear/interactive support was a pillar of the Ogg
design, but it seems to have worked out so that that's hard to support.
I do think it's worth making ogg a useful *source* format so it can be
used for keeping clips around, but I favor using a directory full of
such files and a separate index over trying to pack everything into one
The chaining mechanism is more or less why. It's really a brilliant
idea, and makes life very simple for an editor. As long as we keep
sample-accurate editing, which vorbis has, and of course any lossless
format can provide, an editor can easily cut ogg streams as needed, and
generate new ogg streams by cutting together sections of others
according to an edit list. But by that same token, it doesn't make sense
to multiplex the edit list itself in with *one* of those clips.
And it's the innate clip-level support that's made me wary of
implementing nonlinear/interactive features. There's no reason you
provide dvd-like menus or the like. But being able to refer to other
sections of the chained bitstream breaks the simple concat/cut-here
model. By the same token, I support alpha-composited (oops, that's
apparently patented now) overlays for our video format, but think
programmed transitions between tracks (which quicktime supports) don't
make sense for us.
Anyway, that's an attempt to articulation my vision. I don't think we've
missed the boat at all. We just need to write software. :)
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Vorbis