Quadbike 2: Tape Transcriber

[Diminished]

LATEST VERSION (2.0.1) IS here

---

Need a recording of a tape transcribing on ${MODERN_64BIT_OS}?

quadbike-200-rc4.zip

(2.16 MiB) Downloaded 44 times

Checksums are here: https://pastebin.com/M20AjnJM

There are SIMD-enabled (AVX2, fast) and non-SIMD enabled (slow but more compatible) builds for Windows; please note that this is a command-line application that needs to be run under cmd.exe. There is no GUI for this software.

Users of other OSes will need to build from source (see src/build.sh).

I won't go into detail here, because the documentation is pretty extensive (docs/index.html). It contains more-or-less everything I've learned about tape transcription over the past two years. I would urge anybody else who is considering writing new tape transcription tools to study this document carefully. Trust me, it will save you time.

I have also thrown in the three PHP scripts csw2wav.php, cswblks.php and tibetuef.php (in php/). If you have a tape and need to make a UEF file from it, there are two ways to go: Generate a CSW (-o), and pass it to MakeUEF (on Windows); or generate a TIBET file (-t), and feed it to tibetuef.php (on any OS). You'll need PHP 7 or 8.

The new TIBET format really needs a public-domain reference decoder written in C, so I'll endeavour to produce one at some point. It is, in my opinion, a superior format to CSW because there should be no ambiguity in how it is decoded. This is not true of CSW. I hope maybe to add support for TIBET to an emulator or two. It should be 100% compatible with all known copy-protection systems. If I ever manage to finish my UEF-processing tool Cornfield, it will accept TIBET as an input format.

Let the bug reporting begin.

[vanekp]

A very comprehensive document, seems I will have to change how I have been doing my wav files as I have always been filtering them and converting them to 8bit format as CSW only support that and the documentation for it suggests you filter the file before processing it (and no I have not been keeping my original captured files).
At least the output for quadbike makes a bit more sense now, just need to understand the advanced options a bit more for problem tapes.

[Diminished]

I've now started writing a proper, strict reference decoder in C for TIBET files. This has thrown up some issues. I doubt anyone is desperate to implement a TIBET decoder urgently, but be aware that a mildly revised specification is in the pipeline.

QB2's code is unlikely to change, so releasing a whole new version of it would be overkill. I will just release updated documentation when I have the wrinkles ironed out.

[vanekp]

I saw you could create gzipped tibet files but seems if you create them you cant then use then with the php programs as it does not recognize it, guess that's not supported at this time.

I also notice that if the gaps have a some level of noise quadbike translate it into lots of Chunk even if i try run a filter for silent bits as I always did for csw.

[Diminished]

I saw you could create gzipped tibet files but seems if you create them you cant then use then with the php programs as it does not recognize it, guess that's not supported at this time.

The PHP script isn't great -- I wrote it quickly, just so that there would just be another path for making UEFs if you aren't using Windows. I hope eventually to come up with something better.

I also notice that if the gaps have a some level of noise quadbike translate it into lots of Chunk even if i try run a filter for silent bits as I always did for csw.

I'll see if I can add some sort of silence threshhold control in the next version.



I have been working on bolting a TIBET loader onto b-em. Still a lot of work to do, but it does now load protected tapes including Viper's Ultron (300/1200 baud switching), and Estra and Pace's Fortress (custom blocks with parity switching).

[vanekp]

I am curios how you insert the extra bits for copy protection in a tibet file for like switching parity and baud rate and how you know where to put them.

[Diminished]

I am curios how you insert the extra bits for copy protection in a tibet file for like switching parity and baud rate and how you know where to put them.

You only need those if you're trying to make UEFs. A properly-coded emulator doesn't need to be told what the baud rate and framing are, because its ACIA will already have been correctly programmed by the loader with the correct values. You won't need those lines to load protected TIBETs with B-Em.

