Talk:MIME Types and File Extensions

From XiphWiki
Revision as of 14:36, 17 July 2008 by SamN3 (talk | contribs)
Jump to navigation Jump to search

I came upon this page looking for a speex encoder but, loosely following your arguments, you guys seem to be arguing about how ogg files should be identified. My advice is to copy what they do with XML.

audio/ogg -should be used for audio ogg files generally. audio/vorbis+ogg should be used for vorbis files in an ogg container. audio/speex+ogg should be used for speex files in an ogg container.

If you put video files in ogg, use:


If you use ogg for non-media files use:


And and so on. As for people associating ogg files with vorbis, that is not surprising given that Vorbis was the only show in town for awhile. But because codecs likes speex are not widely supported yet it is important for people to be able to differenciate between different types of ogg files. Therefore I would use a double exension, like "*.spx.ogg" to identify speex files, and "*.vrbs.ogg" to identify vorbis files. --Logomachist 19:21, 1 April 2008 (PDT)

.flac - application/flac

Why not audio/flac?

Presumedly to distinguish it from "unencapsulated" flac. I'm not sure this makes sense though. Native flac is a fairly light container, and I suspect the current application/x-flac usage is just an analogy with ogg. OTOH, I don't think anyone's done flac over rtp, where this would be needed, but that is something that's interesting.

Edit: I have changed my opinion in this subject. Regardless, Josh agrees with audio/flac in case someone is willing to register it. application/flac was never registered.--Ivo 14:57, 7 September 2007 (PDT)
In a way application/flac to describe a stream which uses FLAC encapsulation is the same as using application/ogg to describe a stream using Ogg encapsulation. I don't really know if this is academic thinking and it's more developer-facing than end-user-facing. The question is what is going to be most consistent (and therefore make sense to someone trying to work it out). Since FLAC in Ogg is natively FLAC encapsulated it may make sense to use the same mime-type for native FLAC as the codec mime type to be used for FLAC in Ogg. Imalone 07:26, 28 June 2007 (PDT)

.spx - audio/ogg

Why not audio/spx? To distinguish it from ogg vorbis.

audio/speex is only used for Speex RTP or in any other case of "Oggless" Speex. Speex in Ogg, which is a common sight, is audio/ogg just like every other audio-only Ogg file, be it Vorbis, FLAC, Ghost/CELT, MIDI, and even OggPCM.--Ivo 07:01, 26 January 2008 (PST)
Then we still need it for RTP and in native container seems to me.
Because of the RTP vorbis and speex should have a unique MIME type right?
And also for native container for making correct differences.
(One of the greatest mistakes of computer programming is identifying two different things as the same.)
Because you're goanna have to register it, best use it as well.

".ogg" should be "application/ogg"

I can't accept that ".ogg" becomes Vorbis I only extension. Ogg is not a codec. It is the container of codecs. That change will be missleading people.

".ogg" has been defined as "application/ogg" and already used as Theora+Vorbis. Redefining ".ogg" as Vorbis I only extension and changing MIME type to "audio/ogg" is not backward-compatible. Changing spec should be more carefully. If possible, should not change fixed spec. (I know becoming RFC does not mean fixed spec. But it is treated as fixed spec) --話切徒 07:31, 7 September 2007 (PDT)

