cBlorb versus perlBlorb

Authoring Inform 6
1

Besides the language they’re written in, are there any meaningful differences between cBlorb and perlBlorb?

2

cBlorb does a whole lot of other Inform 7 releasing stuff.

3

I suppose I’ll use cBlorb then. I think I’ve sucessfully converted it into a form that can be used stand-alone. My next problem is how to create a viable Blorb file with audio samples. I can make a Blorb with Zcode alone and one with a picture resource, but not sound. If I try to make with sound, cBlorb reports all is well, but the resulting file won’t load and if I open it up with rezrov, it reports a broken file: “End of file while reading resource data.”, and gives me only one sound file.

Maybe I’m not getting the syntax right? The docs I’ve found for the syntax of the Blurb file are either out-of-date or vague.

4

Possibly related: there is a bug in BlorbLib 1.0.2 to do with reading sound resources. The code for bb_load_resource_snd() contains the following line:

    err = bb_load_resource(map, method, res, bb_ID_Pict, resnum);

which should clearly be

    err = bb_load_resource(map, method, res, bb_ID_Snd, resnum);

This may be why your test file isn’t working in your interpreter. I fixed this years ago in Windows Frotz, so if you have a Windows system you could try with that interpreter.

5

I think you might have pointed that out to me a couple years ago. The line in the Unix Frotz codebase was fixed a while ago

I tried running a few random blorbs from the IF Archive (lecture.zblorb, LiveJoseph.zblorb and LMS_TVG.zblorb). They all work with my latest Unix Frotz up at Github. Nothing I create by manually running perlBlorb or cBlorb works. Nor does a blorb from the Gnome Inform7 IDE work.

"soundtest" by "David Griffith"
When play begins:
say "This game is a test of sound stuff.".
The WhiteRoom is a room. "It's just an ordinary room.  Nothing special about it."
The doorbell is a thing in the WhiteRoom.  Instead of pushing the doorbell: say "Ding dong!"

I was trying earlier to make this code emit proper sounds, but rolled back to just getting a viable blorbfile.

Incidentally, Windows Frotz crashes with a “Call to non routine” if I do anything that causes a sound to play in spy1.blb.

6

I’ve just tried your example source under Windows Inform 7 and it seems fine: the resulting Blorb loads into Windows Frotz.

I don’t know what “spy1.blb” is, though - I’ve never heard of that one.

7

It’s “THE BLORB FILE: or, The Spy Who Came In From The Garden”, a demo that’s found at
http://inform-fiction.org/zmachine/standards/blorb/index.html. I’ve been using that as a touchstone for getting things like audio working.

8

I’ve narrowed part of my trouble to an ongoing bug in Unix Frotz with file extensions. Knowing that, I can now build a blorb containing a zcode exec and the default other stuff that gets thrown into a blorb. That one loads and analyses as a valid file. Now consider this code:

"soundtest" by "David Griffith"
When play begins:
say "This game is a test of sound stuff.".
The WhiteRoom is a room. "It's just an ordinary room.  Nothing special about it."
Sound of bell is the file "dingdong.aiff".
Sound of gong is the file "dingdong2.aiff".
The doorbell is a thing in the WhiteRoom.  Instead of pushing the doorbell: say "Ding dong!".

Note: I’m still trying to figure out the correct syntax for causing a sound to be played. This example will go ding as soon as the game starts, at least in the embedded interpreter.

If I build and package this, I’m left with a broken blorb. Both Windows and Unix Frotz will reject it with an “Unknown Z-code version” error. Note the absurd length of the FORM chunk. The actual size of the file is sane, though.

$ scanblorb bad.blb 
scanBlorb 1.0 [executing on 1120817 at 04:12.47]
File length claimed to be 042ca6 = 273574 bytes
0000000c: RIdx chunk with 000034 = 52 bytes of data
          Resources index:
          000048: Exec 0
          025396: Pict 1
          03b5b6: Snd  3
          03f132: Snd  4
00000048: ZCOD chunk with 024e00 = 151040 bytes of data
          1.120817 (version 5)
00024e50: IFmd chunk with 000532 = 1330 bytes of data
0002538a: Fspc chunk with 000004 = 4 bytes of data
00025396: JPEG chunk with 016217 = 90647 bytes of data
0003b5b6: FORM chunk with 733b0000 = 1933246464 bytes of data
Error: incomplete chunk at 0003b5b6

If I use rezrov and open up the blorb, I’m given a zcode file, only one .aiff and an error of “End of file while reading resource data.”. I don’t know if the zcode that went in is the same that came out because if I compile without wrapping into blorb, I get something that looks totally different under a hex editor. The .aiff file comes out with an extra byte of 0x00 appended. Because the old perlBlorb script also makes similarly broken blorbs when .aiff files are added, I suspect that I found a very old and obscure bug in perlBlorb that Graham inadvertantly reimplemented in cBlorb. Your thoughts?
dingdong.zip (11 KB)

9

The IFF spec (and therefore the Blorb spec) has the requirement that all chunks be padded to even length. This AIFF file has an odd length. So the 0 byte on the end of that chunk is mandatory. (The padding is not included in the length field.)

You’d have to post the blorbs for me to verify this, but it sounds like rezrov is failing to account for the padding byte, and therefore reading the file wrong.

10

Now that I look, the spy1.blb and spy2.blb files appear to be invalid. None of my IF tools can read them. Nor can Zoom or Gargoyle.

Forget 'em. I’d say “update the web site”, but I don’t think anybody’s in charge of the web site any more.

11

Here’s a copy of spy1.blb that I know works in Windows Frotz, Unix Frotz, DOS Frotz, and sFrotz. It also tests good using blorbScan and I can extract all the contents using rezrov. Here is also a copy of the bad blorb.
bad.zip (153 KB)
spy1.zip (99.5 KB)

12

Yes, that looks good to me.

13

Any ideas on the bad one?

14

Looks like a bad length field? Not off-by-one, but completely screwy.

The chunk length on the first AIFF chunk is 1933246464, or 0x733b0000. Maybe that’s supposed to be 0x733b, although that doesn’t match any of the lengths in the valid blorb file. I think it’s just wrong.

15

What happens if you use the Windows Inform 7 IDE to build the second game I posted and wrap it up with two AIFF files?

16

I don’t know why I didn’t fully appreciate this problem at first. It seems that rezrov.c has a bug in it that causes it to create invalid AIFF files when extracting from a Blorb file. Those files I extracted from spy1.blb I then tried to reencapsulate into another Blorb. That’s where my problem started. But still, there’s code in perlBlorb and cBlorb that is supposed to pad chunks if they’re not even, but the code doesn’t seem to work.

17

An odd-length AIFF file is technically invalid, but I think we’re on the wrong side of Postel’s Law there. Lots of them exist, and AIFF-playing libraries accept them, so they’re never going to go away. We should pass them through the Blorb layer unchanged.

18

Whoops, I edited something and you responded to my old post.