The problem with midi

UPDATE: The problem has now been resolved!

When I first set up the tune search, back in 2009, I seem to remember it wasn’t too difficult to provide an embedded midi player next to each tune … once I’d got around Internet Explorer’s quirks, that is.

Sadly however, it seems to be getting harder rather than easier. And it’s not just me that thinks that: as w3schools says “Playing audio in HTML is not easy!

Although people often think of midi files as sound files, strictly speaking they contain a series of instructions (when a note starts, when it ends, etc) and thus enable computers and electronic musical instruments to communicate with each other. I guess this has meant that midi files are a bit more difficult to handle than sound files such as mp3.

In this post I’ll explain the problems and list some of the possible solutions I could try in order to solve it. I don’t have a good solution yet, so I’d welcome feedback – either identifying web browsers where it works/doesn’t work, or, if someone out there has managed to solve the problem easily, some suggestions.

I’m also going to use this post to list some of the useful pages I’ve found – partly for my own benefit, but hopefully they will be helpful to others too.

The plug-in option

Because different computers support midi files in different ways, probably the easiest method is to use the <embed> and/or <object> html tags to embed the midi player.

Both tags use a plug-in, usually either QuickTime or Windows Media Player, depending on how the user’s computer is configured, to actually play the midi (this means, of course, that the plug-in has to be installed on the user’s computer – although easy for the user to rectify, it is potentially a problem as it means that the website can’t guarantee what will appear on the page).

<embed> is the older tag which was (I think) originally introduced by Netscape, dropped in HTML4 & XHTML and then reintroduced in HTML5.

It was replaced in HTML4 & XHTML by the <object> tag, which still continues in HTML5; <object> is slightly better than <embed> as it can be configured to degrade gracefully (e.g. to provide alternate text if the tag isn’t supported).

HTML5 also has the <audio> tag, which would be ideal, but it only supports mp3, wav and ogg files.

The current solution

Currently uses the <embed> tag as this seems to have the best cross-browser support. See UPDATES at the bottom of this post.

When supported, both <embed> and <object> will show an embedded QuickTime midi player looking something like this:Currently this will work in Firefox, Chrome & Safari for both <embed> and <object> tags and in Internet Explorer for the <embed> tag. I believe this is true for both PCs & Macs.

The <object> tag doesn’t seem to work in Internet Explorer and for me either shows an empty scrollable pane (IE 8 & 9) or nothing at all (IE 10).

On PCs, depending on how they are configured, Internet Explorer will sometimes render the <embed> tag to show an embedded version of Windows Media Player looking something like this:However, that hasn’t been working for me recently on any of the PCs I have access to.

Unfortunately, almost nothing works on mobile devices, far as I know.

For example, iPads don’t support midi as a file format, although if you download the midi file you can find apps that will play them. (Most midi apps have far more features than you need to simply play a file and hence are quite expensive but a cheap one I have found is called Symphonix Evolution Player.)

Even when <embed>/<object> tags do work, one downside is that the embedded player automatically downloads the midi file whether or not the play button is pressed. This is not so great for a page of search results with 10 tunes on it because it means that when downloading the page, the browser has to make 10 additional requests to the server.

Possible alternatives

Ideally I would like a portable player that works on all devices. What would be even better would be a player that only starts to download the midi file once play is pressed (like the video and mp3 streaming players you see on various websites).

Here are some thoughts about the possibilities:

Javascript solutions

The obvious solution, because of its portability, is to use javascript … except it obviously isn’t that straightforward.

Paul Rosen & Gregory Dyke,  the developers of abcjs (see , have built a javascript generator that generates midi directly from the abc found on a webpage. However, it relies on the QuickTime plug-in and therefore suffers from the same issues as above.

The closest generic solution I have seen is MIDI.js (see However that only seems to work well in Chrome; as the page says “Firefox and Safari can both perform a bit more like the piano has been drinking” and that’s a generous assessment. So not so portable, but definitely heading in the right direction (and it very nearly works on the iPad, in Chrome anyway).

Another javascript solution I found is Jazz-Soft (see However that requires the user to install another specific plug-in. Interestingly, there is an abc based demo at

File conversion solutions

A second option is for the server to convert midi to mp3 or ogg on the fly and then use the <audio> tag or even the yahoo javascript player (see to play it on the user’s computer.

This seems like it might possible with Timidity and Lame but it would take some configuring. It would also result in a lot more data being transmitted from the site.

BTW if anyone knows of a java-based midi-to-mp3/ogg converter, please let me know.

Applet-based solution

My original plan was a java midi-player applet.

I very nearly finished implementing it (including a slider for speeding up/slowing down the playback and download-on-demand – only downloading when play is pressed) and it could be rolled out on the abcnotation site fairly soon if there was the demand. However, I have stepped back from developing it further because applets are outdated, not completely portable (e.g. they don’t run on iPads) and because recent security scares mean that not everybody is comfortable about installing java on their computer.


So those are the problems. If anyone has any comments, thoughts or suggestions please add a comment below, join the discussion on the abcusers mailing list or contact me directly.


UPDATE 1 (17th July 2013):

I still can’t find a way of embedding a midi player in the tune pages which will work reliably in Internet Explorer so I have switched the site back to using the <object> tag because it degrades better (allowing a download button in place of the player). There is more information on the tune search help page.

Note for webmasters: The latest version of QuickTime, 7.7.4 (May 2013), has become more strict about the midi MIME-type and no longer supports embedded midi if the MIME-type is set to “audio/x-midi” or “audio/midi” (which you will find recommended on a number of sites around the web). Many thanks to Gerhard Schacherl who pointed this out to me.

The fix is to set the MIME-type to “audio/mid” in the <object> tag. However, as far as I know this only works in FireFox and Internet Explorer. I do not have a fix which will work for Chrome, Safari and Opera browsers (other than the user reinstalling QT7.7.3).

The best coding I have found, therefore, for including an embedded midi player is as follows – obviously to use this you would need to change “midifile” to match your own file name (in two places) and you can configure the width and height as you choose:

<object type="audio/mid" data="midifile.mid" width="240" height="45">
  <param name="src" value="midifile.mid"/>
  <param name="autoplay" value="false"/>
  <param name="autoStart" value="0"/>
  Your browser does not support embedded midi

Hope this helps. If so, please create a link to this note (i.e. as I do not believe this is widely known.

UPDATE 2 (December 2014)

I have given up on trying to provide a midi player on the website – they are not well enough supported by the major browsers, let alone on mobile devices.

Instead, I have gone down the file conversion route mentioned above and the tune pages and search results pages use the HTML5 <audio> tag to provide the player. This means that, when requested, the server converts midi files into either mp3 or ogg format on the fly (not all browsers support mp3 and not all of them support ogg either so both must be possible).

The command line string to do the conversion uses TiMidity++ and LAME and on a Linux server are as straightforward as:

timidity file.mid -Ow -o - | lame - file.mp3
timidity file.mid -Ow -o - | lame - file.ogg

You will also need a soundfont installed – I use 8MBGMSFX.SF2 from

UPDATE 3 (August 2021)

The problem has now been resolved with a JavaScript library called html-midi-player!


Tags: , , ,

2 Responses to “The problem with midi”

  1. Very nice article. It is really surprising and hard to believe that MIDI is so badly supported. I am strugling to find an acceptable solution for my site, but it seems so hard.

  2. Chris says:

    Yes – especially since MIDI is such a compact format, it’s particularly disappointing that the HTML5 <audio> tag doesn’t support MIDI.