[vorbis] Ogg FLAC

[rillian]

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

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

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

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 
couldn't include javascript or flash or whatever in an ogg substream to 
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. :)

  -r

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