(quoting from the web archive, I only just subscribed) Monty wrote:> > > (a bit testy that this flamewar has started again, and no one has learned a > > thing from the previous rounds) > > OK, that wasn't fair... the old timers know what's up, but I do wish some of > the folks who bring things up would browse the archive threads or at least not > jump in in large numbers before realizing this has been hashed into the ground > many times before. >Hey Monty (and others), I just read every post in the web archive of vorbis-dev with "mime" in the title. I didn't see any that addressed anything remotely similar to the usability arguments I, and numerous other people, raised in this go-around. Thus, I think "go read the archives" is not a fair response. Also, if people keep questioning this particular decision (including intelligent, experienced engineers), maybe that means that the decision should be reconsidered in light of new information. Another data point: the fact that QuickTime has only a single file type for both audio-only and audio/video files is widely cited as a reason it's largely failed to catch on as a format for audio files, unlike MPEG (which has separate audio and video mime types). I also read over Chris Hanson's arguments where he argues that MIME type is inadequate for selecting the application to launch for a particular file. This simply seems bizzare, because that is the exact purpose for which MIME types were invented. Originally this was meant for email with non-plain-text data but over time has been extended to many more internet protocols, and finally to nearly every desktop that has been invented since the internet became popular (previously, proprietary concepts of type abounded). While the type/creator system is nice, unfortunately most files you get will not come with a creator set, and it is a concept that is not present on any system but the Mac. (Note: Nautilus does not have one and only one application per mime type, it has potentially many, with a system default, a possible user default, and an optional per-file default; I think the Be Tracker works similarly. This is similar to the "creator" system but more meaningful since it directly represents the concept of what application you want to view a file with, rather than assuming the app that created a file will always be the right one to view it. But you still have to figure out what to do with a freshly downloaded file, or one created by an unaware app, so the system and user default settings remain critical). And finally, I think raising the specter of edge cases like files with multiple video, audio and slideshow streams misses the point. The vast majority of files will not be like that; they will be simple audio or audio with video. While it may make sense to call weird complex files "application/ogg", using this as a reason not to call audio files "audio/ogg" or video files "video/ogg" just because you _can_ do something more complex seems unreasonable. A system designed primarily around corner cases is not going to work very well. I still haven't seen any serious reason why it would be bad to have three easily distinguishable types: * audio/x-ogg for files where the primary use is audio * video/x-ogg for files where the primary use is video * application/x-ogg for anything more complicated This would allow users who want one true player for everything to do what they want, and users who want different players for different subtypes to do what they want. Why is this such a bad thing? Please give pragmatic arguments and not theoretical ones (that's not The Way of the Ogg format; MIME types are broken anyway; etc). Sincerely, Maciej P.S. Much like Ali I was unable to find the post where "application/x-ogg" was declared the one true mime type, though I did see older posts that referenced such a decision. Is there some more useful term to use to search the archive than "mime"? P.P.S. I'm not flaming, or at least I don't mean to be. I think everything I've said has been courteous and based on facts and reasoning. Can't speak for others though. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On 25 Oct 2000, Maciej Stachowiak wrote:> I just read every post in the web archive of vorbis-dev with "mime" in > the title. I didn't see any that addressed anything remotely similar > to the usability arguments I, and numerous other people, raised in > this go-around. Thus, I think "go read the archives" is not a fair > response.Yeah, most of the previous discussion has taken place around filename extensions. It's not fair. This should be faq. :-/> Also, if people keep questioning this particular decision (including > intelligent, experienced engineers), maybe that means that the > decision should be reconsidered in light of new information. > > Another data point: the fact that QuickTime has only a single file > type for both audio-only and audio/video files is widely cited as a > reason it's largely failed to catch on as a format for audio files, > unlike MPEG (which has separate audio and video mime types).Not compression quality or the high price of authoring tools? I'd be interested in any reference pointers you have on this. I kinda missed the early years of mp3. Did the early file-trading use the web or another mime-based protocol? What about in multimedia products and games?> I also read over Chris Hanson's arguments where he argues that MIME > type is inadequate for selecting the application to launch for a > particular file. This simply seems bizzare, because that is the exact > purpose for which MIME types were invented. Originally this was meant > for email with non-plain-text data but over time has been extended to > many more internet protocols, and finally to nearly every desktop that > has been invented since the internet became popular (previously, > proprietary concepts of type abounded).That's not a rebuttal to Chris' arguments, but you're right that the creator mechanism (particularly as implemented in MacOS) is less useful in a heterogeneous enviroment. I'm glad to hear Nautilus provides per-file application preferences! That handles many of the usability advantages Chris mentioned, in a smarter way. Is there a mechanism for applications to set that preference, or a policy against same?> I still haven't seen any serious reason why it would be bad to have > three easily distinguishable types: > > * audio/x-ogg for files where the primary use is audio > * video/x-ogg for files where the primary use is video > * application/x-ogg for anything more complicatedRakholh's original question remains: how would we determine this efficiently? Filename extension? Initial binary stream-description substream that works with mime-magic? I think the problem is that we fundamentally rate the audio vs. other distinction as less important than the flexibility of ogg as a content-blind bitstream format. That's why we keep arguing about intangibles.> P.P.S. I'm not flaming, or at least I don't mean to be. I think > everything I've said has been courteous and based on facts and > reasoning. Can't speak for others though.No, you and Ali have both been polite and reasonable. We're just testy about having to rehash this design decision again. Hopefully cordial in return, -ralph -- giles@ashlu.bc.ca --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Ralph Giles <giles@a3a32260.sympatico.bconnected.net> writes:> On 25 Oct 2000, Maciej Stachowiak wrote: > > > Also, if people keep questioning this particular decision (including > > intelligent, experienced engineers), maybe that means that the > > decision should be reconsidered in light of new information. > > > > Another data point: the fact that QuickTime has only a single file > > type for both audio-only and audio/video files is widely cited as a > > reason it's largely failed to catch on as a format for audio files, > > unlike MPEG (which has separate audio and video mime types). > > Not compression quality or the high price of authoring tools?It's used quite a lot for video, despite these factors. I'd actually be surprised if compression quality were a huge factor because QuickTime is a container format and as far as I know could use an MP3 codec, but it's possible the most popular codecs were not very good. But I don't think what I mentioned was the sole reason, just _a_ reason.> I'd be interested in any reference pointers you have on this.The only reference I have is the say-so of the lead architect of System 7, which I admit is not a very good reference.> I kinda missed the early years of mp3. Did the early file-trading > use the web or another mime-based protocol? What about in multimedia > products and games? >Early MP3 trading happened on IRC, usenet, the web, ftp, and wherever else the traders could avoid getting shut down for at least a little while. Older multimedia products and games tended to use uncompressed WAV or AIFF audio for short game sounds, and MIDI or some type of MOD file for the score. Nowadays I think they tend to use audio tracks on the CD the product comes on for the score.> > I also read over Chris Hanson's arguments where he argues that MIME > > type is inadequate for selecting the application to launch for a > > particular file. This simply seems bizzare, because that is the exact > > purpose for which MIME types were invented. Originally this was meant > > for email with non-plain-text data but over time has been extended to > > many more internet protocols, and finally to nearly every desktop that > > has been invented since the internet became popular (previously, > > proprietary concepts of type abounded). > > That's not a rebuttal to Chris' arguments, but you're right that the > creator mechanism (particularly as implemented in MacOS) is less useful > in a heterogeneous enviroment. I'm glad to hear Nautilus provides per-file > application preferences! That handles many of the usability advantages > Chris mentioned, in a smarter way. Is there a mechanism for applications > to set that preference, or a policy against same?Right now the Nautilus metadata API is not exported, but that will be fixed eventually. Once it's exportated, applications that create files will probably want to set that piece of per-file metadata. We'll probably write up a document explaining how various apps could use file metadata in general. And I do think it's a a rebuttal; mime types are intended to distinuish content type in a useful way, and designing new ones should be done with this in mind, rather than fretting about their lack of theoretical perfection. So I deny the relevance of Chris's arguments.> > I still haven't seen any serious reason why it would be bad to have > > three easily distinguishable types: > > > > * audio/x-ogg for files where the primary use is audio > > * video/x-ogg for files where the primary use is video > > * application/x-ogg for anything more complicated > > Rakholh's original question remains: how would we determine this > efficiently? Filename extension? Initial binary stream-description > substream that works with mime-magic?I'd strongly prefer a fixed byte sequence at a fixed offset. Perhaps the stream-description substream you describe would do it. Differing extensions would help legacy systems like Mac or Windows that don't do magic sniffing, but the developers have already expressed strong feelings on the extension issue and I don't want to reopen that can of worms.> I think the problem is that we fundamentally rate the audio vs. other > distinction as less important than the flexibility of ogg as a > content-blind bitstream format. That's why we keep arguing about > intangibles.Yeah, but the user does not care about content-blind bistream formats. She just wants to use her files. So I guess I'll have to place myself squarely on the other side and say I rate functional distinctions that are meaningful to the user above distinctions based on underlying low-level data format. I am particularly unsympathetic to telling users that they don't want certain distinctions.> > P.P.S. I'm not flaming, or at least I don't mean to be. I think > > everything I've said has been courteous and based on facts and > > reasoning. Can't speak for others though. > > No, you and Ali have both been polite and reasonable. We're just testy > about having to rehash this design decision again.I think in light of the substantial new arguments and information presented, at the very least a new justification for the decision which in some way addresses them is owed. But I can understand some level of testiness.> > Hopefully cordial in return, > -ralph >I believe you indeed have been, 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Jack Moffitt <jack@icecast.org> writes:> > The first page should have a TOC that says what kinds of streams are > included within, and probably some way of linking them together. > > This is a difficult design decision. Do not expect this to be complete > in beta3 :) > > I'll try and post a few ideas and usch later today, and we can start > discussing a SOLUTION. We now know that there is a PROBLEM. > > I'm sorry that it took so long to get this out of the way, and I > appreciate the persistance of the Nautilus team in bringing this up. >Jack, Sorry for being a bit pushy about this, and thank you for looking into a solution! I got the sense from the other developers that they felt the situation was not in fact a problem. Maybe I was just misinterpreting though. One thing I'd like to suggest is that your proposed TOC if any, list an intended primary purpose for the file in addition to a list of contained stream types (audio, video, other) to address issues others have raised about how it might not be possible to tell the purpose of a file just by looking at the list of stream types. Thanks for your attention to this, 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On 27 Oct 2000, Maciej Stachowiak wrote:> One thing I'd like to suggest is that your proposed TOC if any, list > an intended primary purpose for the file in addition to a list of > contained stream types (audio, video, other) to address issues others > have raised about how it might not be possible to tell the purpose of > a file just by looking at the list of stream types.Monty and I discussed this a bit today; I thought I'd post a progress summary. We've both found the arguments you (Maciej and Rakholh) have made convincing, but it remains to develop a technical solution. We've always (well, as long as I've been around :) planned on having some kind of stream description metadata for when we've got more than one substream. Because of the way the ogg bitstream format is stuctured, the only place this can go is in another logical substream. Adding a tag like you suggest will be simple enough. What's not clear is how to arrange for this to be efficiently testable. As I said before, the only way I can see mime-magic working is to key on the filename extension, or to guarantee that the first substream will be a special-purpose, binary table effectively adding a header to the headerless ogg. We're not really willing to do either of those. That's about as far as we got. I've definitely added efficient type-determination the the requirements for the metadata header, but unless someone has a brilliant idea, a limited substring search will probably be required. :-/ We still wish you wouldn't fork the mimetype, if only because we don't know how we're going to do this yet. The only ogg files we're generating now are "degenerate" in that they contain only a single vorbis substream. However, since "efficient type determination" almost certainly means putting the stream description metadata substrem (whew!) first, looking for 'vorbis' at byte 29 like I initially suggested is probably not the best idea. Associating application/x-ogg with the initial 'OggS', and handing that to ogg123 by default strikes me as the most future-proof. FWIW, -ralph -- giles@ashlu.bc.ca --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Ralph Giles <giles@ashlu.bc.ca> writes:> > Monty and I discussed this a bit today; I thought I'd post a progress > summary. > > We've both found the arguments you (Maciej and Rakholh) have made > convincing, but it remains to develop a technical solution.Excellent! I'm glad we could provide useful input on this issue.> > What's not clear is how to arrange for this to be efficiently testable. As > I said before, the only way I can see mime-magic working is to key on the > filename extension, or to guarantee that the first substream will be a > special-purpose, binary table effectively adding a header to the > headerless ogg. We're not really willing to do either of those.Why is the second approach you mention a problem? You can always make some default assumptions if this initial stream is missing. While being headerless is a laudable goal, I am not sure how the metadata header you describe below is different. But I am not up on all the issues.> That's about as far as we got. I've definitely added efficient > type-determination the the requirements for the metadata header, but > unless someone has a brilliant idea, a limited substring search will > probably be required. :-/Substring search in a range, or unlimited substring search in the whole file? I think with a proper design for the metadata header will make it really easy to do efficient sniffing. A fixed offset is really best for overall efficiency.> We still wish you wouldn't fork the mimetype, if only because we don't > know how we're going to do this yet. The only ogg files we're generating > now are "degenerate" in that they contain only a single vorbis substream. > However, since "efficient type determination" almost certainly means > putting the stream description metadata substrem (whew!) first, looking > for 'vorbis' at byte 29 like I initially suggested is probably not > the best idea. Associating application/x-ogg with the initial 'OggS', and > handing that to ogg123 by default strikes me as the most future-proof.I'd agree that we should stick with "application/x-ogg" and "OggS" as the magic string for now. I will advocate this approach for the time being. - 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Ali Abdin <aliabdin@aucegypt.edu> writes:> > Right now, I temporarily "forked" the mime-type to use 'OggS' to map to > "audio/x-ogg" (this will just "identify" the file in Nautilus as an OGG file > (which is the description). > > Nothing "depends" on this yet though (such as Music Preview, or 'View as > Music'). At this point in time I see no difference between "application/x-ogg" > and "audio/x-ogg" so I don't see a real incentive to change (especially since > you guys are working on this alternative stream description metadata substream). > > I am now just putting in this "audio/x-ogg" in there and forgetting about it > ;) I do intent to change it as soon as: A) a new Ogg codec is > developed/released or B) you get the 'stream description metadata substream' > done :) > > Of course, I could switch it to "application/x-ogg" just for the sake of > changing, but I'd rather not >Ali, Please change it for now. It won't really matter until non-audio Ogg files are popular, and hopefully the Ogg developers will have a solution for file type detection by then. Since all current Ogg files are audio-only, it might make sense to have the type be audio/x-ogg for now and add application/x-ogg and video/x-ogg later when there are actually multiple types and a detection mechanism, but that's not the way the Ogg guys want to do it and we may as well go with what they suggest for the time being. Thanks, 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
xiphmont@xiph.org (Monty) writes:> > Please change it for now. It won't really matter until non-audio Ogg > > files are popular, and hopefully the Ogg developers will have a > > solution for file type detection by then. > > I assume that making sure you have easy file magic is a sufficient > additional mechanism? >Yes. Presumably at that time the multiple mime types can go into effect. - 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
maybe work together with XMMS/Nautilus developers to make a Music preview component based on XMMS so input/output plugins could be reused instead of rewritten? That way we wouldn't need to write independent plugins for Nautilus. And it would be nice to see a mini XMMS appear in Nautilus' "View as music" view. -- Manuel Amador (Rudd-O) --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
"Manuel Amador (Rudd-O)" <amadorm@usm.edu.ec> writes:> Please: > > This is just my own preference. I use XMMS for both audio and MPEG > video, and I don't have any problems about it. I DO think XMMS needs > some sort of video framework so it can be more useful instead of just > instantiating a new window for each video (that's annoying). So I think > application/ogg is enough since your file manager/browser needs to start > only one application.You hit the nail on the head with the first sentence: this is your preference. Many people have a very different preference and would like to use different applications for audio and video. Having distinct mime types allows both your preferences and theirs to be met - you can just set the same default application for both, and they can set different ones.> You could also preview ogg files' audio data containing video by > hovering the mouse over its icon, by using ogg123 in the background. > Anyway, they probably contain audio too.Yes, but a better way to preview video might be to play a short clip in miniature, and/or to show the key frame even when not hovering.> I think that the Nautilus file types and programs capplet should also > show a checkbox "Can be previewed as music" for each defined MIME type, > or infer that data for those MIME types that have the view "View as > music" available, and make that clear in the FTAP capplet.Nautilus only knows how to play the audio file types it knows about; changing this setting won't make nautilus magically able to play some arbitrary new sound (or other) format.> Oh, and a call for the Nautilus developers. Try to copy the ideas from > the KDE control center's MIME setup. It's EONS ahead from the current > state of Nautilus' one. If I were a beginner, I might have some > problems with KDE's MIME setup, but I'm sure that Nautilus' MIME setup > would be positively impossible for me to use.We do plan to revise the control center applet (we all agree that the current one is messy; mostly we copied the old one and changed it to work with gnome-vfs). We are unlikely to take the KDE one as the primary model. If you have specific criticisms or suggestions for improvement, those would be welcome. - 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.