David Mitchell <mitchell@ucar.edu> writes:> Ralph Giles wrote: > > > > On 15 Oct 2000, Maciej Stachowiak wrote: > > > > > I don't really know the details of the discussion, but I'd like to > > > present this issue from a user-oriented perspective, and from the > > > perspective of how Nautilus wants to use data files. > > > > Thanks for your well argued perspective! It's nice to see rhetoric isn't > > entirely dead. :-) > >Ralph, thanks for your kind words regarding my writing skills, but I'll wait to see the results before I rest on my laurels.> > > You could argue that ogg apps should be universal and handle all types > > > of ogg data. But when it comes to multimedia, it's pretty clear that > > > users _don't_ want to use the same application for video and audio, > > > regardless of the underlying data stream format. I think very few > > > people use xanim to play MPEG audio, and equally few people use xmms > > > to play MPEG video, despite the fact that the underlying data format > > > is fundamentally the same. And indeed, we see distinct mime types for > > > audio/mpag and video/mpeg, and distinct file extensions. > > > > Given our differing assumptions, your argument hinges here. I completely > > agree that users prefer separate applications for audio and video, but had > > usually put cause and effect in the other order. The interfaces on video > > players seem uniformly clunky--perhaps because of the direct visual > > relation to the content, perhaps because of lazy programmers. Certainly > > the complexity of a VCR remote doesn't translate nearly as well a cd > > player's control panel. > >I think the fact that users prefer different programs for video and audio, even in the presence of programs that can handle both, speaks for itself. Writing a program that handles both well is clearly more challenging that one that specializes - this to me indicates by itself that the program is filling different needs. While on one level it's true that a word processor is "clunky" for dealing with tabular numerical data, this is usually taken as a sign that spreadsheets are necessary, not that word processors are broken.> > 12cm optical disks were chosen for DVD to leverage shared functionality > > with CDs, and perhaps to enjoy a familiar physical format. And yet, we > > sell them in very different cases to avoid consumer confusion because > > they'll not work in cd drives or so people will pay more. > > > > Can you argue from a usability (as opposed to popularity) standpoint that > > there are significant benifits to audio-only specialization? > > I would turn this around and ask if there are any significant > benefits to generalizing audio-only and video players. Audio-only > files really are different from video files, at least from a > users point of view. A common feature of MP3 players is shuffle. > Is this likely to ever be used in a video player? On the same > note, it's nice if your video player will let you display a > single frame, or fast forward and rewind by a single frame. Not > to mention grabbing screen shots. Would you ever do any of these > with an audio-only file? > > I would argue that to a user, there is a world of difference > between their audio files, and their video files. They are used > for different things in different settings. The fact that they > might use a common underlying container or stream format is not > important to the user. It's a technical implementation detail > that should be hidden from the user in most cases. It doesn't > make any more sense to lump together all Ogg container files than > it does to lump together all ASCII text files. Do we argue that > your email, .c, .html, and .txt files should all use the same > MIME type because they are all implemented in ASCII? Of course > not. MIME is being used to provide file typing for the user. > Users treat audio files differently from video files. The MIME > typing should reflect that fact. >I agree with everything David says. He said it better than me. I'll further mention the different ways audio and video are used. Audio is often used in a purely background way, while the user is doing something else. Video files, on the other hand, are generally given the user's full attention, or at least most of it. This leads to the differing features David mentioned. Another thing to note is that audio players are often carefully designed not to take a lot of screen real estate since they're mostly used in a background way. However, for a video player, using more screen real estate is actually meritorious. While I can conceive of a program that would make a nice audio player _and_ a nice video player, I'd consider it a clever multipurpose program rather than a program that unifies two obviously related things.> Going back to your DVD vs. CD comparison. Most DVD players will > play CD's, and some people have gotten rid of their CD players > because of that. But does that mean that there is no longer a > need for CD-only players?I have both a DVD player and a 200-disc CD changer and I'm not dimping either any time soon. :-)> As a user of a heavily MIME typed OS (BeOS), my opinion is that > we should have an audio MIME type, and a video MIME type. The > creator of a file should have some way of tagging it to indicate > what they consider to be the "primary" use of the file. Can an > Ogg video player play an audio-only file? Sure. And if a user > wants to use the same player for both, they can easily set their > system up that way. But I don't think we should force them to do > that. Going back to the BeOS, by default it uses the same > application for both audio and video files. And that app works > OK. But, there are lots of third party audio players which > provide more functionality (such as playlists). With MPEG files, > I can easily configure my system to use the built in player for > video files, and whatever player I want for MP3 files. I don't > want to lose that functionality when I start using Ogg files. >It's particularly worth noting that having two mime types does not preclude using the same app for both ogg audio and ogg video - you just set up your system to associate the app with both mime types. However, having one mime type for both makes it very difficult to set different apps as the default handlers for each. Thanks for chiming in, David. - 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.
Maciej Stachowiak wrote:> > David Mitchell <mitchell@ucar.edu> writes: > > > Ralph Giles wrote: > > > > > > On 15 Oct 2000, Maciej Stachowiak wrote: > > > > > > > I don't really know the details of the discussion, but I'd like to > > > > present this issue from a user-oriented perspective, and from the > > > > perspective of how Nautilus wants to use data files. > > > > > > Thanks for your well argued perspective! It's nice to see rhetoric isn't > > > entirely dead. :-) > > > > > Ralph, thanks for your kind words regarding my writing skills, but > I'll wait to see the results before I rest on my laurels. > > > > > You could argue that ogg apps should be universal and handle all types > > > > of ogg data. But when it comes to multimedia, it's pretty clear that > > > > users _don't_ want to use the same application for video and audio, > > > > regardless of the underlying data stream format. I think very few > > > > people use xanim to play MPEG audio, and equally few people use xmms > > > > to play MPEG video, despite the fact that the underlying data format > > > > is fundamentally the same. And indeed, we see distinct mime types for > > > > audio/mpag and video/mpeg, and distinct file extensions. > > > > > > Given our differing assumptions, your argument hinges here. I completely > > > agree that users prefer separate applications for audio and video, but had > > > usually put cause and effect in the other order. The interfaces on video > > > players seem uniformly clunky--perhaps because of the direct visual > > > relation to the content, perhaps because of lazy programmers. Certainly > > > the complexity of a VCR remote doesn't translate nearly as well a cd > > > player's control panel. > > > > > I think the fact that users prefer different programs for video and > audio, even in the presence of programs that can handle both, speaks > for itself. Writing a program that handles both well is clearly more > challenging that one that specializes - this to me indicates by itself > that the program is filling different needs. While on one level it's > true that a word processor is "clunky" for dealing with tabular > numerical data, this is usually taken as a sign that spreadsheets are > necessary, not that word processors are broken. > > > > 12cm optical disks were chosen for DVD to leverage shared functionality > > > with CDs, and perhaps to enjoy a familiar physical format. And yet, we > > > sell them in very different cases to avoid consumer confusion because > > > they'll not work in cd drives or so people will pay more. > > > > > > Can you argue from a usability (as opposed to popularity) standpoint that > > > there are significant benifits to audio-only specialization? > > > > I would turn this around and ask if there are any significant > > benefits to generalizing audio-only and video players. Audio-only > > files really are different from video files, at least from a > > users point of view. A common feature of MP3 players is shuffle. > > Is this likely to ever be used in a video player? On the same > > note, it's nice if your video player will let you display a > > single frame, or fast forward and rewind by a single frame. Not > > to mention grabbing screen shots. Would you ever do any of these > > with an audio-only file? > > > > I would argue that to a user, there is a world of difference > > between their audio files, and their video files. They are used > > for different things in different settings. The fact that they > > might use a common underlying container or stream format is not > > important to the user. It's a technical implementation detail > > that should be hidden from the user in most cases. It doesn't > > make any more sense to lump together all Ogg container files than > > it does to lump together all ASCII text files. Do we argue that > > your email, .c, .html, and .txt files should all use the same > > MIME type because they are all implemented in ASCII? Of course > > not. MIME is being used to provide file typing for the user. > > Users treat audio files differently from video files. The MIME > > typing should reflect that fact. > > > > I agree with everything David says. He said it better than me. I'll > further mention the different ways audio and video are used. Audio is > often used in a purely background way, while the user is doing > something else. Video files, on the other hand, are generally given > the user's full attention, or at least most of it. This leads to the > differing features David mentioned. Another thing to note is that > audio players are often carefully designed not to take a lot of screen > real estate since they're mostly used in a background way. However, > for a video player, using more screen real estate is actually > meritorious. > > While I can conceive of a program that would make a nice audio player > _and_ a nice video player, I'd consider it a clever multipurpose > program rather than a program that unifies two obviously related > things. > > > Going back to your DVD vs. CD comparison. Most DVD players will > > play CD's, and some people have gotten rid of their CD players > > because of that. But does that mean that there is no longer a > > need for CD-only players? > > I have both a DVD player and a 200-disc CD changer and I'm not dimping > either any time soon. :-) > > > As a user of a heavily MIME typed OS (BeOS), my opinion is that > > we should have an audio MIME type, and a video MIME type. The > > creator of a file should have some way of tagging it to indicate > > what they consider to be the "primary" use of the file. Can an > > Ogg video player play an audio-only file? Sure. And if a user > > wants to use the same player for both, they can easily set their > > system up that way. But I don't think we should force them to do > > that. Going back to the BeOS, by default it uses the same > > application for both audio and video files. And that app works > > OK. But, there are lots of third party audio players which > > provide more functionality (such as playlists). With MPEG files, > > I can easily configure my system to use the built in player for > > video files, and whatever player I want for MP3 files. I don't > > want to lose that functionality when I start using Ogg files. > > > > It's particularly worth noting that having two mime types does not > preclude using the same app for both ogg audio and ogg video - you > just set up your system to associate the app with both mime > types. However, having one mime type for both makes it very difficult > to set different apps as the default handlers for each. >I agree that tagging a hierarchical media format containing audio, video or both with a mime type in the form "audio/x-..." or "video/x-..." may seem kludgy and limiting but in practice it works out just fine (the above mentioned BeOS is an excellent example, as are the audio and video MPEG mime types). Regardless of whether you accept the arguments for using "audio/x-..." and "video/x-..." style mime types (and you should :-) there is no reason to not include provisions for magic type identification and make the same mistake the mp3 file format did. I suggest you add easily identifiable magic strings to your file format header. These strings should: - be at least six to eight bytes and contain a mix of printable and non printable characters. - be located as close to the file start as possible, at most 128 bytes from it but preferably closer. - express the essential variants of the enclosed data - the identifier should describe whether the enclosed media data are audio, video or both. You could for example have the following strings: \003\005OggS\001\000 \003\005OggS\000\001 \003\005OggS\001\001 at offset 0 of your file format, identifying Ogg audio data, Ogg video data and Ogg video with sound data respectively. Pavel P.S. The .tar.gz format was designed before mime types and mime magic was widely used in modern desktop apps. You no longer have this as an excuse :-) --- >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.
Hi, I followed this discussion with interest and, as I understandind it (and I apologize if I've missed the whole point) the two sides of the argument are: - There should be different file extensions/mime-types for each different usage (audio, video, etc.) - There should be one type which will cover all cases however specialized. Now while I appreciate the need to accommodate special applications, I do think the vast major of people will use ogg for music and video and might not want to use the same application for both. So my question is why not have both! The ogg extension could be the basic file type and would cover all possible uses (including music and video if wanted), and you could define subsidiary file types that deal only with music or video. This way some super application could be written which deals with all possible uses (or hands them on to other applications), which is general but would, by necessity, be a compromise between different uses, while file containing music and adhering to strict rules (only contains one audio stream and meta-data stream) can be handled by a specialized program which is great at playing music but hasn't a clue about video etc. Just an idea, or did I miss something? Ric. _____________________________________________________________ Want a new web-based email account ? ---> http://www.firstlinux.net --- >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:> > The solution is simple: one MIME type, several programs associated with > it. >I don't understand. This still means the user has to pick the right program to use each time, unless it's the most preferred one (nautilus does let you associated many programs with one mime type, but all except the first only show up on the "Open With >" menu). On the other hand, having multiple mime types and associating the same program with each one is an easy task that can be done once, after which all files will open with the user's program of choice. I understand that you prefer to use the same program for both audio and video files. But having multiple mime types is not incompatible with your preference, so your arguments against it sound like an attempt to enforce your preference on others. Why are you trying to make things hard on people who don't share your preference? - 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:> > I don't understand. This still means the user has to pick the right > > program to use each time, unless it's the most preferred one (nautilus > > does let you associated many programs with one mime type, but all > > except the first only show up on the "Open With >" menu). On the other > > hand, having multiple mime types and associating the same program with > > each one is an easy task that can be done once, after which all files > > will open with the user's program of choice. > > ...or the 'preferred program' is an intelligent launcher that can look > at the file magic.Some of the weaknesses of this approach: 1) The intelligent launcher needs to be configured separately from the user's normal file type --> program mapping 2) The user can't tell what program will be used to launch a file without trying it. This could be fixed by making the launcher have a special `--print' mode where it just prints the name of the program it would run. But the file manager having to launch this external program many times just to get this information would be very wasteful and poor design. 3) The user doesn't get the feedback of different icons and type strings for files that will be handled with different programs. Once again you could hack this by having a `--print-subtype' mode or the like for the external launcher program, but now it seems like you've constructed three types, only part of the magic sniffing is done by an external executable. This again seems like poor design. 4) Using such a launcher program for one mime type might be feasible despite the difficulties, using one for many different file types makes the problems above compound quite a bit. 5) It's an unnecessary (though admittedly very small) performance hit. If you're going to present the file format as three different file types to the user, and at a lower level dispatch to launching three different programs, what is the value of having an intermediate layer that pretends there is only one file type? It only seems to add gratuitous complexity. Why not keep it simple and have three mime types (which people who so choose can easily map to the same icon, type string and launcher program, or treat all three exactly the same in their application) instead of one (where people who want three different launchers, icons and type strings must jump through many hoops)?> We'll be sure static magic is available and easy to use once we go > to non-degenerate streams (and degenrate Vorbis streams already have > static magic).Yep, this is great, the only step that's left is mapping these magic numbers to suitable mime types.> Mime type is simply insufficient for identifying contents od container > file types. We can admit it and go on to find an adequate solution, > or we can keep beating our heads against this already bloodied wall. I > don't feel like saddling a technology I expect to live for a minimum > of 20+ years with the limitations of a system we already acknowledge as > ill-suited to the task (mime type).mime type will definitely live for 20+ years as well, whether you like it or not. mime type is not perfect (more than 2 levels of hierarchy and decent support of containers are two things it does not handle well) but it's too ingrained in too many things to go away. Life sucks that way. Further, the definition of the mime types is external to the code or file format itself. If the world ever abandons mime types, it will be easy to ignore the previous mime type definitions.> > Why are you trying to make things hard on people who don't share your > > preference? > > This requires only a little extra technical tinkering to make it clean > *and* convenient. We're no more likely to give up our design than you > are yours. Neither one of us has to.I disagree. A lot of people have some prima donna file format that they think should be handled specially, but hardcoding special handling of each of them is a waste of valuable time. It's not like having three mime types ("audio/x-ogg", "video/x-ogg", "application/x-ogg") creates a huge administrative or coding burden. It's not like it even fundamentally affects the design, since the magic to do the detection will aready be there. And it has trivial effect on the user/developer experience for people who want to treat all three types exactly the same. I do not buy the cleanliness argument. Epicycles sure seemed more clean than a helicentric model for a while. But the proof is in the resulting total system complexity. Sorry if I sound a bit strident here. I am a bit frustrated at having to argue the same point repeatedly. - 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.
Dan Conti <dconti@acm.wwu.edu> writes:> I dont see how you expect it to survive for 20+ years when such a > challenge exists to adapt it to container types. See more below.It's currently used heavily in email, http, and many other internet protocols. I see no viable strategy for replacing it. Therefore, flaws and all, mime types will continue to exist. Maybe there will _also_ be something better. That would be nice. But the backwards compatibility is not going to go away. Most importantly, no one has proposed a better model for how a user can set up his system to use different players for audio files and video files. The only alternative proposals I have heard (rely on per-file metadata, or use a configurable launcher program that does dispatching) both seem worse in specific ways I have described at some length.> > So what happens when someone puts a meta data stream for lyrics in an ogg > bitstream? Or (for whatever reason) someone streams subtitles along with a > movie, but in a seperate stream? Maybe the administrative or coding burden > is small now, but your approach generates recurring maintenance.The data streams should be tagged according to primary intented use, audio, video, or multimedia/other. In the two cases you mention, the obvious primary uses are audio and video respectively (the user's default audio or video player may or may not be able to use those parts of the stream). Or if the text is somehow essential to the experience of the audio file such that audio-only playing (as with ogg123) would miss the point, the proper type is other. But in general, designing primarily based on the corner cases rather than the common cases leads to bad design. "Oops, it's hard to say whether some files are primarily audio, primarily video or other, let's just throw up our hands, and pretend there is no distinction. And then to solve the problems this causes, let's all call external programs somehow magically make that nonexistent distinction (??!?)"> > It's not like it even fundamentally affects the design, since the > > magic to do the detection will aready be there. > > > > And it has trivial effect on the user/developer experience for people > > who want to treat all three types exactly the same. > > > > > > I do not buy the cleanliness argument. Epicycles sure seemed more > > clean than a helicentric model for a while. But the proof is in the > > resulting total system complexity. > > > > Sorry if I sound a bit strident here. I am a bit frustrated at having > > to argue the same point repeatedly. > > My compliments to you for your ability to religiously argue your point in > the face of so many non-believers.I don't think any of my arguments are religious. I certainly have not made any arbitrary claims without backing. There's two possible models for treating generic multimedia bitstreams: treating it all as one type, or treating it as distinct subtypes. While the latter model makes it trivial to model the former, the former makes it difficult to model the latter. What more could I do to establish this fact? I guess you could call it religious to favor arguments based on making it easier for users and developers to do what they want, over theoretical elegance of file formats.> I urge you to consider that you have consistently used a linear and > restrictive approach to how files should be treated by any given > system; not once have you considered that rather than adapting ogg > to suit your needs, that a more reasonable solution exists.Actually, it wouldn't require making any changes to ogg beyond what people have said they already plan to add. It might require creating two unofficial mime types in addition to the standard one which would be detected based on bits in a particular static location. I would rather not do that without the approval of the ogg hackers, but there is no fundamental technical reason that makes this impossible. Yet it would be far simple than mucking with inventing external programs to detect subtypes, and I would have a hard time convincing anyone it wasn't the simplest solution.> I also urge you to consider that, whereas this is a project in > development and input at this phase can possibly impact results, there are > other bitstreams that are have been through a few revisions, and if your > system can't properly address this problem with ogg then it will likely > have trouble with those formats.We don't have problems with MPEG video or audio, we can tell the difference just fine. Some legacy file formats do have problems being handled reasonably (a .tar.gz file being everyone's canonical example). However, ogg does not have the excuse of being invented decades ago and well past revising, unlike both tarballs and mime types. I do not understand the religious fervor around this issue. You are willing to add bits to files to make them detectable as different subtypes in a simple, static way, yet you are not willing to declare these different types to be distinct mime types. I really can't understand the logic here. It's just some strings. They will make some people's lives easier (comparing strings is way simpler than perfroming arbitrary computation on file contents). They won't make anyone's harder, as far as I can tell. It has exactly _zero_ effect on the file format itself, it's just a string mapping, so it definitely does not tie the format unnecessarily to any obsolete technologies. So what's the big deal? I don't really want to argue about this any more since it leads to endless going in circles. I just hope you guys do the reasonable thing in the end. Later, 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.
Chris Hanson <cmh@bDistributed.com> writes:> I think part of the reason this issue keeps coming up is that there > is no generalized "media framework" used on most Unix variants. > Instead, there are a number of libraries which implement various > formats, each with their own APIs. > > Contrast this with the Macintosh. If I were to implement file > preview functionality on the Macintosh, I'd use QuickTime. If > QuickTime knows how to open a particular file as a Movie, I can then > examine that movie for sound and video tracks. Or -- and this is > more likely -- I can just set up a standard QuickTime controller and > let it handle all of the playback etc. for the preview. > > If I then write a media import component and an audio decompressor > for Ogg Vorbis, anything which uses QuickTime gets support for Ogg > Vorbis for free *including file preview*. > > I bet the situation on Windows is similar. >I don't think that's really the issue. People still write pure audio players on Windows, Macintosh and BeOS, all of which are reputed to have good integrated multimedia frameworks. In fact, experienced Macintosh and BeOS hackers, as in people who worked _on_ the operating systems, not just with them, tell me that many users like to replace the all-in-one media players that come with these systems with audio-specific ones for audio files. The desire of many users to use different programs for playing audio and video is in fact real and not a technological artifact. - 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.
Anthony Arcieri <bascule@holly.ColoState.EDU> writes:> > I don't see this as the real problem. I believe MIME's problem stems from > the fact that it can only list one property of a particular file, which > seems very shortsighted, especially when attempting to describe container > formats. >The goal of mime types is not to describe every possible piece of information about a pice of data, but to say enough about it that you know what program to open it with or what method to use to display it. Recall that mime types were originally invented in the context of email and having the receiving program figure out how to open and display sent data. This is in many ways a judgement call. There certainly aren't any first principles to work from for where to draw the line. You have to draw the line between letting users and programs make useful distinctions, and going into too much detail.> Likewise, I think the point the majority of the Ogg developers > have been trying to get across is that MIME is not an effective tool for > describing both the type and contents of container formats.That's true, but uninteresting. Users don't care about the container, they care about the contents and how they will use it. The primary purpose in life of a mime type is to help general programs figure out what specific programs to use to open a data stream. Thus, mime types should be designed, to the extent possible, to suit this end well.> The question I think we should be asking is if there is some > standard, alternative content description system which works better.I sure don't know of any, especially not one that works with email and the web. - 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.