There is no general way to know where to put the baud and framing lines. For something like Viper's Ultron it's obvious, because there are four blocks which load more slowly than the others, so they're clearly 300 baud ones. For things like Estra which switch serial framing in the middle of a block, you'd probably need to hack an emulator to get it to tell you exactly where in the tape the ACIA is reprogrammed. Then you'd have to split the TIBET data block into two separate data blocks using a text editor, and insert a framing change line between the two.

TIBET 0.4 will re-specify the baud and framing directives as optional hints rather than mandatory keywords -- /baud and /framing rather than baud and framing. B-Em's new decoder ignores these hints for loading, because the ACIA should already know what the correct values are. It will, however, respect these hints if you pick the "catalogue tape" option in the B-Em menu -- so if you have some MOS files saved at 300 baud, "catalogue tape" should be able to see them if you include this information in the TIBET file.

[vanekp]

so won't be easy with games that use a lot of parity switching for copy protection with this system, easier to stick to make uef then.
as for example Estra you need the following in makeuef -z 35 8e1 -z 38 8o1 -z 40 8e1 -z 44 8o1 -z 46 8e1 -z 52 8o1 -z 54 8e1 -z 56 8o1 -z 59 8e1 -z 61 8o1 -z 66 8e1 -z 69 8o1 -z 71 8e1 -z 73 8o1 -z 75 8e1 -z 78 8o1 -z 80 8e1 -z 85 8o1 -z 89 8e1 -z 93 8o1 -z 95 8e1 -z 98 8o1 -z 100 8e1 -z 104 8o1 -z 107 8e1 -z 109 8o1 -z 111 8e1 -z 114 8o1

[vanekp]

I also noticed using quadbike that its is very sensitive to silent areas of tape that are a bit nosy, it or gets confuses altogether or you get lots of blocks of Non-stanadrd data between files.

[fuzzel]

I've downloaded Quadbike 2 today and the early indications are very favourable. I set it to work on a couple of WAV files I'd created previously using GoldWave and it successfully extracted a few short programs which CSW Viewer was unable to. I also attempted to recover my Toccata and Fugue in D minor file but it failed on one block unfortunately - not bad though. I was wondering, for optimum results, what settings I should use for Goldwave to create the WAV? I'm currently selecting mono with 44100 sampling rate and then removing high frequencies with the initial cutoff set at 3600 and steepness at 1.

[Diminished]

I've downloaded Quadbike 2 today and the early indications are very favourable. I set it to work on a couple of WAV files I'd created previously using GoldWave and it successfully extracted a few short programs which CSW Viewer was unable to.

That's great news! An endorsement!

I was wondering, for optimum results, what settings I should use for Goldwave to create the WAV? I'm currently selecting mono with 44100 sampling rate and then removing high frequencies with the initial cutoff set at 3600 and steepness at 1.

You're obviously welcome to experiment with different input processing, but in my testing I tended to find that filtering the input often yielded worse results. I agree it does seem logical that pre-filtering might be a sensible idea, but digital filters can alter the phases of the two frequencies relative to one another, which can be a problem for Quadbike. (The documentation does mention this, but the documentation is a very long read).

Quadbike does of course have its own pre-filter (which is supposed to be linear-phase), which you can activate with the -f option, but I never found it very useful. Your mileage may vary.

44100 Hz should be just fine. You can go up to 48000, and it might improve things if you're lucky. I suspect that a more critical input setting than using 48 KHz may be to sample the audio at 24-bit, but you generally need some high-quality sampling gear (e.g. music production equipment) in order to get 24 bits. Most motherboard sound devices tend to max out at 16 bits.

Sampling the source in stereo might be a good idea. If only one channel suffers a signal drop-out at a particular point, it may be possible to manually paste the audio from the other channel to obtain a fully-working input. (You can actually do this after processing as well by copying and pasting TIBET files, but it may be a bit more fiddly.)

Do remember that Quadbike has various modes and options. There are two sync modes that are known to be equally as effective on different tapes: -s pll and -s freq; you can pick left or right channels with -c L and -c R. The --scale-hf-pwr option can also be very good; you can try --scale-hf-pwr 0.5 and --scale-hf-pwr 2.0 as starting points, and these will resolve many tapes that would not load perfectly otherwise.

