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

[Maciej Stachowiak]

Ralph Giles <giles at a3a32260.sympatico.bconnected.net> writes:

> On 25 Oct 2000, Maciej Stachowiak wrote:
> 
> > Also, if people keep questioning this particular decision (including
> > intelligent, experienced engineers), maybe that means that the
> > decision should be reconsidered in light of new information.
> > 
> > Another data point: the fact that QuickTime has only a single file
> > type for both audio-only and audio/video files is widely cited as a
> > reason it's largely failed to catch on as a format for audio files,
> > unlike MPEG (which has separate audio and video mime types).
> 
> Not compression quality or the high price of authoring tools? 

It's used quite a lot for video, despite these factors. I'd actually
be surprised if compression quality were a huge factor because
QuickTime is a container format and as far as I know could use an MP3
codec, but it's possible the most popular codecs were not very
good. But I don't think what I mentioned was the sole reason, just _a_
reason.

> I'd be interested in any reference pointers you have on this. 

The only reference I have is the say-so of the lead architect of
System 7, which I admit is not a very good reference.

> I kinda missed the early years of mp3. Did the early file-trading
> use the web or another mime-based protocol? What about in multimedia
> products and games?
> 

Early MP3 trading happened on IRC, usenet, the web, ftp, and wherever
else the traders could avoid getting shut down for at least a little
while. Older multimedia products and games tended to use uncompressed
WAV or AIFF audio for short game sounds, and MIDI or some type of MOD
file for the score. Nowadays I think they tend to use audio tracks on
the CD the product comes on for the score.

> > I also read over Chris Hanson's arguments where he argues that MIME
> > type is inadequate for selecting the application to launch for a
> > particular file. This simply seems bizzare, because that is the exact
> > purpose for which MIME types were invented. Originally this was meant
> > for email with non-plain-text data but over time has been extended to
> > many more internet protocols, and finally to nearly every desktop that
> > has been invented since the internet became popular (previously,
> > proprietary concepts of type abounded).
> 
> That's not a rebuttal to Chris' arguments, but you're right that the
> creator mechanism (particularly as implemented in MacOS) is less useful
> in a heterogeneous enviroment. I'm glad to hear Nautilus provides per-file
> application preferences! That handles many of the usability advantages
> Chris mentioned, in a smarter way. Is there a mechanism for applications
> to set that preference, or a policy against same?

Right now the Nautilus metadata API is not exported, but that will be
fixed eventually. Once it's exportated, applications that create files
will probably want to set that piece of per-file metadata. We'll
probably write up a document explaining how various apps could use
file metadata in general.

And I do think it's a a rebuttal; mime types are intended to
distinuish content type in a useful way, and designing new ones should
be done with this in mind, rather than fretting about their lack of
theoretical perfection. So I deny the relevance of Chris's arguments.

> > I still haven't seen any serious reason why it would be bad to have
> > three easily distinguishable types:
> > 
> > * audio/x-ogg for files where the primary use is audio
> > * video/x-ogg for files where the primary use is video
> > * application/x-ogg for anything more complicated
> 
> Rakholh's original question remains: how would we determine this
> efficiently? Filename extension? Initial binary stream-description
> substream that works with mime-magic?

I'd strongly prefer a fixed byte sequence at a fixed offset. Perhaps
the stream-description substream you describe would do it. Differing
extensions would help legacy systems like Mac or Windows that don't do
magic sniffing, but the developers have already expressed strong
feelings on the extension issue and I don't want to reopen that can of
worms.

> I think the problem is that we fundamentally rate the audio vs. other 
> distinction as less important than the flexibility of ogg as a
> content-blind bitstream format. That's why we keep arguing about
> intangibles.

Yeah, but the user does not care about content-blind bistream
formats. She just wants to use her files. So I guess I'll have to
place myself squarely on the other side and say I rate functional
distinctions that are meaningful to the user above distinctions based
on underlying low-level data format. I am particularly unsympathetic
to telling users that they don't want certain distinctions.

> > P.P.S. I'm not flaming, or at least I don't mean to be. I think
> > everything I've said has been courteous and based on facts and
> > reasoning. Can't speak for others though.
> 
> No, you and Ali have both been polite and reasonable. We're just testy
> about having to rehash this design decision again.

I think in light of the substantial new arguments and information
presented, at the very least a new justification for the decision
which in some way addresses them is owed. But I can understand some
level of testiness.

> 
> Hopefully cordial in return,
>  -ralph
> 

I believe you indeed have been,

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