Yearly Archives: 2006

CD Detection Experiment

Some years ago, I wrote a program named the CD Detection Experiment to toy around with compact discs. I reference this tool often in my Multimedia Exploration Journal. The end goal was a tool that could analyze a variety of different CD types, including mode 2 discs, Philips CD-I discs, and 3DO discs. All it does is open a raw CD device under Unix, check the first few sectors, and decide what kind of CD is in the drive. I’m trying to remember if this tool preceded my CD-related work for xine or if I used code from my xine work in this program. There is code for Solaris and FreeBSD reading, so I am guessing that I based this on the xine work.


CDCDCD

Anyway, if you care, here is the code. Here is some sample output, from that Deathtrap Dungeon game discussed in this journal entry, the one with a weird mixed mode:

$ ./cdexp /dev/cdrom
CD Detection Experiment
toc:
  first track = 1
   last track = 18

toc entries:
leadout track: MSF: 76:16:18, first frame = 343218
track  1,  data, MSF: 00:02:00, first frame = 150
 mode 1 data
 iso9660 fs signature found
 system id =
 volume id = Deathtrap
track  2, audio, MSF: 28:09:14, first frame = 126689
track  3, audio, MSF: 30:37:58, first frame = 137833
track  4, audio, MSF: 32:37:28, first frame = 146803
track  5, audio, MSF: 35:32:30, first frame = 159930
track  6, audio, MSF: 39:57:58, first frame = 179833
track  7, audio, MSF: 43:07:24, first frame = 194049
track  8, audio, MSF: 45:45:35, first frame = 205910
track  9, audio, MSF: 49:33:19, first frame = 222994
track 10, audio, MSF: 52:38:22, first frame = 236872
track 11, audio, MSF: 55:17:04, first frame = 248779
track 12, audio, MSF: 58:13:66, first frame = 262041
track 13, audio, MSF: 60:28:28, first frame = 272128
track 14, audio, MSF: 62:43:43, first frame = 282268
track 15, audio, MSF: 64:59:33, first frame = 292458
track 16, audio, MSF: 67:14:00, first frame = 302550
track 17, audio, MSF: 75:36:00, first frame = 340200
track 18,  data, MSF: 76:00:00, first frame = 342000
 mode 1 data
 iso9660 fs signature found
 system id =
 volume id = Deathtrap

Mounting An Executable

I was studying the Executable & Linking Format (ELF) recently. I realized how hierarchically it is organized. Nowadays, whenever I think of something hierarchical, for some reason, I think of cramming it into a filesystem structure via FUSE. Imagine mounting an executable file as a filesystem. One directory could have a list of exported function names. When reading those files, it would automatically disassemble that section of the file.


Executable

I’m working off of the ‘readelf -a’ command here. There would be a directory at the top level called sections/ and would contain 

  .interp/
  .hash/
  .dynsym/
  .dynstr/

And so on. It might be a little tricky because those names have dots in front of them. Another directory can list shared libraries and have symbolic links to the correct libraries. Another directory will list the exported, public symbols. Opening these files would disassemble the functions for display in whatever text editor you want. Of course, not all of the interesting stuff is found at the public entry points, so it will be necessary to employ heuristics to locate other, private function entry points.

For bonus points, make the filesystem writable. This will allow annotations in the disassembled source. This will probably require that a “work” copy of the binary to be stored in the user’s home directory.

Anti-Spam Upgrade

I just upgraded my principle blog anti-spam measure, WP-HashCash, to the latest version. I know that some readers have been blocked by this when trying to comment. In fact, I was even blocked recently when I tried to post a comment. Please let me know if WP-HashCash gives you any trouble.

I think that WP-HashCash uses a great idea to stop spambots by issuing a programmatic challenge to the client before accepting a client’s comment. This sort of thing has been proposed as a solution for email spam but would not be tractable without modifying the fundamental email protocols. I have never seen this blog nailed by spambots so I can only assume that the plugin is doing its job, which I realize may not be very sound reasoning.

Superfluous Source

There is some news today about how Real will be releasing a Linux player with support for Microsoft’s Windows Media formats. For example:

Not mentioned: The fact that Linux multimedia players have already supported these formats for years, sometimes through closed source x86-only binary modules, but increasingly with portable, open source modules. I know, the difference is that Real’s player will have more licensed legitimacy. These news article make it sound as though there will be open source code to decode the Windows Media formats. I sincerely doubt that that’s the case (though if it is true, anyone who is still working to figure out Windows Media Video v8 J-frame coding or Windows Media Audio v3: you can stop now).

I’m still frustrated at Real for a plethora of reasons. One of the most obnoxious things they ever did was send out press releases mentioning something about doing something with open source. This would later manifest as the Helix Player (which, the one time I tried it on an out-of-the-box Fedora Core distro, couldn’t even play a PCM WAV file). But the announcements caused the mailing lists of open source multimedia projects to become inundated with impatient queries about why we didn’t have full Real support since “Real open sourced everything.”