[vorbis-dev] MIME types registration

[Ralph Giles]

On Thursday, May 10, 2001, at 03:43 , Linus Walleij wrote:

> A discussion concerned wether audio/ogg or application/ogg should be
> registered, I will most definately register audio/ogg for Ogg Vorbis, 
> and
> in the future video/ogg may be registered for Tarkin files.

Hmm. Which list are you referring to? The 'which supertype?' question is 
a subject of recurring flame wars on this one. :)

> The audio/ogg RFC I imagine will look something like the audio/mpeg RFC
> ftp://ftp.isi.edu/in-notes/rfc3003.txt except that it will be for ogg :)

That looks like a good approach to take. We hadn't applied previously in 
part because of the standards-documentation requirement, and we're not 
ready to describe vorbis packets formally yet anyway. However, the ogg 
bitstream format itself has been stable for some time and the 
documentation in cvs could probably be turned into a reasonable rfc if 
there was a need.

The real problem is that ogg is a container format. MIME doesn't really 
deal with that, hence our original choice of application/(x-)ogg. A file 
could easily contain no audio, or audio is some format other than 
vorbis. Much lobbying from application developers has convinced us to do 
some kind of audio- or video-specific subtyping, but we haven't worked 
out how we want to do that yet. The standing recommendation is just to 
use 'application/x-ogg' for .ogg and the initial 'OggS' and wait until 
we have more codecs to experiment with before worrying about the audio/ 
or video/ mimetypes.

If you're set on implementing audio/ogg, I'd at least urge audio/vorbis 
or audio/ogg-vorbis as a more future-proof alternative.

To recap, users often want to treat 'audio' and 'video' files 
differently, giving them distinct icons and playing them with different 
applications. To usefully distinguish, we need, as you mention, some 
type of 'magic number' detection. The best suggestion that's been put 
forward for this is to specify that primarily-audio (ogg vorbis) files 
must put the the vorbis header page first, optionally followed by the 
headers for any additional metadata. In contrast, primarily-video files 
would begin with the tarkin header page, followed by the vorbis header 
page, and so on. By specifying the primary media subtype first, we can 
reliably find the packet magic at a particular offset. In the case of 
vorbis, it's the string 'vorbis' starting a byte 29. (well, assuming the 
first page continues to hold one short header packet...that would have 
to become spec too.)

An alternate suggestion is to have some sort of 'table of contents' 
metadata with a 'primary use' flag in it, and require that *that* be 
first. We need something like this anyway to implement the 
alternate-track and overlay features familiar from dvd. But to depend on 
it for magic detection leaves the problem of identifying all the 
'degerate' vorbis streams created with existing encoders without 
additional metadata streams.

FWIW,
  -ralph

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