Category Archives: General

The Freezing Point of Brussels Sprout Soda

In the interest of using the internet to facilitate original scientific research, I am publishing the results of my inadvertent experiment regarding the relative freezing points of various novelty sodas.


Jones holiday soda

Revenge of the White Elephant
At a white elephant gift exchange a few years ago, I received a re-gifted set of novelty holiday-themed sodas created by the Jones Soda Company. They created several of these over the years. This one had pumpkin pie, cranberry, wild herb stuffing, turkey and gravy, and — sigh — Brussels sprout flavors. I never got around (or got up the courage) to sample them and they have languished in my bachelor refrigerator ever since. The reason for the “bachelor” qualifier is that it stays fairly empty and I generally keep a pretty good mental inventory of its contents. Imagine my surprise when I noticed a strange, light green liquid on the bottom.

It smelled strange but I figured it was coming from a plastic container containing a friend’s homemade pickles. I removed the pickles from the equation and cleaned up the liquid. Later on, I noticed some more liquid had collected. The inside bulb is burned out (remember, bachelor fridge) so it’s a bit dark inside. However, I eventually spied a shard of clear glass.


Jones brussels sprout soda bottle, broken

Results
So it seems that the Brussels sprout soda had frozen and expanded until the glass bottle could no longer contain the block. That explains the sound of crashing glass I recall hearing the night before which emanated in the general vicinity of the kitchen.

The bottle was in pretty bad shape but much of the soda was still frozen inside what remained of the bottle. That it must have been gradually melting explains why there was more fluid sometime after the initial cleanup. I immediately, but gingerly, removed the other 4 bottles for fear that they might be ready to burst as well. But none of the 4 showed any sign of freezing.

What to conclude? Either the brussels sprout soda has a significantly higher freezing point than the other 4 flavors and was adversely affected during a freak temperature drop; or the Brussels sprout soda was situated in a colder section of the refrigerator. It’s also possible that all of them were affected by the temperature event but the others didn’t make it to the breaking point before the event reversed.

Impact
I can theorize about it all day. But in the end, I need to clean it up. How does this pertain to multimedia hacking? Well, I was going to add long-overdue test cases to FATE tonight, but that may have to wait. Fortunately, I was at the end of a shopping cycle and all I had to toss were some soda-saturated bananas. I’m keeping the butter since I don’t think it was affected, much. To any coworkers reading: if my cookies taste vaguely of Brussels sprouts over the next month, then, well… I happen to know that’s the closest some of you will come to consuming a vegetable all month.

And I never got to taste the Brussels sprout soda. Actually, that’s the part about this episode that bothers me the least.

Eee PC And Chrome

I complain about a lot of software on this blog. But I wanted to take this opportunity to praise some software for once– Easy Peasy and Google Chrome. I’ve had some ups and downs with my Eee PC 701 netbook— great unit but the vendor-supplied Linux distribution was severely lacking. I auditioned some netbook-tailored distros last year and found one that worked reasonably well while being a bit rough around the edges — Ubuntu-Eee. One notable problem I experienced a few weeks after I installed it was that the wireless network driver quit working (though to be fair, I understand that was a greater problem due to an Ubuntu update around the same time).


Eee PC 701 running Easy Peasy and Google Chrome

These days, Ubuntu-Eee has been renamed Easy Peasy. I was finally sufficiently motivated to try installing it when enough other things on my existing Ubuntu-Eee distro had broken. Essentially all the problems that troubled me in its predecessor distro have vanished– wireless works again (though I still can’t seem to toggle it), all the sound controls work, even the hibernation works which impressed me greatly (even if I never use it).

Pertaining to web browsers, I have traditionally been satisfied with Firefox. Sure, it has been growing large in recent times, but what software hasn’t? It’s the price of software progress and all. However, I took this opportunity to try out Google Chrome which I never thought I would have reason to care about. I am roundly impressed with its speed and responsiveness. Seriously, this browser might even be lean enough for the guru to consider using on a regular basis.

I’m pleased that I can forgo a replacement for this classic Eee PC netbook for the foreseeable future.

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.

Lightweight FATE Testing

Over the years, I have occasionally heard about a program called netcat, but it was only recently that I realized what it was– an all-purpose network tool. I can’t count all the times that this tool would have helped me in the past 10 years, nor the number of times I entertained the idea of basically writing the same thing myself.

I have been considering the idea of a lightweight FATE testing tool. The idea would be a custom system that could transfer a cross-compiled executable binary to a target and subsequently execute specific command line tests while receiving the stdout/stderr text back via separate channels. SSH fits these requirements quite nicely today but I am wondering about targeting platforms that don’t have SSH (though the scheme does require TCP/IP networking, even if it is via SLIP/PPP). I started to think that netcat might fit the bill. Per my reading, none of the program variations that I could find are capable of splitting stdout/stderr into separate channels, which is sort of a requirement for proper FATE functionality.

RSH also seems like it would be a contender. But good luck finding the source code for the relevant client and server in this day and age. RSH has been thoroughly disowned in favor of SSH. For good reason, but still. I was able to find a single rshd.c source file in an Apple open source repository. But it failed to compile on Linux.

So I started thinking about how to write my own lightweight testing client/server mechanism. The server would operate as follows:

  • Listen for a TCP connection of a predefined port.
  • When a client connects, send a random number as a challenge. The client must perform an HMAC using this random number along with a shared key. This is the level of security that this protocol requires– just prevent unauthorized clients from connecting. The data on the wire need not be kept secret.
  • The client can send a command indicating that it will be transferring binary data through the connection. This will be used to transfer new FFmpeg binaries and libraries to the target machine for testing.
  • The client can send a command with a full command line that the server will execute locally. As the server is executing the command, it will send back stdout and stderr data via 2 separate channels since that’s a requirement for FATE’s correct functionality.
  • The client will disconnect gracefully from the server.

The client should be able to launch each of the tests using a single TCP connection. I surmise that this will be faster than SSH in environments where SSH is an option. As always, profiling will be necessary. Further, the client will have built-in support for such commands as {MD5} and some of the others I have planned. This will obviate the need to transfer possibly large amounts of data over a conceivably bandwidth-limited device. This assumes that performing such tasks as MD5 computation do not outweigh the time it would take to simply transfer the data back to a faster machine.

I can’t possibly be the first person to want to do this (in fact, I know I’m not– John K. also wants something like this). So is there anything out there that already solves my problems? I know of the Test Anything Protocol but I really don’t think it goes as far as I have outlined above.