Talk:MIME Types and File Extensions

From XiphWiki
Revision as of 02:36, 21 September 2007 by Imalone (talk | contribs)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

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

text/cmml

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