Re(2): [vorbis-dev] Mime Type and Ogg (More)

[Maciej Stachowiak]

Hi,

I don't really know the details of the discussion, but I'd like to
present this issue from a user-oriented perspective, and from the
perspective of how Nautilus wants to use data files.

In brief, Nautilus makes the assumption that the mime type is
sufficient to pick the right applicatiob or pluggable component to
view/edit a particular content type. This is quickly coming to be the
standard on modern file managers on various operating systems. While
it might be nice to pick the app based on some more detailed
conception of file type, there's nothing else that is equally standard
or universally deployed. If you can't use the mime type to distinguish
ogg audio from ogg video, what can you use? Are applications supposed
to register for what data they can handle using a test function in a
turing-complete language, rather than a simple mime string? Should we
define some form of type identifier other than mime type that provides
more detail? Both of these seem like not so great options. MIME is not
so great but it's the only standard we have.

You could argue that ogg apps should be universal and handle all types
of ogg data. But when it comes to multimedia, it's pretty clear that
users _don't_ want to use the same application for video and audio,
regardless of the underlying data stream format. I think very few
people use xanim to play MPEG audio, and equally few people use xmms
to play MPEG video, despite the fact that the underlying data format
is fundamentally the same. And indeed, we see distinct mime types for
audio/mpag and video/mpeg, and distinct file extensions.

To draw another analogy that is somewhat further afield, XML is
another data format that has many semantically different uses. For
example, there is XHTML (a presentation-oriented web document markup
language), SVG (a vector graphics format), DocBook/XML (a semantic
markup language for documentation) and so on. While it might be
logically correct to give all these documents an extension of .xml,
and a mime type of text/xml, that is not done in practice. All three
formats have their own mime type and their own extension.

So in conclusion, let's not let the fact that ogg is an amazingly
flexible file format lead us astray. In the end, files have to be
identifiable in ways that are semantically meaningful to the user,
because higher level applications will have to know how to help the
user use those files with the most appropriate application.

To best effect this, I suggest the following:

* Have different mime types for different types of ogg files, just as
  mpeg has distinct mime types for audio and video:

   * "audio/x-ogg" or "audio/x-ogg-vorbis" for purely audio files (even if
     they have metadata or subtitles included).

   * "video/x-ogg" for an ogg file that contains video, even if it also
      contains audio or other data.

   * other appropriate types for data that doesn't fall into either of
     these categories.

* To make recognization of the mime type easiest for file manager and
  shell applications, have a distinct sniffable magic number for each
  distinct mime type. Otherwise, algorithmic detection will be
  necessary, as for MP3. Having many file formats with no sniffable
  magic number slows down the whole user environment. Nautilus
  includes a highly optimized mime sniffer that works really fast, but
  if we have to require a lot of special cases, it will slow down a
  lot in the network case and on huge datasets. This is an opportunity
  to do even better than mpeg, where there is no suitable magic number
  detection. Really, there is no excuse for file formats designed in
  this day and age to not have suitable magic numbers.

* To make recognition even easier and more correct in all cases, have
  a distinct extension per type. I bet this will be the more
  controversial point, but consider the fact that users have been very
  happy with the distinction between .mp3 and .mpg/.mpeg files - it
  allows users to organize their data in a way that semantically makes
  sense to them, rather than the way that makes the most sense to the
  program.

I'm sure there are logical reasons based on the structure of ogg
itself that you could use to argue against each of these points. I
hope before raising any of these points, the Ogg Vorbis developers
will pause to consider that the reason we are all here writing code is
ultimately for people to use. In the end, what the user needs to make
use of the data is far more important than what the program needs;
programs are in the end merely tools. 

I hope you will consider my comments and that they will help Ogg end
up closer to the right tool.

I'd like to add that I love ogg, and I really want to see it be the
audio and multimedia infrastructure of the future. I've previously
railed against the patent issues surrounding MP3, but you guys wrote
code that actually does something about it, and for that you have my
tremendous respect.

Regards,

Maciej Stachowiak

P.S. Hi Monty!

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