今更感のする記事ですが、今やっている人がいたので。

EPWINGは1つの書籍に複数の副本を含めることができます（ここでいう書籍・副本はEB Libraryにおける用語です）。 そうすると、中には自分では使わない副本が含まれている書籍も存在したりします。 そういった書籍から使わない副本を取り除いたりするためには、CATALOGSファイルを編集する必要があります。 ですが、このファイルはバイナリファイルになるので、通常は編集に対応したツールを使用します。 2025年現在でもあまり手間暇かけずに使用できる手段を紹介しておきます。

約15年前にEPWINGの全文検索を試みた事があったのですが、それの焼き直しです。

Hyper Estraierを利用するの前回と同様ですが、専用のインデキサを用意して、直接インデックスを作成できるようにしました。 Lookup 1-4+mediaに対応コードを入れたので、インデックスがあれば自動的に使用できます。

かつて、Logic等の音楽制作ソフトを手がけていたemagicという会社がありました。 会社は2002年にアップルに買収され、LogicはLogic Proとして、現在もアップルが販売しています。 emagic社はいくつかのハードウェアも販売していましたが、そのひとつにemi 2|6というオーディオインターフェースがありました。

音質とか性能の話はおいておいて、このデバイスはUSB経由でファームウェアを読み込ませる事でUSB audio class compliantなデバイスとして動作します。 Linuxではドライバはただのfirmware loaderであり、ファームウェア読み込み後は標準のオーディオドライバで動作しています。 また、このデバイスはACアダプタからの電源供給も可能で、その場合、ファームウェア読み込み後は電源が切れるまでUSB audio class compliantなデバイスとして振る舞います。

Windowsへの対応については、メーカーがアップルに買収された事もあり、以降は新たな環境向けのドライバなどは提供されませんでした。 ただし、初期化さえ済ましてしまえば現在のWindowsでも動作は可能です。 そこで、現行のWindowsで動作するfirmware loaderを書いてみました。

前回の続きです。

Hyper Estraierのインデックスがoptimizeで壊れる問題はHyper Estraier側の問題でした。

1. 転置インデックスが複数ファイルにまたがる (通常1.5GiB以上)。
2. 複数回の書き込みが行われている。

上記に当てはまるインデックスにoptimizeをかけるとひっそりと転置インデックスが壊れることがあります。また、

1. ドキュメントの数がとても大きい (確認したものでは約580万)。
2. 各ドキュメントに共通するテキストがとても多い (英語主体で、N-gramを有効にしたインデックスで確認)

上記に当てはまるインデックスにoptimizeをかけると転置インデックスの1ファイルに2GiB以上書き込んでしまい、壊れてしまう事があります。

修正内容はGitHubのリポジトリを参照してください。ついでに2GiB以上のキャッシュサイズの指定に対応していますが、その3倍弱くらいのメモリが必要になるケースがありました。

タグ：Hyper Estraier QDBM

以下の記事は間違いでした。変更で挙動は変わったのですが、変更する前のコードは正しく、挙動が変わった原因は現時点では不明です。

前回に引き続き、QDBMのバグ報告です。

cbdatumcat関数およびCB_DATUMCATマクロが必要なバッファの大きさを1バイト少なく見積もるというものです。 手元ではなぜかSEGVにはならずにプログラムは実行されてしまいますが、Hyper Estraierで巨大なインデックをoptimizeするとインデックスが壊れてしまい、searchできるが不適切な結果が返るようになるバグが修正されました（「巨大な」は必須条件ではく、その方が起きやすいというだけです）。前回分と併せてGitHubのリポジトリで公開しておきます。

タグ：QDBM Hyper Estraier