Archive for January, 2012

Integrating FLAC isn’t the only thing I’ve been working on lately. After the initial work on FLAC (prior to the CHD bit) I decided to integrate some proper JPEG decoding libraries into MAME.

Why? Well, there is one game, which has been running in MAME for a while which actually uses JPEG decoder chips on the PCB. This game is the rather obscure ‘Sliver’. As a game, it’s not even remotely interesting, or good, but from a hardware perspective the pair of Zoran chips used to decode the JPEG images stored in the ROMs make it an interesting case.

Until recently MAME has simply loaded an extra ‘fake’ rom with the JPEG images pre-decoded, and used a look-up table in the driver to convert the addresses requested by the game for the JPEGS into addresses where our pre-decoded bitmaps were stored. Obviously this isn’t how the hardware worked ;-)

By integrating the JPEG library I’ve managed to remove the fake ROM, and can now point the decoder directly at the real JPEG data in roms as and when it’s requested by the game.

Note, you can see ugly JPEG artifacting on the game screen, they obviously didn’t compress the images with very high quality settings ;-)

From an end-users perspective, the game still runs and plays exactly how it did before, but from a MAME perspective the emulation is now better, and we have a JPEG library to play with if we want it, maybe as an option when creating screen-shots at high resolutions where PNG becomes excessively large? Either way, it’s there and could be put to further use.

There is one other game which uses the same JPEG decoder chips on the board Magic the Gathering: Armageddon (Progettoemma link due to MAWS being down after it was used to hack MameWorld) Currently that game doesn’t work, but Phil Bennett was last seen getting some 3D out of it, so having a JPEG decoder should help him get the correct textures, which are encoded as JPEGs in the ROM.

As with the FLAC stuff, thanks also goes to R.Belmont for ensuring it compiles / works on Linux and Mac environments.

One of the criticisms often made of MAME / MESS’s CHD format is that it doesn’t actually provide very efficient compression, especially when it comes to CD AUDIO data. I’ve had a number of people ask me if I can look into improving this, especially when you consider that in with the current format a complete Saturn set is almost 1TB, with a large portion of that being AUDIO.

The reason it’s inefficient is because it’s using zlib’s inflate algorithm for the blocks, blocks which are rather small to ensure that data is decompressed quickly. While this is fine for DATA (it’s the same thing that ZIP files use) it’s absolutely hopeless for AUDIO.

There are dedicated audio lossless compressors out there, FLAC is a popular one.

I’ve spent the last 4-5 days solid integrating support for this into the MAME / MESS tree, and extending the CHD format to not only support it’s native blocks (hunks), but also reference to embedded streams via ‘virtual hunks’ which point at a stream, and allow the actual FLAC codec to do the seeking and decoding work for this.

By doing this I can achieve a good level of compression with FLAC, far better than trying to split it into CHD hunks due to the lower overhead, and improved ability of the compression algorithms to predict how data best compresses. I also still get good speed decoding, as the FLAC format is designed to be quick to seek, and has built in seektable support of it’s own which I’m levering.

I have to say FLAC is an absolute joy to work with, the API does everything you can expect, the documentation is great, and it’s very good at letting you know if something is wrong. (the only issue I had with the documentation / API was with the seektables, whereby calling things in the wrong order / wrong time during encoding could cause data to be overwritten without throwing an error)

I’ve also added support to the MAME SAMPLE interface to playback files from FLAC sources, this should allow the recently dumped tape loops to be compressed much better than they are now (they’re uncompressed PCM .wav files)

The other possibilities for this are endless, -wavwrite could also output FLAC data if support was added, MESS could potentially load cassette based software from FLAC images. It’s an incredibly useful codec to have around.

I’ve uploaded my first pass of this code Here (link offline for the time being, there is definitely still an error). This should be considered ALPHA SOFTWARE and I won’t be held responsible if you end up destroying your CHDs with it. I’m currently in the process of batch converting many images and haven’t found a broken case yet, but still, it’s in testing. While I’m happy with the current format extensions and CHD format created it could change in a final version, you have been warned.

This code has been submitted to R.Belmont, who is currently making some portability fixes. FLAC is designed to be portable, so this shouldn’t be too much of a problem, so fingers crossed it can be sorted out soon.

Usage is simple, I’ve added an additional -createcdflac commandline option which will use the FLAC routines when compressing AUDIO. If you already know how to use CHDMAN then it’s simple enough.

Have fun :-)