自炊ePubのためのあれこれ覚え書き

先日、ちょっとした私家版書籍の電子版製作を依頼され、先月はあれこれ試行錯誤していましたが、ようやくそこそこ形になったので培ったノウハウをメモしておきたいと思います。作業環境はMacです。

■仕様

  • 原稿はWordでレイアウトされたファイル
  • 日本語縦書き
  • 本文は明朝、見出しはゴシック、引用文として丸ゴシック
  • 図版は無し(これがあったら更に大変だったことでしょう…)
  • リフローで作る
  • 汎用フォーマットとしてePub、Kindle用に別途mobiを作成
  • KDPによる出版などはせず、自サイトでの無償配布のみ

てな感じです。

■作業手順概要

元ファイルがWordだったので、一太郎・玄2013で読み込み、ePub書き出しをしてみました。元Wordでのレイアウトがスタイルを駆使したものではなく、個別指定箇所がほとんどだったため、微妙なマージやフォントサイズ指定の差異で、かなりアドホックなCSSクラスが作られてしまいましたorz。

一太郎ではePubのソースは一切いじれないので、そこからはSigilで手作業。ただし、Sigilは縦書きに正式対応したePub3.0には対応しておらず、Android系やWindowsストア系のePubリーダーアプリでは縦書きにならない問題が発生(iBooksやmobi化してKindle PaperwhiteではOK)。結局ePub3.0化を決意して、テキストエディタ(Sublime Text2を使用)でちまちま修正することにしました。Sigilは非対応なタグを強制的にePub2.0仕様に書き換えてしまうので、おそらく一太郎出力時点でePub3.0だったものが色々書き換えられてしまったんじゃないかと思います。今後はSigilを使わずにエディタを使おうと思います。Sigilの出力したファイルをePub3.0互換に書き換えるには、EPUB日本語文書作成チュートリアルが参考になりました。

Sigilの便利な点はePubを読み込み、ePubを書き出す、という作業が自動で行える点です。ePubは実際にはxhtml、css、画像その他のメタファイルを一定のフォルダ階層ルールに沿って配置し、zipで固めて拡張子をepubにしたものです。テキストエディタ等で手編集する場合は、デバッグ作業をする度に、zip化->リネームをしなければなりません。しかも、mimetypeというファイルがアーカイブの先頭になければならない、というルールがあり、単純にアーカイバにフォルダをドロップ、というわけにもいきません。具体的には、Macのターミナルで、こんな感じで作業しました。カレントディレクトがソースフォルダhogeのルート(トップ)にいるとします。

zip -0 -X ../hoge.epub mimetype
zip -r ../hoge.epub * -x mimetype

1行目で新規アーカイブhoge.epubを1つ上の階層(ソースフォルダと同じ場所)に作成し、mimetypeのみ追加。2行目で同じアーカイブにmimetype以外の全てを追加、という手順ですね。アーカイブの拡張子はepubが直接指定できているのでリネームは必要ありません。ターミナルの履歴を使えばさほど手間ではないですが、いっそバッチやドロップレットにしてしまうのも手かも知れません。

OSX MervericksではMac版iBooksが搭載されているので、できたファイルをダブルクリックすればiBooksで開き検証ができます。Mervericksが出る前はMurasakiを使っていました。Mac版iBooksはデフォルトではページ中心に隙間があいた2ページ表示ですし起動もややもっさりしていおり、更には単に元ファイルを上書きするだけでは更新されず、ライブラリからアイコンを削除しないと変更が反映されないこともありました。なので、Mervericksであってもデバッグ作業はMurasakiの方が効率が良いかも知れません。たぶんレンダリングエンジンは同じWebKitベースだと思います。

■縦書きにする

色々試しすぎてどれが効いているかやや微妙ですが、憶えてる限りでは、スタイルシートに、

html {
    writing-mode: vertical-rl;
    -epub-writing-mode: vertical-rl;
    -webkit-writing-mode: vertical-rl;

    line-break: strict;
    -epub-line-break: strict;
    -webkit-line-break: strict;

    word-break: normal;
    -epub-word-break: normal;
    -webkit-word-break: normal;

}

としました。色々な環境に対応できるよう、-epub-と-webkit-のプレフィクスを付けた指定も重複して指定してあります。どの環境でどれが必要になるかまでは検証してません(笑)。

あとはページ送り方向を右綴じ準拠にする為、content.opfのspineタグの部分に、

<spine page-progression-direction="rtl">

のようにpage-progression-direction属性を追加しました。

■マージン指定に関するTips

段落毎などにマージンをいれたい場合、margin-right(段落の手前)、margin-left(段落の後)を使います。Kindle出版ガイドに、「emではなく%で表示しないと、文字を拡大した時に無駄に行間が空いちゃうよ」と書かれており、試しに%に書き換えてみたんですが、iBooksでヒドいことになり戻しました。どうも基準となる100%の幅として画面縦のピクセルを使っちゃうようです。ウインドウの縦の長さを変えると、横にマージンが広がる、という状態にw。縦書き対応が不十分なんですかね。あるいはright/leftではない別の指定方法があるのかも。ググるとmargin-beforeみたいな物理方向に依存しない指定方法を検討はされてるみたいですが、今のところ正式には決まってないみたい(ePbu3.0自体がまだドラフトなんですよね)。

