Monthly Archives: July 2009

Renoise XRNS

A little piece of me died today when I read of the existence of XRNS, a music tracker format that uses XML. A music tracker format that uses XML! Can you imagine? If you can’t, Google for “filetype:xrns” to find plenty of samples.

[xml]
< ?xml version="1.0" encoding="UTF-8"?>


4
1
false
4
96
123
3
true

36
68
67
47

Untitled
By Somebody
…

…

[/xml]
And on it goes. It’s difficult to articulate why this feels so heretical. It’s like those old MOD/tracker formats were designed to be so pure, so efficient. This completely destroys that. Now your playback engine has to carry the baggage of a full XML parsing library.

There are elements of the FFmpeg development team that would enjoy seeing the program grow to be able to handle all the various tracker-type formats (myself included, obviously). It’s not going to be pretty when XRNS collides with FFmpeg.

Addendum: Share the love over on the Renoise forums.

The Murder FILM

Do you have any idea who killed Jennifer Shefield?
How well did you know Jennifer Shefield?
What can you tell me about Jennifer Shefield?

Call me cold, but I just can’t bring myself to care about the above questions more than I care about what multimedia format is being used in an old Amiga shareware game simply entitled Murder, the demo of which can be downloaded in 11 .lha files from Aminet. LHA… does that ever take me back to the BBS days. That and ARJ.

Back to the format, though, it’s definitely not related to Sega’s FILM format (one of my all-time favorite formats). I think this may just be a series of Amiga IFF files with a header on them. This is because I see markers such as “8SVX”.

The files also contain curious advice about playback. Apart from a string that specifically stipulates “Motorola 68000 family”, there’s also this tidbit in the header: “Amiga Hint LIST subtype FILM requires that all CAT chunks are exactly the same size, start at long word boundaries (pad with filler chunks) and come one after the other right to the end of the LIST. Write to agmsmith at 71330.3173@CompuServe.com for more info.” I would email that address for the sake of due diligence but — darn — bad timing! CompuServe finally died just last week. The files were apparently made by a piece of software named AGMSMakeFilm which also seems to be available at the Aminet.

MultimediaWiki page and samples, naturally.

Google Visualizing FATE

I guess that Cloud Computing stuff doesn’t only apply to data storage. There are also things like Google’s Visualization API for manipulating and presenting data. In this paradigm, the data is under my control but the code to manipulate it lives on Google’s servers.

Good or bad? That’s up for debate, but the table visualization definitely caught my eye. Look at the experimental results when I put FATE data into the table. Notice how easy it is to sort by columns (the default sort is such that the failed builds float to the top). I may be a little too close to the situation, but I think it’s a little better than my last attempt. Again, no more up-to-15-minute delay with this system; new build data is available for presentation as soon as it is submitted to the database.

Let me know what you think. Personally, I think we may have a winner here. Maybe Google’s other visualizations (assorted graphs and such) could be just the thing we have been searching for in order to plot trends like performance and code size.

I just wish I could understand the data source wire protocol. As it stands, the index-v3.php script generates JavaScript on the fly to populate the table. It would be a bit more elegant if the data were provided by a separate script. But, hey, this works.

DCT PR

Some people think that multimedia compression is basically all discrete cosine transform (DCT) and little else.

2 years ago at LinuxTag, I gave a fairly general presentation regarding FFmpeg and open source multimedia hacking (I just noticed that the main page still uses a photo of me and my presentation). I theorized that one problem our little community has when it comes to attracting new multimedia hacking talent is that the field seems scary and mathematically unapproachable. I have this perception that this is what might happen when a curious individual wants to get into multimedia hacking:

I wonder how multimedia compression works?

Well, I’ve heard that everyone uses something called MPEG for multimedia compression.

Further, I have heard something about how MPEG is based around the discrete cosine transform (DCT).

Let’s look up what the DCT is, exactly…


Discrete cosine transform written out on a chalkboard
Clever photo cribbed from a blog actually entitled Discrete Cosine

At which point the prospective contributor screams and runs away from the possibility of ever being productive in the field.

Now, the original talk discussed how that need not be the case, because DCT is really a minor part of multimedia technology overall; how there are lots and lots of diverse problems in the field yet to solve; and how there is room for lots of different types of contributors.

The notion of DCT’s paramount importance in the grand scheme of multimedia compression persists to this day. While reading the HTML5 spec development mailing list, Sylvia Pfeiffer expressed this same line of thinking vis-à-vis Theora:

Even if there is no vendor right now who produces an ASIC for Theora, the components of the Theora codec are not fundamentally different to the components of other DCT based codecs. Therefore, AISCs [sic] that were built for other DCT based codecs may well be adaptable by the ASIC vendor to support Theora.

This prompted me to recall something I read in the MPEG FAQ a long time ago:

MPEG is a DCT based scheme?

The DCT and Huffman algorithms receive the most press coverage (e.g. “MPEG is a DCT based scheme with Huffman coding”), but are in fact less significant when compared to the variety of coding modes signaled to the decoder as context-dependent side information. The MPEG-1 and MPEG-2 IDCT has the same definition as H.261, H.263, JPEG.

A few questions later, the FAQ describes no less than 18 different considerations that help compress video data in MPEG; only the first one deals with transforms. Theora is much the same way. When I wrote the document about Theora’s foundation codec, VP3, I started by listing off all of the coding methods involved: DCT, quantization, run length encoding, zigzag reordering, predictive coding, motion compensation, Huffman entropy coding, and variable length run length Booleans. Theora adds a few more concepts (such as encoding the large amount of stream-specific configuration data).

I used to have the same idea, though: I was one of the first people to download On2’s VpVision package (the release of their VP3 code) and try to understand the algorithm. I remember focusing on the DCT and trying to find DCT-related code, assuming that it was central to the codec. I was surprised and confused to find that a vast amount of logic was devoted to simply reversing DC coefficient prediction. At the end of a huge amount of frame reconstruction code was a small, humble call to an IDCT function.

What I would like to get across here is that Theora is rather different than most video codecs, in just about every way you can name (no, wait: the base quantization matrix for golden frames is the same as the quantization matrix found in JPEG). As for the idea that most DCT-based codecs are all fundamentally the same, ironically, you can’t even count on that with Theora– its DCT is different than the one found in MPEG-1/2/4, H.263, and JPEG (which all use the same DCT). This was likely done in On2’s valiant quest to make everything about the codec just different enough from every other popular codec, which runs quite contrary to the hope that ASIC vendors should be able to simply re-use a bunch of stuff used from other codecs.