お約束ですが、何はともあれ reader.php の31行目にある
require_once 'Spreadsheet/Excel/Reader/OLERead.php';
を
require_once 'excel/oleread.inc';
に変更します（パスは環境に合わせて変えます）。
パスだけならまだしも、なんでファイル名まで違うんだろうか？ OLERead.php なんてファイルないのにね。
あと、日付の扱いについてバグがあるそうです（自分がダウンロードしたものでは、970行目でした）。
それにしても、Excelは日付計算に２つの方式があるとは知りませんでした。 MSのせいではないんですけどね。
自分は遭遇していませんが、「Notice: Undefined variable: formatstr in ～」というエラーメッセージが出る場合の対処法というのもありました。 おまじないとして修正しておいた方が良さそうです。
これまた自分のところではまだ発生していませんが、ファイルサイズの大きな日本語を含むExcelファイルの取り込みに失敗するという事象も起きているようです。
これについては、修正版の reader.php を配布して頂いているサイトもあります。 こちらの reader.php だと、先程の日付のバグは 1257行目になりますね。
ただ自分のところでは、この修正版を使うとむしろ取得できないセルがでたりして、かえってうまくいきませんでした。
とりあえず日付バグを修正したオリジナル版で問題なく使えているので、こちらを使っています。
と思ったら文字化けを発見。 「×」（ShiftJIS：817E、UTF-8：C397）という文字が化けます。 これってWEB開発備忘録に書いてあった症状と同じかな？ ウチではダブルクォートは問題ないみたいですが。
Excelの内部文字コードはUTF-16LEみたいですが、$excel->setUTFEncoder('mb'); を指定すると mb_convert_encoding を使い、setUTFEncoder('iconv'); を指定すると iconv を使って、$excel->setOutputEncoding('UTF-8');で指定した文字コードで出力するようです。
ウチは「mb」で「UTF-8」でやってます。 試しに「iconv」を指定してみましたが、文字化けは変わらず。
ちなみに「iconv」を指定すると「～」が変換できないという話もあるようです。
いろいろな文字を含むExcelファイルで試してみると、どうやらUTF-16LEで「00」で始まる文字（例えば「×」は「00D7」）がダメみたいですね。 だけど「￠」（00A2）と「￡」（00A3）は大丈夫でした。
php-excel-reader でもチャレンジしてみましたが、こちらもダメでした。 php-excel-reader は PHP-ExcelReader の開発を引き継いでいるみたいですが、処理が遅いですね。
ところで全然関係ない話ですがチリでの鉱山落盤事故で、13日からようやく救出が始まるとニュースでやってました。
その救出用の縦穴の名前が「プランB」だということでした。
同じ13日に、「プランA」を推進している担当者との間で、整合会をすることになっています。 向こうがどの程度進んでいるのか知らないのですが、双方のカードをオープンしたら何が出てくるか、楽しみですね。