2013年01月29日

Soxは便利

以前、soxでカセットテープ音源のスピード調整という記事でAudacityなみの処理をコマンドラインから行うSoxというアプリを使った経験を書いたが、再びこのSoXを利用したので一例報告まで。

発端は、妻がBluetooth接続のスピーカーを買ったことだ。5年ばかり前の引越しの際に妻が長年愛用したカセットコンポを処分して以来、我が家にはオーディオ機器がなかった。今回買ったBluetoothのスピーカーは、オーディオ機器というにはあまりに貧弱だが、それでもたとえばテレビのスピーカーなんかに比べればはるかにマシで、いい音がする。ある意味、音質に限界のあるMP3ファイルの再生にはちょうど似つかわしいかもしれない。ということで、MP3プレーヤーとして使えるスマホを音源として、久々に音楽のある生活が戻ってきた。

ところが、ここで困るのがMP3ファイルの音のレベルの差だ。音源がレコードやCDならその1枚の中でレベルはきっちり調整されている。自分で録音したテープなら、録音するときにそのあたりは気を使ってできるだけ差の出ないようにしている(というか、はるか昔、「エアチェック」をやっていた高校生の私は、けっこうそのあたりに気を使ったものだ)。しかし、MP3ファイルはバラバラのソースからバラバラに入手したものをまとめて聞くので、レベルの差が気になる。曲が替わるたびに音量を変更するのは現実的ではないし、かといって突然大きな音になったり聞き取れなくなるのもの快適ではない。

ということで、MP3の録音レベルを統一する必要がある。Audacityでやれば簡単なのだけれど、いちいちファイルを開いてフィルタをかけ(「正規化」というフィルタでたいていはOKだ)、エクスポートするという操作をファイルの数だけ繰り返すのはたいへんだ。となると、SoXでバッチ処理がよかろうということになる。

調べてみると、SoXの正規化は、
sox infile outfile gain −n
というコマンドでOKなようだ。これをバッチでやるには(元ファイルが.ogg形式として)、

for i in `ls *.ogg`; do echo -e "$i"; sox $i a/$i.ogg gain -n; echo -e "$i.ogg"; done

というスクリプトになるようだ。なお、このコマンドは該当するファイルの存在するディレクトリにはいって実行し、実行前に予めそのディレクトリ内に「a」という名前のフォルダを作成しておく必要がある。このスクリプトの詳細な意味は、実のところ私にもよくわかっていない。前の記事に書いたスクリプトを必要に応じて変更しただけだし、そのさらに元のスクリプトの出典は、その記事のどこかにリンクをはってあるはずだから、必要な方はぜひたどってほしい。

ともかくも、これで録音レベルは揃った。音楽を聞くのもなかなか一筋縄ではないな。
posted by 松本 at 21:19| Comment(0) | TrackBack(0) | Ubuntuのアプリケーション | このブログの読者になる | 更新情報をチェックする

2013年01月14日

PDFの文字入れならXournal

一つ前のエントリでKarbonが思いがけず使えたと書いたが、そのコメント欄でTOYさんから「PDFに赤入れするならXournalが簡単ですよ。」と教えていただいた。早速、Xournalを調べてみたら、スタイラスペンでの入力のためのアプリらしい。PDFの編集とはちょっとお門が違うようだけれど、モノは試しとインストール。Ubuntuのリポジトリにあるから、Synapticパッケージマネージャで(というよりいまではソフトウェアセンターで、というのがメインストリームなんだろうが)ごく簡単にできる。

立ち上げてみると、レポート用紙のような罫線の画面になる。なんとなく、iOSアプリの7notesを思い出す。たぶん、用途としてはそういう方向性なのだろうが、メインの用途ではないPDF編集に使うわけだから、この画面は要らない。メニューのFileからAnnotate PDFを選ぶとファイルの選択画面が出るから、ここからPDFファイルを開く。すると、その上に罫線を引くことも文字を打つことも自由にできる、という具合だ。

Inkscapeのようなドローイングソフトと違うのは、文字や図形のベクターデータを編集可能なかたちで読み込まないこと。基本的にはevinceのようなPDFビューワでPDF文書を閲覧しているのと同じだと思えばいい。あとからXournal上で打ち込んだ文字や図形は、おそらく元のPDFに追加されるだけで元データそのものはいじらないのだろう。