まぁ、KDPで出版するわけじゃないので、em指定に戻しました。Kindle Paperwhiteでも特段不都合出てないような気がします。

■縦中横を指定する

縦中横とは、縦書き文中の英数字、記号などが横に寝てしまっているのを正立させる指定です。丸数字や2桁程度の数字に適用させました。スタイルシートにtcyというクラスを作り、必要箇所にspanタグで指定しました。

/* 縦中横(丸数字などを正立させる) */
span.tcy {
text-combine: horizontal;
-epub-text-combine: horizontal;
-webkit-text-combine: horizontal;

text-indent:0;
}

■フォントを埋め込む

これが一番苦労しました。本文に丸ゴシックがあるのですが、多くのリーダーは明朝とゴシックが1書体ずつ入っているのみ。また手持ちの初代SONY Reader PRS-350は内蔵フォントをCSSで指定することもできないっぽい(後継モデルは大丈夫らしい)。iOS版iBooksでは「ヒラギノ丸ゴ W4」が追加ダウンロードできるので、CSSで指定してやればOKでした(Mervericks版は標準でOK)。

ハードウェア内蔵フォントが使えないとなると、ePubに埋め込むか、リーダー自体に追加するかですが、後者はユーザにリテラシーが必要なので今回は除外。しかしePubに埋め込んで配布する場合はライセンスの問題が発生します。一般に売られているPC/Mac用の商用フォントは埋め込み禁止のものがほとんどです。使っているフォントのみ埋め込む「サブセット化」ならOKというのも聞くのですが、サイトの記載だけだといまいちはっきりせず。フリーの丸ゴシック系フォントはないものかと探したところ、「モトヤマルベリ3等幅」というのが、Android4.0搭載用にApacheライセンスでオープンソース化されていることが判明。こちらで配布されています。MTLmr3m.ttfが「モトヤマルベリ3等幅」、MTLc3m.ttfが「モトヤシーダ3等幅」という角ゴシック体のようです。今回は商用配布でもないのでコスパ優先ということでこちらを採用することにしました。Apacheライセンスなのでコンテンツ中(配布サイトでもいいのかな?)にライセンスを明記する必要があるかも知れません。また、埋め込みフォントならばPRS-350でも有効っぽかったので、角ゴシックも埋め込みで対応することにしました。

なお、これらの2書体を縦書き用にカスタマイズしたというKoboMaruとKoboNakuが公開されているようですが、試したところ記号がズレてしまってダメでした。

これら2書体のをそのまま埋め込むと、130KB程度だったファイルサイズが一気に3MB位になってしまいました。iBooksでは不要なものなのでちょっと悔しい。かといってiBooks向けとそれ以外向けでePubを複数バージョン管理するのもしんどい。ということで、サブセット化をしました。武蔵システムさんが公開しているフォントサブセットメーカーを使用します。Windows版とMac版があるのが有り難いです。実際に使用する文字をテキストで指定する必要があるわけですが、今回は原稿Wordファイルからテキスト出力して使いました。本当は角ゴシックの部分、丸ゴシックの部分だけのテキストファイルを用意してやればさらに小さなサブセットが作れるはずですが、さすがに面倒なので断念。結果として出来上がったePubは700KB程度に。これならばiOSユーザの人にもさほど負担がない範囲かと。

なお、上記ページから辿れるWOFFコンバータでWOFF(Web Open Font Format)形式にしてやれば更に縮むっぽかったんですが、一部環境でアプリがクラッシュするなど問題が起きたので今回は見送りました。

埋め込み方法ですが、まずソースファイルのOEBPSフォルダの下、つまりTextやStylesフォルダと同階層にFontsフォルダを作り、ttfファイルを入れます。今回は、MTLc3m_sub.ttf、MTLmr3m_sub.ttfという名前にしました。

次にコンテンツファイルの目録であるcontent.opfファイルのmanifestタグの内側に下記2行を追加します。

<manifest>
(…各種xhtmlファイルなどが列挙されてる部分…)
  <item href="Fonts/MTLmr3m_sub.ttf" id="MTLmr3m_sub.ttf" media-type="application/x-font-ttf" />
  <item href="Fonts/MTLc3m_sub.ttf" id="MTLc3m_sub.ttf" media-type="application/x-font-ttf" />

</manifest>

そしてスタイルシートで、

@font-face {
    font-family: "MTLmr3m";
    font-weight: normal;
    font-style: normal;
    src: url("../Fonts/MTLmr3m_sub.ttf");
}
@font-face {
    font-family: "MTLc3m";
    font-weight: normal;
    font-style: normal;
    src: url("../Fonts/MTLc3m_sub.ttf");
}

と定義した後、任意のクラス等に

/* 角ゴシック */
.kaku {
    font-family: "ヒラギノ角ゴ ProN W3", "Hiragino Kaku Gothic ProN", "MTLc3m", "@MS ゴシック", "@MS Gothic", sans-serif;
}

/* 丸ゴシック */
.maru {
    font-family: "ヒラギノ丸ゴ W4" ,"Hiragino Maru Gothic ProN",  "MTLmr3m", "@MS ゴシック", "@MS Gothic", sans-serif;
}

