On 1/16/07, Aaron Colwell <[EMAIL PROTECTED]> wrote:
What happens when a new audio/video codec is added to the mix? A new extension?
Nope. As stated in the original message, it's not possible to guess all kinds of combinations that may go inside an Ogg container, nor what kind of new formats Xiph may develop in the future (Holy Ghost Batman!). This proposal is aimed at the more important formats in the Ogg family, those that need to be marketed aggressively, those that are to be used by the average joe.
What would be the extension for a chained file that contains audio-only and A/V segments? (My _favorite_ corner case in the ogg format. :| )
.ogg It falls under the mixed bag category mentioned above.
What is wrong with the MP4/Matroska/Windows Media/RealVideo model? .oga (Vorbis, Speex) .ogv (Theora, Theora + Vorbis, Theora + Speex, Tarkin, etc)
All kinds of things are wrong there. Those extensions use a three letter namespace, they are hard to remember, easy to confuse, and moreover they tell the user nothing much about what the file is supposed to be about.
Why do we need a new extension for FLAC?
Ian proposed a new extension for FLAC. I, on the other hand, believe FLAC players should accept .ogg as possible container for FLAC, as right now they don't. And the idea of Ogg FLAC has been around for quite a while. Although .music-perfect has a nice sound to it, it's possibly too large for an extension. Of course that applies to .video-perfect as well, but those are so far only a suggestion asking for feedback. Personally, I stand behind .video, .music and .voice. It's simply perfect. It's a shame that we are apparently going over yet another extension flamewar, but things as they are, are not all right. There wouldn't be this kind of talk all the time if things were okay. Let's hope a consensus is achieved soon, because there's far more important things to fix around here.
Media applications are able to deeply inspect the file if they really need to determine which codec it contains.
If this were true in all (or most) cases, we wouldn't be having this discussion.
Don't burden the masses with a ton of extensions just to appease a select few. Proliferation of a bunch of new extensions will only confuse users in my opinion.
Although I respect your opinion, I believe it's just the other way around. Moving away from legacy extensions, and in the process trying to unite more the projects under Xiph will only benefit users. Those extensions are the kind easy enough to remember that if one day they become mainstream, people will look with suspicion at things like .wmv, .avi and .acc. It just makes no sense. Since players are (in theory) supposed to accept legacy extensions for backwards-compatibility, the (few) people right now that care about the Ogg family will not mind the change, as their old media will still play well. Finally, I also believe that this change means also a change of attitude from Xiph. Many in the industry, or even in the mailing-lists here, have quite a few times pointed out that we are not promoting our projects well, or even at all. This, I hope, is a step in the right direction. On 1/16/07, Silvia Pfeiffer <[EMAIL PROTECTED]> wrote:
Also consider that the extensions and an associated mimetype will need to be ratified by the IETF to become "standard". They would never agree to these extensions since they are too broad.
This might be the only problem I've seen so far, and even then, I'm not sure it's really a problem. As far as I understand how the RFC process works, extensions shouldn't mean much. Regarding, MIME issues though, I'll mention (again) Ralph's disposition-type proposal. Since to me it doesn't seem like it breaks any application that relies on application/ogg, I doubt the IETF will oppose that. Best wishes, Ivo Emanuel Gonçalves
_______________________________________________ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