これはこれで、ひとつの利点になる。というのは、Inkscapeのようなドローイングソフトではフォントがうまく読み込めないときにはフォントの置換を自動的に行い、それがレイアウト崩れの原因になる。さらに、いったん読み込んだPDFを保存するとファイルの大きさが増大するケースが多い。図形の読み込みでもエラーが起こる場合もあり、いじるつもりのない部分までいじることができてしまうというのは、用途によっては(たとえば書式に書きこむだけのような場合には)ない方が嬉しいぐらいだ。そういう点で、Xournalは使い勝手がよさそうだ。

ただ、メニューのFileからExport to PDFを選んで保存しようとしても、ファイルによってはうまくいかない場合があるようだ。ちょっと試しただけなのだけれど、うまく保存できたファイルとあとから打ち込んだテキスト文字だけが保存されて元データが保存されなかったファイルとがあった。ただし、後者の場合でもPrintからPDFファイルとして保存するというベタな方法なら問題なく元データと、その上に書き込んだデータの両方がきちんと保存される。問題というほどの問題にはあたらないだろう。

元データの一部でもいじりたいとき(たとえば図形の位置を変更したいとか文字を削除したいとか)ならやっぱりInkscapeだとは思うが、実用的にはほとんどがこのXournalで間に合いそうだ。いいツールを教えていただいて感謝している。

posted by 松本 at 21:12| Comment(0) | TrackBack(0) | Ubuntuのアプリケーション | このブログの読者になる | 更新情報をチェックする

2013年01月10日

Karbonが思いがけず使えた。

PDFで与えられた様式にデータ上で記入するのは案外と面倒だ。オフィス系のソフトでこれをやろうとすると、直接PDFデータを取り込むことができないから、画像化するぐらいしか方法がない。適当な方法、たとえばスクリーンショットとかでPDFデータを画像化し、それを下絵としてワードなりなんなりの文書に貼り付ける。その上からテキストを配置していくわけだ。だが、この方法はスマートとは言いがたい。アウトラインデータはドット化するし、文書を保存したらそのぶんだけ重くなる。

PDFを直接編集するならAdobeのAcrobatにその機能があるが、Linuxの場合、これはPDF Editorになる。ただ、このPDF編集ソフトは、あまりフレキシブルとは言いがたい。きれいにデータを加工するのであればやはりベクター編集ソフトであるInkscapeでPDFを読み込んで、その上で編集してやるのがいちばんだろうと思う。

今朝、たまたまPDFの様式があって、これにいくらか文字を記入しなければいけない作業が生じた。いつものようにPDF文書を右クリックしてInkscapeから開くように指定した。2ページある文書の1ページ目に記入する必要があったのでそちらを選択し、さて、開くように指示をしたが、いつまでたってもそこから先に進まない。

PDFはかなり複雑な仕様なので、ごく稀にこういうことが起こる。Inkscapeで開けないPDFは編集は基本的に無理なので、画像として処理するしかない。こういうときはやはり右クリックからInkscapeではなく、画像処理ソフトのGimpを選択する。そして、画像としてGimpで文字を貼りつけていくのがいいだろう。

そう思って、右クリックで「別のアプリで開く」を選択したら、そのリストにKarbonが上がっている。実は、少し前、ベクターグラフィックソフトにKarbonというのがあると聞いてインストールしてみていた。インストールしてから気がついたのだが、これは以前のKOffice、現在のCalligra Suiteの一部を構成するソフトだ。だったらあまり期待もできないなと思って試用して、「まあ、Inkscapeには勝てないな」とその後放置してきたものだ。

けれど、せっかく候補に上がったのだからとそれでPDFを開くようにしてみたら、あっさりと開くことができた。Inkscapeでは無理なのがKarbonだと通るということがあるようなのだ。これには、正直、「お、やるじゃないか」と思った。

ただ、肝心の文字を打つ方法がわからない。どうするのかなあと思ったら、右下隅にArtisticというアイコンがあって、これで一行テキストを挿入できる。そして、テキスト編集に入ると、それまでアラインメントを表示していた部分にテキストの属性指定の画面が現れるので、これである程度のことができる。UIがちがうので最初かなり戸惑うが、それなりのことはきちんとできるようだ。

ただ、結局これで作成した文書は使わなかった。最初に読み込んだとき、フォントの置換がうまくいかなかったらしく、元文書のレイアウトが少しだけ崩れてしまったからだ。結局はGimpで処理したのだからKarbonのご利益は特になかったと言える。それでも、今後が楽しみに思えてきた。また機会があれば試してみよう。
posted by 松本 at 22:02| Comment(2) | TrackBack(0) | Ubuntuのアプリケーション | このブログの読者になる | 更新情報をチェックする

2013年01月08日

WineでInDesign - WindowsユーザーがUbuntuに乗り換えるべきもうひとつの理由?

時間がなくて最近はそれほどマメに見ていないTwitterを開いたら、タイムラインに「無料のAdobe製品をダウンロードした」というようなTweetがある。どうせ海賊版か何かだろう、触らないほうが吉と無視を決め込んでいたら、どうやらそれは、こちらの記事にあるような事情のことらしい。

「無償でライセンス提供していない」--アドビ、CS2ダウンロード騒動に正式コメント

アドビ、CS2製品データ公開は「正規ライセンス保持者への措置」と発表
 
私はかつてアドビ製品を使って仕事をしたこともあるが、現在はライセンスを何一つ所持していない。だから、海賊版ではないにせよ、これをダウンロードして使うわけにはいかない。これは記事のとおりだ。だが、この記事を読んでいてふと気になった。今回、ライセンスを所有しているユーザーに対して旧製品のダウンロードサービスをAdobeは提供しているわけだが、その理由はどうやらこれらの製品はそもそも現代的なOSでは動作せず、Adobeとしてもサポート外としているということに関係しているらしい。「旧来のOS上で継続してCS2製品およびAcrobat 7を利用するユーザーを考慮し、」というわけだ。
ということは、Windows Vista以降、CS2が動作しないということでAdobe製品の使用を断念するかXPにとどまり続けるかの選択を強いられたユーザーがいるということだ。そして、CS2のライセンスにとどまり続けている人々は、時代遅れのXPから進歩できずにいる(あるいは仮想環境を使う不便を強いられている)。その詳細は、たとえばこちらにある。

しかし、ひょっとしたらUbuntu上のWineなら、最新の環境でCS2が動作するのではないかと気がついた。私はライセンスはないけれど、動作確認をするぐらいの試用ならお咎めを受けることもあるまいと思って、Creative Suitesの中でも特に出色のできだったと私が思っているInDesignをダウンロードしてみた。そして、Wineで走らせると、順調にインストールできる。

ただし、起動はうまくいかない。やっぱりだめなのかなと思いながらWineの公式ページを見ていると、こちらに対処方法が書いてあった。ネイティブのsystem32/oleaut32.dllをコピーし、.wineのProgramフォルダ内にあるInDesignのディレクトリのPlug-Ins/Script/Support for Visual Basic.aplnを削除すると起動するらしい。やってみると、まちがいなく起動した。そして、はるか昔にInDesignで作成したデータも無事に開くことができた。

もちろん、Wine上の動作なので、完璧とはいかない。ごく短時間の試用でも、「あれ?」というようなところはいくつかあった。たとえばプリンタはうまく認識しない。おそらく機能的には十全ではない。けれど、とにかく動作する。

ということは、CS2(あるいはInDesignの4.0)の正式ライセンスをもった方でXPを離れられずにいる方は、Ubuntuに乗り換えれば最新の環境でInDesigneを使い続けることができる、ということではないだろうか。これは、Windowsを捨ててUbuntuに乗り換える理由にはならないか?

まあ、ならないだろうなとは思う。InDesigneはかつかつ動くものの、Illustratorはどうやら動作しないようだから。Photoshopは動作するらしいけれど、この時代のPhotoshopならいまのGimpのほうがたぶん上を行くだろう。なによりも、今回のダウンロード製品は英語版で、日本語の表示はできるし基本的な機能はOKだけれど、やっぱり日本語環境で100%使いこなすには難があるだろうから。