等と指定します。なおこの例では最終的に丸ゴシックが使えないケースも想定してフォールバックフォントに角ゴシックを指定しています。iBooksだとヒラギノが優先的に使われ、それ以外では埋め込みのモトヤ、それもダメならMSゴシックか内蔵フォントという感じです。多くのリーダーだと、sans-serifでゴシック、serifで明朝の内蔵フォントになるようです。

■目次ファイル

Sigilが出力していたePub2.0ファイルセットを手作業でePub3.0化した際、目次ファイルであるtoc.ncxは使われないので削除してOKと書かれていたんですが、そうしてしまうとKindle PaperwhiteだったかSONY Readerだったか忘れましたが目次が使えなくなってしまいました。ので結局残してあります。目次ファイルが複数になってメンテナンス上は手間ですがまぁ仕方ないですね。

■様々なリーダー環境で確認

そんなこんなで、以下のプラットフォームで概ね良好なレンダリングが得られるものができました。

・iOS (iPad/iPhone/iPod touch)

Apple純正リーダーであるiBooksを使用。メール添付はSafariからのダウンロードでePubファイルをインストール可能。iOS6まではiMessage添付でもいけたんですがiOS7はダメになってるっぽい?配布ページにてヒラギノ丸ゴW4を別途インストールするようお願いをしています(アプリ内のフォント選択ポップアップで簡単に追加できます)。

・Mac OSX Merverick

こちらも最初からインストールされているiBooksで閲覧可能です。

・Mountain Lion以前のMac

上述のMurasakiが軽くてオススメですが、Adobe Digitai Editons辺りが大手企業ということで紹介しやすいかも知れません。

・Windows

同様に、Adobe Digital Editionsが無難でしょうか。

・Windows 8/RTストアアプリ

ePub対応を謳うアプリは山ほどありますが、残念ながら縦書きすら見られないようなものばかりでした。何か良いものがあれば是非ご紹介下さい。

・SONY Reader

