Archive for the 'tool' Category

Page 2 of 3

SUDOKU Solver tool

Published on June 7, 2005 in tool. 11 Comments

I have just created a tool to help solve the Sudoku puzzles: the forret.com Sudoku Helper. I’ve added it to my Forret tools directory.


You solve a Sudoku puzzle by filling in numbers (1-9) in a 9×9 square.

  • Rule 1: every row should contain ALL 9 numbers, and no number can occur more than once.
  • Rule 2: every column should contain ALL 9 numbers, and no number can occur more than once.
  • Rule 3: every 3×3 square should contain ALL 9 numbers, and no number can occur more than once.

(see also sudoku.com)

De Morgen (Belgian quality newspaper) has just started printing such puzzles in every issue, and they are an addictive hobby. Here they are: the EASY, MEDIUM and ADVANCED one for Monday June 6, 2005.

My Helper just checks the 3 rules above and will indicate which cells can easily be filled in because there is only 1 option left. Yes, it can be kind of a spoiler, so only use it to get out of a deadlock, or if you’re in a hurry, or to show off.

The more difficult puzzles will require you to cunningly plot your strategy 2 or 3 steps ahead, which my Helper page will not do or help you with. If you want to spoil even these brain gymnastics, check Sudoku Solver by Logic

For those of you who like a client program that can work off-line, check Sudoku Solver (Windows – free).

CD-to-MP3 ripping speed estimation

Published on February 12, 2005 in bandwidth, copyright, music and tool. 0 Comments

As every sensible car-owner in Brussels, I rip my CDs to MP3 so I can put copies of them in my car. As every self-respecting geek, I have multiple PCs at home. Which brings me to following observation: not all PCs rip alike. On one PC the CPU maxes out at 100% for the whole ripping procedure, and on the other, I never get above 75%. So I started wondering: what are the elements to define the maximum ripping speed you can get on a PC?
My hunch:

the CD-ROM drive speed:

the original CD audio specification required a constant data rate. This was implemented by running the CD at 500 rpm for the first/inner tracks on the CD (ø 48mm) and at 200 rpm for the outer tracks (ø 118mm). If the CD would have been played at a constant 500 rpm, the data rate at the end would have been 500/200 = 2,5X. (cf Devnulled: Ripping speed)
With CD-ROM the data should be delivered as fast as possible. So the rotation speed is turned up as much as possible. The physical boundaries are the vibrations and the centrifugal forces that occur at high speeds. Maxwell claims the maximum safe speed is 48X. Since the “48X” is marketing speak, this speed is only obtained at the outer border of the CD: this means that the rotation speed would be 48 x 200 = 9200 rpm. Some CDs seem to explode above 10.000 rpm.
To convert this speed into a data rate: at 9200 rpm, the outer tracks would deliver 48x the data rate of an audio CD: 67,74 Mbps or 8.47 MB/s. The first tracks, at ø 48mm, deliver data 2,5 times slower: 27,52 Mbps or 3,44 MB/s.
Real-life tests of a whole bunch of drives on DAE speed results.
For the exact sizes: CD-R/CD-RW technical specifications

the bus speeds:

