[vorbis-dev] ogg stream-id options

[Ali Abdin]

On Sun, 19 Nov 2000, Ralph Giles wrote:

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

Its Scrollkeeper (scrollkeeper.sourceforge.net) - Basically it is a 
project for all doc projects (GNOME, KDE, LDP, FreeBSD, etc.) that will 
implement a few scripts and possibly a library to index metadata (OMF 
files) of docs. 
 
> 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. :-)

I guess the bit count is not a really good argument (although it is just 
"one point" against using XML). I really do like XML, but isn't it easier 
to parse 'Title=Foo' instead of '<title>Foo</title>' - I mean what 
advantages do you get from using XML? (besides being buzzword-compliant 
;) Also what about "binary data" in the TOC (somebody mentioned for 
example that Real JukeBox has the ability to embed images in an MP3 file 
header (or something like that)). It is an interesting idea (attaching a 
still image for the artist name for example) - although if that 
capability is not there, I think people can live without it ;)

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