ということで、まああまり役にも立たない試行となった。ライセンス違反でとやかく言われるのは嫌なので、すぐにインストールしたソフトは消去した。これは、ホームフォルダ内の隠しフォルダ.wineをまるごと消去するのがいちばんだ。wineのおもしろいところは、このフォルダを入れ替えることで、環境の復元や初期化が非常に簡単に行えること。この魅力は捨てがたい。少なくともいろいろ遊んでみる上では。
posted by 松本 at 22:06| Comment(0) | TrackBack(0) | Ubuntuのアプリケーション | このブログの読者になる | 更新情報をチェックする

2013年01月03日

soxでカセットテープ音源のスピード調整

ずいぶんと以前、Audacityでカセットの整理で書いたのだが、古いカセットテープの音源は、すべてMP3に落として後生大事にハードディスクに保存している。なつかしいテープばかりだから、捨てる気になれず、手間暇かけてMP3化したわけだ。ところが、この音楽ファイルを聞くことは滅多にない。いろいろと理由はあるのだけれど、最大の問題は再生装置がないことだ。もちろんパソコンで再生することはできるし、MP3プレーヤーで聞くこともできる。けれど、コンポが壊れて以来バックグラウンドミュージックとして部屋で流すのに適した装置がなく、わざわざイヤホンつけてまで聞くのも大層なので、ほとんどオクラ入りになっていた。

実際、最近は音楽を聞くのはほとんどカーステレオに限られてきてしまっている。だから、MP3プレーヤーとFMトランスミッターを組み合わせて車で聞くつもりだった。ところが、これが雑音を拾うばかりでちっとも快適ではない。なんだかなあと思って、それもやめていた。調べてみると軽自動車ではエンジンからトランスミッターまでの距離の関係で雑音を拾うことがあるらしい。どうもそういうレアなケースに遭遇したらしいと、すっかりその方面は諦めていた。

ところが、最近になって妻がMP3プレーヤーの代わりにiPhoneを持ちだしてFMトランスミッターを試してみると、雑音のないクリアな再生音がする。なんのことはない、雑音を拾っていたのはFMトランスミッターではなく安物のMP3プレーヤーだったわけだ。そうとわかったら、やっぱり古い音源も聞きたくなるだろう。

だが、ここで問題が発生した。いや、あらためて発生したというよりも、以前から放置してあった問題がクローズアップされることになった。

カセットテープの走行速度は、ちゃんとした規格が定められている。もしも規格外のスピードで再生したら、音程やテンポが元の音源と狂ってしまう。けれど、実際にはカセットテープの走行速度はデッキやテープレコーダー、ラジカセの機種によって、微妙に異なっている。このことはずいぶんと以前から気づいていた。というのははるか昔、高校入学祝いにカセットデッキを買ってもらったとき(というか、「祝いに買ってやる」というので自分で日本橋に買いに行ったのだけれど)、そのデッキでラジカセ録音のテープを再生すると音程が違うのに気づいたからだ。これは私がギターが趣味で、録音した音源に合わせてギターの練習をしていたからはっきりとわかったのであって、ぼんやり聞いていたのではわからないレベルだっただろう。実際、その後も「デモテープ作ったから練習しておいて」と言われて渡されたテープの再生でフラストレーションを感じたことは何度もあった。

そして、妻と私が過去に何台かのデッキで録音したテープを最終的にMP3化する際に使用したウォークマンタイプのカセットプレーヤーで再生すると、ほとんどのテープで再生速度が数%遅くなる現象が発生した。なかには音程がぴったりのものもあったから、このあたりは相性というか組み合わせの問題だったのだろう。

最初は、「まあいいか、しょせんはカセットテープの音源だし」と思っていたが、この数%の間延びした音は、音楽として楽しむにはちょっとつらいものがある。ようやくちゃんとした環境で古い音源を鑑賞できるようになったのに、どうにも間延び感が気に入らず、結局は聞くのをやめてしまった。

