2012/09/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/09/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/09/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/09/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/09/07

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

2012/08/31

CodeWeavers CrossOver 無料キャンペーン?

CodeWeaversが開発しているWINEベースのWindows互換レイヤ「CrossOver」がアメリカの大統領選挙? を記念したキャンペーンを行なっているそうです。本当はアメリカ国籍限定っぽいですが、一応外国人も参加出来るらしい……。

10万人分の署名(というかメールアドレスと記名)が集まったら、24時間限定でCrossOver MacあるいはLinuxのいずれか一つ(12ヶ月分の使用権)を無料でプレゼントしてくれるらしい?

ちなみに既にCrossOverを購入している人や以前登録していて今は期限が切れている人でも、最新版の使用権12ヶ月分を新たに追加してくれるそうです。多分……。

日本からだと多少後ろめたいですが、欲しい人が居たら参加してみるのも悪くはないですね……。詳細は未確認なので本当かどうかは各自で判断して下さい。

#YouTube
CodeWeavers Announces "Flock The Vote" - YouTube
http://youtu.be/Hme34hka_wg



#外部リンク
Run Windows on Mac and Linux, easily and affordably
http://www.codeweavers.com/

Press Releases - CODEWEAVERS TO MAKE CROSSOVER SOFTWARE FREE IF 100,000 PLEDGE TO VOTE IN PRESIDENTIAL ELECTION Announcing CodeWeavers’ “Return of the Quack: Flock the Vote!” CEO reluctantly revives “Lame-Duck – like” giveaway; readies company for potential collapse and books 1-month silent retreat at undisclosed Wisconsin winery/meditation compound - CodeWeavers
http://www.codeweavers.com/about/general/press/20120829/

Flock the Vote - CodeWeavers
http://www.codeweavers.com/flockthevote/

2012/08/26

Raspberry Pi が MPEG-2 と VC-1 のハードウェアデコードに対応

とうとうRaspberry Piがハードウェア(OpenMax)経由のMPEG-2とVC-1のデコードに対応したみたいです。といっても、それぞれのコーデックはライセンスが必要なので有料ですけど:-(

ちなみにMPEG-2が2.40英ポンド(約300円)、VC-1が1.20英ポンド(約150円)個別に掛かるようです。以前のブログでMPEG-2のデコードにRaspberry Piのコストの約10%が掛かると書きましたが、だいたいあってるみたいですね。

1個につき約300円というのは人によって高いかどうかの判断は分かれると思いますが、Raspberry Piのように安価な製品だと万人が許容できるレベルでは無いでしょうし:-( もともと教育用のマシンですからね。

とはいえ、300円の支出でMPEG-2の再生が可能になるというのは選択肢が広がるという意味で喜ばしい事だと思います。DVDを見るには外付けのDVD-ROMか独自にISO化した上でCSS暗号を解除しなければならないので、そう簡単ではないですが、CSS暗号の解除はソフトウェアで十分可能(法律は別として)だと思うので、そのうち何とかなるかもしれませんね。個人的にはHandbrake等でMP4あるいはMKV化した方が遥かに取り扱いが楽だとは思いますけど……。後は地デジ等のTSがデコード出来るかですが、正直どうなんですかね。

VC-1の方ですが、よく解りませんがドスケベなビデオとかですか? DRMフリーが大前提になるでしょうけど。まぁ再生出来ないよりは出来た方がいいですしね。

他にもH.264のハードウェア・エンコードやCEC(HDMIのリモコン?)の話も出ていますが、まだ詳しくみていないのでよく判っていません。そのうち詳細が明かされると思いますので、楽しみに待ちたいと思います:-P

#YouTube
libCEC support for the Raspberry Pi - YouTube
http://youtu.be/XPyOyJsnB1o



#外部リンク
New video features! MPEG-2 and VC-1 decode, H.264 encode, CEC support | Raspberry Pi
http://www.raspberrypi.org/archives/1839

Raspberry Pi lands MPEG-2 and VC-1 decoding through personal licenses, H.264 encoding and CEC tag along -- Engadget
http://www.engadget.com/2012/08/26/raspberry-pi-mpeg-2-vc-1-licenses-cec-h264/

Raspberry Pi Store
http://www.raspberrypi.com/

#内部リンク
BLOG.MINAWA.NET: Raspberry Piの新しい動画
http://blog.minawa.net/2011/09/raspberry-pi_09.html

BLOG.MINAWA.NET: MPEGがロイヤリティフリーのビデオコーデックを計画中?
http://blog.minawa.net/2011/02/mpeg.html

BLOG.MINAWA.NET: Raspberry PiとXBMC
http://blog.minawa.net/2012/02/raspberry-pixbmc.html

BLOG.MINAWA.NET: 久々にOgg Theora の話題
http://blog.minawa.net/2012/08/ogg-theora.html

2012/08/24

OpenPandora の "Product 3"

最近またOpenPandoraの事が気になってきて、ちょくちょくフォーラムを覗いているのですが、気になるニュースが書いてあったのでメモ。

1,2ヶ月前にCraig氏が何か企てているというのを書いたのですが、その内容が明らかになりました。仮称「Product 3」というアイテムですが、どうやら"iControlPad"の進化系なようです。昨日フォーラムに投下されたスクリーンショットがコレです。

#Picasa


見て判る通り、コントローラーと(簡易)キーボードが一体となったようなデザインですね。何となくPandoraのコントローラー兼キーボードのレイアウトと似ていますが、それもそのはず、このレイアウトが現在企画中の「Pandora2」のベースレイアウトとなる(予定)らしいです。

まだ詳細は語られていませんが、この"Product 3"は、iControlPadのような単体コントローラーのみで、実際に使用するにはAndroidのようなスマートフォンやタブレットが必要らしいです。ちょっとデザインが野暮ったいので、どのような形でスマートフォン等と組み合わせるのか想像が付きませんが、多分Bluetoothで接続する形になるのでしょうね。

うろ覚えですが、Craig氏は今話題の"Kickstarter"を利用したいそうです。この"Product 3"か"Pandora2"からなのかは微妙ですけど。

ちなみに"Kickstarter"は米国に籍を置く企業以外は問題があるそう? なのですが、どうやら今年中にCraig氏が住む英国でも同様なサービスを展開する予定らしく、それがスタートしたらOpenPandoraも参加する予定らしいです。確か11月? だったかな? 今時間が無いので後で調べてみます。

気になるお値段ですが、現行のiCPよりも若干高めらしいです。正直、iCP自体も今となっては高い気がしますけど。個人的には50ドルくらいが限界かなぁと思います。

それと"Pandora2"ですが、Craig氏の発言によると、かなり高性能なSoCを使用するらしい? お値段も高くて、およそ"700ドル"! くらいになるらしい? 少数(1000台?)の愛好家のみが対象になるとかなんとか。申し訳ないですが、ちょっといい加減な情報で、全然違っているかもしれませんが……。

この話は、また続きを書くつもりです。今日は時間が無いので取り敢えずここまで。おやすみなさい。

#内部リンク
BLOG.MINAWA.NET: 超久々にOpenPandoraの話題
http://blog.minawa.net/2012/06/openpandora.html