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

[Pavel Cisler]

Maciej Stachowiak wrote:
> 
> David Mitchell <mitchell at ucar.edu> writes:
> 
> > Ralph Giles wrote:
> > >
> > > 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. :-)
> > >
> 
> Ralph, thanks for your kind words regarding my writing skills, but
> I'll wait to see the results before I rest on my laurels.
> 
> > > > 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.
> > >
> 
> I think the fact that users prefer different programs for video and
> audio, even in the presence of programs that can handle both, speaks
> for itself. Writing a program that handles both well is clearly more
> challenging that one that specializes - this to me indicates by itself
> that the program is filling different needs. While on one level it's
> true that a word processor is "clunky" for dealing with tabular
> numerical data, this is usually taken as a sign that spreadsheets are
> necessary, not that word processors are broken.
> 
> > > 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?
> >
> > I would turn this around and ask if there are any significant
> > benefits to generalizing audio-only and video players. Audio-only
> > files really are different from video files, at least from a
> > users point of view. A common feature of MP3 players is shuffle.
> > Is this likely to ever be used in a video player? On the same
> > note, it's nice if your video player will let you display a
> > single frame, or fast forward and rewind by a single frame. Not
> > to mention grabbing screen shots. Would you ever do any of these
> > with an audio-only file?
> >
> > I would argue that to a user, there is a world of difference
> > between their audio files, and their video files. They are used
> > for different things in different settings. The fact that they
> > might use a common underlying container or stream format is not
> > important to the user. It's a technical implementation detail
> > that should be hidden from the user in most cases. It doesn't
> > make any more sense to lump together all Ogg container files than
> > it does to lump together all ASCII text files. Do we argue that
> > your email, .c, .html, and .txt files should all use the same
> > MIME type because they are all implemented in ASCII? Of course
> > not. MIME is being used to provide file typing for the user.
> > Users treat audio files differently from video files. The MIME
> > typing should reflect that fact.
> >
> 
> I agree with everything David says. He said it better than me. I'll
> further mention the different ways audio and video are used. Audio is
> often used in a purely background way, while the user is doing
> something else. Video files, on the other hand, are generally given
> the user's full attention, or at least most of it. This leads to the
> differing features David mentioned. Another thing to note is that
> audio players are often carefully designed not to take a lot of screen
> real estate since they're mostly used in a background way. However,
> for a video player, using more screen real estate is actually
> meritorious.
> 
> While I can conceive of a program that would make a nice audio player
> _and_ a nice video player, I'd consider it a clever multipurpose
> program rather than a program that unifies two obviously related
> things.
> 
> > Going back to your DVD vs. CD comparison. Most DVD players will
> > play CD's, and some people have gotten rid of their CD players
> > because of that. But does that mean that there is no longer a
> > need for CD-only players?
> 
> I have both a DVD player and a 200-disc CD changer and I'm not dimping
> either any time soon. :-)
> 
> > As a user of a heavily MIME typed OS (BeOS), my opinion is that
> > we should have an audio MIME type, and a video MIME type. The
> > creator of a file should have some way of tagging it to indicate
> > what they consider to be the "primary" use of the file. Can an
> > Ogg video player play an audio-only file? Sure. And if a user
> > wants to use the same player for both, they can easily set their
> > system up that way. But I don't think we should force them to do
> > that. Going back to the BeOS, by default it uses the same
> > application for both audio and video files. And that app works
> > OK. But, there are lots of third party audio players which
> > provide more functionality (such as playlists). With MPEG files,
> > I can easily configure my system to use the built in player for
> > video files, and whatever player I want for MP3 files. I don't
> > want to lose that functionality when I start using Ogg files.
> >
> 
> It's particularly worth noting that having two mime types does not
> preclude using the same app for both ogg audio and ogg video - you
> just set up your system to associate the app with both mime
> types. However, having one mime type for both makes it very difficult
> to set different apps as the default handlers for each.
> 

I agree that tagging a hierarchical media format containing audio, video
or both with a mime type in the form "audio/x-..." or "video/x-..." may
seem kludgy and limiting but in practice it works out just fine (the
above mentioned BeOS is an excellent example, as are the audio and video
MPEG mime types).

Regardless of whether you accept the arguments for using "audio/x-..."
and "video/x-..." style mime types (and you should :-) there is no
reason to not include provisions for magic type identification and make
the same mistake the mp3 file format did.

I suggest you add easily identifiable magic strings to your file format
header. These strings should:

- be at least six to eight bytes and contain a mix of printable and non
printable characters.
- be located as close to the file start as possible, at most 128 bytes
from it but preferably closer.
- express the essential variants of the enclosed data - the identifier
should describe whether the enclosed media data are audio, video or
both.

You could for example have the following strings:

\003\005OggS\001\000
\003\005OggS\000\001
\003\005OggS\001\001

at offset 0 of your file format, identifying Ogg audio data, Ogg video
data and Ogg video with sound data respectively.

Pavel

P.S. The .tar.gz format was designed before mime types and mime magic
was widely used in modern desktop apps. You no longer have this as an
excuse :-)

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