[Vorbis] Extension proposal - partly serious

[Arc Riley]

<20040620190623.GF9120 at xiph.org>
<200406211332.17596.jwm at eslnz.co.nz>
Message-ID: <20040621021500.GH9120 at xiph.org>

On Mon, Jun 21, 2004 at 01:32:17PM +1200, John Morton wrote:
>
> The funny old thing about the notion of a file type is that it tends to be
> related to things what you use the data in the file for, or what sort of
> program you need to make the file do something useful.

That's right.  You need a media player.  Anything with OggFile support
can play any form of media, wether it's audio which lacks a video stream
or video that lacks an audio stream.  The old days where you have
audio-only media players is pretty much phased out, with the exception
of hardware players.  Even the (future) players which lack video support
will still be able to play the audio part of the video.

And speaking of these legacy players, there's going to be the issue of
having them play non-Vorbis streams after awile.  Everything is going to
have to be upgraded to use OggFile anyway.

> It contains *multimedia* data. That's important. By definition, all files
> contain some sort of data (except the empty ones), so giving it an extension
> to tell you it's a file is redundant. The problem is that 'multimedia' is
> still a bit broad for most user's needs.

I disagree.  "Ogg" is as specific as we can get without dropping off
into an abyss of illucid extension bloat.

A good example is lossless vs lossy.  Users may want to encode to both
so that they can re-encode, but easily transport the lossy versions
around.  As far as wether it has a video stream or not is not the issue,
but the user may want them to open in different programs.

What about a demuxed Ogg?  You have subtitles in one, audio in another,
video in another, but they're all part of the same master file.  And you
want them each to be opened in their own seperate editor.  What do you
call the subtitle-only one?  What about the metadata codec?  Do these
get their own extensions?  Why not, if audio and video do?

No.  The .ogg extension is enough to pass the stream to something that
can understand it, and the user-side app can do all that custom stuff on
it's own.  Inventing new extensions puts us on a massive slippery slope.

> Hang on. Are you suggesting that there be only one mime-type for all files
> that are ogg containers?
<snip>
> That doesn't help the operating system decide what is the right thing to do
> when I click on one in a file browser, or in a web browser. It can't tell
> whether it should run the app-that's-good-at-video or the
> app-that's-good-at-audio with just a .ogg for everything, or
> application/x-ogg. So you need some helper app to parse the file and call the
> right program, but as that's not part of the way the browser does things
> normally, you have to associate ogg with the helper app, then, inside the
> helper app, associate video with one app and audio with another.

We already have an official mime-type.  Please atleast research what
you're debating before suggesting massive changes like this.
application/ogg has been official, through the IETF, for a long time
now.  It is associated with the .ogg extension.

This discussion, and all of the arguments and viewpoints put forth in
it, has been hashed out atleast three times over the last few years.
It's been played out so many times that the core development team has
resolved to simply ignoring this "Eternal Fucking Extension Flamewar" so
they can spend their time on more important things, like getting OggFile
Theora and Icecast shipped.

The Ogg helper app has been suggested many times.  Nobody has written it
yet, and yes, it would be a good solution.

I've personally committed to writting it in Python using py-ogg2.  It
should be completely portable to Windows and Mac once libogg2 matures a
bit more.  It will allow automatic renaming of batch files, ie,
mymovie.TheoraVorbis.ogg or mymovie.video.ogg, or moving these batch
files to different directories by a rule (movies/ and music/), and could
also contain the rules for opening certain apps when the switcher is run
with a file as it's argument.  I also plan to have this app be available
in a compiled form (no python interpreter needed) for Windows.