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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.