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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
On 15 Oct, Maciej Stachowiak wrote:> * 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.I disagree. Why not have mime type application/x-ogg launch a "SuperOgg" program which passes on the request to the appropriate player?> * 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.Wholeheartedly agreed. Even if the format is fundamentally the same, the difference between video+audio and audio only is substantial for users. And it's the users we care about, right? -- Taral <taral@taral.net> Please use PGP/GPG to send me mail. "Never ascribe to malice what can as easily be put down to stupidity." <HR NOSHADE> <UL> <LI>APPLICATION/pgp-signature attachment: stored </UL> -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/octet-stream Size: 241 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001015/346d97f8/part-0001.obj
On 15 Oct 2000, Maciej Stachowiak wrote:> 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.Thanks for your well argued perspective! It's nice to see rhetoric isn't entirely dead. :-)> 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.Given our differing assumptions, your argument hinges here. I completely agree that users prefer separate applications for audio and video, but had usually put cause and effect in the other order. The interfaces on video players seem uniformly clunky--perhaps because of the direct visual relation to the content, perhaps because of lazy programmers. Certainly the complexity of a VCR remote doesn't translate nearly as well a cd player's control panel. 12cm optical disks were chosen for DVD to leverage shared functionality with CDs, and perhaps to enjoy a familiar physical format. And yet, we sell them in very different cases to avoid consumer confusion because they'll not work in cd drives or so people will pay more. Can you argue from a usability (as opposed to popularity) standpoint that there are significant benifits to audio-only specialization? [...]> 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.I may well be arguing from the program's point of view. Jack is supporting your point when he says things like "ogg123 will probably continue to play only audio streams." But it does seem to me that mime has a poor conceptualization of container formats, so the distinction isn't as clear-cut as you suggest. What's the mime-type for .tar.gz? Is that a 'special case' in nautilus? Not to say we demand representation on par with tar! :-) Curious, -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.
Ralph Giles <giles@a3a32260.sympatico.bconnected.net> writes:> On 15 Oct 2000, Maciej Stachowiak wrote: > > > 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. > > I may well be arguing from the program's point of view. Jack is supporting > your point when he says things like "ogg123 will probably continue to play > only audio streams." But it does seem to me that mime has a poor > conceptualization of container formats, so the distinction isn't as > clear-cut as you suggest. What's the mime-type for .tar.gz? Is that a > 'special case' in nautilus? > > Not to say we demand representation on par with tar! :-) >Yes, MIME does not work very well with container formats, particularly ones like tar where sometimes you want to treat it as a unit, and sometimes as a container where you can browse the contents. Nautilus actually does not have the feature to browse into tar files and treat them like directories yet, but it will. For .tar.gz files that represent something semantically higher-level than just a generic container, like a Gtk+ theme or the like, I hope to convince people to use meaningful extensions and a gzip type tagging tool I am working on (the gzip format actually has space to put in an arbitrarily sniffable magic number). But handling of tar files and compressed files and other such stuff is a pretty broken area in most file managers; it's very hard to get right becaust it doesn't want to play nice with the mime type framework. Tar has the excuse of being originally designed on ancient character-based command-line systems for purposes of tape backup. However, Ogg has no excuse for not fitting in well with a modern system. - Maciej --- >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.