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

[Manuel Amador Rudd-O]

Please:

This is just my own preference.  I use XMMS for both audio and MPEG
video, and I don't have any problems about it.  I DO think XMMS needs
some sort of video framework so it can be more useful instead of just
instantiating a new window for each video (that's annoying).  So I think
application/ogg is enough since your file manager/browser needs to start
only one application.

You could also preview ogg files' audio data containing video by
hovering the mouse over its icon, by using ogg123 in the background. 
Anyway, they probably contain audio too.

I think that the Nautilus file types and programs capplet should also
show a checkbox "Can be previewed as music" for each defined MIME type,
or infer that data for those MIME types that have the view "View as
music" available, and make that clear in the FTAP capplet.

Oh, and a call for the Nautilus developers.  Try to copy the ideas from
the KDE control center's MIME setup.  It's EONS ahead from the current
state of Nautilus' one.  If I were a beginner, I might have some
problems with KDE's MIME setup, but I'm sure that Nautilus' MIME setup
would be positively impossible for me to use.

Maciej Stachowiak wrote:
> 
> 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.


-- 
Manuel Amador (Rudd-O)

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