手持ちのPRS-350(最新ファーム3.0.03.03190で縦書き、ルビ、縦中横、埋め込みフォント、目次ともに正常に機能しているようです。

・kobo

手持ちがないので未検証。楽天優勝セールで半額になってたので、kobo gloを注文しました。検証できたら追記します。確かkoboは段落毎に通し番号IDをつけないと目次や既読位置保存が使えないみたいな制約があったはずです。あと、拡張子をkepub.epubみたいな二重拡張子にしないといけないんでしたっけ?

・Android (Nexus7 2013でテスト)

これもePub対応リーダーは結構ありますが互換性は微妙でした。やはり商用リーダーアプリが優秀で、「紀伊國屋書店 Kinoppy for Android」と「ソニーの電子書籍 Reader™」で検証をしていました。ただ、サブセットフォント化したらKinoppyでの記号が崩れるようになってしまいました。また表紙画像がないePubはKinpppyでは真っ白な四角形になってしまうのもイケてないです。Readerは1ページ目のサムネイルを自動生成してくれます。ということで、今回の配布サイトではSONY Readerアプリを推奨することにしました。

なお、両者ともローカル保存したePubファイルを本棚に自動登録する機能があり、KinoppyではDownloadフォルダ、ReaderではReader->downloadsフォルダに保存した上で、アプリ内メニューから「追加コンテンツの検出」(Kinoppy)や「ファイルの取り込み」(Reader)すればOKです。

■Kindle用mobiに変換する

最後にKindle対応です。ePubを直接読むことはできないので、Amazon自身が配布しているKindleGenというツールを使って.mobi形式に変換します。ただし、残念なことに現状ではフォントの埋め込みは認識されないようです(Paperwhiteのみで検証)。先のCSSでかろうじて内蔵の角ゴシックにはなりましたが。シェアは大きいので一応対応したいところですが、やはり自炊用としてはKindleは微妙ですね。

どうせ埋め込んだフォントは使われず、貴重なKindle端末のストレージを無駄に占有するだけなので、ePub時点で埋め込みフォントを抜いたものを作ります。本当はCSSやopfも書き換えるべきなんですが、毎回作り分けるのは手間なので、内部エラー上等ってことにしてzipする時に除外するだけにしますw。区別のためにhoge_nofont.epubという名前にしておきます。

zip -0 -X ../hoge_nofont.epub mimetype
zip -r ../hoge_nofont.epub * -x mimetype *.ttf

KindleGenはコマンドラインツールですが、使い方は簡単でKindleGenとePubがあるフォルダで、

./kindlegen hoge_nofont.epub

などとするだけで、同じ場所にhoge_nofont.mobiが出来ると思います。警告が多少出ましたが、とりあえず問題なく読めるようなので良しとしましたw。

できたmobiを、USBでマウントしたKindleのDocumentsフォルダにコピーすればOKです。

 

まぁ、こうしてみると、「電子出版は紙代、インク代、輸送代がタダなんだから紙版より安くできないのはおかしい!」という読者視点の考えにやや無理があるのはわかりますねw。紙版からのコンバートは結構大変です。この上、挿絵などの画像データの扱いも含めて様々な環境での動作確認をしてなんてコストはバカにならないでしょう。今後、紙用の組み版もePubベースになる等して制作コストが一元化できるようになってくればまた違ってくるんでしょうけどねぇ。InDesignとかなら出力コマンド一発で出し分けられたりするのかしら?

iPad Air衝動買い

iPad mini Retinaを買う予定だったんですが、せっかくAir発売日だし実機触りに行くか、ってんでヤマダ電機いって、気付いたら買っていたぜ。

もともとNew iPad (以下iPad3)と初代iPad miniを使っていて、最近はminiばかり使うしRetinaになるなら新miniに一本化してもいいなぁ、と思ってたんです。「おやゆびでお」なんてアプリ作るくらいで、片手持ちで動画や電子書籍の閲覧が主なので軽さが大事。ただAir実機を触ったら「これくらいの重さならアリなんじゃないか?であるならば大きい方が動画も書籍もいいよね!」と。7インチ機としてはNexus7 2013があるしとか。

容量としては、WiFiがMIMO(デュアルバンド)に対応して速度あがるなら自炊動画もほぼストリーミングで済んで容量は一番安い16GBでいいんじゃね?的な。現にiPad miniは16GBで全然困ってなかったし。てことで、急遽Airでいいじゃん!って心変わり。朝イチで普通に在庫ありました。ちなみに夜にヨドバシ横浜に行った時点では16GBシルバーのみ残り三台、後は品切れ、次回入荷未定となってました。

あとAppleショップのこの展示什器、ワイヤーに常に引っ張りテンションがかかっているので、全然軽さが体感できないんですよね…

1390596_10202342302505790_1946714705_n

■ハード周り

基本、見た目は軽くなって薄くなって端子がLightningになった以外あんま変わりないです。色味もiPad3を見慣れた目で違和感なし。若干緑に違和感を感じるのも同じ。

レスポンスも一般的なアプリを使う分にはそんなに違いは感じないかな。ただキーボード周りのサクサク感は向上したように思います。iPad3だとややかったるかったのが、iPhone並に不満なく入力できるようになった気がします。

ついにスピーカーがステレオになったっぽいですが、あいかわらず縦持ち基準のレイアウトなので横にして動画を観る時には微妙。Kindle Fire HDみたいに再生品質にこだわるよりはデザインや薄さ優先ってのはAppleらしいです。

Lightning化は単純に嬉しい。開発用Macやベッド周りのケーブル環境が共通化できてスッキリします。これでDockコネクタは車載用のiPod nano 4thのみ。母艦機にだけケーブルをつないでおけばよくなりました。いっそnanoもLightningなモデルに買い換えたい衝動に駆られますが、先月iPhone5s買ったばかりだし、iPad mini2を買う可能性が完全に消え去ったわけではないので自重w。

■MIMO効果は微妙?

MIMOにより「おやゆびでお」でHD動画をHTTPストリーミング時の途切れが改善されるかなと期待したんですが、あまり変化は見られない気がします(http live streamingではなくmp4の直リン)。ちなみにアクセスポイントはAirMac Extremeの300Mbps世代機。二世代前のものですがiPad Air/mini2は300Mbpsの2×2 MIMOなので充分なはず。ここが一番残念。Webサーバー側の限界なのかなぁ。

■アクセサリ

基本家ではカバー(フタ)を取った状態で使いたいのでマグネット脱着できるものにしたいのと、背面に吸盤リングをつける関係でバックケースはハードでつるつるなものにしたい派。

朝行ったヤマダでは純正SmartCoverもSmartCaseも入荷しておらず、エレコムのクリアハードケースだけを購入。夜にヨドバシに行ってSmartCoverを買ってきました。今回のSmartCoverは素材がポリウレタンのみになり色がiPhone5cとあわせたような明るめの色ばかりで、どれも40のオッサンには使いづらく悩みました(さすがに黒本体に黒は面白くないし)。レッドがグリーンで悩んだ挙げ句、Product (RED)で募金になればいいやくらいの消極的理由でレッド。

が、早速とりつけようとして失敗に気付く。エレコムのケースがSmartCoverに対応してなかったorz。そういえばiPad3の時もminiの時も気をつけて買っていたはずなのに、すっかり失念してました。一応マグネットはつくものの、スタンド状態にすると外れてしまう(そりゃそうだ)。仕方ないのでTUNEWEARのものを注文。発売まで少し日数があるみたいで届くまで我慢ですわ。

液晶保護フィルムは保留中。基本家使いで持ってでかける時はSmartCover付けるので、普段は裸でもいいかと。最近のガラスは強度はあるし耐指紋性能も指滑りも不満ないレベルだし、と。

 

とまぁ、そんな感じでベッドに寝転がってしばらく動画を観てみたんですが、やはりminiに比べるとそりゃ重くて腕の負担は大きいですw。胸の上にスペアの枕を置いて、その上にiPad本体を置くようなスタイルなので全ての重量が腕にかかってるわけでもないんですが。画面サイズが変わって当然視距離も離れるので腕の保持姿勢が若干かわるのもあるかな?もう少し姿勢を煮詰めていきたい。

でmini2への欲求が完全に収まったかというと微妙w。現物をみた時にまた気絶しないとは言い切れない…。iPad3とiPad miniを処分すれば今回のAir購入費は捻出できそうなので、あとは使わなくなったSONY Tablet SとかWALKMANとかとかを処分すればそんなに無理な買い物じゃないかなぁとか…

Windows8.1 UI面ではここが良くなった!

iOSと違ってデベロッパー契約や法人契約もしてないし、Previewつっこむ程の興味もなかったので一般リリース日に初めて触った感じで、予備知識もあまり仕入れてなかったんですが、デスクトップ、ノート、タブレットの計4台に入れてみての感触。

とても良いと思います!

すごくこなれてきた感じで色々しっくり来てます。以下、ざっと要点や気に入った点をまとめます。「いやそれは8から出来たよ」ってのがあったらごめんなさい。

■スタートボタンは復活したのか?

スタートボタンの位置に確かにボタンは復活しましたが、動作はちょっと違います。Windows7以前のようなメニューランチャーが表示されるのではなく、あくまでWindows8で導入されたスタート画面に遷移するショートカットボタンです。チャームのスタートボタンやキーボードのWindowsボタンを押すのと同じ。ただチャームやWindowsボタンって気付けないとなかなか押せないところではあるので、気軽にスタート画面にいけるようになったのは歓迎すべきことでしょう。

また玄人好みの裏技としては、この新スタートボタンを右クリックすると、コンパネやコマンドプロンプト、シャットダウン/再起動系の項目にいけるようになってます。これはチャーム内のスタートボタンには無かったし、結構面倒だったので助かりますね。

■スタート画面の改善

・マウスポイントだけでスクロール

スタート画面は基本的に横スクロールをさせて使いますが、従来のホイールに加え、画面端へマウスカーソルをもっていくだけでもスクロールするようになりました。縦ホイールで横スクロールというのがいまひとつ直観的でなかったし気付かない人もいたと思うんですが、これでとても感覚的に使えるようになったと思います。

・全アプリ一覧に行きやすくなった

Windows7でいう「すべてのプログラム」に相当する一覧ですが、今まではチャームの「検索」から行ってたんですが、8.1ではスタート画面の”下”という位置づけになりました。タッチデバイスなら上下スワイプで行き来できますし、マウスの場合は画面の下に(↓)ボタンが出てクリック一発でいけます。また設定でスタートボタンを押した時にホームではなくこちらの画面に直接遷移させることも可能になりました。

ここでキー入力をすればリアルタイムで絞り込みされるので、目的のプログラムがサクっと探せます(ちなみにホーム画面でキー入力しても同じことができます)。

・起動直後の初期画面がスタート画面ではなくデスクトップにできるようになった

最初はどうしても鳴り物入りのスタート画面を見せたかったんでしょうが、実用面でいうとまだまだデスクトップ主体な使い方が多いので、これは地味に便利です。フリーウェアで実現できていたことですが標準でできるようになったことが大事。

・スタート画面の背景にデスクトップの壁紙を出せるようになった

これが意外と認知的に大事(だいじ&おおごと)な気がしています。今まではスタート画面の壁紙は独立していて(しかもイケてないデザインばかりで)、デスクトップアプリとタイルアプリの2つの世界を行き来して使う、という印象が強かったんですが、壁紙を同じになることで、「デスクトップの世界の上にオーバーラップしてスタート画面が出る」といイメージになります。上の設定と合わせることで、「従来のWindowsデスクトップありきで、スタートメニューがスタート画面に置き換わり、タイルアプリの世界がかぶさっている」という従来Windowsユーザにとってとっつきやすいメンタルモデルが描けるようになったと思います。以後、リテラシー低めの人の導入サポートをする機会があったら、この2つの設定はONにしておいてあげようと思ってます。

・その他

スタート画面上のデスクトップアプリのアイコンに、タイルアプリとよく似た座布団がつき、スタート画面上で2つの見分けがよりつきにくくなりました。これは両者の区分けをあまりさせないことにしようという狙いでしょうか。

またカラム毎にグループ名をつけられるようになってるみたいです。個人的にはあまり必要性を感じないのでまだ試してないです。

■「ヘルプと使い方」アプリ

8.1にアップグレードするとスタート画面の右の方に勝手に追加されます。むしろ何故今までなかったのかと。Windows8/8.1の基本操作をアニメーションも交えて解説してくれます。

ただ、タッチとマウスでそれぞれ操作が違うんですが、タッチデバイス非搭載のマシンでもデフォルトがタッチの説明になってるのがいただけない。マウス使ってるのにジェスチャー操作の説明見せられたらかえって混乱してしまうでしょう。それくらい自動認識して切り替えておいてくれよと。ちなみに画面左下の辺りに切換えスイッチがあります。

■チャームの改善

24インチ級のモニタでないと気付かないかも知れませんが、チャーム上の5つのボタンが垂直中央寄せから上寄せに変更になってます。これはマウスでチャームを表示する操作が「右上コーナーつつき」なので、そこから下がってボタンを選ぶまでの距離を縮めたということなんでしょう。これはとても良いです。

2013.11.2追記:

その後気付いたんですが、単に上寄せになったんじゃなく、右下コーナーでもチャームが出せるようになってて、その場合はちゃんと下寄せで表示されるんですね。

ただし今はまだ慣れないので今までの位置を思い描いてマウスが通り過ぎてしまうことも。スタートボタンが真ん中、ってのはそれはそれで狙いやすかったんですよね。これはスタートボタンの復活や検索方法の変更でチャーム自体の利用頻度が下がることを見越して初めてできた工夫なのかも知れません。

■その他、個人的に嬉しいところ

ロック画面の選択設定のところん「参照…」ボタンがついて好きな画像を指定できるようになりましたね。正直ロクなのがなかったのでこれは嬉しいです。

ドキュメントやピクチャといったユーザファイルを別ドライブに自動でバックアップする機能がついたようです。複数ドライブがついているマシンでも選択肢として出ない場合もあって、いまいち動作ルールが不明ですが、簡易バックアップとしては重宝しそう。

あとExplorerのコピー関係の警告ダイアログでしか確認できてませんが、例えば「上書きして良いか?」みたいなダイアログが通知としても表示されるようになったっぽいです。例えばたくさんのファイルのコピーをかけて、待ち時間にタイルアプリでニュースを見てたとします。従来だとデスクトップで「同名ファイルがあるので上書きしますか?」って聞かれても気付かず、時間をおいて戻って見たらほとんど進んでなかった、なんてことが起きえた訳ですが、通知として出るのであればタイルアプリにしていても気付きやすくなるという訳です。これExplorer側が通知出力に対応したんですかね?いっそデスクトップアプリがモーダルダイアログを表示したら全部通知してくれるみたいな仕組みなら嬉しいかも。

■ビミョーなところ

ローカルアカウントで使っていた場合、改めてMSアカウントの紐付けを強要されます。(ネットワークをOFFってれば良いという話も聞きますが)基本的にスキップができず、意地でもMSアカウントでログオンするのを基本にしたいようです。それにともなってアップグレードのウィザードがかなり煩雑になっていて、初心者の人にはかなり難しい手順になっています。従来のService Pack扱いだとすると勝手にインストールされるのかはわかりませんが、ある日いきなりこのウィザードになったらフリーズしてしまう人が続出でしょう。

 

逆に言うとネガはそのアップグレードのところだけな気がします。全体として、新機能であるタイルの世界推しが行き過ぎていた感が収まり、「まだまだデスクトップの世界がメインだよね」っていう現実を受け入れた実用性重視のチューニングがなされたなという印象を受けます。Windows8はもともと軽さや堅牢性などではとても優れたOSなので、今回のUIチューニングで食わず嫌いだった人も警戒心を解いて触ってみてもらえるといいなと思います。

5年ぶりに(メイン機の)グラボ交換

仕事&エンコ用のメインWindows機のグラボをGeForce GTX260から実に5年ぶりリプレース。CPUやマザーは途中でSandy Bridgeに移行したのに、グラボはそのまま使い続けていました。前エントリで日常エンコにもTMPGEnc Video Mastering Works 5を活用する機会が増えそうなので、これを機に改めて1)CUDAを活用して凝ったフィルタも使ってみようかなぁとか。あと、最近同機が不調で画面が固まったりする(マウスとか時計もフリーズしてるので切り分け不能だけど、ディスクアクセスなんかはそのまま動いてるっぽかったり)のも2)治るといいなという期待、そして5年の進歩で3)消費電力や発熱もさぞ低減されているだろうという期待で。

