times.
After a few times helping people get MIDI working correctly on the Web, I've finally gotten around to what I've been threatening to do and am writing up a page on it.
No. Although the information on this page was written specifically to address MIDI files, it can apply to WAV or other types of audio files. The main difference would be that the MIME types would be something other than 'audio/midi' and 'audio/x-midi'.
Here is one common problem on the web. It's WYSIWYG not WYSIWOG! Basically, Hey! it works for me, why doesn't this work for other people?
So far in my experience as far as MIDI in web pages goes, this is usually been caused by one thing: servers not sending the proper MIME type. Correcting this server problem has cleared up all the end user problems. There are other work-arounds that fix some cases, but if it is a server problem, fix the server.
OK, well sometimes is does happen that it is a problem with improper markup for the MIDI file. But usually it is the other problem.
So far in my experience as far as MIDI in web pages goes, this is usually been caused by one thing: servers not sending the proper MIME type. Correcting this server problem has cleared up all the end user problems. There are other work-arounds that fix some cases, but if it is a server problem, fix the server. (hmmm... familiar)
Guess what here? In all the cases I have seen, it is a problem with the server changing and sending the wrong MIME type. (Gee, see a theme here?)
Here is where a lot of the problems people are having can be tracked to. In general, when a server sends a file to a web browser, it should send an item in the header telling the browser what type of data the file is. The Web uses MIME type strings to identify this. For a generic text file, the MIME type is "text/plain"; for an HTML file it is "text/html". MIDI files should be sent as "audio/midi" (or the somewhat outdated "audio/x-midi"). The problem is that sometimes they are not.
When there are problems, the servers often send MIDI files as "text/plain", "application/octet-stream" or sometimes "audio/mid". None of these is the generally accepted type, and this will cause problems on some systems. Since it is only some systems that have problems, it is not always easily recognized.
What I usually do is just simulate an HTTP connection by hand, issuing a HEAD method in order to get the info and look at the MIME type that the server is sending, along with many other details. Of course, I'm a programmer, enjoy using command-line tools, and that sort of thing. If you already know how to do the HTTP thing, go ahead, otherwise just use a different way.
If you are running Netscape, then this is fairly easy. From the "View" menu, select the "Document Info" menu item. Then click on the MIDI file and look at what is displayed under "File MIME Type:". Not as much detail, but much easier.
Simple. Get the server admin people to fix their problem. They might say something like "Hey, it works for most people, and all you need to do is change your program to recognize .mid". BZZZTTT! Wrong answer! Thanks for playing. (Gee, can you tell I'm opinionated on this one?). The server is supposed to be providing the proper content type. If it does not, the client software will try to make its best guess, but it is still just a guess. For example, on a Macintosh, the filename is supposed to be meaningless as far as determining its content goes. If the server sends the wrong type (as opposed to the far more rare sending of no type), then the browser it supposed to treat it as the type the server sent.
If the ISP is giving you a hard time about supporting proper MIME types, tell them to check the RFC (1945). It is fairly clear on not sending the wrong MIME type:
If and only if the media type is not given by aContent-Typeheader, as is the case forSimple-Responsemessages, the recipient may attempt to guess the media type via inspection of its content and/or the name extension(s) of the URL used to identify the resource.
[The emphasis is on "only if" theirs. The Simple-Response is
usually for the outdated HTTP version 0.9]
You can always tell them to look here and read for themselves what to do.
Here is the problem. Some people want to have background music for their web pages. Some people find it very annoying (Sometimes I find it very annoying, especially when my 3-year old daughter is sleeping in the next room, or I'm at work and they are giving a demo in the next room...).
OK, I won't get into the whole debate on why to do it here (just be aware that it exists). I'll just cover the how.
There are two main approaches to this. The first is to place a link for the MIDI file somewhere in the page so that someone viewing the page can click on it and activate the music. The other is to use a proprietary markup tag to place the music. For the link method, there is really only one way to do it. The other method has lots of variations.
So, we have these:
There. That's it. Short, simple and works on just about any browser around. Probably on any browser capable of playing MIDI assets.
| Tag | <A> | <EMBED> | <BGSOUND> |
|---|---|---|---|
| From | HTML | Netscape | Microsoft |
| AOL browser | Yes | ? | ? |
| Lynx | Yes | No | No |
| Mosaic | Yes | ? | ? |
| MSIE | Yes | Some | Yes |
| Navigator | Yes | Yes | No |
| Opera | Yes | No | Yes |
| WebTV | Yes | No | Yes |
| IBrowse (Amiga) | Yes | No | Yes |
| most everything | Yes | ??? | ??? |
Please send me mail with any info for updates to this chart
There are two main ways of embedding MIDI files in a web page:
This is where the big debate starts. You have two different tags, both will get the same results. Which one should you use?
<BGSOUND SRC="name.mid" LOOP=INFINITE>
<EMBED SRC="name.mid" AUTOSTART=TRUE LOOP=TRUE WIDTH=144 HEIGHT=15 CONTROLS=SMALLCONSOLE>
NO.
The main reasoning for placing both tags in a document was that since MSIE will ignore the <EMBED> and Netscape will ignore <BGSOUND>, both browsers will work and neither will show any ill effects. Well, starting with MSIE 3.0, MSIE now supports the <EMBED> tag. If your page is being viewed by someone with MSIE >= 3.0, and they have plugins enabled, they will get a broken link, or their browser will actually try to start the sound twice. On most systems that will cause Windows to throw up a system error dialog. Bad.
Also, the <EMBED> method for MSIE 3.0 is recommended by Microsoft for playing sound on NN and MSIE.
(Please note that I am talking about both tags, not both browsers)
Currently I am aware of two main solutions in use. The first is to use JavaScript to present only the sound tag for the current browser. The second is to use an <OBJECT> tag to obscure the <EMBED> tag from systems that can handle <BGSOUND>. There are problems with both solutions. Try just using a link.
There is another solution that has been presented. I think that it should do the job nicely, but let me know if any problems come up. What it does is surround the <BGSOUND> tag with <NOEMBED> </NOEMBED> tags to hide the <BGSOUND> tag from IE 3.0.
<EMBED SRC="name.mid" AUTOSTART=TRUE LOOP=TRUE WIDTH=144 HEIGHT=15 CONTROLS=SMALLCONSOLE></EMBED>
<NOEMBED>
<A HREF="test.mid">Some BG music (MIDI, .42K)</A>
<BGSOUND SRC="name.mid" AUTOSTART=TRUE LOOP=INFINITE>
</NOEMBED>
Here is the sample in action:
---------------
---------------
I have a short list of others sites relevant to this issue