ページ

2012年9月30日日曜日

Ubuntu で音楽CDをアレコレする その3

昨日の続きです。前回導入した「Audacious」と「CDEMU」ですが、実はシステムトレイに収納する事が出来ます。Unityだと旧来型のシステムトレイはデフォルトで使えない状態なのですが「dconf-editor」というアプリを使って設定する事が出来ます。ちなみにdconf-editorはデフォルトでインストールされています。

dconf-editorを起動させて以下のように設定すれば、システムトレイに表示する事が可能になります。
['JavaEmbeddedFrame', 'Wine', 'Update-notifier', 'sflphone-client-gnome', 'gcdemu', 'audacious', 'desura']
デフォルトでは'JavaEmbeddedFrame'と 'Wine'と'Update-notifier'が設定されているのですが、私はSFLPhoneとGCDEMUとAudaciousとDesuraを追加しています。

#Picasa








あと前回の記事を書いてから気付いたのですが、FlacとCueの取り合わせと仮想ディスク化したモノとだと、Audaciousに読み込んだ際のトータルの再生時間が微妙に違うのですね。仮想ディスクと実際のCDとは同じなんですけど。プリギャップとかが関係してるのですかね。

AudaciousにCDを読み込ませた場合


AudaciousにリッピングしたFlacファイルをCueシートで読み込ませた場合
一番下の表示が"CD"から"Flac"に変化しています


AudaciousにCDEMUで仮想化したディスクを読み込ませた場合
下の表示がCDになっていますが、実ファイルはFlacです


今日を目安にだいぶ急いでCDとDVDのアレコレを書きましたけど、正直時間が足りなかったです。本当はもう少し練ってから書きたかったのですが、時間切れになりそうなのでコレで良しとします。誰かの訳に立てたのならば幸いです:-P

#外部リンク
UbuntuのデスクトップUnityでタスクトレイ・アイコンを表示する - BK class
http://www14.ocn.ne.jp/~bkclass/doc_unity_taskicon.html

Ubuntu でDVDをアレコレする

前回は(音楽)CDをアレコレする話を書きましたが、今回はDVDをアレコレする方法です。前回も書きましたが10月から法律が変更されて、これから行う行為が法律違反になってしまうらしいです。というか既にマズいかすらよく解っていませんが、一応注意書きしておきます。

まず最初にUbuntuというかLinuxでDVDを再生する方法について軽く書きたいと思います。DVDを再生するには最低限、MPEG2とAC-3やMP2といったコーデックの再生とDVDメニュー等の操作が可能な事、商用DVDの場合はCSSによる暗号化の解除も必須です。

この中で一番厄介なのが最後のCSSによる暗号化なのですが、有難い事にLinuxでも対策可能です。DeCSSという解除プログラムを元にした「libdvdcss」がそうです。

ただし、このlibdvdcssは国によって解釈が違うので、残念ながらUbuntuのデフォルトリポジトリには収録されていません。使いたいならば個人の判断によってローカルからインストールするか「Medibuntu」のようなリポジトリを追加してインストールする必要があります。

ちなみにメディアプレイヤーとしては「VLC」が一番使いやすいと思います。このVLCはクロスプラットフォームなのでWindowsやMacと同じように使えるのも大きなメリットだと思います。

このVLCはシステムに「libdvdcss」がインストールされていれば自動的に認識してDVDを再生する事が可能になっています。Ubuntuで商用DVDを再生したい場合はlibdvdcssを手動でインストールしVLCもインストールすれば簡単に見られるようになります。

次にDVDをリッピングして好きなようにエンコードする方法ですが、これもクロスプラットフォームな「Handbrake」が一番手っ取り早いと思います。

このHandbrakeもVLCと同じく単独でCSSによる暗号化を解除出来ませんが、libdvdcssをインストールすればシームレスにリッピングからエンコードまで行えるようになります。

しつこいようですが10月からは暗号化されたコンテンツを解除して保存する事が法律で禁止されるようなので、このHandbrakeとlibdvdcssの組み合わせでのリッピングは違法という事になるようです:-(

しかもレンタル等だけでなく、自らが所有しているDVDでもリッピングする事が違反となるらしいので注意が必要です。正直、ユーザーの権利を侵害しているとしか思えないのですが、今更言ってもどうしようもない事なのかもしれませんね……。どうみてもおかしいですけど:-(

Handbrake自体の使い方ですが、これはLinux特有という訳ではないので検索すれば、もっと詳しく解説されているウェブサイトがあると思います。ですので敢えて説明しません。

ただHandbrakeには「HandBrakeCLI」というコマンドラインで操作出来るインターフェースもあるので、そちらを簡単に説明したいと思います。

まずDVDをDVDドライブにセットします。あるいはDVDのISOイメージをHDDに用意します。最初にDVDの内容を表示します。
$ HandBrakeCLI -i /dev/dvd -t 0
$ HandBrakeCLI -i Movie.iso -t 0
上がDVDドライブからで、下がHDDに保存してあるISOファイルからの読み込みです。
+ title 1:
+ Main Feature
+ vts 1, ttn 1, cells 0->13 (2441827 blocks)
+ duration: 01:49:38
+ size: 720x480, pixel aspect: 853/720, display aspect: 1.78, 23.976 fps
+ autocrop: 58/62/0/0
+ chapters:
+ 1: cells 0->0, 132021 blocks, duration 00:05:54
+ 2: cells 1->1, 126876 blocks, duration 00:06:25
+ 3: cells 2->2, 147231 blocks, duration 00:07:00
+ 4: cells 3->3, 257751 blocks, duration 00:11:16
+ 5: cells 4->4, 108529 blocks, duration 00:05:36
+ 6: cells 5->5, 298975 blocks, duration 00:13:06
+ 7: cells 6->6, 73934 blocks, duration 00:03:46
+ 8: cells 7->7, 373033 blocks, duration 00:16:26
+ 9: cells 8->9, 360527 blocks, duration 00:15:49
+ 10: cells 10->10, 235804 blocks, duration 00:10:21
+ 11: cells 11->11, 175811 blocks, duration 00:08:14
+ 12: cells 12->12, 151148 blocks, duration 00:05:43
+ 13: cells 13->13, 187 blocks, duration 00:00:00
+ audio tracks:
+ 1, English (AC3) (5.1 ch) (iso639-2: eng), 48000Hz, 384000bps
+ 2, Japanese (AC3) (5.1 ch) (iso639-2: jpn), 48000Hz, 384000bps
+ subtitle tracks:
+ 1, English (Closed Caption) (iso639-2: eng) (Bitmap)(VOBSUB)
+ 2, Japanese (iso639-2: jpn) (Bitmap)(VOBSUB)
+ 3, Japanese (iso639-2: jpn) (Bitmap)(VOBSUB)
+ title 5:
+ vts 4, ttn 1, cells 0->0 (9310 blocks)
+ duration: 00:00:28
+ size: 720x480, pixel aspect: 853/720, display aspect: 1.78, 29.970 fps
+ autocrop: 68/76/98/100
+ chapters:
+ 1: cells 0->0, 4957 blocks, duration 00:00:16
+ 2: cells 0->0, 4166 blocks, duration 00:00:12
+ 3: cells 0->0, 187 blocks, duration 00:00:00
+ audio tracks:
+ 1, Unknown (AC3) (5.1 ch) (iso639-2: und), 48000Hz, 448000bps
+ subtitle tracks:
+ 1, Closed Captions (iso639-2: und) (Text)(CC)
すると、こんな感じで結果が表示されると思います。DVDによってはやたらと長い結果、例えば「アイアンマン2」とかだと、タイトルが99個もあったりして、ほぼ選別不可能だったりします。明らかにリッピング対策が施されているタイトルも多いのでHandbrakeではリッピング出来ない物もあります。

読み方ですが"title"から次の"title"までが一つの区切りとなっています。上記の例では"title 1"と"title 5"の2つの区切りがあります。title 1の次はtitle 2のような気がしますが、DVDによってバラバラなので注意が必要です。

"duration"は文字通り"再生時間"。これは本編を探る重要な手がかりなので見逃さないようにしましょう。"title 1"では"01:49:38"もあり、"title 5"では"00:00:28"しかありません。

"size"もそのものズバリですね。両方共"720x480"ですが、フレームレートが"23.976 fps"と"29.970 fps"と明らかに違いがあります。

"chapters"もそのものズバリ"チャプター"ですね。この例だとtitle 1は"1-13"、"title 5"は"1-3"までしかありません。ちなみにチャプター単位でエンコードする事が出来ます。ですから、"3-5"のように指定してあげれば、自分の好きなチャプターだけ切り出してエンコードが可能になったりします。

"audio tracks"も文字通り"音声"ですね。この例だと英語と日本語のAC3、5.1chの音声が収録されています。title 5は国籍不明でAC-3、5.1chの音声が一つだけ収録されているようです。

最後に"subtitle tracks"ですが、これも"字幕"の事ですね。title 1だと英語と日本語が2つの計3つの字幕が収録されているようです。映画の場合、一つはセリフでもう一つ監督のコメントだったり、必要最低限だけの日本語解説だったりするようです。"title 5"の"クローズドキャプション"は、具体的にどうなのか判りません。

取り敢えず、そんな所ですかね。続いて実際のエンコード方法ですが、私はプリセットを利用して手抜きしています。以下が主なプリセットの内容です。
#Devices
+ Universal: -e x264 -q 20.0 -a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 0.0,0.0 -f mp4 -X 720 --loose-anamorphic -m -x cabac=0:ref=2:me=umh:bframes=0:weightp=0:8x8dct=0:trellis=0:subme=6

+ iPod: -e x264 -b 700 -a 1 -E faac -B 160 -6 dpl2 -R Auto -D 0.0 -f mp4 -I -X 320 -m -x level=30:bframes=0:weightp=0:cabac=0:ref=1:vbv-maxrate=768:vbv-bufsize=2000:analyse=all:me=umh:no-fast-pskip=1:subme=6:8x8dct=0:trellis=0

+ iPhone & iPod Touch: -e x264 -q 20.0 -a 1 -E faac -B 128 -6 dpl2 -R Auto -D 0.0 -f mp4 -X 480 -m -x cabac=0:ref=2:me=umh:bframes=0:weightp=0:subme=6:8x8dct=0:trellis=0

+ iPhone 4: -e x264 -q 20.0 -r 29.97 --pfr -a 1 -E faac -B 160 -6 dpl2 -R Auto -D 0.0 -f mp4 -4 -X 960 --loose-anamorphic -m

+ iPad: -e x264 -q 20.0 -r 29.97 --pfr -a 1 -E faac -B 160 -6 dpl2 -R Auto -D 0.0 -f mp4 -4 -X 1280 --loose-anamorphic -m

+ AppleTV: -e x264 -q 20.0 -a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 0.0,0.0 -f mp4 -4 -X 960 --loose-anamorphic -m -x cabac=0:ref=2:me=umh:b-pyramid=none:b-adapt=2:weightb=0:trellis=0:weightp=0:vbv-maxrate=9500:vbv-bufsize=9500

+ AppleTV 2: -e x264 -q 20.0 -r 29.97 --pfr -a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 0.0,0.0 -f mp4 -4 -X 1280 --loose-anamorphic -m

+ AppleTV 3: -e x264 -q 20.0 -r 30 --pfr -a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 0.0,0.0 -f mp4 -4 -X 1920 --decomb="7:2:6:9:1:80" --loose-anamorphic --modulus 2 -m -x b-adapt=2

+ Android Mid: -e x264 -q 22.0 -r 29.97 --pfr -a 1 -E faac -B 128 -6 dpl2 -R Auto -D 0.0 -f mp4 -X 480 -x cabac=0:ref=2:me=umh:bframes=0:weightp=0:subme=6:8x8dct=0:trellis=0

+ Android High: -e x264 -q 22.0 -r 29.97 --pfr -a 1 -E faac -B 128 -6 dpl2 -R Auto -D 0.0 -f mp4 -X 720 --loose-anamorphic -x weightp=0:cabac=0

#Regular
+ Normal: -e x264 -q 20.0 -a 1 -E faac -B 160 -6 dpl2 -R Auto -D 0.0 -f mp4 --strict-anamorphic -m -x ref=1:weightp=1:subq=2:rc-lookahead=10:trellis=0:8x8dct=0

+ High Profile: -e x264 -q 20.0 -a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 0.0,0.0 -f mp4 -4 --decomb --loose-anamorphic -m -x b-adapt=2:rc-lookahead=50

#Legacy
+ Classic: -b 1000 -a 1 -E faac -B 160 -6 dpl2 -R Auto -D 0.0 -f mp4

+ iPod Legacy: -e x264 -b 1500 -a 1 -E faac -B 160 -6 dpl2 -R Auto -D 0.0 -f mp4 -I -X 640 -m -x level=30:bframes=0:weightp=0:cabac=0:ref=1:vbv-maxrate=1500:vbv-bufsize=2000:analyse=all:me=umh:no-fast-pskip=1:psy-rd=0,0:subme=6:8x8dct=0:trellis=0
"Devices"は、iPhoneやiPad向けのプリセットで"Regular"はPC等の汎用性重視のプリセット、"Lagacy"は名前の通り古い端末? 向けのプリセットなので、あまり使う事は無いと思います。

私は基本的に"Regular"の"Normal"プリセットを使っています。"High Profile"でも良いのですが、一応互換性重視という事で:-P

基本的に、このプリセットをベースに自分で足りないオプションや変更したいオプションをコマンドラインで追加して使用します。それぞれのオプションの説明は、複雑すぎてここでは説明出来ませんが、Handbrakeのウェブサイトで説明されているので、自分で確認してみて下さい。

試しに上記のDVDのタイトル1をリッピングしてエンコードする場合は、以下のような感じになります。
$ HandBrakeCLI -Z "Normal" -i /dev/dvd --markers -t 1 -a 2,1 -s 1,2,3 -o ./Movie.mp4
-Z "Normal"がプリセットの指定、"-i"でDVDドライブの指定、"--markers"で再生時のチャプター再生設定、これはVLC等の一部のメディアプレイヤーにしか適用されません。"-t"でタイトルの指定、これを"-t 5"とすると、タイトル5がリッピング対象になります。"-a"で音声指定。コンマで区切る事で複数選択可能です。"-a 2,1"でデフォルトの再生音声が2番目の日本語になります。"-s"で字幕指定。こちらも音声と同様にコンマで区切って複数指定、最初の数字が優先的に表示されます。"-o"で出力先の指定です。

他にも色々とオプションがありますが、余りにも膨大なので、ここでは割愛します。上記のDVDはもともとプログレッシブなので、特にフィルターを掛けていませんが、"29.970 fps"のソースなんかは"--deinterlace"や"--decomb"等のフィルター補正が必要になる事もあるので注意して下さい。

大雑把な目安として、古いアニメなんかは"--decomb"、大人同士の裸のぶつかり合い(えっ)なんかは"--deinterlace"じゃないと激しいシーンで取りこぼしがあるかもしれません。この辺りはソースに依存するので、自分で判断して下さい……。

駆け足で説明しましたが、普通はGUI版のHandbrakeを使用すると思うので、こんなややこしい事は必要ないかと思います。ただ、慣れてくるとHandbrakeCLIの方がテンプレ化出来て楽ではあります。個人的意見ですけど。

さて、勢いで書いてしまいましたが、果たして書いて良かったのだろうか……。危なかったら即消しますのでご容赦下さい……。

#外部リンク
HandBrake
http://handbrake.fr/index.php

CLIGuide – HandBrake
https://trac.handbrake.fr/wiki/CLIGuide

VideoLAN - Official page for VLC media player, the Open Source video framework!
http://www.videolan.org/vlc/

VideoLAN - developers - libdvdcss
http://www.videolan.org/developers/libdvdcss.html

DeCSS - Wikipedia
http://ja.wikipedia.org/wiki/DeCSS

Medibuntu :: Multimedia, Entertainment & Distractions In Ubuntu
http://medibuntu.org/

HandBrake Releases : John Stebbins
https://launchpad.net/~stebbins/+archive/handbrake-releases

このように対策されているDVDもあります
HandBrake and the 99 title DVD mystery | Macworld
http://www.macworld.com/article/1154702/99_title_dvd.html

2012年9月29日土曜日

Ubuntu で音楽CDをアレコレする その2

長くなったので分割。前半は大まかなCDのリッピングの流れについて説明しました。後半は具体的なやり方を書きたいと思います。

まず「Rubyripper」ですが、上級者なら自分でビルドしてインストール出来ますが、親切な方がUbuntu用にパッケージ化してくれているので今回はそちらを使用します。パッと見た所、PPAにもありますが私はPlayDebバージョンを使用しています。PlayDebを既に使っているからなので、使っていない人はPPAの単独パッケージ版の方が良いかもしれませんね。もしかしたらRubyripperとは別に手動で「Cdrdao」パッケージ等をインストールしないと駄目かも知れません。

Rubyripperの設定ですが判る範囲で説明すると「Secure Ripping」タブの「Cdrom device」でCDドライブの指定をします。通常は弄る必要は無いですが、後述する「CDEMU」を導入した場合、初期設定だと仮想ドライブが2つ増えます。

私の場合、SATA接続の物理ドライブが一台ですので、そのドライブが"/dev/cdrom"で、仮想ドライブが"/dev/cdrom1""/dev/cdrom2"といった形になっているようです。

「Cdrom offset」というのがCDドライブのオフセット値で、この値は物理ドライブによって変化します。私が使っているドライブは「DH40N」なので"+6"にセットします。この値は普通の人が測れるモノではないので、オフセット値が集められたウェブサイトのデータを使用します。たいていのCD・DVDドライブなら掲載されています。

次に「TOC analysis」タブですが「Create cuesheet」にチェックします。更に「RIP CD to single file」にもチェックするとリッピングしたファイルが単体のファイルとして生成されます。この.cueとflac(指定したコーデックによる)が2つで一つの仮想ディスクとなります。

次の「Codec」タブは、文字通りリッピングしたファイルをどのコーデックでエンコードするかの設定です。CDEMU経由で仮想ディスクとして認識させたい場合は「Flac」か「Wav」を選択して下さい。他の「Vorbis」等は、曲ごとにエンコードする場合や、仮想ディスクとしてではなく「Audacious」等のアプリの機能で単体ファイルをCueシートで分割する場合に使用します。この場合、再生できるかはアプリに依存しますので汎用性は落ちます。

次の「Freedb」ですが、デフォルトのままでも認識率は高いですが、日本のCDをリッピングする場合は「freedb 日本語」に切り替えた方が認識率は上がります。「freedb server」の欄を"http://freedbtest.dyndns.org:80/~cddb/cddbutf8.cgi"で置き換えて下さい。

Freedbですが、デフォルトのままでも十分日本語タイトルを認識出来ますので、まずはデフォルトのままで使用してみた下さい。上記で削除した"http://freedbtest.dyndns.org:80/~cddb/cddbutf8.cgi"ですが、何処にも詳しい説明がされていないので一度保留扱いにします。以前、どこかで見たのですが、今調べてもよく判らなかったもので……。

取り敢えず、基本的な設定はコレで出来たと思います。CDをセットして起動させると自動的にスキャンしてくれます。もしスキャン出来なければ、CDドライブの設定欄を見なおしてみて下さい。

「Rip CD Now!」ボタンを押すとリッピングが始まります。設定にもよりますが、かなり時間が掛かります。気長にお茶でも飲みながら待ちましょう。初期設定だと2回精査します。終わると自動でトレイが開くので外蓋を閉めないように注意しましょう:-P

全て上手く行くと指定したフォルダに「〜.flac」「〜.cue」「〜.log」の3つのファイルが出来上がっていると思います。このうち、.logは単なるログファイルなので実用上は無くても問題ありません。.flacと.cueが対となるファイルなので、大切に保存しましょう。

どのように使うかですが、Audaciousの場合、〜.cueを読みこませればFlacファイルとして認識してくれます。仮想ディスクとして使う場合はCDEMUに〜.cueを読みこませれば、通常のCDとして扱えるようになります。この場合は、Audaciousだけでなく、Rythmbox等でもCDとして認識できます。しかもwavファイルとして出力されますし。多分。

これで一応再生編は終了です。続いて仮想ディスクとしての応用編に入りたいと思います。CDEMUに読み込ませた.flacと.cueファイルをRubyripperに読み込ませます。

やり方は設定から「Cdrom device」欄を"/dev/cdrom1"あるいは"/dev/cdrom2"に変更します。この値は環境により変化するので詳細は自分で確かめて下さい。

この状態で"Scan Drive"ボタンを押すと、実CDと同じようにCDDBに問い合わせが行ってリッピング可能な状態になると思います。ただし仮想ディスクの場合、実ドライブで設定した「オフセット値」が変化しているので、「Cdrom offset」の値を"0"に変更します。

試しにコーデックをFlacにして1曲だけでリッピングしてエンコードしてみて下さい。この仮想ディスクからエンコードした音楽ファイルと実CDで同様に作成したFlacファイルで全く同じファイルが生成されると思います。

私が試してみた所、md5sumのハッシュが全く同じである事を確認しました。ちなみに仮想ディスクのオフセット値を"0"以外にしていると、md5sumのハッシュが異なってしまいます。

まぁここまで病的に拘る必要も無いとは思いますが、せっかく出来る設定なので一応書いてみました。ここまで書いておいてなんですが、これは素人のおっさんが適当に考えた方法なので、実際に合っているのかは全く判りません。また10月から施行される某法律では、暗号化されていない通常のCDをリッピングしても罪には問われないと思いますので、今後も使えるテクニックだと思います。

ただし、CCCDのように暗号化が成されている「CDもどき」は、厳密に言うと違法になるかもしれないので、来月からは注意が必要かもしれません……。正直、こんなクソ法案は通すべきじゃなかったと今でも思っていますが、今更どうしようもない事なのかもしれませんね……:-( さてと次はDVDについて書くつもりです。こちらはCCCDと同じで来月からは違法扱いになっていまいますしね……。て、書くだけなら犯罪じゃないですよね。少なくとも今月中なら……。

#追記
書き忘れてましたが、CDドライブのオフセット値は以下のウェブサイトで調べる事が出来ます。
http://www.accuraterip.com/driveoffsets.htm

#Picasa
AudaciousにCDを読み込ませた場合


AudaciousにリッピングしたFlacファイルをCueシートで読み込ませた場合
一番下の表示が"CD"から"Flac"に変化しています


AudaciousにCDEMUで仮想化したディスクを読み込ませた場合
下の表示がCDになっていますが、実ファイルはFlacです


Rubyripper


ドライブ名が"HL-DT-ST DVD-ROM DH40N NP01"と表記されています
オフセット値も"+6"で設定


リッピングには結構時間掛かります。この例では"410秒"+"411秒"と2回精査されています




実ドライブのオフセット値設定等。










出来上がったファイル


"CDEMU"に読み込ませた仮想ディスクをRubyripperに読み込んだ場合
"cdrom device"を仮想ドライブのパスに変更して"Cdrom offset"の値を"0"に変更する


ドライブ名が"HL-DT-ST DVD-ROM DH40N NP01"から"CDEmu Virt.CD/DVD-ROM 1.20"変更されています
オフセット値も"6"から"0"へ変更しています


MD5SUMの検証 上が実CDから直接リッピングしたFlacファイルで下が仮想ディスクからリッピングしたFlacファイル
一応一致しているようです:-P


#外部リンク
Ruby Ripper : Brandon Snider
https://launchpad.net/~brandonsnider/+archive/ruby-ripper

PlayDeb.net Beta - Welcome
http://www.playdeb.net/welcome/

PPA for CDEmu : “CDEmu” team
https://launchpad.net/~cdemu/+archive/ppa

Web Upd8: Ubuntu / Linux blog: Ubuntu PPAs By WebUpd8
http://www.webupd8.org/p/ubuntu-ppas-by-webupd8.html

freedb 日本語
http://freedbtest.dyndns.org/

Digital Audio Extraction
http://www.accuraterip.com/driveoffsets.htm

Ubuntu で音楽CDをアレコレする その1

久々に投稿。このネタを書くかどうか、ずっと迷っていたのですが、やはり書くことにします。来月になると多少? 面倒くさい事になりそうですので……。

勿体振って書きましたがUbuntuで音楽CDを快適に使うためのTIPSって感じですかね。具体的には音楽CDをリッピングしてパソコンのHDDに保存したり、個別の音楽ファイルにエンコードしたりといった感じです。

といっても単純にリッピングしてエンコードするだけならUbuntuのデフォルトアプリケーションだけで十分可能なのですが、今回はもう少し突っ込んでみようと思います。

通常、音楽CDのコピーを行う場合、デフォルトアプリの「Brasero」を使用すれば「.toc」と「.toc.bin」形式のイメージファイル化が可能です。ただ、この形式は取り扱いに難がある(と個人的には思う)ので、ちょっと使い辛いです。

またMP3やOgg Vorbisへのエンコードは「Sound Juicer」等のアプリで可能ですが、今回はもう少し体系的な使い方をしたいので使用しません。普通の使い方なら、Sound Juicerで十分なんですけどね。

これらのアプリより本格的な音楽ファイル作成をする場合、従来は「abcde」というコマンドライン型リッピングアプリが基本でした。このabcdeを使うとCDのリッピング、エンコード、CDDBを使用しての曲情報のタグ付けを一気に行う事が可能です。

また一つのCDを単体ファイルとしてリッピング、エンコードが可能なのが大きな特徴です。曲自体の分割は同時生成された「.cue」ファイルで行う事になります。Windowsだと、この一連の作業をしてくれるツールはあるのですが、Linuxだと中々ありません。

また.cueファイル(所謂cueシート)を正しく認識して分割した音楽ファイルとして扱える音楽プレイヤーもLinuxでは、そう多くありません。

この辺りの話は、かなり長くなる上に私自身あまり把握していないので今回は深く追求しません。気になる方はググるなりして見てください:-P

という事で、このabcdeを使えば一見落着のように見えるのですが、実はそうでも無いのです。私も曖昧な知識しか無いので間違っているかもしれませんが、abcdeを使ったcueシート作成では完全にはリッピングされている訳ではないらしいのです。

具体的に何が足りていないのかというとCDドライブの「オフセット値」とCDの「プリギャップ」情報がabcdeでは不足しているらしいです。

オフセット値というのは各CDドライブの持つズレを補正する値の事で、この値を合わせる事によって各環境でも均一なリッピングが可能になるらしいです。

プリギャップというのはCDにある曲間の切れ目の無音部分の事? らしいです。abcdeでも、このプリギャップを割り出せるのですがabcdeでは「INDEX 00」という値しか割り出せないようです。Windowsの「EAC」は、このINDEX 00と、もう一つ「INDEX 01」という値も割り出す事が可能です。具体的に何なのかは私は上手く説明出来ませんが……。

じゃあLinuxではWindowsでの定番アプリ「EAC」のような完璧なCDのリッピングが不可能なのか? と思いますが、実は可能です。「Rubyripper」というアプリがソレです。見た目は多少悪いですが機能的にはEACに匹敵する内容で上記の2つの値「オフセット値」と「2つのプリギャップ」も検出可能です。

またRubyripperはabcdeと同様にリッピングの後に単一のファイルにエンコード可能です。この単一ファイルをFLACでエンコードし、Cueシートも同時に作成する事が現状で一番理想的な音楽CDの保存方法だと個人的には思います。

Rubyripperで作成した「.flac」と「.cue」の組み合わせは再生出来る音楽プレイヤーが限られてしまうのが難点です。Windowsだと定番は「foobar2000」辺りになるのでしょうがLinuxでもいくつか有ります。

私がオススメするのは「Audacious」というXMMSの流れを汲むプレイヤーです。このプレイヤーを使うと.cueをそのまま読み込めます。勿論ちゃんと曲ごとに分割して再生する事が可能です。

これで再生まで可能になったのですが今回は更に一歩進めてみたいと思います。実は「.flac」と「.cue」の組み合わせを仮想CDとして使う事が可能です。通常のままでは不可能なのですが「CDEMU」というアプリを使用する事でLInuxでも仮想CDを取り扱う事が可能になります。Windowsでいう「DAEMON Tools」って所ですかね。例えが古いかもしれませんが:-(

このCDEMUは非常に優秀なアプリで、この.cue以外にもいろいろな仮想ファイルをマウント可能です。今回は割愛しますがWindowsで作成した資産を有効に使う事が出来ると思います。以前は.cueと.wavの組み合わせの仮想化しか読み込めなかったのですが、いつの間にか.cueと.flacでも仮想CDとして認識してくれるようになっていました:-P

音楽再生だけならAudaciousで.cueの読み込みが可能なので仮想化する必要性は無いのですが仮想CDとしてマウント出来ると.cueを認識出来ないアプリでの取り扱いが非常に楽になりますしね。長くなったので一度終了します。

#外部リンク
Rubyripper - Hydrogenaudio Knowledgebase
http://wiki.hydrogenaudio.org/index.php?title=Rubyripper

rubyripper - A secure audiodisc ripper for Linux and OS X - Google Project Hosting
http://code.google.com/p/rubyripper/

abcde: Command Line Music CD Ripping for Linux
http://www.andrews-corner.org/abcde.html

abcde - A Better CD Encoder [ver 2.3.99] - 暇つぶし【ソフトウェア/Linux】
http://old.ikoinoba.net/index.php?UID=1203585800

Audacious - An Advanced Audio Player
http://audacious-media-player.org/

CDEmu
http://cdemu.sourceforge.net/

2012年9月14日金曜日

iControlPad 2 の Kickstarter 告知ページが出来てた

寝ようと思ったら、iControlPad 2のKickstarterの告知ページが開設されてたので紹介しときます:-P へぇ、思ったよりデザイン悪くないですね。て、流石に今日は時間無いのでこれだけで終わります。おやすみなさい。

#Picasa


#YouTube
iControlpad2 - Kickstarter - An open source controller - YouTube
http://youtu.be/l3uKuZq7yBM



#外部リンク
iControlPad 2 - The open source controller by Product 3 LLC — Kickstarter
http://www.kickstarter.com/projects/1703567677/icontrolpad-2-the-open-source-controller

Opus Codec に期待する事

さっきの続きです。前回はOpus Codecという標準コーデックが出てきた事によって、主流のVoIPサービスの相互接続性が(技術的に)向上するかもしれないと書きました。

データを見た訳ではないですが、現在主流なVoIPサービスの代表格は、マイクロソフトに買収された「Skype」だと思います。更に最近ではGoogleが「Google Voice」というサービスを展開しています。Googleは他にもGoogle+上で「ハングアウト」というビデオチャットも展開していますね。

MS、Googleとくれば、気になるのが「Apple」です。勿論、アップルも似たようなサービスを展開しています。「FaceTime」というらしいですが、実際に使った事はありません。一応「ビデオチャット」となっていますが、基本的には音声のみでも同じ仕組みで可能だと思います。

他にも、標準的なSIPサービスを展開している所はありますが、規模という面では、やはりこの3大OSメーカーに絞られると思います。

この3つのうち、Skypeは既にOpusに対応を宣言していますし、Google Voiceも追従する可能性は高いかなと思っているのですが、正直Appleはどう出るのか全然判りません。

ちなみに、この「FaceTime」ですが、実はこの3つの中では、技術的には一番標準的な構成みたいなんですよね。あくまでウィキペディアによるとですが:-(
The FaceTime protocol is partly based on numerous open industry standards.:

H.264 and AAC – video and audio codecs respectively
SIP – IETF signaling protocol for VoIP
STUN, TURN and ICE – IETF technologies for traversing firewalls and NAT
RTP and SRTP – IETF standards for delivering real-time and encrypted media streams for VoIP
基本的には、SIPサービスといった感じですね。コーデックがH.264とAACですが:-( この部分をOpusに変更と迄はいかなくとも追加してくれれば無問題なんですけどね。

まあFaceTimeに限った事ではないですが、別にコーデックが違うサービスでも、ゲートウェイで変換すれば問題はないのですけど、変換に掛かるオーバーヘッドがバカにならない部分もあると思うので……。

FUSION IP-Phone SMARTもそうですが、やはりVoIPというのは、通常の音声サービスと比べると信頼性は劣りますからね。特にモバイル環境だと、通信速度だけじゃなくてバッテリー消費にも気を付けなくてはいけませんし。

そういう観点から見ても、iPhoneというかiOSは一歩先んじてるんですよね。本日発表された「iOS6」でFaceTimeの3G回線での使用が一部解禁されるようですし、前回のiOS5では「iMessage」という既存の3G網に左右されないテキストメッセージサービスも実現させていますし。このiMessageのベースとなっている「Apple Push Notification Service(APNS)」というアップル自前のPUSH通知サービスは本当に素晴らしいモノで、これがあるとiPhoneでのPUSH通知をバッテリーの消費を抑えつつ行う事が出来るようです。

実際、FUSION IP-Phone SMARTのようなSIPサービスを使用する場合でも、このAPNSを使用しているSIPクライアント「Acrobits Softphone」を使うとプッシュ通知設定が可能になり、Android版よりもバッテリー消費を抑える事が出来るらしいですし。

一応、Androidにも似たような技術「Google Cloud Messaging for Android (GCM)」というのが、Android 4.1から導入されたので、暫くすればiPhoenと似たような状況になるかもしれませんけど……。

なんか最初書きたかった事とズレてきてますが、恐らく将来的には携帯電話もキャリア依存の電話サービスではなく、iPhoneやAndroid、あるいはマイクロソフトのモバイルOSといったキャリア非依存の電話サービスが主流になってくると思います。

今更、キャリアの決めたコーデックをOpusのような新コーデックに変更しろといっても、無理でしょうがスマートフォンのような柔軟かつ陳腐化が激しい環境だと新コーデックへの乗り換えも比較的簡単でしょうからね。

書き忘れてましたが、このOpusの開発者が所属しているMozillaも「Firefox OS」というモバイル向けのOSを開発中です。こういった新興のOSでも、標準的なコーデックを自由に使用出来る事によって、音声サービスの相互接続性が担保出来るのも、大きなメリットになるのではないかと個人的には思っています。

他にも書く予定でしたが、長くなったので今日はこのあたりでやめておきます。なんか凄い中途半端かつ意味不明な内容になっていますが、ご容赦願います:-(

#外部リンク
アップル - iOS 6 - FaceTime。顔を見ながら通話をするための、最も簡単な方法です。
http://www.apple.com/jp/ios/facetime/

FaceTime - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/FaceTime#Standards

Verizon Wireless confirms FaceTime over cellular on all data plans -- Engadget
http://www.engadget.com/2012/09/12/verizon-wireless-comfirms-facetime-over-cellular-on-all-data-pla/

iMessage - Wikipedia
http://ja.wikipedia.org/wiki/IMessage

Apple Push Notification Service - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Apple_Push_Notification_Service

Google Cloud Messaging - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Google_Cloud_Messaging

Microsoft Notification Protocol - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Microsoft_Notification_Protocol

2012年9月13日木曜日

Opus Codec がIETFで標準化されたらしい

ようやく万能オーディオコーデックである「Opus」が、IETFの「RFC 6716」として標準化されたそうです。偉そうに書いてますが、詳しくは全く理解していません:-( 我々一般人からしたら、Opusが正式なコーデックとしてデビューしたって感じですかね。

あらためてOpusの特徴を書くと以下のような感じですかね。
Fearfully low latency: Frame sizes from 2.5 ms to 60 ms
Surprising voice and music quality (it beats all other comers across its operating range, including Vorbis and AAC)
Ruthless bitrate efficiency from 6 kb/s to 512 kb/s
Mono and stereo support (> stereo as paired channels)
Narrowband 8 kHz to fullband 48 kHz (enjoy high fidelity in your comfy chair)
以前は8kb/sが下限だった気がしたのですが、いつの間にか6kb/sになってますね。勘違いかもしれませんが。上限は512kb/sですが、正直そこまで高ビットレートな用途は、あまり必要ないと思いますけどね。

他にも特徴がありますが、一言で言えばVoIPから高音質なストリーミングまでカバーした、文字通り「万能」型なオーディオコーデックってところでしょうか。

コーデック自体以外に、開発体制も今までのコーデックとは違うのも特徴だと思います。以前にも書きましたが、このOpusというのは、Ogg Vorbis等で有名な「Xiph.Org」が開発していた「CELT」というコーデックと、Skypeが開発していた「SILK」という低ビットレートに強みのあるコーデックを一つにまとめた複合型なコーデックでもあるのです。

Opusが開発された段階では、Skypeは独自の会社だったのですが皆さんもご存知の通り、あのマイクロソフトが85億ドルという巨費を投じて買収した経緯があります。買収された後に、Opusの開発協定がどうなるのか気になってはいたのですが、そこは流石にマイクロソフト。特になんの変化もなく協力体制は維持されてきたようです:-P

今回の正式版に合わせてかSkypeの新コーデックとして、このOpusが投入される事が既にアナウンスされています。またAsteriskでもOpusがサポートされる予定(された?)です。これは非常に面白い事態になりそうだなと個人的には思っています。

最近、Googleの「ハングアウト オンエア」にも新コーデックが採用されたらしいのですが、もしかしたらこのコーデックというのがOpusである可能性がありそうです。これとは別に「Google Voice」というGoogleの音声通話サービスがあります。

現在のところ、使用コーデックは「G.711」のみのようですが、将来的にOpus、更に「Codec2」がコーデックのラインナップに加わったとしたら面白いのですけどね。

何が面白いかと言うと、現在インターネットで主流になっているVoIPサービスである「Skype」と「Google Voice」、そして「FUSION IP-Phone SMART」のような従来型のSIPサービスの使用コーデックが「Opus」(もしかしたら「Codec2」も……)という誰もが使用可能なオープンなコーデックで「統一」される可能性があるからです。

プロプライエタリ、オープン問わずに使える標準コーデックが出来れば、相互接続性が飛躍的に高まりますしね。相互のコーデック変換がなくなるだけでもオーバーヘッドはかなり減るでしょうから、それだけサーバーに掛かる負担も減りますし、音声の遅延も少なくなるでしょうし。

ここまで書いてきたなんですが、長くなりそうなので一度ここで切ります。

#外部リンク
Opus Audio Codec
http://opus-codec.org/

September 11, 2012: Opus audio codec is now RFC6716, Opus 1.0.1 reference source released
http://www.xiph.org/press/2012/rfc-6716/

It’s Opus, it rocks and now it’s an audio codec standard! ✩ Mozilla Hacks – the Web developer blog
https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/

Jean-Marc Valin's random rants on DSP, Speex, open-source - Opus is out, it rocks, and it's a standard
http://jmspeex.livejournal.com/11320.html

Internet Engineering Task Force - Wikipedia
http://ja.wikipedia.org/wiki/Internet_Engineering_Task_Force

Request for Comments - Wikipedia
http://ja.wikipedia.org/wiki/Request_for_Comments

Skype promising CD quality sound from new 'Opus' audio codec, fewer choppy calls -- Engadget
http://www.engadget.com/2012/09/12/skype-opus-codec-cd-quality/

Skype - The Big Blog - Skype and a New Audio Codec
http://blogs.skype.com/en/2012/09/skype_and_a_new_audio_codec.html

ハングアウト オンエア - Google+
http://www.google.com/intl/ja_ALL/+/learnmore/hangouts/onair.html

ミュージシャンに朗報―Google+ハングアウトに追加されたStudio Modeで高音質のライブ・ストリーミングが可能に
http://jp.techcrunch.com/archives/20120813google-hangouts-studio-mode/

2012年9月11日火曜日

Steam Box キターーーッ

いや、違いますけどね。以前からアナウンスされてた「Big Picture Mode」っていう、リビングルームにあるTV画面でSteamする為の新UIですが、コレ完全に据え置き機意識してますよね……。

ちょっと時間ないんで、取り敢えずビデオ貼って寝ますけど。いやぁ明日のゲーム系サイトの記事読むの楽しみだなぁ:-P

#YouTube
Steam's Big Picture - YouTube
http://youtu.be/EFrL6-OhN94



#外部リンク
Valve Is Bringing Steam To Your TV Today. Watch Out, Consoles.
http://kotaku.com/5941793/valve-is-bringing-steam-to-your-tv-today-watch-out-consoles

2012年9月7日金曜日

SFLPhone 1.2.0 リリース

数カ月前に発表された050番号を無料で持てるSIPアカウントサービス「FUSION IP-Phone SMART」の話題で、Ubuntuで使えるSIPクライアントとして紹介した「SFLPhone」のバージョンが「1.2.0」に上がりました。

実はこの前ブログに書いた後に、自分なりに気になる部分があり、SFLPhoneの翻訳を「Launchpad」上で進めていたのですが、今回の1.2.0で私の翻訳部分が無事取り入れられたみたいです:-P

といっても、既に8割方は日本語化されていたので、細かい調整くらいしかしていませんけどね。専門用語はそのまま手付かずですし:-( まぁ意味的には以前の訳より、多少自然な日本語になったのではないかと思っています。ちなみに1.2.0以降に更に手直ししましたので、上手く行けば1.3.0にも修正部分が取り入れられると思います。

その「SFLPhone」ですが、どうやらKDEの正式なソフトウェアとして採用されたようです。素晴らしい。このSFLPhoneは基本的にGUIツールキットを選ばない仕様になっているらしいので、KDE向け、GNOME向け、更にはCUIのみといったクライアントが複数存在しているようです。

他にも、このバージョンからARM環境への移植も正式に始まったようで、それに合わせて柔軟な機能選択が可能になったようです。もしかしたらですが、Raspberry Piのような非力なARM機器でも、簡易的なSIP端末として仕上げる事も可能になるかもしれませんね:-P

まぁ今なら古いAndroid電話機やパナソニックのハードウェアSIP電話機のようなものがあるので、そんなに需要がある訳でもないでしょうが、コーデックの拡張や多機能との連携等が比較的自由に出来るLinuxボックスで動かせるようになるというのは面白いかもしれません。何と言っても安いですし。まぁRPiの場合、音声入力部分が無いので、USBやBluetooth経由になると思いますが……。

コーデック部分ですが、先日のFirefox 15 で期待の「Opus」のネイティブなデコードが可能になりましたね。本当に素晴らしい。これで基本的にはSkypeと同等のVoIPコーデックがオープンソースソフトウェアに使用可能になったという事ですし。当然、SFLPhoneにも使用可能になる予定です。それも近い内に。

また、Opusと並んで期待している「Codec2」ですが、こちらにも動きがあるようです。どうやら、Codec2にVoIP向けの4kbpsバージョンを追加する予定みたいですね。

基本的にCodec2は、デジタルなアマチュア無線向けのコーデックなのですが、VoIPにも使いたいという声が多く、実際Asteriskや、いくつかのSIPクライアントで使用出来るようになってきているようです。

ただ現状のSIPの仕様では、いくらコーデックが4kbpsで使用出来るといっても、その他のオーバーヘッドが必ず追加されるので、あまりコーデック自体のビットレートは関係無いみたいなんですよね。そりゃ、低いに越した事はないのでしょうが……。

とはいっても、4kbpsというのは、プロプライエタリな低ビットレートなコーデックの代表格である「G.729」の8kbpsと比べても半分のビットレートで済む計算なので、かなり優位性はあると思います。

現状のCodec2は更に低い2.4kbpsですが、その分、音質は犠牲に成らざるを得ないですからね。4kbpsまで緩めれば、音質はその分余裕が出てくるでしょうし。まぁあくまで素人の意見ですけど。

ちなみに、この4kbps版Codec2の開発ですが、どうやら匿名の某企業からの支援を受けての開発なようです。一体どこなのかは明らかにされていませんが、なかなか粋な計らいですね:-P

最後にまたSFLPhoneの話題ですが、Opusの対応と並んで、上記でも名前が出た「G.729」の対応も視野に入れているそうです。とはいっても、自由なコーデックであるOpusやCodec2と違い、G.729はプロプライエタリなコーデックなので、実装出来るからといって、気軽に誰でも無料で使えるという訳でもないでしょうけど……。続報を待ちたいと思います。

#Picasa
以前はこんな感じでちょっと表示がおかしかった


直しときました:-P 




#追記
そうだ。肝心のUbuntuでの1.2.0の追加方法を書くの忘れてました:-( といっても、SFLPhoneのウェブサイトに書いて有りますけどね。
sudo add-apt-repository ppa:savoirfairelinux
sudo apt-get update
sudo apt-get install sflphone-client-gnome
これだけです。ちなみにGNOME版クライアントは、アドレス帳がevolutionのモノらしいので、正直使い勝手が悪そうです。って、使ってないので判りませんけど。

あと、ARM版への移植と併せてか、Andoroid版の開発も進んでいるようです。Androidにはデフォルト(ストック?)なSIPクライアントもありますし、他にもいくつか有料、無料のSIPクライアントがありますが、どれも決定打が無い印象なので、もしかしたらSFLPhoneベースのSIPクライアントが主流になる可能性もあるかもしれませんね:-P 選択肢は多いに越したことはないですし。

それと見て判る通り、携帯番号の後ろに"@fkr2.fusioncom.co.jp"といったドメインが追加されてしまいます。このままだと折り返しかける事が出来ません。また"fkr"の後ろも1や2といった番号が複数あるので、アドレス帳に登録する際に非常に面倒くさい事になりかねません。ソフトウェアによっては出たり出なかったりするようですが、常用するには何かしらソフトウェア側で対処しないといけないかもしれませんね……。

#外部リンク
Stable version 1.2.0 released | SFLphone - SIP/IAX2 softphone and VoIP client for GNU Linux
http://sflphone.org/news/stable-version-120-released

Stable release | SFLphone - SIP/IAX2 softphone and VoIP client for GNU Linux
http://sflphone.org/download/stable-release

SFLPhone KDE client joins KDE family | KDE.news
http://dot.kde.org/2012/08/21/sflphone-kde-client-joins-kde-family

SFLphone - Story or Feature #13273: Integrate opus codec - Savoir-faire Linux
https://projects.savoirfairelinux.com/issues/13273

SFLphone - Story or Feature #14301: G729 support - Savoir-faire Linux
https://projects.savoirfairelinux.com/issues/14301

Codec 2 wins the ARRL Technical Innovation Award « Rowetel
http://www.rowetel.com/blog/?p=2647

#内部リンク
BLOG.MINAWA.NET: FUSION IP-Phone SMARTを試す その2
http://blog.minawa.net/2012/05/fusion-ip-phone-smart-2.html

BLOG.MINAWA.NET: OpusとCodec2
http://blog.minawa.net/2012/06/opuscodec2.html

BLOG.MINAWA.NET: Opusの活躍は案外早いかも?
http://blog.minawa.net/2012/06/opus.html