Tip Toi Reveng turns a toy pen's file format into a toolchain

Reverse engineering a children's audio book pen

The stated goal of this project is to understand the file and paper format for the Ravensburger TipToi pen, and the ultimate goal is that everyone can create their own books, with their own sounds.

That is the whole scope, and it is a narrower and more interesting one than a general media tool. A TipToi book is a paper book with printed codes, and a pen that reads the codes off the page and plays audio. The audio lives in a GME file on the pen, and the format of that file was undocumented. The project set out to work out how it is put together, and the current status is stated plainly: most of the file format is understood, and the understanding is written down in the GME file format specification, GME-Format.md.

The tool that came out of that work is tttool, and it does two different jobs. It dissects existing files, so you can find out what is inside a GME file you already have, and it generates new ones from scratch.

The project is written in Haskell, which is worth noting for a format reverse engineering effort, since the C implementation in the same repository, libtiptoi.c and gameanalyse.c, is there as an alternative tool for investigation and for replacing audio files in GME files, and can be compiled and run for diagnostic output.

The licence is MIT, with a LICENSE file at the repository root, and the project has a German-language user site at tttool.entropia.de alongside the repository and its wiki.

The command set is organised by what you want to do

The tttool subcommands are grouped in the documentation by intent, and the grouping tells you how the project thinks about the format.

The creation commands are the ones that produce artefacts. The GME creation command is assemble, which creates a gme file from the given source. The OID code creation commands are oid-table, which creates a PDF or SVG file with all codes in the yaml file, oid-codes, which creates files for every OID in the yaml file with PNG as the default, and oid-code, which creates PNG files for each given code.

The modification commands are narrow by design: set-language sets the language field of a GME file, and set-product-id changes the product id of one. Both of those are the kind of edit you want without rebuilding the whole file.

The analysis commands are the largest group, and they are the reason the project exists. There is info for general information about a file, export to dump the file in the human-readable yaml format, scripts to print the decoded scripts for each OID, script for a specific OID, games for the decoded games, lint which checks for errors in the file or in the program itself, segments to list all known parts of the file with a description, segment for the segment containing a specific offset, explain for a hexdump with descriptions, holes to list all unknown parts, and rewrite which parses the file and writes it again for debugging.

The extraction commands dump all audio samples and all binaries. The simulation command is play, which interactively plays a GME file.

Global options are learned from ./tttool --help, including DPI settings, and each command has its own help. The wiki holds the longer explanations.

The holes command is the honest part of the tool

Two of the subcommands deserve more attention than the rest, because they describe the state of the reverse engineering rather than the state of the tool.

The first is holes, which lists all unknown parts of the file. A format reverse engineering tool that names the parts it does not understand is unusual and valuable, because it converts a vague sense that something is incomplete into a list you can work through. The segments command is the companion: it lists all known parts of the file, with a description, and segment prints the segment containing a specific offset.

The second is rewrite, which parses the file and writes it again, and the documentation marks it as being for debugging. That is a round-trip test with a specific purpose. If parse and write disagree, the file changes, and the tool can tell you where.

The repository also has a wip directory, described as work in progress, which contains notes about the parts of the GME files that are not fully understood yet. And the TODO section of the README is short and specific: what are all the header fields, with a pointer to wip/Header.md. A project that lists one open question, in the place where a README usually lists a roadmap, is being straightforward about its boundaries.

There is a further resource outside the tool. The oid-decoder.html page allows you to manually decode an OID image, which is the case where you have a printed code and want to know what it maps to without running anything.

Making a book means recording audio and writing YAML

The process for building your own GME file is described as four steps, and each one is concrete.

First, record the audio samples you want to include, as Ogg Vorbis files, mono, 22050Hz. The README shows the sequence it uses:

        arecord -r 22050 foo.wav
        oggenc foo.wav
        rm foo.wav