In general, a rough guess at the quality of the output produced can be gleaned from the "odd runs" messages:

Code: Select all

    Odd runs (before fix): (data 0/1): 3/4; (squawk 0/1): 3/6.
    Odd runs (correction): Inserted 7 atoms.
    Odd runs (after fix) : (data 0/1): 0/0; (squawk 0/1): 3/6.

The fewer odd-runs that are reported, the better, so you can try tweaking --scale-hf-pwr to minimise these numbers. Another quick way of divining the quality of the file produced is to request CSW output (-o) and then run cswblks.php against this output (my own test procedures work this way). In time I hope to replace all of these PHP stopgap tools with a proper C utility, but it has been a while since I have had the chance to make much progress on this.

You can also try messing with the various -e options to try to get some error correction if just one or two blocks are troublesome (although -e isn't often very effective).

I also noticed using quadbike that its is very sensitive to silent areas of tape that are a bit nosy, it or gets confuses altogether or you get lots of blocks of Non-stanadrd data between files.

I'm working on version 2.0.1 now. The main change to the software in this version is an improved tibetuef.php which supports more chunk types, but I am also adding an option --hush-threshold to Quadbike, which should hopefully help with the problem you mention.

[fuzzel]

Thanks for this, I'm saving my original recording as 8-bit WAV (mono), 16-bit WAV (stereo) and FLAC. This gives me three chances of a hit on each block. The tape I'm working on btw is an old C90 comprising a number of games - Lords of Time, Castle of Riddles, Bumble Bee, Planetoids, Cruncher, Danger UXB and the mysterious Adventure Sato. I may have shared a copy of an old WAV with you when you were developing Quadbike. I'm getting close to recovering Adventure Sato which is &5E blocks on length but I'm still missing eight blocks (all three saves are missing the same blocks). I wonder if Quadbike would be more successful if I only presented it the Adventure Sato recording rather than the full C90? Does decreased variability across the tape increase my chances? Also, I haven't looked into tibet, I need to understand if the data file it produces could help me reconstruct manually those blocks.

[Diminished]

Thanks for this, I'm saving my original recording as 8-bit WAV (mono), 16-bit WAV (stereo) and FLAC. This gives me three chances of a hit on each block.

There is not much point keeping both FLAC and WAV -- they both contain exactly the same audio. FLAC is (basically) just a zipped WAV file.

I wonder if Quadbike would be more successful if I only presented it the Adventure Sato recording rather than the full C90? Does decreased variability across the tape increase my chances?

I would recommend this. I think a shorter input sample might help. Also, a shorter input file means Quadbike will finish faster, which is preferable if you're running it multiple times with multiple parameters.

Also, I haven't looked into tibet, I need to understand if the data file it produces could help me reconstruct manually those blocks.

I intended this file format to be human-readable, and easy to edit manually, which is certainly not true of CSW or UEF. It's just a text file, and the cycles on tape are just encoded as dots and dashes, so the TIBET representation is in black here:

[BigEd]

Thanks for this, I'm saving my original recording as 8-bit WAV (mono), 16-bit WAV (stereo) and FLAC. This gives me three chances of a hit on each block.

Be sure to try the left and the right channels of the stereo recording individually.

The levels that you used to capture the recording in each case may also have an effect: a likely cause of trouble in the original tape is a dropout, which is a great reduction in level. If your recordings are at a low level, those small numbers will be even smaller. It might be worth specifically taking a new digital capture at a high level - I'd suspect that a bit of clipping won't be a problem where the signal is strong, but you may get a benefit where the signal is weak.

[fuzzel]

Need a recording of a tape transcribing on ${MODERN_64BIT_OS}?

Yes please.
And does Quadbike 2 work? You betcha!!!!!!!!!!!



Ok, it took me seven attempts, three of which were FLAC (I didn't realise that I didn't need to do FLAC) and of the four WAV files, one was 8-bit mono and three were 16 bit stereo. The options that worked the best in the end were:
8-bit mono with --scale-hf-pwr 2.0 -o which scored a success rate of 93/95 blocks
16-bit stereo with --scale-hf-pwr 2.0 -c R -o which scored a success rate of 92/95 blocks

Both were different Goldwave recordings and interestingly they had different missing blocks.

I'm hopeful that I can now go through my entire tape collection and if I find anything missing from all known archives I will of course upload them to stardot.

And speaking of missing games, I present - Adventure Sato, copyright T. Sato 1982. I've never heard of this one but I got it from the Washington Computer Club bitd.

DH Tape 2A.ssd

(25 KiB) Downloaded 21 times

[Diminished]

And speaking of missing games, I present - Adventure Sato, copyright T. Sato 1982. I've never heard of this one but I got it from the Washington Computer Club bitd.

DH Tape 2A.ssd

Great news. I'm glad my two years of work weren't wasted.

I assume T. Sato is this guy.

[vanekp]

Trying to use csw2waf converter but every csw file I try to use it gives a Error 04 or 05, does this only work on csw created with quadbike?


php csw2wav.php BugEyes(Icon)(1985).csw BugEyes(Icon)(1985).wav
csw2wav.php v3.1
M: Loading BugEyes(Icon)(1985).csw ... 145682 bytes.
E: Bad flags: 0x04

php csw2wav.php GetSetPartition(GriffinSoftware).csw GetSetPartition(GriffinSoftware).wav
csw2wav.php v3.1
M: Loading GetSetPartition(GriffinSoftware).csw ... 82369 bytes.
E: Bad flags: 0x05

[Diminished]

Trying to use csw2waf converter but every csw file I try to use it gives a Error 04 or 05, does this only work on csw created with quadbike?


php csw2wav.php BugEyes(Icon)(1985).csw BugEyes(Icon)(1985).wav
csw2wav.php v3.1
M: Loading BugEyes(Icon)(1985).csw ... 145682 bytes.
E: Bad flags: 0x04

php csw2wav.php GetSetPartition(GriffinSoftware).csw GetSetPartition(GriffinSoftware).wav
csw2wav.php v3.1
M: Loading GetSetPartition(GriffinSoftware).csw ... 82369 bytes.
E: Bad flags: 0x05

Can I have one of the CSW files, please?

[vanekp]

Here are the two I mentioned.

GetSetPartition(GriffinSoftware).csw

(80.44 KiB) Downloaded 21 times

BugEyes(Icon)(1985).csw

(142.27 KiB) Downloaded 24 times

[Diminished]

Here are the two I mentioned.
GetSetPartition(GriffinSoftware).csw
BugEyes(Icon)(1985).csw

Thanks.

These files are a bit strange because:

a) the CSW version in the file header is 2.1 rather than 2.0;
b) they have some header extension data;
c) they set bit 2 of the flags field in the header, and I don't know what this means.

