Out of those three formats, the most practical for IF purposes is MP3. Historically, Blorb didn’t support MP3 because of patent concerns. But those patents expired almost a decade ago now (in the US; in the EU it’s almost two decades), so this should no longer be an obstacle.
An MP3 file has chunk type 'MP3 '. This is a high-quality (but lossy) audio compression format with widespread support. The MP3 format is documented at:
Section 14.3 mentions that the Z-machine should treat AIFF sounds differently from Ogg sounds. I suggest that MP3 should be treated like Ogg for this purpose until such time as “future versions of the Z-machine [specification] address this issue”.
It’s a very small change to the specification, and it won’t have much real-world impact until software is updated to support it. But that updating won’t happen until the spec is updated, so we have to start the ball rolling somewhere! And better now than after Inform 11 is out with BINA workarounds in place.
As context: MP3 support in browsers is essentially universal at this point, and has been since 2012.
Ogg support is alsoclose to universal – but only as of March 2025 (when Safari 18.4 added it). IE is still missing Ogg support, and I assume always will.
So there is at least some argument for saying “Safari caught up, we’re good now.” This may not be a strong argument considering that we want to support Macs more than a few years old. But we should at least compare the probable timeline for adding MP3 support to the timeline for “most people” getting off of older Safari versions.
(I believe all Macs built 2019 and later can install MacOS Sequoia and therefore Safari 18.4.)
The immediate proposal is to update the Blorb spec. Along with this, we should update Blorb-handling software; for my part that includes
I know there was some discussion of audio formats on the I7 dev repo (either github or jira). But I was having a busy month (year) and didn’t follow it carefully. Which now of course I regret. Can someone summarize? Zed? Dannii?
My concern is whether I7 has started moving down a path that assumes this is not happening, in which case we have more than one train to re-route.
I’m not heavily involved in that part of the I7 discussion, but my understanding is that Inform really wants to have MP3 support even if Blorb doesn’t (as part of its upcoming support for non-Blorb-using web interpreters). So the current proposal is to accept MP3s as sound resources on the I7 level, and trust non-Blorb interpreters to handle them correctly; if the story is compiled to a Blorb, I7 will emit a warning and embed the MP3 as a meaningless BINA chunk.
Per Graham’s write-up at IE-0042 that Daniel linked to above, Inform now does include “minimal” support for MP3’s. This exists in current development Inform.
…which Daniel already said this while I was writing this.
Inform 11 supports MP3s mainly in separated mode (for Parchment, Bisquixe etc). If you do a Blorb release then it currently embeds MP3s as a BINA chunk. It would be good to swap that to an official chunk before Inform 11 is released.
I assume we’ll need some Glk changes too? Just a gestalt for support? Or does it need more than that?
I frankly wouldn’t even give it a gestalt. Call glk_schannel_play and see if it returns success or failure. The only sound format that currently gets a gestalt is MOD, specifically because it’s so weird and hard to support; it’s assumed that if sound works, then OGG and AIFF work.
I began to heavily favor ogg vorbis personally when I began to adopt open source software across the board. (The only thing that isn’t, outside of games, is Windows, which is my best choice for an OS, seeing as Apple has largely stopped updating the VoiceOver screen reader for the most part, and Linux’s screen reader, Orca, is lacking in many features that are required in the modern era. Also, it looks like Google’s TalkBack is getting somewhat worse as far as response times as well, so I may end up needing to switch to an iPhone.)
This conversation started out about MP3s in blorbs for web users. But i don’t see why you’d want to put media in a blorb for web serving at all. Surely, it makes the serving of streaming media more difficult. Why not just have all media outside the blorb?
Regarding lossless formats, this is nice for local copies of games, but not nice for web serving of media. Because it’s going to be bigger and cost more download bandwidth. The only exception is Wade’s point about latency. You might want some sounds to be very low latency, such as a mouse click sound. You could afford these to be lossless when such sounds are very short.
It’s more that Inform wants to support the same set of formats regardless of whether you’re compiling to a blorb or a web site. Currently, the development version supports MP3s when compiling to a web site, but not when compiling to a blorb, because the blorb format doesn’t allow it.
You could use several fetches to fetch the header, and the chunk headers, and defer loading media until after the executable resource chunk has been loaded.
I think that would mean, with a little work, we could get even massive blorbs to be loaded fine in the browser.
It’s a bit of a different scenario, since SQLite conveniently uses fixed-sized pages, but I’ve seen HTTP range requests used to run quick SQL queries over a 600MB+ SQLite database that was hosted for free on GitHub pages.
Yes, you are right about this. It would actually be possible to range request excepts of blorbs and even stream them.
I use range requests in my web interpreter quite a lot. Mostly for streaming. eg video. so I’m range requesting parts of a video file or audio file. not a blorb or some single-file archive.
it could be done for blorbs, but whether the work is worth it, is another question.
For web deployment, you also have other stuff like fonts, JavaScript and css. so these probably wont stream from inside the blorb. What this would mean, is you’re jumping through hoops to stream fro the blorb but, on the other hand, allowing some game content to be separate. It kind of kills the idea of a single archive. insofar, as web deployment anyway.
Time to catch up on this! As I reminded by the fact that there’s an I7 proposal in progress.
The short answer is, we’re going ahead, with 'MP3 ' as the chunk type. Type strings are four bytes, so that’s 0x4D503320.
Assorted questions:
I prefer that layout too. In fact the I7 proposal is “Release along with separated resources”. But the single-file package also has its place. And, as Draconis says, we want format parity between the two models. (So that it’s easy to flip between them.)
Range requests for parts of Blorb files is interesting but way outside the scope of what we’re looking at. :)
Cool. I have updated my blorb tool Bamboozle to accept MP3 files without a warning – previously it would notify the user that MP3 was only supported for ADRIFT games.