We understand your concern, but application/ogg isn't about audio, and people out there have wrongly associated .ogg with Vorbis only, making it harder for other codecs like Theora to succeed because of the file extension. They do not understand that Ogg is a container; they think Ogg is Vorbis. Although this proposal is somewhat radical and some people aren't 100% happy with it, it's for the best. video/ogg and audio/ogg will also be much useful now with the <video> and <audio> elements of HTML 5.--Ivo 08:04, 7 September 2007 (PDT)
".ogv" and ".oga" may be useful. I can accept this. But changing the definition of ".ogg" is really needed? I can't find the necessity of this. It breaks backward-compatibility. No one will be happy with this change... --話切徒 13:56, 7 September 2007 (PDT)
We are not breaking backwards-comaptibility. That's why Vorbis and Speex will be allowed to use .ogg and .spx instead of .oga. The only thing that may break backwards-compatibility is deprecating application/ogg in favor od video/ogg and audio/ogg. That and Theora files, but since there are no Theora hardware players that we know of, existing Theora files may be renamed to .ogv easily, making compatibility with previous files a non-issue. Backwards-compatibility was seriously considered during the creation of this proposal. We are not breaking it.--Ivo 14:53, 7 September 2007 (PDT)
Ummmmm..... I think ".ogg" re-definition is not necessary. My best resolution is simply adding the new ext definitions to RFC:
  • ".ogg" is application/ogg (as RFC3534)
  • define new ext and MIME : ".ogx", ".oga", ".ogv", etc...
  • Use of new extensions is recommended.
  • Official tools are using new ext (except .ogg for Vorbis I?)