CUDAなのでGeForce一択。700系が最新ですが、コスパ狙って1世代前の600系で、なおかつ消費電力が64Wと低い650無印でいいや、ってのは割と一瞬で決まりました。その上のGTX650 Tiだといっきに110Wとかいっちゃって動機3)が弱くなるなと。実のところGTX260もCUDAに期待して投資(当時3万位したような)したものの、結局つかいどころがないままだったので、動機1)はまぁ期待半分だったんですよね。

で、GTX650をAmazonでググったところ、DVIが2ポートついてて小型でしかも補助電源いらずってのがあったので、またまた玄人志向のお世話になることにしました。

1385837_10202184370917599_1674972461_n

■とりあえず不調が1つ治った

もう随分前、Windows7の頃からなんですが、コールドブート後にログオン画面になってすぐにログオンすると画面が真っ黒のままになる現象が出ていました。デスクトップアイコンも出ず。マウスカーソルだけは反応するんだけど、結局Ctrl+Alt+Delして一旦ログオフしてから再度ログオンするとOKみたいな。あるいはログオン画面でしばらく我慢してサービス関係がひとしきり起動し終えた頃にログオンする、みたいなおまじない的な使い方をしてました。それが、グラボ交換でサクっと直り、実質のコールドブート時間が大幅に短縮。これだけでもう買って良かったと感激しきりw。