これではあんまりにも情けない。Audacityを使えば再生速度の変更はフィルター一発でできる。もともとMP3への変換ではAudacityを使ったのだからその時点でひと手間かけておけばなんの問題もなかったわけだ。ただ、それをいまからやり直そうと思ったら、いちいちファイルを開き、フィルターをかけ、保存をしなおすという手間をファイルの数だけやらなければならない。テープはA面とB面の2ファイルに分かれているから、約300本のテープで600ファイル以上。これはやっていられない。

こういうバッチ処理は、やはりスクリプトで処理すべきだろう。私は「端末を開いてコマンドを」というCLIがほとんどできないGUI派だけれど、スクリプト処理の威力は知っている。コマンドラインでAudacityが使えればいちいち手作業で変換処理をしなくてもバッチでOKではないかと見当をつけた。

その上でちょっと調べてみると、Audacity並みのパワフルなサウンド処理ができるCLIのソフトでsoXというのがあるのを知った。これはUbuntuのリポジトリにも収録されている。そこで、このsoxをインストールし、端末を開いて
sox 1.mp3 2.mp3 speed 1.04
と入力してみた。ここで1.mp3というのはテスト用のmp3ファイル、2.mp3が出力ファイル、1.04という数字は4%だけスピードを早くするようにという指定である。ところがエラーが出て処理ができない。ちょっと悩んだが、これはリポジトリに収録されているsox用の追加のライブラリをインストールすることで解決した。このコマンドを実行すれば、1.mp3というファイルの再生速度が修正されたファイルが2.mp3として作成される。

さあ、あとはこれをバッチでやればいいんだと思ったものの、方法がわからない。ワイルドカードを使ってみてもうまく行かない。というのは、出力側のファイル名をうまく指定できないからだ。こういうときはシェルスクリプトを書けばいいとは思うのだが、シェルスクリプトの作法は知らない。昨年少しだけPythonを勉強する機会があったのでそれを応用しようかとも思うけれど、正月早々にそんな大層なことをやるのも面倒だ。

そんなことを思いながらさらに調べていたら、こちらにsoxを使ってwav形式のファイルを.cdrという形式に変換するコマンドが掲載されていた。ちなみに.cdrという拡張子のファイルがどういう形式なのかはさっぱりわからないが、この際それはどうでもいい。最終的にこのコマンドを参考にして、次のコマンドでバッチ処理を行った。

$ for i in `ls *.mp3`; do echo -e "$i"; sox $i a/$i.mp3 speed 1.04; echo -e "$i.mp3"; done

これを大量のmp3ファイルがあるディレクトリで端末を開いて実行する。なお、このディレクトリ内に"a"という名前のフォルダを予めつくっておいた。変換後のファイルは、このaフォルダに生成されていく。スクリプトの意味は恥ずかしながらあんまりわからないが、端末に処理済みのファイルの名前が次々に表示されていくところを見ると、「echo」はその指定なのだろう。lsでフォルダ内のファイルの情報を読み取り、それを順次処理していくことになるようだ。最終的にできるファイルは、ファイル名が1.mp3.mp3というぐあいに拡張子がダブってしまう。これをスクリプトで処理しておくのが本当なのだろうけれど、このぐらいのことならxfce4のデフォルトファイルマネージャであるThunar付属のバルクリネームであっという間に処理できる。ちなみに、上記のスクリプトはファイル名にスペースがあるとエラーを起こすので、処理前にファイル名のスペースを別文字に変換しておく前処理が必要になる。この処理にもバルクリネームは使える。なに、Thunarでフォルダを開いておき、ファイルを複数選択してF2を押すだけなので至って簡単。

うまくいかなかったのは、おそらく元ファイルの圧縮率の関係で、変換後のファイルサイズが変換前のおよそ2倍になってしまうこと。圧縮率を変化させるコマンドもsoxにはあるのだけれど、これはどうも使い方がよくわからずに断念した。

本当は、一律4%ではなく、それぞれのファイルごとに微妙に音程は異なるようだ。けれど、そこを突き詰めるよりは、とりあえずこれで快く聞けるようになったのだからよしとしようではないか。

posted by 松本 at 16:14| Comment(12) | TrackBack(0) | Ubuntuのアプリケーション | このブログの読者になる | 更新情報をチェックする