The format constraint is specific and matters: mono Ogg Vorbis at 22050Hz. Second, write a my-book.yaml file containing general information and, especially, the scripts, meaning what to do, for each OID, meaning the various fields of a book. The example.yaml file is offered as a starting point and is said to contain more information in its comments. Third, run the assemble command and make sure it reports no error, which the README phrases as finishing silently. Fourth, copy the generated my-book.gme file to the pen.

The debug path is the clever part of the workflow. If you need to find out which OID code corresponds to which part of the book, you generate a debug GME using the debug.yaml file, adjusting its Product-Id to your product's id, build it with the assemble command and load the result on the pen. The pen will then read out the codes as a sequence of English digits, which gives you a way to map codes to fields by listening rather than by guessing.

If your existing audio is in another format, the README points at ffmpeg:

    ffmpeg -i input-audio-in-some.fmt -ar 22050 -ac 1 foo.ogg

The same mono, 22050Hz target applies.

Text to speech and printing your own pages

Two extras make the workflow practical rather than theoretical.

The first is text to speech. If you have libttspico-utils and vorbis-tools installed, tttool can generate the audio files from text for you, which the README says makes developing the yaml file much easier. There is a text2speech.yaml file with more information, and a text2speech-multi-lang.yaml for multiple languages, so a multi-language book is a configuration choice rather than a new tool.

The second is printing. With the code in the repository you can create GME files, and the README makes the obvious extension explicit: it is even more fun if you can also create your own books. The work of working out how to do that was done by a contributor named Pronwan, demonstrated in a video, and explained in a thirty minute video tutorial in German.

That is the part of the project that is genuinely unusual. Most reverse engineering efforts stop at understanding a format, and the point of understanding it is usually to read or extract from someone else's files. This project states the intent up front, that the ultimate goal is that everyone can create their own books, with their own sounds. The paper side of the format is as much a part of the target as the file side, and the oid-table and oid-codes commands exist to produce the code pages to print.

The print-ready outputs are a PDF or SVG table of all codes, and PNG files for individual codes, so the paper can be generated from the same yaml that describes the audio.

Building it, and where the project actually is

The distribution is a zipfile for Windows and Linux users, found in the releases section of the GitHub project, and Linux users are likely to want additional packages, with the README naming the command:

sudo apt install libttspico-utils vorbis-tools

Those two packages are the ones the text to speech and the audio conversion steps need, so the dependency note and the workflow note are the same fact seen from two directions.

Building from source is covered in Building.md, and the Makefile shows what it involves. The tttool target depends on src/*.hs and runs cabal install for the dependencies and then for the binary into the current directory, with a commented-out cabal update. The all target builds the three C programs as well:

tttool: src/*.hs
	# cabal update
	cabal install --only-dependencies
	cabal install --bindir=.

So the toolchain is the Haskell one, GHC through cabal, with the frozen dependency set in cabal.project.freeze, and the C helpers compiled with gcc. The repository also carries a default.nix and a shell.nix, so a Nix build path exists, and a 34c3-ad directory.

On maintenance, the picture is mixed and worth stating carefully. The repository is not archived and the last push was on 2026-07-21, so work continues. The releases, however, are old: 1.11 and 1.10 both from 2023-02-11, and 1.9, the Big-Mac-Release, from 2019-12-05. There is a Changelog.md in the repository.

That combination, a maintained branch and a stale release list, is a familiar one for a project whose users build from source. The releases are for people who want a binary, and the README points anyone building to Building.md, which is where the current state of the code is described.

Editorial conclusion

tip-toi-reveng suits someone who owns a TipToi pen and wants to make their own books with their own sounds, and who is willing to write YAML and record Ogg Vorbis audio. It is the wrong tool for a general media workflow, and it is the wrong tool for anyone who needs every field of the format, because the project still lists the header fields as an open question. Before you adopt it, read GME-Format.md for what is actually known, install libttspico-utils and vorbis-tools on Linux because the text to speech and audio steps need them, and check the wip directory before assuming a field you need is understood.

Frequently asked questions

Official sources

1. entropia/tip-toi-reveng on GitHub
2. License: MIT
3. Project website
4. README
5. Releases