I have updated csw2wav.php to version 3.2 which can now successfully WAV these files. The waveform of GetSetPartition looks very weird in places, but I have tested both WAVs on hardware and they seem to load OK.

Here's an updated PHP script.

csw2wav-3.2.php.zip

(4 KiB) Downloaded 18 times

[vanekp]

Here are the two I mentioned.
GetSetPartition(GriffinSoftware).csw
BugEyes(Icon)(1985).csw

Thanks.

These files are a bit strange because:

a) the CSW version in the file header is 2.1 rather than 2.0;
b) they have some header extension data;
c) they set bit 2 of the flags field in the header, and I don't know what this means.

I have updated csw2wav.php to version 3.2 which can now successfully WAV these files. The waveform of GetSetPartition looks very weird in places, but I have tested both WAVs on hardware and they seem to load OK.

Here's an updated PHP script.

csw2wav-3.2.php.zip

thanks for the updated version have tested it on a few csw files and seems to work fine now, I should have mentioned it also affects cswblks.php with these type of files.
the only think I have found on csw format specifications was this

0x02: Z-RLE (CSW v2.xx only)
Pulses are encoded exactly as in method 1, but the generated byte-stream is further compressed with the standard deflate() algorithm as defined by the ZLIB library (RFC 1151 and 1152). In fact the compression is equivalent to "gzip -9" (without the magic signature); the source code of the compression routines we used is the same as in our RZX SDK. [more tech details here].