Changing of ".ogg"'s MIME type is really necessary? --話切徒 16:35, 7 September 2007 (PDT)
Want also to see more consistent behaviour like changing name of vorbis into something like n/m/l/w-orbis.
And mime type is then audio/ n/m/l/w-orbis
ogx is a very good way to overcome problems but be sure to let it have an internal version number for making changes later
Because of RTP and native containers codecs better have unique MIME-types, always:
Changes: vorbis: still .vorbis would be better(change name to something that doesn't starts with a v, nor, xor or g)
This solves the problem with backwards compatability because .ogg isn't used.
MIME: audio/ogg => audio/vorbis, speex: MIME: audio/ogg => audio/speex
(audio/ogg with everything on it is being used for .oga and that
stands for ogg audio is very consistent and easy to see)
It has to be registered anyway for RTP !!!!
(It wouldn't be such a big assigment now to do that, but over a year or two,
you can't go back anymore because of compatability!!!)
And people think that vorbis is a video format because it starts with a v.
So they look around if their player supports vorbis video but they find out only audio is supported.
Mad about getting wrong information and quit ogg for an alternative mostly.
Please change the name or create a new format that is essentially vorbis with another name.
(And also add new metadata formats in to have a reason for people to update.)


text/cmml for CMML without container: the Codec mime types are to be used in Skeleton, can this mime type be applied to the CMML Ogg mapping? (It's not plain text in the way that Vorbis mapped into Ogg is exactly audio/vorbis.)

.oga - able to rip cd's with all of it's contents also metadata like picture of the album (also separate pictures for each song)? Yes? This is fantastic

Can multiple audio streams/files be packed to one oga? (I mean that there are seperatable flac/speex/vorbis files that can be played separately). If this is the case then oga is a very good candidate for ripping a cd with all of it's contents and metadata without loss.

On a cd there is usually a picture. If you rip the cd to one of's free formats, it's lost because nothing supports this. Mayby oga could support this with some extra metadata and pictures in jpeg: a picture for the .oga and a picture for each number via metadata-system or something like that. This way someone can easily rip cd's and keep them in a consistent way on his or her computer. (One oga per cd, with the same picture as one the cd box, with all the numbers of one cd in oga file that can be played separatelly)

Yes, Ogg can carry multiple streams of audio, so you could backup an entire album in Ogg as FLAC or Vorbis and use the .oga extension. In this case alone, it is recommended to use .oga instead of .ogg because .ogg is for a single Vorbis stream file, while .oga requires a Skeleton stream which helps players recognize all the different songs in the file. Confused? One song, .ogg. Multiple songs in one file, .oga. Just make sure that the .oga file has a Skeleton stream. You can verify that with the ogginfo command line tool. And yes, you can also add a JPEG or PNG inside Ogg. I just don't know of any program that supports it, but theoretically it is possible. Just a heads up again, a song and an image are two streams of data, not just one, so again it would use .oga instead of .ogg. This also prevents breaking existing players that don't support embeded images.--Ivo 08:48, 25 January 2008 (PST)
This sounds great and about streams of audio:

Can I think of those streams also as separate audio files inside a multistream file? Because flac for example can also do up to eight streams.

Have also a few other questions: - Is it possible to have an oga with an album in with a mix of songs in flac, vorbis and speexs? - Is it possible in oga to have a different picture for each song, stream ? (For when people make their own albums out of different albums and they want the picture of that album for each song.)

Again, yes. Theoretically, there is no limitation in what you can put in Ogg and the order you want it in, but while the format has no such limitations, this is not the case with the software out there. So, the short answer is, for the general public it will look as if Ogg cannot do that which you ask even though it can.--Ivo 06:58, 26 January 2008 (PST)
Fantastic, please make sure this is included into the libraries of since applications can easily include them.
To the extent that is possible, the libraries already support embeding of pictures in Ogg. The problem is the programs out there. If you care about this issue and you are either a developer or have money to hire one, you should patch free software programs like VLC to support it. Then hopefully the non-free programs like foobar2000 will follow the lead.--Ivo 12:48, 2 February 2008 (PST)
When is there going to be support for lyrics for audiofiles and in what form (what file extensions will be able to have it and what metadata standards will be able to do it) ?
It is currently no way to save those.
Support in third party player software ? Lyrics for audio files are a lot like movie subtitles - text mapped to a time interval (unless you mean lyrics without the timing, in which case you could store them in Vorbis comments).
For timed lyrics, CMML and Kate can store this in a muxed stream, with the caveat that many Vorbis-only players will choke on a muxed stream.
You still need a way to display those in a player, however, but this is a question for the programmers for whatever player you're using
Hoped for player (or specification) that is able to show text mapped to a time interval without the timing.
Or else the text have to stand in the file two times. One time for mapping and another time for serving as meta data.
If you want it without the timing, you have to store it in headers, as streaming it will get you the text only as its presentation
time is reached. You could do that if you were loading from a file, but that's only a special case, so it's best to leave that text
interleaved with other streams. A player wanting to display the entirety of the lyrics at once would have to, if possible (eg, if not
streaming), scan the entire file to recover the text. Parsing Ogg packets is relatively fast, so a threaded player could do this while
starting streaming a file and have the text ready in under a second for a typical song I suppose. Still, this is player specific code
using whatever codec's library. For instance, if the lyrics are stored as a Kate stream, you could do something like:
char lyrics[4096]; /* you'll want to dynamically allocate this as you read text */
while (1) {
if (get_packet(&oy,&os,&init,&op)) break;
if (kate_high_decode_packetin(&k,&kp,&ev)>0) break;
if (ev) { strcat(lyrics, ev->text); strcat(lyrics, "\n"); }
As you see, it's very little code once you have the Ogg stream ready for sync, but this has to be done by each player
as the get_packet thing will be piggybacking on that player's Ogg read routines.


Ar Dubya, Reno, NV here -- Firefox does about everything but digest one's food, how about a Firefox extension that takes a jam-packed (pun) .oga file full of timed lyrics, pix, and eight-track FLACs created from DTS-HD Master Audio source material, and renders the whole shebang seamlessly? I'm not a developer and don't feel a particularly strong urge to become one to provide non-audio data in the ogg container. As it is, the .oga file can carry my surround sound studio master quality FLACs and render them on-the-fly in my buddy's VLC player on his PC 12,000 miles away. Frankly, I'd like to see more emphasis on perfecting audio technology as opposed to all this other (non-audio) nonsense. By analogy, I'm reminded of a fellow who travels frequently by air, and his pointing out to a companion on a flight, that if you want good food, go to a restaurant. Don't expect a five-course gourmet meal on a plane. That wasn't why it was built.

For an example of ogg's doing what she does best, check out my son's Metal band, Blasphemous Creation on the Internet Archive: