前 8 - 03 p ｜ 
もくじ i ｜ 次 8 - 05 n 
2003年8月17日 たのしいページ♪ 仁保学区子ども会-仁保学区子ども会育成協議会-
これは広島市南区
現時点では法律的にはリッピングは合法であり、 合法であるのが自然です。 その点をごまかそうとする業界のいかがわしさと、 そうした工作があること自体まるで知らない様子ののんびりとした雰囲気が、好対照。
wmal2pcm_setup.exee WMA9 Lossless の音声を、無圧縮 WAVにデコードするコマンドラインツールが出ました。用法は
wmal2pcm input.wma output.wav
可逆なので当たり前ですが、WaveCompareにかけると圧縮前と一致します。
APE の DirectShow FIlter 出現
可逆音声圧縮コーデック Monkey's Audio (.APE) を Windows の一般のメディアプレーヤーで再生できるようにする DirectShow Filter （DSF）がサードパーティーにより公開された。
http://dsp-worx.de/index.php?pg=projects&tid=18
これを使うと、Media Player Classic (MPC) や Windows Media Player (WMP) から APE の再生が可能になる。
APE 3.98 も再生できるが、3.97 に最適化されているようだ。 同梱のDLLは 3.97 であり、3.98で圧縮したAPEをデコードできないので注意。 DLL 3.98 との組み合わせでも動作するが、CPU使用率が異常に高くなるなど不具合がある。 3.97 以下で圧縮したものと DLL 3.97 のデコーダの組み合わせでテストすると良い。 foobar2K などで直接再生したときに比べて若干CPU負荷が高いが、すでに十分に実用になる。
APE と FLAC を比べた場合、APE のほうが圧縮性能が良いが、そのぶんデコードがFLACより重い。 また、APEでは後方互換より圧縮性能を優先しているため、 新しいエンコーダーが作ったファイルは古いデコーダーでは開けないことがある。 したがって、FLACのほうが無難といえば無難だが、純粋に「圧縮比」だけを問題にするなら、 実力はAPEのほうが上だ。
すでに CoreFLAC というプロジェクトが名前は存在して、FLACのDSFが先に出るというのがおおかたの予想だった。 APEのDSFの出現で、Monkey's Audio に新しい可能性が広がると、 最近不活発なFLACがますますマイナーになってしまうかもしれない。 （FLAC は、Xiph のプロジェクトの一部になったが、 Xiph は、いま Theora のほうに集中している。 9月頭には Theora のほうで動きがあるかもしれない。）
これによって、近い将来 APE を動画の音声成分として使うことが可能になると見られる。 もちろん、 将来的には FLAC 音声の動画も来そうだ。 完全にロスレス（無損失）でオリジナルの音質を保存し、WAVに比べて40～60%のサイズになるAPEは、 画像の圧縮は手を抜いて軽くしてでも音にこだわりたいクラシック音楽の演奏会のような動画で需要があるかもしれない。 古典派～印象派くらいまでのクラシック音楽なら音の進行も規則性が高いため、 FLACでもAPEでも特に縮みやすい。 軽音楽でも、短いPVなら、APEやFLACで完全にクリアな音質、というのもそう悪くない。 音がメインで画像がオマケのような動画なら、音にビットをまわすのは、もっともな選択だ。 自分でCDをリッピングして音声APEでオリジナルのPVを作ってみるのも楽しいかも。
AAC なら64Kbpsでもけっこうきれいとか言うけれど、 やっぱり可逆圧縮と聞き比べると、64だとボロボロですしねーー。 なお、このDSF、れいによってパスに日本語の文字があると駄目かも知れない。 テストはASCIIのファイル名でどうぞ。
Reported by: NekoKoneko, "Animaniac"
このフィルターは、その後改良が続けられ、Unicodeファイル名にも対応。 2004年12月現在の最新版は、 DS-Monkey Source v1.00（推奨）
これとは別系に、クローズド開発されたRadLight APE directshow filterもある。
![[OFR]](img/frog.png)
2004年3月18日 RadLight OptimFROG DirectShow Filter v1.0.0.0 .ofrがDS再生可能に
フィルター名 RLOFRDec.ax 1.0.0.1, OptimFROG.dll 1.0.0.0
音声のロスレス圧縮といえばAPE、FLAC、Shorten、WavPackの4つが古くからの定番だろう。 OptimFROG もけっこう有名で、サポート例も割と多い。 最近は IEEE Float のロスレス圧縮を世界で最初にサポートしている。
WMAロスレスとかRealAudioロスレスとかロスレスばやりだが、 DS再生できるものにAPE、FLAC、そして今回のこのOFRが加わった。 FLACは、もちろんCoreFLAC、動画の音声にも使える。 そして今回RadLightからFROGのフィルターが出た。これで .ofr がDSプレーヤーで直接再生できる。
.ofr はもともと foobar2000 のような対応プレーヤーで再生できるが、 このDSフィルターによって任意のDSプレーヤーで再生できるようになる。 手元では MPC, WMP6.4, WMP9, ZP, TCMP で再生できることを確認した。 Bs Player では Unknown Format というエラーが出て再生できなかった。 また高圧縮のOFRではジッターが出たものの（それなりのCPUパワーが必要）、 標準では再生はなめらかだった。
ちなみにOFRの圧縮率は、デフォルト同士ではAPEと同程度（APEより高いことも）。速度もまずまずだ。 高圧縮設定で比較すると、APEには圧縮率ではかなわないようで、特に圧縮速度でかなり負ける。 とはいえ、ロスレスに興味あるかたは、とりあえず試してみてください。 ちなみに日本でも MIO というロスレス圧縮が開発中（ERIシリーズ）。 また、RKを音声圧縮に特化した RKAU という形式も比較的知られている。
WavPack （.wv）のメジャーバージョンアップ 4.0 が、 まもなく正式公開される見通しだ。 WavPack は、ユニークなハイブリッド・モードを持つオープンソース（BSDライセンス）の可逆圧縮。 再生側は 3.97 と後方互換を保っている。
3.97 からの変更点をまとめると、
(1) 内部構造が完全に変わって、ブロック単位の圧縮になった。そのため、
- (1a) シークが軽くなった。手元の foobar2000 でテストしたところ、小刻みなシークはうまく反応してくれないときもあるが、 パッと前後に大きく飛ぶのは非常に速い。
- (1b) エラーに強く、ストリーミングも可能。そして多重化しやすい。動画の音声成分として有望なので、 オーディオマニアでなくても、ちょっと注目していいかと。
(2) 32ビットがサポートされた（CoolEdit の独自の32ビットも含む）。
(3) 「VHQ みたいな」オプションができた。 例えば、fast モードで圧縮するとき、-xスイッチをつけると、再生時負荷は fast モードの軽さのままで、 圧縮率が少し上がる。ただし圧縮はかなり遅くなる。fast モードで効果があるようだ。 数パーセント変わる。 もともと圧縮率重視のモードでは、害はないが、効果は少なく、相当遅くなる。
(4) lossy での音質が向上。また、ハイブリッドモードで「全体のサイズ優先」というオプションができた。 WavPack というのは斬新な圧縮テクノロジーで、可逆と不可逆の両方が使える。 例えば、不可逆で 256 kbps などにもできる。 ところが、このとき -c スイッチをつけて、.wvc という「補正」ファイルを作っておくことで、 256 kbps の .wv と、この .wvc の両方が同じフォルダにあると、可逆になる。 （.wvcが同じフォルダにない場合には）.wv 単体でも（不可逆圧縮として）デコードできる。もちろん、不可逆wv+wvc でも全体としては、 オリジナルよりずっと小さくなるのだが、上記の機能を実現するため、可逆wvよりは効率が悪くなる。 その効率をアップする（圧縮率を高める）オプションがついた。ただし、不可逆wvの音質に影響するとのこと。
作者は、今後、Linux版やMac版の開発に協力するほか、 Cueシートをサポートする予定だという。
（ハイブリッドについての補足説明）
foobar2000 のような対応プレーヤーでは、 それ単体では不可逆の.WVと同じフォルダに対応する.WVCがあると、自動的に可逆で再生し、 .WVCがなければ、.WV単体でも不可逆で再生（賢い）。
要約: FLAC の仕様にはサイズの制限はないが、 現在の flac.exe は2GBを越えるFLACファイルを出力できない。 長時間（おおむね5時間以上）のラジオ番組などをFLACで圧縮しようとすると、エラーが発生する。
リバースエンジニアリングにより作られた。
テストしたら、ちゃんと動作した。
input.wav を Apple lossless で test.m4a にして… alac -f out.wav test.m4a input.wav 4B6A62A6 out.wav 4B6A62A6
Wavpack - 3 Questions, lossy high bitrates and cmdline options
Using WavPack Version 4.1 の Usage Guide には、 次の推奨設定が掲載されている。
Bitrate High quality Faster Encode ------- ------------ ------------- 256 kbps -hb256x -hb256 320 kbps -hb320x -hb320 384 kbps -b384x -hb384
384 のときは、高音質モードを指定する -h は不要なのだろうか。 それとも、これはマニュアルのミスタイプなのだろうか。 この疑問に対して、作者自身の回答が引用されている。
384 で -h を使えば、確かに理論的には音質は向上するが、-h がなくてもすでに十分以上の音質で、-h を使うと処理時間が倍増するから、 このレートでは実際上 -h は要らない、「理論的には使ってもいいが、使う必要ない」というのが作者の見解。 ミスタイプではなく、意図的に -h なしにしたと。
言い換えれば、超高レートで h と x を併用すると悪い副作用があるというわけではない。 併用したければしてもいいし、理論的にはそのほうがいいが、知覚可能な変化は起きないよ、ということらしい。
おおざっぱに -h は計算を高精度でていねいにやる（だから必ずある程度は音質が向上する）といった一般的なオプションであるのに対して、 -x は「圧縮しにくい難しいパターンを検出して、適切な処理を行う」というオプションだという。 -x はほとんどの場合、大きな音質向上にはつながらないが、「難しいパターン」があったときには絶大な威力を発揮する。 だから超高レートでは、-h はなくても事実上問題ないが、通常のアルゴリズムではうまく圧縮できないパターンがたまたまあっても対処できるように -x は使うのが無難、という結論のようだ。 高レートの高音質志向で h と x のどちらかを省くとしたら、h を省いたほうが良い、ということになる。