■エクスペリエンスインデックスは微妙

まず構成ですが、CPUがi7/2600K定格。マザーはPCIex Gen3に対応してるんですが、CPUが初期Sandy BridgeなのでGen2までしか使えず、Gen3対応のGTX650の実力が出し切れていない可能性があることをお断りしておきます。

Windows8エクスペリエンスインデックスは7.1->7.2の微妙な差に。実は最初に測った時GTX260は6台だったんですが、ドライバを最新版に更新したらあっさり7.1に向上。そのあとで交換したらあまり変わりないことに。5年前のモデルとはいえ当時そこそこお高かっただけはあるんですかね。

GTX260

・交換前GeForce GTX260

GTX650

・交換後 GeForce GTX650

ちなみにこちらのCUDAの「Compute Capability」という指標をみると、GTX260は1.3、GTX650無印は3.0となっています。よくわからない指標ですが、APIのバージョン的なものではなく、9800GTを1.0とした比率だとしたら倍以上高速なはず。そして現時点で最高が3.5なのでなかなかのはず!

■TVMW5での効果

前提としてエンコード自体にCUDAを使う気はありません。エンコはあくまでx264。フィルター処理が軽くなればいいなと思っています(さすがにCUDAのエンコード画質はまだ保存には耐えないレベルだろうと)。でもまぁものは試しにとCUDAでエンコードさせてみると、同じフィルタ条件下(24fps化動き優先+逆プルダウン(縦縞除去)+リサイズ)で1分ソースが58秒が41秒と短縮されますね。

