Acorn RISC OS Software available for download:

Last updated: 17 Jan 2010 (Scripts)

The following software was written on / ported to an A5000 with RISC OS 3.11 and some of the newer stuff on a StrongARM RiscPC with RISC OS 3.7. Most of it is unlikely to work on RISC OS 2. All software is provided in ZIP archives; you can uncompress them using SparkPlug / SparkFS, to name but two examples.

Since there is little room for this homepage the following programs are usually not kept locally any more but refer to the Stuttgart FTP server (apart from some exceptions, probably). Please inform me if any links to that server have changed so you can't access them anymore.

Software I wrote:

Applications

• Metamorphosis (release #2) (429345 bytes): A megademo I wrote some time ago. Includes texturemapping and vectormorphing. This is the StrongARM compatible release #2. Freeware.

• Deep4All V0.12 (15373 bytes): A viewer for sprites of any colour depth which also works on older (pre-RiscPC) machines. Converts a number of image formats (JPEG, GIF, TIFF, ...) to sprites in the background using ChangeFSI. Freeware.

• FastSpool V0.20 (8788 bytes): Fast data transfer to the parallel port (Freeware). Needs a computer with a new style parallel port (e.g. A5000, RiscPC,...).
  A much more powerful, commercial version called FastSpool+ was released at Acorn World 97 in association with Warm Silence Software. FastSpool+ is fully integrated into RISC OS, providing its own Filing System, true background printing (i.e. the spooler won't stall when you leave the desktop), supports more printers, can also drive old parallel hardware fast and and and. Available for £15 from october '97.

• Fractulus V0.10 (44540 bytes): Fractulus is basically a multitasking fractal generator environment. The frontend provides the user interface, the actual calculation is done by small programs I call cores. The interface between cores and frontend is documented so everyone with a little knowledge in ARM assembler can write their own. Fractulus can also create movies by calculating a sequence of sprites. Freeware.

• BreadPatch.zip V1.4: NEW (2 Sep 98) (29276 bytes) This is a patch for the Breadbox V0.44 by Denys Bogatz. It cures some bugs in the original version and gives the program simple IO (which makes programs like the Last Ninja-series work). This version also handles vectored Kernel-calls correctly (now the RealSIDPlayer works as well). Also $DC00 gives the correct value when reading now which makes some programs work that used to have difficulties reading the joystick in port 2. This version can patch both release #1 and release #2! That means both release #2's, the one you got when you bought it from Pulse Computer and the one that's now available as Shareware. Make sure you read the !Help file so you use the right patch. Freeware.
  Click here to download a Mahjongg variant I wrote a couple of years ago for my C64.

• Optimum Palettes (13822 bytes): This CLI-program reads 32bpp sprites and converts them to 1/2/4/8bpp sprites with an optimized palette using an iterative error-gradient approach. It's rather slow in spite of being written in assembler, but the result usually looks very good. It's currently Videoware but will probably become Shareware soon.

• PCLTools NEW (20 Oct 97) (59922 bytes): This is a collection of utilities for PCL printers (e.g. DeskJets, LaserJets). Programs marked PP will only work on a pageprinter (e.g. Laserjets).
  • asc2pcl: (PP) This allows fast text printing by using the printer-resident fonts. You can define your own formats (like 2up landscape). It also contains a powerful search and replace-engine that lets you for instance do context-sensitive C-printing (like Zap's coloured C-mode). Recompiled.
  • PDumperLJ: This is a patched version of Acorn's PDumperLJ V1.17. It uses more advanced compression techniques which means it doesn't work on older printers any more (AFAIK older than LaserJet 3) but compacts regular stuff like text to less than half the size of the original PDumper.
  • rpcl: Converts PCL printouts as created by the Acorn printer drivers (B/W, CMYK) to sprites. New version converts all the pages contained in a printout, storing each in its own sprite file.
  • plr: (PP) Reads in PCL printouts and positions them according to your specifications. Creates multiple pages if necessary. This allows you for instance to place 2 printouts @ 400dpi on one 600dpi page in landscape. New version can also handle multiple raster areas per input file, start/end-page and arbitrary page increments.
  • ppcl: Reads in PCL data or B/W sprites and outputs PCL data in various compression formats. The resulting data should then be processed with plr. Recompiled.
  • PCLtoRGL: This is a post-processor that converts CMYK printout files as created by Acorn's !Printers to RGL printout files. RGL is a related printer language. Formerly available as a seperate archive.
  • psprite: Converts sprites to monochrome or CMYK sprites or PCL data using error-diffused dithering with user-configurable brightness mapping. Runs in a TaskWindow, doesn't need to keep the whole source sprite in memory, doesn't need !Printers, can print new style sprites even on old machines and is about 4 times the speed of printing sprites with the Acorn printer driver.

• Axis4HD NEW (26 Jan 98) (4391 bytes): This patch allows you to install the classic game Axis on any filing system (although, as the title indicates, the main motivation was installation on a harddisc). You need the original discs to perform the patch. The discs will be stored in a compressed image file; since I didn't feel like optimising the compressor much time-wise this procedure takes a while, but the decompressor is really fast which is the main thing. The patch does not contain a WIMP frontend, it's CLI-based and shouldn't be attempted by anyone who's not familiar with the CLI.
  Please do not use this patch to spread pirate copies of Axis (OK, since the game didn't have a copy protection in the first place this patch doesn't give you any new opportunities, but anyway...). Also don't hold TBA responsible if anything goes wrong -- me neither, BTW, because it's Freeware.

• ViceROKit UPDATED (3 Sep 2006) (134070 bytes): Wanna compile Vice for RISC OS yourself? Then you might want this archive which contains some tools to make life a lot easier (especially if you're on the Vice mailing list and have to keep up to date with the development version). The tools are now released under the GNU Public License (GPL). This archive also contains a set of Makefiles for version 1.20. Also includes a script riscosconfig.sh which can be used to build it using the GCCSDK crosscompiler on Unix systems.

• Source Tools NEW (16 Mar 2003) (22176 bytes): Some useful tools for people handling source trees, both of which originated from my Vice port and can also be found in ViceROKit. instsrc installs a source tree in unix format (dir.file/ext) into RISC OS format (dir.ext.file). cmake creates makefile dependencies for all C/C++ sources visible in the current directory. The tools come precompiled and with full source code, released under the GNU Public License (GPL); documentation can also be found in the archive.

• StampNews NEW (1 Jan 2003) (8797 bytes): Little utility to stamp files containing mail/news post (as in NewsBase) with the date given in the header. This addresses a bug in NewsBase's expiry algorithm which uses the filestamp rather than the file header to determine whether a file is obsolete. Comes with full source code under the GPL, requires WimpLib to compile.

• DigitalRenderer 0.52 (32bit) NEW (15 Jan 2006) (17567 bytes): Important Note: further development of this module will most likely be carried out in the GCCSDK Project, so the version presented here may be obsolete. In case you're having trouble with the module version or would just like to verify you've got the latest build, please consult GCCSDK as well.

  This module for playing sound samples from applications has a long history and dates back to the days when I ported Frodo (hence also the name, BTW, because the sound synthesis code in Frodo was called Digital Renderer). Nowadays, development is mostly driven by my requirements in Vice which go considerably beyond what I needed for Frodo. The original version replaced the channel handler which worked OK but is something one shouldn't normally do. I recently gave the whole thing a serious overhaul and rewrote it to use the standard voice generator interface, also fixing a number of bugs in the process. Version 0.40 also offers a pseudodevice "DRender:" which allows playing samples just like on Unix by opening a special file and writing to it. Version 0.50 can also use the 16bit sound hardware available on newer machines transparently. So rather than continue publishing it hidden in some of my ports (most notably Vice) I now offer it as a standalone archive; it should prove very useful to most people writing applications containing sound code, especially ones where synthesis has to be done in real time (e.g. in emulators). Full documentation of the SWIs, a C-header file, assembler and AOF stubs are provided in the archive.

  • Interfaces: single buffer, streaming (arbitrary length buffer), direct application callback
  • Data formats: 8bit ulaw, 16bit signed linear
  • Pseudodevice "DRender:" (filing system number 167, registered)
  • Transparently uses old 8bit logarithmic or new 16bit linear sound hardware

  This is the binary release of the module; for source code go here.

• GameSupport 0.03 (32bit) NEW (15 Jan 2006) (14534 bytes): This module originates from my Doom port DIY. When I was working on release 4.3 I got fed up with serious crashes being able to total the machine because the runtime environment didn't allow deinstalling handlers. So I made the handlers as application-independent as possible and pushed them into a module, GameSupport. This includes an asynchronous frame buffer (i.e. switching the displayed screen bank happens in the background and doesn't stall the foreground task), sound- and keyboard handlers and some misc support code. Some vectors (most of all sound) still have to branch into application code (because the module can't know what to synthesize), but you can make the module sit on the OS exit handler and thus make sure there are no branches into application code after it was mapped out (normally the OS should do that, but RISC OS doesn't seem to consider this necessary; don't ask me what they were thinking...). There's also a rather low-level hack of mine that tries to recover SL from the stack of an SCL program if that was corrupted when a fatal signal was raised. You can also activate logging of important events (registering / deregistering handlers, handlers being called etc.) into a file for debugging; that file is opened and closed for every log message to make sure you get some info even in case your machine locks up. As all of my modules, all resources are officially registered. The archive contains module, documentation and stubs for interfacing with C (header file, assembler glue code and resulting object code). This is the binary release of the module; for source code go here.

• DrawInfo NEW (1 Jan 2003) (6077 bytes): This is a small utility which reads a Draw file or sprite, calculates its size in millimeters and returns the scaling factor required to make it fit into a user-specified bounding box. I use this for my LaTeX package diagrams.sty to determine the scaling factor on RISC OS. The archive contains an executable binary of the program as well as the C source code (requires WimpLib to compile) and is released under GPL.

Libraries

• Wimplib 0.01 UPDATED (2 Sep 99) (67611 bytes): this library dates back to the days when I ported Frodo, bits of it were also used for Doom, but so far it was mostly a couple of source- and headerfiles that got modified as needed. While I was working on Vice I finally made a real library out of it, containing some low-level OS glue code, some very handy timer stuff, the frame buffer used in Doom as well as a better interface to windows and icons.

  Wimplib is in no way exhaustive; a lot of stuff is missing because I didn't need it, so don't expect the full SWI functionality of RISC OS to be supported by this lib. That's why I'm releasing the library with the full source code, i.e. you can modify the source and add the things you're missing. This version is public domain.

• Wimplib 0.11 beta (32bit) UPDATED (15 Jan 2006) (337136 bytes): newer version, as required for Vice 1.5, but still beta (may include debug output and possible bugs) and will change frequently. The biggest change is the addition of a powerful text window class, a basic C++ binding for WIMP apps and a complete rewrite of the fractal demo app in C++; more information when it has left the beta stage. Also the assembler stuff was finally split up to make linking more efficient and there's an SCL-conformant emulation layer for some common POSIX extensions (such as read, write, readdir, stat or fileno). The license is now LGPL.

  This updated version is 32bit compatible, but the library that comes with the archive is compiled on a 26bit system, so you have to compile it yourself if you want a 32bit version. I also included Makefiles for building the Library with the GCCSDK crosscompiler on Unix systems.

• libfastlz 0.01 (32bit) (12 May 2003) (19197 bytes). This is a small LZ77-based compression library designed for very fast decompression. It was originally developed by me for compression of WAD lumps for my Doom port DIY; I recently made it into a separate library to avoid duplicating code between armDeu and the main DIY engine. The library is portable across many different platforms and should also compile fine on most Unix systems; the optimized ARM assembler code for decompression is 32bit-transparent. The library is distributed under GPL.

Source code for relocatable modules I wrote:

Since modules aren't linked into programs but, being OS-extensions, are called via SWIs, my understanding of the GPL at this point is that the resulting modules can be used by anyone, but use of the source code itself is restricted by the GPL. This is what I intended with this licensing scheme, but in case I misinterpreted anything, I'd appreciate hearing about it rather sooner than later. In case there are C headers and assembler stubs provided, these are licensed under LGPL and can therefore be used in all kinds of projects.

Right, that's that; hopefully some of these will be useful to other developers and be improved one way or another. I'd appreciate being informed about updates to any of these modules, BTW.

• D64ImageFS 0.11: NEW (15 Jan 2006) (54186 bytes). This is an image filing system for D64 images (as used by C64 emulators). It lets you access D64 images like any other RISC OS directory, including writing to them. Version 0.10 can also handle 1571 images and cures a few smallish bugs. Version 0.11 doesn't add any functionality, it's merely the first GPL release of the full archive, including the source code. Note that this module is not 32bit compatible (but that should be a pretty straightforward job if anyone wants to tackle it).

• Digital Renderer 0.52: NEW (15 Jan 2006) (42546 bytes). This is a source-only release. For binaries and a full description of what it does, see here. Note that further development of this module will most likely be carried out in the GCCSDK Project, so the version presented here may be obsolete. If you want to make sure you've got the latest version, please consult GCCSDK as well.

• Game Support 0.03: NEW (15 Jan 2006) (35513 bytes). This is a source-only release. For binaries and a full description of what it does, see here.

• BPlot 0.03 NEW (15 Jan 2006) (42334 bytes). This archive contains the source code of the bitmap plotter BPlot I originally wrote for Frodo and which is also used (optionally) in VICE. Due to the history of the module, the BASIC source PGen2 doesn't create a binary module but rather an AOF assembler file which you have to translate into a module (since the plotter was originally linked with the emulator and only was made into a module later on). This can be a bit tricky and ugly with the free tools, but I can't be bothered to rewrite this thing. Creating the object file is straightforward and I succeeded making the module using drlink -bin -base &fffffffc -o BPlot o.Plotters and then cutting the first word out from the module (that's why the -base-statement above is needed). Like I said: it's ugly, but I can't be bothered to change it.

Software I ported:

Applications

• Frodo V4.1: NEW (5 Sep 97) (328896 bytes) Frodo is a Freeware C64-emulator written in C++ by Christian Bauer. It needs a computer with a lot of oomph so if you want 100% emulation speed you really need a StrongARM. For more info see Christian Bauer's homepage. This is V4.1 which includes binaries of Frodo, FrodoPC and FrodoSC.
  Click here to download a Mahjongg variant I wrote a couple of years ago for my C64.

• dvi_dvi_lj: (202238 bytes) This archive contains two DVI utilities:
  • dvidvi: Allows you to change the layout of DVI-files, like for instance placing multiple DVI-pages one one page.
  • dvilj: This is a DVI to PCL5 printer driver that allows printing DVI files on LaserJets. It was written by Gustaf Neumann and modified by Karl Berry. I did some modifications myself, like supporting Draw- and Sprite-Files as well as introducing compression of raster areas as well as fonts, cutting down printout size dramatically. The latest version also supports arbitrary resolutions. The advantage compared to printing from DVIview is speed (40-60 pages/minute on an A5000). The disadvantage is a somewhat more complex installation.
  Both programs are Public Domain / fall under the GNU General Public License.

• TeXUtils: (329525 bytes) This archive contains a number of utilities to use with TeX:
  • C++2LaTeX: Name says it all, basically. Converts C(++) source code into LaTeX source code, using different text styles, depending on the context (so it's like Zap's coloured C mode).
  • html2LaTeX: Converts html source code to LaTeX source code. Good for simpler stuff but tends to fall over a little (not crashing or anything) with more complex sources.
  • LaTeX2rtf: Converts LaTeX source code to rtf (Rich Text Format, as used by Micro$oft Word, for instance). It can only deal with standard LaTeX commands, so you have to edit a bit if you defined your own LaTeX commands in the document.
  • rtf2LaTeX: Converts the other way around. This seems to work pretty well, actually. I haven't tried it with really big or complex documents yet, however.
  • rtf2TeX: Does the same but the target format is TeX.
  The programs included in this archive are Public Domain or fall under the GNU General Public License.

• Doom It Yourself: (NEW (11 Mar 98) My port of iD's Doom sources, licensed under GPL. Works on various Unix variants including Solaris (Sparc), HPUX, Linux, as well as RISC OS. More information on the DIY Homepage.

• Vice-1.20 for RISC OS (32bit): NEW (3 Sep 2006) (4521608 bytes). Vice is a GPL Commodore emulator originating from the UNIX world which has been developing quite radically over the past couple of years and is the most accurate free CBM emulator around. This archive contains the full binary Vice distribution, i.e. emulators for C64, C128, CBM2, PET, Plus4 and VIC20 as well as a VSID player for all the lovers of the old C64 tunes. Version 1.12 was the first 32bit-compatible RISC OS release and required the new Shared C Library available from the Castle website. Note that due to space restrictions, the link above no longer references an archive on my homepage but the archive in the official Vice download area. Also note that from version 1.13 on, the Digital Renderer module is no longer part of the VICE release but must be downloaded and installed separately (see !ViceRsrc.!Help). Get the latest version here. For more information on Vice and the source code see the official Vice homepage.

  Warning: Vice is huge and needs lots of processing power. The emulators need a Wimpslot between 9MB and 13.5MB and you can't hope to get anywhere near 100% emulation speed unless you've got a StrongARM; for 100% speed even under complex emulation conditions (such as most games) you'll need an Iyonix-class machine and even that one will struggle with really demanding stuff. So it's quite pointless to download this huge archive if you don't have a 16MB RiscPC with StrongARM minimum spec.

  If you want to compile your own version for RISC OS you'll need a C/C++ environment like GCC (preferably 2.95.4 or newer, since 2.7.2 had some annoying optimizer bugs), a make utility, the wimplib 0.11 and to make life a little easier also ViceROKit which contains Makefiles and tools. I recommend crosscompiling with GCCSDK on a fast Unix machine, though.

  But why is it so demanding?

  It just emulates ancient 8-bit systems after all, right? Well, the problem is that the C64 in particular was really taken to the limit like no other system I'm aware of. A lot of software only works if the entire system is emulated with cycle accuracy. On this level, even machine instructions are no longer atomic and you have to emulate what multi-cycle instructions are doing in each of the cycles rather than the final result. A typical example is a fastloader for floppy disks, which came with more or less all of the larger games. In order to successfully emulate this, you have to emulate the entire chipsets of both the computer and its floppy drive (the 1541 had its own microprocessor and was basically a fully-blown computer minus video and audio) at cycle accuracy, or at least the two processors and the IO chips. This is by orders of magnitude more complex than just emulating an isolated 6510 processor. Another example would be video effects, many of which demand cycle accuracy as well, for instance the trick to remove horizontal borders. Doing a good C64 emulation is really in a league of its own since it demands a level of accuracy that would be severe overkill for more or less all other platforms. Don't compare the performance of a good C64 emulator like VICE with emulators for other 6510-based systems unless you know what happens under the hood (in which case you'll probably be amazed how well it performs in spite of the complexity).

  And regarding the RISC OS port: VICE would run considerably faster if there was actual RISC OS hardware with something you could call "memory bandwidth" without laughing, but unfortunately the last system where that parameter could be called sufficient (in relative terms) was the original ARM6-based RiscPC back in '94.

Libraries

• NetLib for UnixLib 3.7: NEW (25 Apr 2000) (46712 bytes). This is basically just a compiled version of the netlib directory of UnixLib37b (by default no network support is available). This is necessary because socketlib and UnixLib don't coexist together too well. For all copyright issues see the main UnixLib distribution.

• ZLib version 1.1.3: NEW (1 Jan 2003) (42597 bytes). The well-known standard compression library by Mark Adler; the full distribution can be downloaded from here.

• JPEG version 6b: NEW (1 Jan 2003) (200736 bytes). The latest version of the JPEG standard library; includes the executables djpeg and cjpeg. The full distribution can be downloaded from here.

• PNG version 1.0.6: NEW (1 Jan 2003) (103918 bytes). The latest version of the PNG library. Define the macro RISCOS when including the headers. Requires zlib. The full distribution can be downloaded from here.
• TIFF version 3.4 beta 037: NEW (1 Jan 2003) (396576 bytes). The latest version of the TIFF library, compiled with maximum supported formats. That means it also requires zlib and jpeg. Includes some tool executables as well: gif2tiff and tiffmedian. The full distribution can be downloaded from here.
• GIF version 2.0: NEW (1 Jan 2003) (18479 bytes). A free GIF library by Gershon Elber and Eric S. Raymond.

Useful Software by 3rd Parties

• kbd.zip: NEW (24 Oct 2000) (4804 bytes). This archive contains two relocatable modules for keyboard handling. Both these modules were created using Nick Craig-Wood's "riscpckeys" archive available from e.g. Hensa, but unfortunately this patcher does no longer work with recent versions of the modules (e.g. RO3.7 or newer), therefore I put the resulting modules rather than the patcher on my site. The modules can be used independently of each other.
  • IntKeyBrd+ is a keyboard handler module for US-Layout keyboards (flat return key, backslash above it); this is no longer necessary on RO4 or newer, but before that there was no support for US layout, so if you have one of these keyboards (the best you can get for programming), use this module.
  • Keyboard+ allows you to swap Caps Lock and left Ctrl key for those stupid PC keyboards which put Caps Lock rather than Ctrl above the left shift key.
  These modules go into your PreDesk boot directory. For more info peruse the ReadMe file provided in the archive.

Miscellaneous

• lplain.zip NEW (06 Dev 2000) (247067 bytes) LaTeX format file for bigvirtex of the new armTeX release including US english and german (traditional) as languages (the standard format contains US english only). You should use this if you want correct german hyphenation, which is not provided by german.sty. Copy the file in the same directory as the other formats (look for latex/fmt) and change the latex script in armtex.bin to read bigvirtex &lplain %* rather than bigvirtex &latex %* and everything should work fine.

• Diagrams.sty NEW (06 May 2002) (4137 bytes): LaTeX2e style for portable diagrams (plain TeX using PostScript files with \psfig, armTeX using DrawFiles and Sprites with \DVIview_diagram or pdfTeX using PDF/PNG/JPG files with the inbuilt \pdfimage command). The archive contains some documentation on how to use the package and is released under LGPL.

Generic source code I wrote

• sudoku.zip NEW (27 Aug 2005) (4955 Bytes). Generic Sudoku-solver for arbitrary matrix sizes (not just the original 3x3), written in C++ and licensed under GPL. The program is run from the command line and requires a CSV-file with the input matrix as first parameter. Unspecified cells in this matrix are represented by whitespace or zero. An example CSV-file is also included in the archive. All you need to build this program is a halfway up-to-date C++ compiler, no additional libraries are required.

• membandwidth.zip NEW (28 Jan 2006) (1878 bytes). This is a tiny C-program useful for testing a computer's memory bandwidth in cache and main memory. It's written in pure ANSI-C and should therefore build on pretty much any system; that's its main point, to have a 100% portable and therefore comparable bandwidth measurement, rather than being precise to the umpteenth digit. By default, it performs its operations on data blocks of size 1024 (-c size) to determine cache bandwidth and blocks of size 8388608 (-m size) to determine main memory bandwidth, both for 10 seconds (-s duration). Operations performed are memcpy() (read-write) and memset() (write-only) from the C runtime library and a custom blocksum-operator (should reflect read-only performance; it only sums up the block because you can't just read memory in C and do nothing with it). You can find some timing results of running this program here.

• prboom-2.4.0-fastlz.diff.gz NEW (10 Apr 2006) (2612 bytes). This patch enables Unix versions of PrBoom 2.4.* to access compressed WADs using my open source fastlz library. It was originally developed for 2.4.0, but works on 2.4.1 just as well and probably will for the entire 2.4.*-series. Handling compressed WADs is now system-specific because 2.4.* mmap()s the WADs and requires different source code for Unix and Windows; I also have a patch for 2.2.4/2.2.5 here which works for both systems, in case anybody's interested. I developed the fastlz-library for my own Doom port DIY and got really fond of WAD compression (OK, compared to the sizes of Doom3-mods this is peanuts either way, but what the heck). WADs can be compressed and decompressed using armDeu (also open source and multiplatform).

  To apply the patch, you'll need the PrBoom source, of course. Copy the patch in your prboom-source-directory, CWD there and type "gunzip -c prboom-2.4.0-fastlz.diff.gz | patch -p1". Then copy the fastlz library in PrBoom's src-directory and build it there. Then build the PrBoom sources just as you normally would, at the end of which there'll be a linker error because I didn't change the Makefile and the linker needs fastlz/libfastlz.a. You can either add that file to the linker line in src/Makefile (look for prboom_LDADD) or you just CWD to src, copy and paste the link command that threw the error and add the library manually. Any linker errors still persisting after that are not my fault ;-). Enjoy.

Some useful scripts

• add-meta-data.sh NEW (17 Jan 2010) (5153 bytes). This is a useful shell-script for tagging FLAC files (Free Lossless Audio Codec, the recommended file format for archiving your CDs) created from CDs via cdda2wav. Provided you allowed cdda2wav to look up the CD in a CDDB database, you should have files audio.cddb and audio.cdindex in the directory with the FLACs. This script has to be executed in the directory of the CD-RIP you want to tag. It reads the data in audio.cddb and tags the FLAC files using metaflac (which should be included in most FLAC packages). The script doesn't convert the WAV files output by cdda2wav to FLAC but assumes the FLACs are already there (albeit untagged). Tagging the FLAC files in a seperate step after encoding them is pretty painless because apparently the FLAC encoder always reserves space for tagging; I've never seen noticeable delays in any of the 500 albums I've tagged so far. Note that the script calls metaflac with the switch --preserve-modtime so the files will still have their original timestamp after tagging; don't mistake this for "nothing happened". Also note that unless you call the script with the --dowrite switch, nothing will be written but the commands that would be executed are written to stdout. This output can usually be fed directly into another shell to actually execute the tagging (in case you want to do modifications too complex to be addressable with the scripts' other switches), but there are some exceptions, i.e. tags containing special characters like the exclamation mark or double quotes. I didn't bother to properly escape these for output because cases were I need to use the output for tagging are pretty rare to begin with and these special characters are also pretty uncommon, so it just wasn't worth it IMHO.

  Some notes on parsing: getting artist and album is done by parsing the DTITLE entry. The usual format convention for this entry is "ARTIST / ALBUM", which of course raises problems if either ARTIST or ALBUM contain slashes. In these cases, you'll most likely have to fix this by using the script's --artist and --album switches. Another thing to watch out for are DTITLE-entries spreading over multiple lines. I addressed this effect for track titles, but not for the DTITLE entry, so in case this happens (you'll have multiple DTITLE entries then) you'll also have to specify the album (and maybe the artist) by hand. Note that all these cases are very rare (unless maybe you're collecting AC/DC bootlegs), so trying to address them generically in a script really isn't worth the effort IMHO.

  • --artist string: override the artist tag with string
  • --album string: override the album tag with string
  • --genre string: override the genre tag with string
  • --year string: override the date tag with string
  • --performer string: add the performer tag string (not available in audio.cddb; mostly useful for classical recordings)
  • --dowrite: actually write the tags with metaflac, otherwise the commands that would be executed are written to stdout
  • --incremental: incremental mode, tags are added to existing ones. When not specified (the default), tags that will be written are reset first.

• dump-meta-data.sh NEW (17 Jan 2010) (166 bytes). Mini shell-script that reads the tags from all FLACs in the current directory (and below) and dumps them to stdout. Useful for checking whether add-meta-data.sh did the right thing.

• ptransfer-flacs.ruby NEW (17 Jan 2010) (1742 bytes). A useful Ruby-script which copies FLAC files (and only those) from one directory to another, alternatively transcoding them to OGG files on the way; I wrote it for my portable audio player (I only store my CD RIPs as FLACs). In case you transcode to OGG, the script can dispatch parallel transcodes (two by default), so you can make good use of multicore machines. The reason I transcode to OGG is not fundamentalism ("bad MP3, good OGG") but that OGG and FLAC share the same tagging namespace, so all tags in the FLAC files can be transferred to the OGGs automatically. Requires Ruby Gems and a FLAC-enabled version of oggenc.
  • --src directory: source directory is directory
  • --dest directory: destination directory is directory
  • --create: when specified, the destination directory will be extended by the leaf directory of the source path, so if your source is /home/rips/GreatBand-ShittyAlbum and your destination is /external/player, the files will actually be copied to /external/player/GreatBand-ShittyAlbum. Caveat: since the source is most likely a Linux filing system and destination is usually something like VFAT, this may not always be possible because some characters that are legal on one are illegal on the other and vice versa.
  • --quality floatval: quality for oggenc is floatval. If this parameter is not specified, files will not be transcoded but copied as FLACs.
  • --threads intval: in case of OGG-transcoding only, use intval threads. Setting this to the number of cores of your CPU is usually the best approach.

Back to my private homepage.