可逆圧縮完全マニュアル(への道) の構成
- EACの実際とWindowsとの共存、文字コードの解決
- WAVE+CUEの多角的活用法の提示、Linuxで自由自在
- 可逆圧縮完全コントロール。ここまでできて「漢」
- DLNA/uPnP配信まで視野にいれよう。
- きっかけ
付記、もともとの序文
ひとつのファイルで楽曲管理/FLACで決まり
当初は、アルバム単位の単一ファイルで楽曲管理すると楽かなと思いたち、ubuntu/mintで試行してきました。Windowsは圧倒的にこの点リア充なので楽ちんですね。自身の結論からいうとよほどのニッチなニーズさえ持たなければ可逆圧縮音声ファイルの取扱では、特にLinuxで困ることはないってことがわかりました。むしろLinuxの利便性のほうが自分のなかでは上回ります。ニッチなニーズというのはどうしてもWindowsアプリケーションを使いたいというようなものです。そこまで無理して使わなくてもいいのではないか、と。
以下は数年に渡る検討のあーでもない、こーでもないを記録したものです。そうとう以前に中間総括としては(自分は主力フォーマットはFLACで決定しました)になっていましたので問題は特にありません。
当初はCD/PCMレベルのWAV,FLAC(44.1kHz/16bit)を主たる議論の対象にしていましたが、ハイレゾ含めて、FLACで決まりました。ピュアオーディオ志向の方はいろいろ深いものがあるのでしょうが、ここではカジュアルオーディオなので、FLACの利便性に軍配が上がります。
「ひとつのwav ＋ cue 」が便利なのかな?! 悩み中です。ちなみに、一定の年齢層以下であればアルバム単位という視聴概念が希薄です。圧縮フォーマットとしてflacは次世代標準になりそうな勢いですが、圧縮していないwavも扱いは楽（そのままだし）なのは当然。タグも埋め込まないわけではありませんし。cueが埋め込みできることもわかっていますが、それは除外します。mkaも除外します。
タグの問題を考慮すればflacがいちばんよさそうです(良いです。とりあえず自分のところではトラブルが一度も起きていない)。id3タグの混乱はまだ続いているわけですしね。FLACに決めました、その2。
そもそもストレージが安くなってきているので、母艦では圧縮保存しなくてもいいのでは？という考えが浮かぶのも不思議ではありません。もちろん展開にCPUパワーくわないほうがいいのではないかという観点も一定程度はだいじでしょう。FLACに決めました、その3
ただ、この考えはあっけなくハイレゾFLACの前には否定されます。なにせハイレゾFLACはそれだけでも巨大です。圧縮なしの状態だとSSDがいくらあっても足りなくなるかもしれません。購入費も大変です。仕様上32bitを除外すれば、FLACに決めました。32bitは自分でどうこうする範囲ではなくて、特定ターゲットに向けた販売のためのフォーマット(高品質のためのとはいわないところが素直じゃない)ともいってもいいわけで。
――圧縮率の高さでいえばAPEは優秀とはいえ、WAVに比べてたとえば30%減程度ですね。他のフォーマットと比較しても誤差レベルの差です。flacはWindows10で標準サポートされたのでそれを契機にWindowsのみならずLinux系でもアプリケーション環境が充実していくと思われます(もともと対応しているので変化する点が特にない)。ついでにいえば、当社調べでAPEもFLACもTTAも圧縮効率は誤差レベルです(繰り返します)。議論しても仕方がないです。今後大手が採用し、幅広いユーザーが利用する可能性がないもの(個人的断言)を使っても仕方ないので、FLAC以外はめんどくさいだけ。FLACです。
考慮すべきは、汎用性。壊れないか。バージョン違いで復元できないなどのトラブルはないか。それも含め、今後の標準化しだいではないかと思います。――FLACに決めました。FLACが標準になります。Appleの世界は特別なので議論から除外。
結論からいえば、flac の方がAPEなどの他のフォーマットよりコンビニエンスと断言してもいいのではないかといいうことになります。以下、詳細は時間がないため、アウトラインのみ整理してみました。スケルトンです。FLACに決めました。
以下は数年に渡る検討のあーでもない、こーでもないを記録したものです。そうとう以前に中間総括としては(自分は主力フォーマットはFLACで決定しました)になっていましたので問題は特にありません。
当初はCD/PCMレベルのWAV,FLAC(44.1kHz/16bit)を主たる議論の対象にしていましたが、ハイレゾ含めて、FLACで決まりました。ピュアオーディオ志向の方はいろいろ深いものがあるのでしょうが、ここではカジュアルオーディオなので、FLACの利便性に軍配が上がります。
何が正解なのだろう:FLACに決めました。次の節へ
「ひとつのwav ＋ cue 」が便利なのかな?! 悩み中です。ちなみに、一定の年齢層以下であればアルバム単位という視聴概念が希薄です。圧縮フォーマットとしてflacは次世代標準になりそうな勢いですが、圧縮していないwavも扱いは楽（そのままだし）なのは当然。タグも埋め込まないわけではありませんし。cueが埋め込みできることもわかっていますが、それは除外します。mkaも除外します。
タグの問題を考慮すればflacがいちばんよさそうです(良いです。とりあえず自分のところではトラブルが一度も起きていない)。id3タグの混乱はまだ続いているわけですしね。FLACに決めました、その2。
そもそもストレージが安くなってきているので、母艦では圧縮保存しなくてもいいのでは？という考えが浮かぶのも不思議ではありません。もちろん展開にCPUパワーくわないほうがいいのではないかという観点も一定程度はだいじでしょう。FLACに決めました、その3
ただ、この考えはあっけなくハイレゾFLACの前には否定されます。なにせハイレゾFLACはそれだけでも巨大です。圧縮なしの状態だとSSDがいくらあっても足りなくなるかもしれません。購入費も大変です。仕様上32bitを除外すれば、FLACに決めました。32bitは自分でどうこうする範囲ではなくて、特定ターゲットに向けた販売のためのフォーマット(高品質のためのとはいわないところが素直じゃない)ともいってもいいわけで。
――圧縮率の高さでいえばAPEは優秀とはいえ、WAVに比べてたとえば30%減程度ですね。他のフォーマットと比較しても誤差レベルの差です。flacはWindows10で標準サポートされたのでそれを契機にWindowsのみならずLinux系でもアプリケーション環境が充実していくと思われます(もともと対応しているので変化する点が特にない)。ついでにいえば、当社調べでAPEもFLACもTTAも圧縮効率は誤差レベルです(繰り返します)。議論しても仕方がないです。今後大手が採用し、幅広いユーザーが利用する可能性がないもの(個人的断言)を使っても仕方ないので、FLAC以外はめんどくさいだけ。FLACです。
考慮すべきは、汎用性。壊れないか。バージョン違いで復元できないなどのトラブルはないか。それも含め、今後の標準化しだいではないかと思います。――FLACに決めました。FLACが標準になります。Appleの世界は特別なので議論から除外。
結論からいえば、flac の方がAPEなどの他のフォーマットよりコンビニエンスと断言してもいいのではないかといいうことになります。以下、詳細は時間がないため、アウトラインのみ整理してみました。スケルトンです。FLACに決めました。
以下、不必要：記録として残します。
おまけ2：flac/lame/tta エンコーダ、デコーダのインストール
ttaバイナリ
http://sourceforge.net/projects/tta/files/tta/ttaenc-linux/最新版。解凍、sudo cp ttaenc /usr/bin
sudo apt-get install flac
sudo apt-get install lame
ヨーロッパで人気みたいなwavpackだけは試しませんでした。よくわからないTAKも試しました。ですからこれで主要フォーマットは網羅できたと思います。flacで十分なんですけどね。flacでいいや。flacが趨勢ってことで。
おまけ3：Monkey's Audio インストール
https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media/+build/5803789
PPA登録するか、バイナリを2つダウンロードし、dpkgインストールするかです。flaconが3.99なので少しこまったことになるかもしれません。flacconを導入した後、4.11でいけるかと思います。
などとして使います。オプションは後に付けます。macという名前は個人的に収まりがわるいので、エイリアス ape にしました。
モンキーオーディオを導入する。16.04LTS
sudo add-apt-repository ppa:mc3man/xerus-mediasudo apt update && sudo apt install monkeys-audioEACやそのケーススタディ - 全5回
wav,ape,tak,tta,flac,+cue FLACに決めた. manjaro/ubuntu/mintの楽曲管理- EACの実際とWindowsとの共存、文字コードの解決
- WAVE+CUEの多角的活用法の提示、Linuxで自由自在
- 可逆圧縮完全コントロール。ここまでできて「漢」
- DLNA/uPnP配信まで視野にいれよう。
- きっかけ