[Diminished]

cswblks.php

cswblks-3.2.php.zip

(14.42 KiB) Downloaded 20 times

This also addresses a couple of other problems: the error-handling logic has changed slightly, and it now decodes the (1200 baud) blocks of Viper's Ultron correctly. I think the problem here was that the final block of the first file of Ultron specifies a very long block length, and so cswblks.php was assiduously eating up the blocks from another file in order to fulfil this oversized block length quota.

[fuzzel]

I'm trying to recover a game called Robots from one of my old tapes but I'm failing miserably having only recovered 6 of 25 blocks so far using Quadbike 2.0. I'd therefore like to learn how to employ tibet to perhaps recover the remainder but I could do with a short lesson in its use if someone would be so kind. I've had a look at the Quadbike help file but it's a bit over my head I'm afraid. What I've done for starters is to Quadbike the first program from Lords of Time (filename TIME) which is only one block long and I've created a uef of this as well as a tibet file. I've attached a screenshot of the contents of the file using MZAP and also the tibet file. Could someone explain how the tibet data is arranged please? I'm hoping that Quadbike fails to recover a block when there is a single error on one bit / byte of data so in fact most of the program may be intact. Following on from this is it possible for Quadbike to force a correction to ensure each block is recovered, albeit with probable corruption?

Code: Select all

# quadbike-avx2 --scale-hf-pwr 2.0 -c R -t time.tibet TIME.WAV
# Rate: 48000


tibet 0.3

/time 0.000000
silence 0.604187   # (seconds) [0]

/time 0.604458
/phase 0   # (degrees)
/speed 1.000000
squawk
.-......................--....................   # [29014] 
end

/time 0.623625
/speed 1.012147
leader 395   # (cycles) [29934]

/time 0.785875
/phase 0   # (degrees)
/speed 0.965138
data
--------..................................----..--..--..--......   # [37722] 
..............   # [39049] 
end

/time 0.819479
/speed 1.033364
leader 12129   # (cycles) [39335]

/time 5.702187
/phase 0   # (degrees)
/speed 1.035028
data
----..--..--..----..------..--..--..--..--..----..----..--..--..   # [273705] 
--....----..--..--..--..------..--..------------------..--------   # [274947] 
----------..----......--------..------------------..------------   # [276175] 
------..--..........------..----------------....----------------   # [277394] 
--..------------------..------------------..------------------..   # [278620] 
--..----..----..--..------------------..----------------....----   # [279850] 
--------------..------------------..------------------..--------   # [281087] 
----------..----..------------..--..--..............--..--....--   # [282308] 
------..------------------..----..--..--------..----....--------   # [283535] 
--..--....--..--........--......--....----..--..--....--------..   # [284758] 
------------------..--........--------..--..----..--------..----   # [285987] 
..--..--..----..----....------..--..--------....--..--..--..----   # [287224] 
--....----..--------......----..--..--....--------..------------   # [288454] 
------..------..--..------..--------..--..----..----..--..--..--   # [289684] 
--..--....--..----..--..--..--..------..--..--..----....--..--..   # [290921] 
----------....----..----..--..--..----..------....----..--..----   # [292161] 
......--..----..------..--..--..--..--..----..----..--..--..--..   # [293404] 
..----..--..--..--..------..--..--..--..--....----..------......   # [294632] 
....--..--..--....----..--..----..--..--..----..------....----..   # [295858] 
--..----......--..----..------..--..--..--..--..----..----..--..   # [297090] 
--..--....----..--..--..--..------..--..------..--....----..----   # [298326] 
--..........--..--..--....----..--..--....--------..--..--..----   # [299564] 
------..--..------....----..--..------....----..--..----....----   # [300789] 
..----..--......--....----..--....----....----..----..----....--   # [302029] 
--..----------....----..------..........--..--..--....----..--..   # [303265] 
--..--....--------..------------------..----........------..----   # [304498] 
------..------..----..--..--..----..----....------..--..--------   # [305733] 
....--..--..--..------....----..--....----....----..--------....   # [306957] 
..----..------....--..----..----------....----..------....--..--   # [308197] 
--..--..------....----..----..----....----..--------......----..   # [309427] 
--..--....--------..--..................--....--......----..----   # [310671] 
..--....------.....................   # [311903] 
end