フィルタでは、通常の「ノイズ除去」程度では全く使ってくれずCPU100%。より演算負荷の高い「高精度ノイズ除去」でようやく20%ほどがCUDAの分担になるようです。処理時間は2分36秒と実時間の2.5倍ほどになるので、あんま普段には使わないかなぁ。ただCPUだけでやったら3分13秒なので効果は出てますね。30秒程度の差ですが、24分のコンテンツなら12分も変わってきます。

更に「スマートシャープ」上乗せどんっ。CUDA使用率は45%に。エンコ時間は2分52秒(CUDA OFFだと3分41秒)。ただまぁスマートシャープかけるなら、aviutl側でWarpSharpプラグイン使った方が仕上がりが好みなので、これもあんまり使う機会ないかな(^^;)。

 

てことで、重ためのフィルタをかけると効果は確実に出るけど、普段使いのレシピだとあまり出番がないかなという印象。CPUをIvy Bridge世代にものにすると、PCIex Gen3が開放されて速くなるかも?という期待がありますが、その分CPUも速くなるからCUDA使用率はどうなんだろとも。いずれにせよ今月はiPadも出るししばらくは手が出ないかな。

TVMW5でロゴ消し

今までMediaCoderをベースにしていたアニメエンコレシピを久しぶりに刷新しました。MediaCoderは様々なフリーツールを裏で呼び出して使うフロントエンドGUIツールで、今まではAviSynthでデインタレと局ロゴ消しをして、x264でmp4にエンコードするというレシピにしていました。MediaCoderは各種パラメーターがGUIで指定できて便利は便利なんですが、いまいち不安定な箇所もあります。最新版が良いとも限らないので迂闊にアップデートもできず、既に治ってるバグもあるかも知れないですが、ウチでは少なくとも、

・カンパしたのに定期的にIDを聞かれるダイアログがでてエンコが中断される

・カンパしたのにブラウザで広告ページが表示されたりしてウザい

・環境設定にFireFoxを使うのだけど、ついにFF最新版ではエラーが出るようになった(MediaCoderも最新版にすればいいんだろうけど、上記理由で勇気が要る)

など。そして、AviSynth(aviutl)によるデインタレ処理のスクリプトが難しく、色々ググってはマネしてみたんですが、単一のスクリプトで汎用性のあるものに仕上げられないでいました。

一方、デインタレでいえばTMPGEnc Video Mastering Works 5(以下TVMW5)で24fps化した方がずっと簡単で安定することはわかってたんですが、こっちは透過合成フィルタがなくロゴ消しができないので、仕方なく上述のMediaCoder環境を使っていた、という感じです(ここ2,3年位)。

それでもiPhoneやiPad、車載モニタで見る分には正直あまり気になってはいなかったんですが、最近は友達と遠隔同期視聴をしたりするので、PCモニタやプロジェクターで再生してやっぱガタガタだなぁ、と思う機会も増えてきたり。もともとチルト(縦スクロール)するカット(確かストパン2のED)がガタガタするのが気になってAvySynthを導入したんですが、気付いてみると最近はパン(横スクロール)がガタガタなのに凹む日々。

連休を使ってレシピの再検討を行いました。以上、毎度長い前振り。

■TVMW5でも局ロゴ消せる!?

なんでもっと早くググらなかったんでしょう。結論からいうとできました。正確にはaviutlで「透過性ロゴ」フィルタをかけただけの編集プロジェクトファイル(.aup)を作り、それをTVMW5にVFAPI経由で読み込ませます。aupファイル用のVFAPIプラグインはaviutlに添付されているので、TVMW5のフォルダに放り込んでやれば認識するので、環境設定画面で有効化してやればOKです。

以下、当面の手順メモです。個々のソフトの細かい操作方法などは割愛します。

・TMPGEnc MPEG Smart Renderer 4でCMカットする

tsを直接aviutlに食わせてたaupをTVMR5に食わせてからカット作業してもいいんですが、最近のTMSR4はCM検出機能とかついて便利なのと、aviutlに生tsを食わせるとGOP検出とかで読み込みに数十秒待たされるので、CMカットは従来通りTMSR4を使うことにしました。HDD容量的には中間のMPEGファイル作らなくて済ませられるのも魅力なんですが作業性優先で。ここで生成されるファイルは、CMカット済みMPEG2ファイル、以下(A)と、(チャプター付きmp4を作りたい場合は).keyframeファイル(B)です((B)は環境設定で自動的に出力されるようにできます)。ちなみに我が家ではここまでは録画機で行います。

