[vorbis-dev] Return of the Son of MIME type

[Ali Abdin]

* Maciej Stachowiak (mjs at eazel.com) wrote at 15:51 on 03/11/00:
> Ralph Giles <giles at ashlu.bc.ca> writes:
> 
> > 
> > Monty and I discussed this a bit today; I thought I'd post a progress
> > summary.
> > 
> > We've both found the arguments you (Maciej and Rakholh) have made
> > convincing, but it remains to develop a technical solution.
> 
> Excellent! I'm glad we could provide useful input on this issue.
> 
> > 
> > What's not clear is how to arrange for this to be efficiently testable. As
> > I said before, the only way I can see mime-magic working is to key on the
> > filename extension, or to guarantee that the first substream will be a
> > special-purpose, binary table effectively adding a header to the
> > headerless ogg. We're not really willing to do either of those.
> 
> Why is the second approach you mention a problem? You can always make
> some default assumptions if this initial stream is missing. While
> being headerless is a laudable goal, I am not sure how the metadata
> header you describe below is different. But I am not up on all the
> issues.
> 
> > That's about as far as we got. I've definitely added efficient
> > type-determination the the requirements for the metadata header, but
> > unless someone has a brilliant idea, a limited substring search will
> > probably be required. :-/
> 
> Substring search in a range, or unlimited substring search in the
> whole file? I think with a proper design for the metadata header will
> make it really easy to do efficient sniffing. A fixed offset is really
> best for overall efficiency.

An unlimited substring search would be rather inefficient, wouldn't it?
 
> > We still wish you wouldn't fork the mimetype, if only because we don't
> > know how we're going to do this yet. The only ogg files we're generating
> > now are "degenerate" in that they contain only a single vorbis substream.
> > However, since "efficient type determination" almost certainly means
> > putting the stream description metadata substrem (whew!) first, looking
> > for 'vorbis' at byte 29 like I initially suggested is probably not
> > the best idea. Associating application/x-ogg with the initial 'OggS', and
> > handing that to ogg123 by default strikes me as the most future-proof.
> 
> I'd agree that we should stick with "application/x-ogg" and "OggS" as
> the magic string for now. I will advocate this approach for the time
> being.

Right now, I temporarily "forked" the mime-type to use 'OggS' to map to
"audio/x-ogg" (this will just "identify" the file in Nautilus as an OGG file
(which is the description).

Nothing "depends" on this yet though (such as Music Preview, or 'View as
Music'). At this point in time I see no difference between "application/x-ogg"
and "audio/x-ogg" so I don't see a real incentive to change (especially since
you guys are working on this alternative stream description metadata substream).

I am now just putting in this "audio/x-ogg" in there and forgetting about it
;) I do intent to change it as soon as: A) a new Ogg codec is
developed/released or B) you get the 'stream description metadata substream'
done :)

Of course, I could switch it to "application/x-ogg" just for the sake of
changing, but I'd rather not

Regards,
Ali

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