/time 6.512062
/speed 1.030036
leader 4145   # (cycles) [312579]

/time 8.186021
silence 3.484000   # (seconds) [392929]

[Diminished]

I've had a look at the Quadbike help file but it's a bit over my head I'm afraid. What I've done for starters is to Quadbike the first program from Lords of Time (filename TIME) which is only one block long and I've created a uef of this as well as a tibet file. I've attached a screenshot of the contents of the file using MZAP and also the tibet file. Could someone explain how the tibet data is arranged please?

I'm not sure how better to explain it than is outlined in the documentation.

The highlighted section above is one byte of 8N1 data on tape, which is what most Acorn software uses. One cycle of slow 1200 Hz tone is a 0 bit. Two cycles of fast 2400 Hz tone is a 1 bit.

This byte or "frame" of serial data consists of a start bit S, eight data bits, and a stop bit s. The start bit is always a 0. The stop bit is always a 1.

The eight data bits are stored on tape in reverse, least significant bit first. Reversing the bits gives you the byte 00101010. This has a hexadecimal value of &2A, which is the ASCII character '*'.

The bottom line (the dots and dashes) are how this stream of cycles is represented in the TIBET file. Two dashes represents a single 0 bit. Two dots represents a single 1 bit.

If you look at the first few characters of the long block of data in the TIBET you posted, you have

----..--..--..----..

This is the bitstream sequence 0010101001. The first 0 is the start bit; the final 1 is the stop bit.

S01010100s

Again, the bits need to be reversed, so now we have

00101010

This is, once again, hexadecimal &2A, or ASCII '*', which is the "sync character" that begins every data block in Acorn MOS.

After that you have the block header, which contains load addresses, execution addresses, filename, block numbers and so on, which is all outlined here. These are built up out of bytes, which are all represented the same way as in the examples above.

Following on from this is it possible for Quadbike to force a correction to ensure each block is recovered, albeit with probable corruption?

This isn't the job of Quadbike -- it's the job of tools that process the CSWs or TIBETs it produces. I am sorry but these tools are not great at this time, because I am working on four things at once. You can try making a CSW rather than a TIBET and using cswblks.php instead of tibetuef.php. cswblks.php has the option +x to extract all blocks to a directory; it also has the option +r to attempt to repair damaged blocks by flipping bits in an attempt to make the data CRC match. You might be able to get more of the individual blocks out this way.

[fuzzel]

Thanks, that's a very clear explanation, I should be able to examine the tibet file now.

[vanekp]

with generating any decent output you need the best quality input file, or you end up with garbage in garbage out.
are your wave file of good quality to generate any decent uef files?

[fuzzel]

They're of variable quality. Most so far work reasonably well, if I adjust the settings I can usually get a complete file. I have one though which just happens to have a potentially new game which I'm really struggling with. It's very quiet comparatively and there's a bit of a clicking sound when the tape runs.

[fuzzel]

I've posted links to my Google Drive files with my cassette 3 WAV files on. There are four copies of side B with the Robots game on (two are mono and two are stereo) in case anyone wants to have a go at recovering the files. I've also added a link to side A.
viewtopic.php?p=392127#p392127

[Diminished]

New version: 2.0.1:

