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

[Manuel Amador Rudd-O]

your media player should not show a Video window if it's not needed.  It
should be small, just like XMMS, and you should be able to windowshade
it if you want. It should use a multimedia framework.

why two different applications?  I understand that Kaiman takes a LONG
time to start up, but isn't that the application's fault?  audio/ogg and
video/ogg is completely inaccurate.  Video streams can contain audio,
and audio streams can contain other types of media.  The logical thing
is to have only one media player instead of redoing different work (but
that doesn't mean anyone is forcing you to have only one media player). 
Or, you could do like KDE that allows several applications to be
associated with a MIME type, with order of preference.  That way, if you
have primarily video files, you could set your favorite video player to
be the most important, and open it with only one click, and the same for
audio junkies.

The solution is simple: one MIME type, several programs associated with
it.

David Mitchell wrote:
> 
> Chris Hanson wrote:
> >
> > At 8:29 PM -0200 10/19/00, Ali Abdin wrote:
> > >Doh! Windows uses file extension! my bad. Well, KDE/Konqueror use mime-type! I
> > >believe BeOS uses mime-type, what about MacOS X? Unix in "general" uses
> > >mime-type for some stuff. But whatever.
> >
> > Mac OS X uses file types and creators as I described previously, with
> > file extensions as a fallback.
> >
> > (Also, just so everyone knows, there are a number of people who use
> > the QuickTime Player to play audio as well as video files.  Aside
> > from the stupid brushed-metal look it's actually really functional
> > and useful.  If Apple added playlist support it'd be killer.  Then
> > again, there are people who have written shareware playlist
> > applications that work with the QuickTime player...)
> >
> > >  > Besides, it appears that the decision has already been made.
> > >  > Nautilus needs to fit in with the rest of the world, not try to bend
> > >  > the rest of the world to conform to its vision (particularly where
> > >  > its vision is flawed, such as in its assumption that a MIME type or
> > >  > an imbedded magic number conveys enough information about a file to
> > >  > determine what application to use to launch it).
> > >
> > >Whoaaaah! Thats a pretty deep statement. You are basically saying "MIME type"
> > >is useless and apps shouldn't use it to determine a file type.
> >
> > WRONG.  What I'm saying is that MIME type ONLY specifies a file's
> > type, and that a file's type is often insufficient for determining
> > which application to use to launch it.
> 
> So, I have to ask. What exactly do you think MIME is for? Is
> determining a file's type some sort of abstract operation that is
> done for it's own sake? No. Identification of a files type is so
> that the operating system and/or applications can make decisions
> about what to do with that file. In the case of a browser, the
> MIME type is often used to determine which application to launch.
> In the case of a mail agent receiving a MIME attachement, the
> MIME type is used to determine which application should be used
> to handle the attachment. In BeOS, KDE, and Gnome, the MIME type
> is used to determine which application should handle the file. I
> don't see how you can say that this is not the realm of MIME
> types. I ask you, what is the purpose of determining a file's
> type if your are not going to make a decision on how to handle
> the file based on that? MIME types are as sufficient as the
> people creating them want them to be. If we only have
> application/x-ogg then the MIME type will be insufficent. If we
> have audio/x-ogg and video/x-ogg in addition, it might not be
> perfect, but it will be closer.
> 
> >
> > An Ogg file is an Ogg bitstream.  *That* is its type.  It may contain
> > a Vorbis stream or two, a video stream or two, an effects track, a
> > metadata track, closed captioning tracks in several languages...
> > Tell me, what would you have the MIME type be for an ogg bitstream
> > containing two audio tracks -- audio and artist's commentary -- plus
> > text caption tracks in several languages?  How would you determine
> > the "right" application to open for this particular file?
> 
> I think the creator of the file should be able to tag it to
> indicate what type of file it is. Say it's a movie with alternate
> endings, multiple languages, closed captioning, etc. If it's a
> movie, the creator would probably tag it as being video knowing
> that that is it's primary use.
> 
> On the other hand, maybe it's an audio track. Maybe the video
> stream is just static pictures of the album cover and maybe the
> band. The closed captioning is the lyrics. While the stream can
> provide a whole multimedia experience, it's primary purpose is as
> an audio file. So, the creator tags it as audio/x-ogg. If the
> users audio player can handle the album cover great. If not, well
> the user misses out. But if I, as a user, select a bunch of audio
> files to listen to in the background, I might not want half of
> them to play with my audio player and half with my video player.
> Or maybe I do. But that should be up to the user.
> 
> This fact is there is no way to determine what a files primary
> use is just from looking at the mix of streams that are in it.
> That's why I think the creator of a stream needs to be able to
> tag it.
> 
> Another letter in this thread mentioned that there isn't anywhere
> in the stream to put a MIME magic number. What about adding a new
> stream type that can indicate this sort of information? If files
> that include it always put that stream first, the information
> should show up in a static location, right? The information
> doesn't have to be MIME-specific. It can just be some sort of
> variable or bit-field that the creator adds to give guidance to
> the users and their applications. The logic for adding this is
> simple to me.
> 
> 1: It's a fact that Ogg streams will be used for different
> purposes. A movie is not a song.
> 
> 2: It's a fact that some end users will want to deal with
> different kinds of Ogg files in differnet ways. When I tell my
> desktop that I want to search for all of my audio files, I want
> to distinguish between songs and movies. Just because some people
> do not want to make this distinction doesn't mean that no one
> does.
> 
> 3: I think it can be safely assumed that looking at the mix of
> streams in an Ogg stream will not tell you what the creator of
> the stream intended it to be used for. Both movies and songs
> might end up with text streams in them. Both movies and songs
> might end up with multiple audio tracks. And what about when
> someone decides to build a presentation program ala PowerPoint
> that uses Ogg streams? It is certainly a different type of file,
> but may contain audio, video, and text.
> 
> Conclusion. The author of a stream needs be able to mark it to
> indicate what "type" or "use" he thinks the file has. While
> developers might think of them all as being just Ogg streams, and
> I cannot stress this enough, users do not think that way. Ogg is
> just a technology that can be used to create songs, movies,
> presentations, whatever. Users don't want to lump all Ogg streams
> together any more than they want to lump all ASCII files
> together. This whole focus on "all Ogg streams are the same.
> There should be only one true Ogg handler. Users will never want
> to distinguish between different uses of Ogg files" is really
> misguided. Users don't think that way, and if we don't recognize
> that, Ogg will end up being a cumbersome format for them to use.
> 
> So, it seems to me that defining a new Ogg stream type which
> contains this sort of type/creator/use information would be
> beneficial. We want Ogg to have obvious advantages to the users
> in real world situations. Making it possible for their system and
> applications to easily distinguish between the different types of
> Ogg files will provide for a qualitative improvment in the user
> experience.  By designing the stream such that if it is included
> first in the file magic-number based file typing algorithms work
> will make it much easier for applications to "do the right
> thing." and should be pretty simple to do. Compatability
> shouldn't be threatened, since players that don't understand that
> stream or don't care should just ignore it anyway.
> 
> >
> > All of this argues for not worrying about this stuff at the file-type
> > (MIME type, MacOS type code, file extension) level and instead
> > putting the onus on the playback applications to do the right thing
> > with whatever files they're told to open.  If you build a playback
> > application with as good an interface as the QuickTime player (minus
> > the stupid brushed metal look) and add good playlist support your
> > problem would be solved.
> 
> To be more exact, _your_ problem would be solved. However, don't
> assume that every ogg user in the world wants to use your
> solution. The simple fact is that people use audio and video
> files for different purposes in different situations. Our MIME
> typing should reflect that reality. Having a single Ogg handler
> which decides what to do with Ogg files doesn't make sense. Ogg
> is an underlying technology which should be largely invisible to
> the user. It's an implementation detail. By your logic, there
> should only be a text/ascii MIME type, and users should just
> lauch emacs and let it figure out what to do with the file ;-)>
> 
> -David Mitchell
> 
> >
> >    -- Chris
> >
> > --
> > Christopher M. Hanson <cmh at bDistributed.com>
> > President & CEO, bDistributed.com, Inc.
> > Developers of database-backed web sites
> > (847) 372-3955
> >
> > --- >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.
> 
> --- >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.