[vorbis-dev] ogg stream-id options

[Ralph Giles]

On Sat 18 Nov 2000, Michael Smith wrote:

> Yes. I think bits of Dublin Core have been considered, but much of it is
> inappopriate (which isn't a problem. Using the bits which are appropriate
> is fine given the way DC is designed, I think).

Certainly. One of the ideas with Dublin Core is that you can "dumb down"
your metadata format so that foreign parsers can get useful information out
even if they can't tell the difference between a lead guitarist and a 
guest soloist.

Rakholh: what's the other project? (just curious)

If we don't end up using one of the recommended (xml) encodings I then
we really just need to insure a bijective mapping to the dc element set,
since foreign parsers won't be able to get at the data anyway. For example,
the canonical tags for the Vorbis comment header mostly aren't dc, but
there are clear correspondences: artist->creator, organization->publisher,
copyright->rights.

> The size difference is basically irrelevent. Compared to the size of the
> actual data, even 'bloated' metadata will be tiny.

And if every bit *does* count, we can run the stream through gz/bz2 and
remove any difference. :-)

> It doesn't really help you much with getting details out for complex stream
> types (since there can be an arbitrary number of streams, identifiers
> obviously CAN'T be at a fixed offset for all of them. It could use a simple
> table (at a fixed offset) of 'pointers' into the data - you'd always need
> to check each of them, that's unavoidable, but this would make it possible
> to do it quickly and simply).

I think we're talking about general usage classes here, not detailed
capability determination, which could just be the first entry.

Technically the offset+<value at other offset> method is required for
degenerate streams as well, unless you can make an assumption as to
how many lacing values the head packet requires.

We can't really do that with an xml-based toc. There could be arb.
whitespace and other tags in from the the <usage> so you really have
to search. OTOH, if we do go the binary or text-vector routes, I think
it's only fair to support magic detection at a specific offset in the 
first packet. (my last example does this)

To the nautilus people: how hard is it to do 'if (first magic) { more magic }'
tests? Are you really looking just for magic+offset entries you can stick in
a table, or do you support hierarchic determination in some form?

In another message, Monty wrote:

> No. The metaheader is meant to be something *much* simpler. No XML
> there (and I say this because I don't want a full blown XML parser,
> again, just to figure out what to do with a stream. XML is alot of
> weight). It's to be a single page with very basic arrangement
> information.

Ah, I had misunderstood your position.

> Except I want something simpler than what you propose. Perhaps
> something more complex than what I'm thinking of now will become
> necessary (actually I expect that to be the case). This is meant to
> be information for applications to use, not as much humans.

Simpler than the XML/RDF/DC proposal, or simpler than the text-vector
toc format I suggested in the last message? I don't see any way to
simplify the second and still support any DVD-like features. And if
not that, what do we need it for?

To be fair, I don't think RDF is especially human-intended either. :)

Cheers,
 -ralph


--
giles at ashlu.bc.ca

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