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

[Maciej Stachowiak]

Dan Conti <dconti at acm.wwu.edu> writes:

> I dont see how you expect it to survive for 20+ years when such a
> challenge exists to adapt it to container types. See more below.

It's currently used heavily in email, http, and many other internet
protocols. I see no viable strategy for replacing it. Therefore, flaws
and all, mime types will continue to exist. Maybe there will _also_ be
something better. That would be nice. But the backwards compatibility
is not going to go away.

Most importantly, no one has proposed a better model for how a user
can set up his system to use different players for audio files and
video files. The only alternative proposals I have heard (rely on
per-file metadata, or use a configurable launcher program that does
dispatching) both seem worse in specific ways I have described at some
length.

> 
> So what happens when someone puts a meta data stream for lyrics in an ogg
> bitstream? Or (for whatever reason) someone streams subtitles along with a
> movie, but in a seperate stream? Maybe the administrative or coding burden
> is small now, but your approach generates recurring maintenance.

The data streams should be tagged according to primary intented use,
audio, video, or multimedia/other. In the two cases you mention, the
obvious primary uses are audio and video respectively (the user's
default audio or video player may or may not be able to use those
parts of the stream). Or if the text is somehow essential to the
experience of the audio file such that audio-only playing (as with
ogg123) would miss the point, the proper type is other.

But in general, designing primarily based on the corner cases rather
than the common cases leads to bad design. "Oops, it's hard to say
whether some files are primarily audio, primarily video or other,
let's just throw up our hands, and pretend there is no
distinction. And then to solve the problems this causes, let's all
call external programs somehow magically make that nonexistent
distinction (??!?)"

> > It's not like it even fundamentally affects the design, since the
> > magic to do the detection will aready be there.
> > 
> > And it has trivial effect on the user/developer experience for people
> > who want to treat all three types exactly the same.
> > 
> > 
> > I do not buy the cleanliness argument. Epicycles sure seemed more
> > clean than a helicentric model for a while. But the proof is in the
> > resulting total system complexity.
> > 
> > Sorry if I sound a bit strident here. I am a bit frustrated at having
> > to argue the same point repeatedly.
> 
> My compliments to you for your ability to religiously argue your point in
> the face of so many non-believers. 

I don't think any of my arguments are religious. I certainly have not
made any arbitrary claims without backing. There's two possible models
for treating generic multimedia bitstreams: treating it all as one
type, or treating it as distinct subtypes. While the latter model
makes it trivial to model the former, the former makes it difficult to
model the latter. What more could I do to establish this fact?

I guess you could call it religious to favor arguments based on making
it easier for users and developers to do what they want, over
theoretical elegance of file formats.

> I urge you to consider that you have consistently used a linear and
> restrictive approach to how files should be treated by any given
> system; not once have you considered that rather than adapting ogg
> to suit your needs, that a more reasonable solution exists.

Actually, it wouldn't require making any changes to ogg beyond what
people have said they already plan to add. It might require creating
two unofficial mime types in addition to the standard one which would
be detected based on bits in a particular static location.

I would rather not do that without the approval of the ogg hackers,
but there is no fundamental technical reason that makes this
impossible. Yet it would be far simple than mucking with inventing
external programs to detect subtypes, and I would have a hard time
convincing anyone it wasn't the simplest solution.

> I also urge you to consider that, whereas this is a project in
> development and input at this phase can possibly impact results, there are
> other bitstreams that are have been through a few revisions, and if your
> system can't properly address this problem with ogg then it will likely
> have trouble with those formats.

We don't have problems with MPEG video or audio, we can tell the
difference just fine. Some legacy file formats do have problems being
handled reasonably (a .tar.gz file being everyone's canonical
example). However, ogg does not have the excuse of being invented
decades ago and well past revising, unlike both tarballs and mime
types.

I do not understand the religious fervor around this issue. You are
willing to add bits to files to make them detectable as different
subtypes in a simple, static way, yet you are not willing to declare
these different types to be distinct mime types. I really can't
understand the logic here. It's just some strings. They will make some
people's lives easier (comparing strings is way simpler than
perfroming arbitrary computation on file contents). They won't make
anyone's harder, as far as I can tell. It has exactly _zero_ effect on
the file format itself, it's just a string mapping, so it definitely
does not tie the format unnecessarily to any obsolete technologies. So
what's the big deal?

I don't really want to argue about this any more since it leads to
endless going in circles. I just hope you guys do the reasonable thing
in the end.

Later,

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.