・aviutlでロゴを指定して.aupファイルを生成

aviutlに(A)を読み込ませ、チャンネルにあったロゴをセットします。aviutlは最後に使ったロゴを自動的に適用してくれるので、同じチャンネルの番組を連続で読み込ませると作業性が上がりますね。aupファイル(C)は単なるプロジェクトファイルなのでサイズは小さいし一瞬で保存されます。

aviutlのコマンドラインツールとかで上手いことマクロ化すれば、(例えばチャンネル名をファイル名末尾に足しておいて)このaupファイル出力までを自動化できるのかも知れませんが、まだよくわかってないです。aviutlって局ロゴ透過ファイルを作るのくらいしか使ったことないので…

・TVMW5に(C)を読ませる

VFAPIフィルタが正しく設定されていれば、普通にプロジェクトにドラッグとかで一括投入できます。ただしaviutl側でAC3音声を認識できてないせいか、TVMW5側でも音声トラック無しとして読み込まれます。そこで音声トラックとして手動で(A)を再指定します。(A)は映像と音声が両方入ったファイルですが問題なく音声トラックだけが利用されます。またkeyframeファイル(B)はここでは使いません。TVMW5にはキーフレームをiOSのチャプターとして出力するというチェックボックスがありますが、ウチでは機能してないっぽいので(コンテナ拡張子を.m4vとかにしたらいいのかも?)。また、keyframeファイルを読み込ませると、プラグインがクラッシュするっぽいです。エラーダイアログを無視して進めればいいだけなのでサムネイル生成に失敗してるのかな?まぁ鬱陶しいのには変わりありません。

・TVMW5でエンコする

TVMW5もH.264なmp4はx264を使うので、MediaCoderの時と同じです。もともとパラメーターを似せた出力テンプレートを作ってあったのでこれを指定。またフィルタも24fps化(動き優先)や軽くノイズ除去を適用したテンプレート作っておいて一括適用。この辺り、なるべく数をまとめてエンコした方が効率は良いです。

 

単に再生できりゃいいという方ならここまで。以下はチャプターやメタタグ、アートワークなどを一括処理する為の追加レシピです。

・keyframeファイル(B)からiOS用チャプターファイルを生成

自作のdgKeyframe2Chapterというツールを使い、.chapters.txt形式のファイル(D)を作ります。

・各種付随ファイルを統合して、高機能mp4ファイルを生成

iOSやMPCHCでチャプターを認識し、iTunes上で「TV番組」として認識して番組名やエピソード番号、サブタイトルなどが正しく表示され、更にはアートワークまで表示されるmp4ファイルにします。

AtomicParsleyというコマンドラインツールを使えば良いのですが、バッチ処理のためのGUIフロントエンドツールdgMP4Taggerを公開しています。

  • .mp4ファイル
  • .chapter.txtファイル(チャプター情報)
  • .jpgファイル(アートワーク用)

の3つを合成して新しいmp4ファイルを作ります。詳しくはリンク先や同梱のマニュアルをご覧下さい。

 

とまぁ、電子書籍レシピ同様、相当な物好きじゃなけれ
ばマネできない手順ですが、とりあえず自分の記録のために書き留めておきます。新旧レシピの比較としては、

  • パンニングなどのカットが滑らかに動くようになった
  • 動画解像度(?)も上がった気がする
  • サイズが20%程度縮まった!
  • エンコ時間が若干伸びた?(たぶんノイズ除去フィルタの分)

という変化が。今までインタレ解除がヘッタクソだったせいで、何フレームか毎に写真のような混合フレームができちゃっていました。再生ソフトでポーズかけまくってるとこういうフレームに遭遇します。当然圧縮には不利でしょうし、なによりこうした物理的にブレたフレームが混じることで見た目も悪くなります。新レシピだとスペースキー連打しまくってあちこちでポーズしてもこうしたフレームが見当たりません。

mixedframe

実際にはインタレ解除ってもっと奥が深くて、こだわってる人は番組毎、下手するとエピソード毎に最適なデインタレレシピを適用しているようですが、σ(^^)はさすがにそこまでの手間はかけたくありません。なので、TVMR5のそこそこのインテリジェントさにおまかせできるのがこのレシピの最大のメリットですね。また、ソフトとして安定度が上なのも大きいです。複数本のバッチ処理をかけて安心して寝ることができます。もっと早くググってレシピを見直すべきだったと反省しきり。

さて、これで何年戦えるんでしょうね。最近はBDレコーダーやnasneなどでもH.264のハードエンコができるようになったし、iOS端末から直接、しかも外出先からも視聴できるような環境が整ってきています。そろそろソフトエンコの時代でもないだろ、という気も。ただやはりそうしたハードエンコは画質的にはまだ微妙でブロックノイズ等が気になることが多いし、やはりOPスキップなどがフリックでできる拙作「おやゆびでお」+自作ライブラリサーバーの方が快適なんだよなぁ(ステマ)。