I found myself in need of some binutils today. What do you suppose it is about this basic Apache file listing page that makes Google Chrome think it’s in French?
Opting to translate doesn’t seem to have any affect, aside from ruining the alignment of the columns.
That quirk aside, the page translation facility is actually quite nifty.
I was poking at the data files of a really bad (is there any other kind?) interactive movie video game known simply by one letter: D. The Sega Saturn version of the game is comprised primarily of Sega FILM/CPK files, about which I wrote the book. The second most prolific file type bears the extension ‘.dg2’. Cursory examination of sample files revealed an apparently headerless format. Many of the video files are 288×144 in resolution. Multiplying that width by that height and then doubling it (as in, 2 bytes/pixel) yields 82944, which happens to be the size of a number of these DG2 files. Now, if only I had a tool that could take a suspected raw RGB file and convert it to a more standard image format.
Here’s the FFmpeg conversion recipe I used:
ffmpeg -f rawvideo -pix_fmt rgb555 -s 288x144 -i raw_file -y output.png
So that covers the files that are suspected to be 288×144 in dimension. But what about other file sizes? My brute force approach was to try all possible dimensions that would yield a particular file size. The Python code for performing this operation is listed at the end of this post.
It’s interesting to view the progression as the script compresses to different sizes:
That ‘D’ is supposed to be red. So right away, we see that rgb555(le) is not the correct input format. Annoyingly, FFmpeg cannot handle rgb5[5|6]5be as a raw input format. But this little project worked well enough as a proof of concept.
If you want to toy around with these files (and I know you do), I have uploaded a selection at: http://multimedia.cx/dg2/.
Here is my quick Python script for converting one of these files to every acceptable resolution.
work-out-resolution.py:
Continue reading
I recently read a magazine article about Lego Mindstorms. Naturally, the item that caught my eye was the mention of a bit of Lego software that converts various audio file formats to a custom format called RSO that can be downloaded into a Mindstorms project to make the creation output audio. To read different sources, one might be left with the impression that there is something super-duper top secret proprietary about the format. Such impressions do not hold up under casual analysis of a sample file.
A Google search for “filetype:rso” yielded a few pre-made samples that I have mirrored into the samples archive. The format appears to be an 8-byte header followed by unsigned, 8-bit PCM. More on the wiki. If FFmpeg could gain an RSO file muxer, that would presumably be a heroic feat to the Lego hacking community.
I thought I had brainstormed a simple, elegant, multithreaded, deadlock-free refactoring for FATE in a previous post. However, I sort of glossed over the test ordering logic which I had not yet prototyped. The grim, possibly deadlock-afflicted reality is that the main thread needs to be notified as tests are completed. So, the main thread sends test specs through a queue to be executed by n tester threads and those threads send results to a results aggregator thread. Additionally, the results aggregator will need to send completed test IDs back to the main thread.
But when I step back and look at the graph, I can’t rationalize why there should be a separate results aggregator thread. That was added to cut down on deadlock possibilities since the main thread and the tester threads would not be waiting for data from each other. Now that I’ve come to terms with the fact that the main and the testers need to exchange data in realtime, I think I can safely eliminate the result thread. Adding more threads is not the best way to guard against race conditions and deadlocks. Ask xine.
