Author Archives: Multimedia Mike

Dear Nano

Dear Nano: You know I love you. You are the GPL’d heir to the old UW-Pine-derived Pico editor, my text-editing savior when I was unceremoniously thrust onto the Unix command line early in my computer science education and told to write a program.

However, clever error messages may seem funny to you but are actually aggravating to the end user due to their failure to actually articulate what went wrong:


GNU Nano - Be Reasonable

This is not helpful when a user is trying to be productive and honestly has no idea what misstep just occurred. Fortunately, I have been using using GNU Nano long enough to know that “Come on, be reasonable” usually means that, rather than pressing Ctrl-W to search for text, I mistakenly pressed Ctrl-/ (go to line number) and entered a non-numeric value.

I wonder if non-English-speaking users have to put up with the same error message? Using my limited ability to interpret non-English languages, I delved into the .po files in the Nano source. Well, what do you know?

de.po:

msgid "Come on, be reasonable"
msgstr "Komm schon, sei vernünftig"

fr.po:

msgid "Come on, be reasonable"
msgstr "Allez, soyez raisonnable"

it.po:

msgid "Come on, be reasonable"
msgstr "Avanti, sii ragionevole"

This is especially egregious since “come on” is literally translated and I doubt that the idiom has the same connotation in other languages.

Thankfully, a brief perusal of the other msgid strings does not immediately reveal any other unintuitive errors. As a bonus, I just figured out that Nano must have a bracket-matching feature due the presence of such strings as “Not a bracket” and “No matching bracket”.

Naive x86 Re-targeter

Here’s the complete, do-it-yourself instructions and code for that re-targeting experiment. First, the files:

The re-targeter wants to process code like that found in function.txt. This is the disassembly format output by my favorite Win32 PE disassembler, Sang Cho’s Disassembler. I knew in advance that the function expects 4 parameters, and that fact is hardcoded in the re-targeter along with the file name. The testbench.c file contains the opcodes for the original function and allows the programmer to switch between the original opcodes and the re-targeted code for verification.

To run this experiment:

  • download all 5 files into one (Unix, x86) directory
  • ./unnamed-re-project.py > bitreader.c
  • gcc *.c -o testbench

The testbench.c program simulates the data structure that the re-targeted bitreading function expects, along with a bitstream that looks like 0xA5, 0x5A repeated. Running the program should result in:

 12 bits = A55
  4 bits = A

If compiling on x86_32, you can switch the “#if 0” to “#if 1” in order to test the original opcodes.

I took a stab at making the re-targeter portable to a big endian platform, as brainstormed last night. However, I soon realized what my hastily scrawled, year-old note about that task’s difficulty must have warned about– the outlined approach works for source arguments, but is not as straightforward for destination arguments.

I don’t have immediate access to an x86_64/Linux environment, but I would like to know if the re-targeted code compiles on that platform. The entire point of a re-targeter is to run code on a different platform, though I suppose alternate operating systems on the same CPU architecture is another interpretation.

So, of course the re-targeter is super-naive in its current form. It only implements enough instructions to handle that one function in function.txt. It does not handle branching at all. In order to do so, each of the instruction emitters would also need to output the code that adjusts the appropriate flags after each arithmetic instruction. Then, a branch would map to a simple goto with the correct address label.

Related Posts

Implementing The Re-targeter

It was nearly a year ago that I tried my hand at writing a re-targeter — a program that can take machine opcodes and automatically translate them into a portable C program, which certainly sounds simple and intuitive enough. I was really quite busy last year about this time and I don’t remember how I found time for the re-targeter experiment in the first place. But it looks like I had time to write up some notes that I never fleshed out and published. It was hard enough just to locate the old source code. I was completely surprised to find that I had actually managed to write the re-targeter in Python; I had no idea I knew so much of that language (which, granted, isn’t much).

Here are some of the problems I encountered when I took a stab at writing a re-targeter; let’s see if I can remember the specifics a year later:

Continue reading →

XSPF And XML

Every so often, it’s a good idea to surf over to Xiph’s site to see if they have absorbed any other well-meaning multimedia-related free software projects. I’m not sure if XSPF started out as a separate effort, but it’s underneath the Xiph umbrella now. The project is billed as “the XML format for sharing playlists.” Yippee. To continue the “those who can, do…” series: Those who can, do; those who can’t, create metadata formats. Anyway, all the buzzwords are there: XML, open, portable, simple, XML. I’m surprised that it’s not an RFC yet (that I could find). I’m sure it’s only a matter of time. Going forward, all of the free multimedia players will be morally obligated to support XSPF. Be advised.

Maybe I’m just irritated because XSPF is supposed to be pronounced “spiff” which, to me, defiles the memory of Calvin.

I think those 3 letters — XML — put me off of this idea the most. Every now and then, I have entertained the idea of using XML to store or transport data for my own programs. But then I realize that I may as well just use an arbitrary binary format that is easier to parse. After all, isn’t XML just an arbitrary textual format? Actually, no. Arbitrary textual data would be easier to parse (e.g., records of data separated by carriage returns with individual fields separated by commas or some other character guaranteed not to occur in the regular data; i.e., CSV). XML requires strict structure around the arbitrary textual data.

As my esteemed multimedia hacking colleague, Attila Kinali, once articulated, “if you really think that XML is the answer, then you definitely misunderstood the question.” (Attila: Michael and I and the rest of the gang are going to make sure that quote is what you’re best known for.)

I think that XML is intuitively antithetical in the mind of the average multimedia hacker. Such an individual instinctively attempts to encode things with as few bits as possible for the express purpose of making transport or storage of that data more efficient. XML explicitly defies that notion by representing information with way more bits than are necessary.

Suddenly, I find myself wondering about representing DCT coefficient data using an XML schema — why not express a JPEG as a human-readable XML file?

[xml]
< ?xml version="1.0"?>











…
…
…
…
…

…
…

[/xml]

Don’t laugh — it would be extensible. Someone could, for example, add markup to individual macroblocks. Is it anymore outlandish than, say, specifying vector drawings as XML?