Archive for the 'tool' Category

Page 3 of 5

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. Closed

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 2¹⁰ instead of 10³, 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: badge, button, icon.

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: