EBシリーズサポートとは直接かかわりがないのですが、
LDOCE5のデータを抽出していて問題があります。
'C:\Program Files\Longman\LDOCE5\ldoce5.data\exa_pron.skn\files.skn\CONTENT.tda'
は、LDOCE5のうりの例文データのmp3データに相当します。
このデータの、2689と15746番目(はじめを0として）のチャンクは、
zlibの解凍ができず、'data error'となってしまいます。
どなたか、この壊れたデータを何とか復元する方法をご存じないでしょうか。ひとつのチャンクに5-6個のMP3データが入っていますので合計で10個以上のデータが利用できないことになってしまいます。
どなたかご教示をお願いします。
下記に2689番目の壊れているだろうと思われるデータをrapidshareにuploadしておきます。
http://rapidshare.com/files/322330779/2689.dat.html
MD5: 17AD3F292A82DCAB4C1FC1291A4FF7A7

OALD7でも同様の現象に遭遇しましたが、末尾にゴミがついているチャンクがあるようです。
例えばアップロードされたデータですと末尾1バイトを取り除けばエラー無く伸張できました。
oald7-fpwではエラーを無視して伸張するという対応をしています。

kazuhiroさん、ご教示ありがとうございました。

まだ詳しく調べていないのですが、末尾1バイトを取り除けばエラー無く、zlibで伸張できるようなのですが、
伸張したunzipedデータの拡張子をmp3に変更して聞いてみると、
本来7個のmp3データがあるようですが3つまでしか正しく再生されず、以降は再生されないようです。
再生されない部分のmp3のヘッダをよく見てみる必要がありそうですが。。
なにはともあれ問題の方向性は見えてきたように思えます。（ただ、どうやって、末尾をのけるとよいことがわかったのでしょうか？）
ずうずうしいのですが、今後のためにお聞きしたい点があります。

一つ目は、zlibの解凍時にエラーを無視するときは、ソースコードのC上でチェックをはずしているのでしょうか、
それともコマンドのなかで制御する機能があるのでしょうか。
当方はdelphi上でzlibのC　ソースをラパーで利用する使い方をしています。

もう一点は、OALD7のことなのですが、当方fpwの使い方がわからないため、自分でepwingに変換するソフトを作ってみたのですが、実用的に最小限のentry,pronuk,pronusのみからデータを抽出して辞書を再現させてのですが、kazuhiroさんが今回書かれているようなチャンクの伸張でエラーは認められませんでした。ところが、tripper_USA70850.MP3はデータがおかしいようです。これはチャンクの伸張の問題でしょうか。

最後にもう一点、OALD7のなかで外字に相当する文字を解析してみると
kazuhiroさんの使っている変換テーブルよりも実際は多いように思えます。
実際の利用ではほとんど問題にならないと思いますが、
変換するかどうかは何か基準があるものでしょうか。
epwing形式は便利でいいのですが、unicodeに対応してないので、
unicodeの処理部分に力がそがれてしまうように思います。。
大きな枠組みなので仕方ないと思いますが。。

いろいろ質問ばかり書いてしまいましたが、もし時間があればご教示お願いします。よろしくお願いします。

> （ただ、どうやって、末尾をのけるとよいことがわかったのでしょうか？）

OALD7で同様の状況になった時は、純正のソフトでは伸張できていた事と、
伸張できた部分のデータのサイズがインデックスに書かれた伸張後のサイズに
一致していた事から不要なデータが末尾にあるのだろうと推測しました。


> 一つ目は、zlibの解凍時にエラーを無視するときは、ソースコードのC上で
> チェックをはずしているのでしょうか、
> それともコマンドのなかで制御する機能があるのでしょうか。

oald7-fpwではPerlのCompress::Raw::Zlibモジュールを使っています。
これのinflate関数はエラーになった時もそれまでに伸張したデータは得られるので、
そのデータをそのまま使用しています。


> ところが、tripper_USA70850.MP3はデータがおかしいようです。
> これはチャンクの伸張の問題でしょうか。

元のデータがおかしいようです。
少なくともWindows上ではOALD7に付属のソフトからも再生できません。


> 最後にもう一点、OALD7のなかで外字に相当する文字を解析してみると
> kazuhiroさんの使っている変換テーブルよりも実際は多いように思えます。
> 変換するかどうかは何か基準があるものでしょうか。

すみません、覚えていません。
・JIS X 4081に収録できる文字で代替できると判断した。
・もれがあった。
・チェックが面倒になったので指摘されたら修正する方式にした。
のどれかだと思います。

kazuhiroさん、丁寧なご返信ありがとうございました。
とても参考になりました。

おそらくだれかが変換ツールを出されるでしょうが、
チョコチョコとボケ予防もかねてやっていきたいと思います。
（ただ、データサイズが大きいのでepwing形式にできるのかわかりませんが。。）

いろいろと教えていただいたお礼になるかわかりませんが、
mp3データにかぶせるRIFFヘッダ作成codeをpascalで作ってみました。
codeは、RIFFヘッダ作成用のCのcodeをmp3用に改変したものです。
mp3_profilerとmp3_to_wavがoverloadされているのは、入力をファイルとMemoryStreamの両方から受けるためです。
汚いソースで恥ずかしいのですが、もしよければ参考にしてください。

http://rapidshare.com/files/323502006/mp3_profile.pas.html
MD5: 8199E6443A3D7E93AC7C2DD50F4A5001

参考にさせていただきます。
こちらこそありがとうございました。