quadbike-201-rc1.zip

(2.17 MiB) Downloaded 46 times

Checksums: https://pastebin.com/AyYiuhFC

(Remember to check that the date on the pastebin is sane! I really need to host QB somewhere else)


Quadbike itself has not changed too much. I am now building using Visual Studio 2022 instead of 2017. The big change in this package is actually to tibetuef.php, but I'll get to that in a second.

I also noticed using quadbike that its is very sensitive to silent areas of tape that are a bit nosy, it or gets confuses altogether or you get lots of blocks of Non-stanadrd data between files.

I have added an option --hush-thresh to Quadbike which may help with this problem. By default, --hush-thresh has the value 4, but you can try increasing it. This should reduce the amount of rubbish that is transcribed between blocks. The default value is set very low, because it is much better to include data incorrectly than it is to omit data that should be present.

TIBET has been updated to 0.4, making it incompatible with prior versions.

tibetuef.php now reads gzipped TIBET files (.tibetz), fixes a bug in chunk &114, has neater output, and now compresses UEFs. More importantly, it also now generates a much wider variety of data chunks. For starters, it will recognise leader/dummy byte/leader patterns and encode these using chunk &111. More interestingly, though, it now supports encoding actual data using four different chunk types: &100, &102, &104, and even &114. You can force data transcription using non-&100 chunks with the options +102, +104 and +114.

• Chunk &100 is the default UEF 8N1-only chunk type, which is widely supported by emulators, but it is only useful for 8N1 data.

• Chunk &104 allows any type of framing, but this framing needs to be passed to the UEF generator (using manually-inserted hints in the TIBET file) in order to program the UEF chunks with the correct values. It is therefore not useful for general transcription of tapes in which the framing is not known beforehand.
  
  Chunk &104 is also widely supported by emulators.

• Chunk &102 is more flexible, because it encodes the bitstream in its entirety, including explicit start, stop and parity bits. There are a couple of disadvantages -- you can no longer just inspect the (gunzipped) UEF file's hex dump in order to read its bytes, and (more seriously) nothing yet supports reading chunk &102 (until tibetuef.php, nothing supported writing it either). I am in the process of overhauling B-Em's entire tape system, and the overhauled version now supports this chunk type. (I have not released a patch yet -- I needed to release QB 2.0.1 first, so I don't have to produce one B-Em patch for TIBET 0.3 and then another one for 0.4.)
  
  It is important to realise that chunk &102 still does not provide complete generality, however, because of 300 baud tapes. A title like Viper's Ultron switches between 1200 and 300 baud. Once again, a UEF generator needs to know which blocks are 1200 baud and which are 300 baud, because it will need to insert chunk &117 in order to switch the UEF from one rate to the other. If the baud switches are not known beforehand (and hints added to the TIBET manually), the encoder will mis-encode 300 baud data.
  
  However, there is one chunk type which does provide complete generality. Which brings me to

• Chunk &114 is not intended for storing data. This is the "security cycles" or "squawk" chunk, which is intended for encoding short bursts of cycles.
  
  However, it has a very generous 24-bit length field, which means it is entirely possible to abuse this chunk to store large amounts of data. Furthermore, since it encodes cycles, not bits, it is entirely appropriate for storing any framing and any baud rate. As a result, tibetuef.php supports encoding tapes using chunk &114, which provides all the generality of TIBET or CSW. (This is also supported by the upcoming B-Em tape patch).

[Diminished]

As an addendum to the above, here is Chuckie Egg in four different UEFs, utilising the four supported data chunk types (&100, &102, &104, &114). My expectation is that right now 100 and 104 will work in most emulators; 102 and 114 will not.

(All four of these load to completion in my modified local copy of B-Em.)

chuckie100.uef

(9.04 KiB) Downloaded 24 times

chuckie102.uef

(12.8 KiB) Downloaded 17 times

chuckie104.uef

(9.05 KiB) Downloaded 18 times

chuckie114.uef

(16.21 KiB) Downloaded 23 times