the CD-ROM drive is connected to the PC by a ATAPI, SCSI, FireWire or USB connection. In theory there could also be a network in between (e.g. when using a Ethernet connected CD Jukebox).
The slowest ATA-33 has a theoretical max throughput of 33MB/s. Most modern SCSIs go above 20MB/s and FireWire gives 50 MB/s. So they would not be the bottleneck in the ripping process.
USB1.1 is limited to 1,5 MB/s (in practice even lower). Most common networks would be a bottleneck too (even Fast Ethernet at a theoretical 12,5 MB/s since 7MB/s would be more of a realistic top rate in practice, certainly if the network is used for other stuff too. Same thing with WiFi standards: 802.11g’s advertised “54Mbps” will in real life never translate in an actual 6,75MB/s throughput.

the CPU speed:

encoding raw audio data to MP3 is CPU intensive. Main parameter will be the clock speed – which I would expect to scale linearly: a 2GHz processor does it twice as fast as a 1GHz. Extra influences: brand of processor (Intel/AMD), model (Celeron/Pentium4/Athlon/Athlon64), number of processors (or HyperThreading). Also, the software you use to encode (LAME/GOGO/RealPlayer/Windows Media Player/…) will have an impact.
Some data can be found on GamePC.com: an Intel P4 3.06 GHz encodes 200MB of raw data info 160 kbps MP3 in 57 seconds: 3,5 MB/s or 20X. The AMD AthlonXP 2700+: 3,28 MB/s or 18.6. More info on GamePC.com confirms our hunch that performance scales linearly with clock speed. For the Pentium4: (1,15 MB/s) per GHz or 6,5X per GHz.

the MP3 bitrate:

the above numbers are for 160 kbps, but what with 192 kbps and 64 kbps? Is encoding faster or slower? I found no data on the net, and I haven’t tested it myself. So no hunch here. Also, the output of the encoding process, even at a very high quality 320kbps is largely within the capacity of any output, even Bluetooth, god forbid. So I don’t take that parameter into account.


So in the following situation:

  • a 24X CD-ROM drive
  • a Pentium 4 2,8GHz processor
  • ripping with the LAME encoder to 160 kbps

Your ripping will start at about 9,8X and speed up until your CPU is saturated at 18,2X. Which gives the graphic at the right. Now there’s a rule of fist.

Remark: looking at the benchmarks, adding a second processor (or HyperThreading) does not enhance the ripping speed (probably since the MP3 encoding code does not do parallelisation). But if you have 2 CPU’s, only one CPU will go to 100% and you keep some breathing room while your PC is creating the MP3s.

Binary confusion: kilobytes and kibibytes

Published on February 4, 2005 in bandwidth and tool. 9 Comments

When I created my Bandwidth Calculator, easily the most popular web tool I ever made, I came across the following problem: in computer technology there is a habit of using kilobyte (KB) as 1024 bytes, megabyte (MB) as 1024*1024 (1.048.576) bytes. Most of you might think this is correct, but it’s not. The International System of Units (SI) (that defines the kilo, mega, giga, … and milli, micro, nano prefixes) uses only base 10 values. A kilo is always 1000, even for bytes. In order to find a solution for the IT ‘contamination’ of using kilo for 210 instead of 103, the IEC introduced new units in 1998:

In 1999, the International Electrotechnical Commission (IEC) published Amendment 2 to “IEC 60027-2: Letter symbols to be used in electrical technology – Part 2: Telecommunications and electronics”;. This standard, which had been approved in 1998, introduced the prefixes kibi-, mebi-, gibi-, tebi-, pebi-, exbi-, to be used in specifying binary multiples of a quantity. The names come from the first two letters of the original SI prefixes followed by bi which is short for “binary”. It also clarifies that, from the point of view of the IEC, the SI prefixes only have their base-10 meaning and never have a base-2 meaning.
(from en.wikipedia.org)

So this is the correct usage for file, disk, memory size:

Kilobytes (KB) 1.000 Kibibyte (KiB) 1024
Megabyte (MB) 1.000 ^ 2 Mebibyte (MiB) 1024 ^ 2
Gigabyte (GB) 1.000 ^ 3 Gibibyte (GiB) 1024 ^ 3
Terabyte (TB) 1.000 ^ 4 Tebibyte (TiB) 1024 ^ 4
Petabyte (PB) 1.000 ^ 5 Pebibyte (PiB) 1024 ^ 5
… … … …

The problem is: the industry has not adopted these standards. If Windows shows the size of a disk, it converts 28.735.078.400 bytes to “26.7 GB”. It should be either 28.7 GB, or 26.7 GiB. Remember the 1.44MB floppy? It actually never existed: it is either 1.40MiB or 1.47MB.

On September 18 2003 Reuters has reported that Apple, Dell, Gateway, Hewlett-Packard, IBM, Sharp, Sony and Toshiba have been sued in a class-action suit in Los Angeles Superior Court for “deceiving” the true capacity of their hard drives. This of course was due to ambiguity of “GB” when used by software and hardware vendors. This precedent might prompt Apple to adapt binary prefixes in its Mac OS, as well as other companies to put pressure on Microsoft to adapt them in its Windows operating systems.
from members.optus.net

One could argue: people have always used the MB = 1024*1024 for disk drives, why change now? Well, clarity is a good reason, and unambiguity. NASA lost the Mars Orbiter because engineers had mixed metric speed (km/h) with English speed (mi/h). Don’t even get me started on miles per gallon.

So: a disk of 160GB should have 160.000.000.000 bytes. And it is about 150GiB. Get over it.

Brilliant Button Builder

Published on January 26, 2005 in tool. 2 Comments Tags: , , .

I needed some buttons to accompany my Webjay Wizard. I like the 80×15 format used by most sites, and was looking for an on-line button maker application.

The one most sites point to is the Kalsey.com buttonmaker, but it does not support the usage of image files. You still can make nice buttons like:

It took me a while longer to find Luca Zappa’s Brilliant Button Maker. It allows the usage of jpg/gif/png files to include in the button. With this one, I could re-use Webjay’s logo to create:

And a vanity button with my Ibanez EDC-705:

Caffeine and error messages

Published on January 26, 2005 in tool and webdev. 0 Comments


made with Atom Smasher’s Error Message Generator

Programming is the process of converting caffeine into error messages.
(via Joel on Software)

Live traffic info

Published on December 16, 2004 in Belgium, Society and tool. 0 Comments


Yahoo just announced that they now have live traffic information on their mapping service:

In a milestone for Internet-based traffic services, Yahoo! has beefed up its existing mapping services to allow customers to plot a route from one local destination to another, and overlay traffic data such as road speeds and potential delays.
(via cnn.com)

When you live in a city like Brussels, you know how unpredictable and unnerving traffic can be. Here in Belgium we also have some services that give up-to-date traffic info:

  • radio1.be gives some info on Brussels and Antwerp in text-format (not much really)
  • verkeerscentrum.be gives an map of Flanders and traffic condition for the main arteries
  • vab.be shows the traffic map info of the whole of Belgium, based on police information.
  • wegeninfo.be also gets info from the Federal Police and show it in a blog-like text-way (reverse chronological).


In France they have something much better: on parisrhinrhone.com they have 10 webcams watching the Paris/Lyon/Dijon motorways and anyone can see the live feed. Sometimes a picture is worth a thousand words!

William Beaty has his theory on how defensive driving helps solve traffic congestion.

That’s the whole point. We WANT people to merge ahead of us before that other lane comes to an end. If I fear that someone will leap into the space ahead of me, or if this makes me resentful or angry, then I close up ranks and prevent everyone from merging. If I try to become the “vengance police” and punish the cheaters who zoom ahead, then I close up ranks and stop all merges. Closed ranks create traffic jams. “Cheaters” don’t trigger traffic jams, it’s the people who try to punish the cheaters who do it.
Lane-jumpers are not the real problem. Traffic jams are commonly caused by people who attempt to punish the lane-jumpers by eliminating all spaces! In the merge-jam animations, the goal isn’t to maintain the empty space under any circumstance. The goal is to ALLOW PEOPLE TO MERGE AHEAD OF US! Closing up the ranks is what produces that jam in the animation.
(from amasci.com)

To see an accurate simulation of how a traffic jam is born at an highway entry, check the Martin Treiber java application.

Mappy has aerial photo overlay

Published on November 9, 2004 in Belgium, Brussel, Web2.0 and tool. 0 Comments


They might already have it for a while, but I hadn’t noticed: Mappy.com can add an aerial picture of the neighbourhood you are searching. The street map is then overlayed on the aerial picture and you have a slider to manage the transparency of the street map. I stopped using Maporama one year back, because Mappy was just better but I hadn’t realised how much better.

Justitiepaleis/Palais de Justice
See the above result for my neighborhood (Marolles, Brussels).

You can see Rue Blaes & Rue Haute, the Breughel place, Place Poelaert, the Palais de Justice on the bottom right, a tip of the Vossenmarkt/Place Jeu de Bal in the left bottom corner.

[Listening to: "Songs for you" - royalgroove.org] (via punkey.com)

Port redirection in Windows

Published on June 1, 2004 in tool, webdev and windows. 2 Comments

We use port redirection/proxy often on our platforms. In the production setup, separate (Linux-based) servers take care of this, but for our development and testing environment, we need port redirection for Windows system. I generally use 2 command-line packages:

  • stunnel.org: TCP proxy for adding or removing TLS (tunnel encryption aka SSL) from a stream
  • rinetd: plain TCP proxy for that accepts TCP connections and just transfers them to another TCP/IP address/port

    Typical use of stunnel:

  • adding TLS to a non-secure server (you will need a server certificate for this), HTTP to HTTPS, SMTP to SMTPS, POP3 to POP3S, FTP to FTPS, … stunnel -d smtps -r localhost:smtp
  • adding TLS to a non-secure client, e.g. a mail client without SMTPS
  • tunnel an existing non-TLS capable protocol through a TLS tunnel (e.g. DNS)

    Typical use of rinetd:

  • transfer a site on port 8080 to another IP address on port 80, to get rid of server:8080 side effects
  • transfer a port 88 to port 80, so you can have different Network Load Balancing policies on both ports, while they both run off the same site

    Claire Forlani
    Meanwhile on the other screen: Claire Forlani in ‘Meet Joe Black’. Mediocre movie, lousy acting by most of the crew, but mmmmm, that face.