５分で学ぶ！ 初心者向け動画編集フリーウェア
前の会社の後輩が「ちょっと真剣に動画作ってみようと思ってるんですけど、正直何からどうすれば良いかわかんないんです」とメールしてきたのをきっかけに、主に国産であるもの、または海外発祥だが国内においてもドキュメントの充実しているものをピックアップして、各フリーウェアごとのあらましを書いておくことした。なので、もう動画作ってるもん、と言う方はもうとっくに存じ上げている話である。まさにチラ裏。
■ AviUtl + exedit
元々AviUtlはわりと昔から動画編集ツールとしてその名を知られていたが、そもそもAviUtlは「一本のAVIファイルを編集加工する」ことを目的として作られたツールであったため、タイムラインと言う概念が存在しなかった。編集対象となるAVIが全てだったのである。
これはAviSynthにも同じ事が言えるため、相互乗り入れをするようなプラグインが双方に存在する。ゆえにAviUtlは「気軽にAviSynthを使う」ためのフロントエンドとしての機能も有していたと言うことができる。なにせAviSynthはフロントエンドと言う概念が異常なほどに乏しいことも有り、またAviUtlそのものが国産のフリーウェアであることも手伝い、国内では「フリーの動画編集と言えばAviUtl」と言うのは比較的共通言語化していたことも事実である。
だが、AviUtlはある一点より確実に「進化」を遂げた。「拡張編集プラグイン」と言う新たな動画編集概念を引っ提げて、強烈なパワーアップを計ったのである。
現状の拡張編集プラグイン（以下、プラグインのファイル名を取ってexeditと呼ぶ）は最大で100枚のレイヤーを保持し、また画像平面を3D空間に配置することを可能としている。3D空間がある以上「カメラ」の概念が存在し、またライトレイヤーも実装されているなど、ほぼ一通りのことはもう、exeditで実現できてしまう。
その上、動作の安定性は本線で動画ファイルを扱っているエンジンはこれまでも非常に堅牢に作られており、非常に安定していることも知られている。各レイヤに設置した動画に対して、個別にエフェクトを掛けることもでき、任意のレイヤをグループ化して同時にカメラ１個で視点変更を可能にすることも難しくない。
その上、これまでAviUtl用として制作されたフィルタプラグインも適用可能である。ただ、exeditでは設定できないフィルタも有るが、そのようなフィルタは本体側から掛けてやれば良い。その程度の仕様制限は有るものの、まず「動画編集」と言う側面を練習したい、学びたいとする向きには打って付けの環境である。そして、単に初心者向けには留まらない、幅広い応用を持っていることも、AviUtl+exeditの特徴であろう。
だが、一つ勘違いしてはいけないことがある。
それは、exeditはあくまで「プラグイン」である、と言うことだ。
まずレイヤが最大100枚と言うのは、完全に仕様制限である。もっとも、100枚のレイヤが同時にタイムライン上に走る、と言うのはあまり好ましい編集の仕方ではないとしても、一応そういう制約は存在すると言う点には注意が必要である。
それと、レイヤに掛けるエフェクトは、実はexeditと言うプラグインが全てバイナリコードとして内包する形で実装されている。これは、exeditがプラグインと言う実装形態を取っている以上、致し方ない問題であった。それでも、現状存在するエフェクトは充分な数が揃っており、これ以上のものを望むのであれば自力でプラグインを書くか、Luaスクリプトによる拡張をユーザが自ら行える仕組みを導入しているので、その気になれば既存エフェクトの重ね掛けや、新しいエフェクトの導入なども可能にはなる。但しLuaプログラムを書く必要があると言う点には、特にプログラミングに習熟していないユーザには注意が必要である。プラグインはもっと大変（C++とWin32についての知識が要る）なので、当初はあまり考えなくても良いだろう。
ただ、Luaスクリプトを書くことによって得られるのは、飛躍的な表現の広がりと言うよりもどちらかと言うと「いちいちぽちぽち中間点を打って、その度にちまちまと設定ダイアログから設定を繰り返す」と言う手間の削減の意味合いが強いように思う。ただ、プリセットスクリプト（exedit.scnにある）だけでもかなり表現の幅は広がるだろう。特にscenechangeスクリプトを活用することで、様々なトランジション表現を可能にしていることは、やはり特筆に値する。
ではここからは「難癖」の世界であることを、予めご承知おき頂きたいと思う。
3D描画は実装されているが、現状奥行き関係などを考えると「精度的に弱い」。これは作者様ご自身もおっしゃっていることだが、ポリゴン精度は決して高くないため、オリジナルステージの構築などと言う問題になると途端に話が変わってくる。さらに、描画にDirectXを使っている関係上、テクスチャの質感として「べたっとした画面」になってしまう。AviUtlかAE/NiVE2/Javieかを区別する時、前者と後者群の大きな違いは、この3Dレンダリングエンジンに何が用いられているか、と言う問題がある。
DirectXはそもそもゲーム用に開発されたライブラリ群であり、非常に低レベルな――コンピュータに明るくない方は誤解されるかも知れないが、コンピュータプログラミングにおける「低レベル」とは「よりハードウェアに近い」と言う意味である――難しい処理を包括するためのライブラリである。もっとも、包括されたところであんだけ引数まみれのメソッドを要求する時点で「ちっとも高レベルじゃない！」と言うところはあるが。
まぁ、兎にも角にも、exeditが使っている3Dライブラリはほぼ確実にDirectXだ。そして、元々読み込んでいる動画・画像の質感がベタッとしていると、ほぼその通り再現するため、何となく違和感を覚えるのである。
もっともこれがOpenGLになると話が変わるのか、と言うと話は別だ。おそらくOpenGLでレンダリングしたってテクスチャがベタッとしていれば必然的にベタッとする。そういったことも考慮に入れ、画面の「質感」を考慮する際には、この3Dレンダラの違いと言う部分を頭の片隅に入れておくことが肝要である。
もう一つ、これは結構面倒だ。これはAviUtlの仕様なのかも知れないが、再生速度を早める指定を実現しようとすると、当然幾らかのフレームは間引かれることになるが、間引いた分の描画フレームは「どっかに行っちゃったまま」になる。
NiVE2やJavieと言ったAEを意識して作られている動画加工ツールは、こうした再生速度の変更――専門用語で「デュレーション」と言う。今後はそう呼ぶ――に対応するためにフレームブレンドを行う、あるいはモーションブラーを掛けると言った「間引かれたフレームの補完」と言う作用を与えることが出来るのだが、AviUtlは本体にその機能を内包していない。
ではAviUtlはフレームブレンドやモーションブラーが出来ないのか？ と言うと、そういうことではない。まずモーションブラーはexeditがデフォルトで持っている。フレームブレンドはエフェクトとしては存在しないが、先ほど申し上げたとおりLuaスクリプトによって充分表現可能だ。ただし、手元で試している範囲では壮絶に重いのも現実である。Luaがスクリプト言語であると言う壁がそこに立ち塞がっている、と言う言い方も出来ようか。もっとも、アルゴリズム次第でもっと軽く作れるのだろうが、フレーム補完が必要な場面になったら別のツールを使っているので、ここでは触れない。ごめん。
一応「フレーム補完」について触れておく必要はあるだろうか。
「フレーム補完」と言う処理は前述した通り、デュレーションの変更により欠損した描画フレームを何らかの手段によって補完し、間引かれたフレームの前後の描画をより滑らかな動きにするための手段である。
例えば、元々の素材として60fps.でキャプチャした動画を30fps.に落としたい、と考える。なぜなら、60fps.の描画を要求するよりも、30fps.のほうが処理が軽いからだ。ではそれを「えいやっ」と間引くとどうなるか。これは、実際に動画を作って見てもらったほうが分かりやすいかも知れない。
特に動きの激しい場面に於いて、明らかに30fps.側は「カクカクしている」。つまり、動きが不自然に見える。これは視聴する側にとってあまり気持ちの良いものではない。だからその「気持ちの良くない」動きを気持ち良く見せるために、フレーム補間と言う処理を挟んでやる必要が存在するのである。
と、言った「難癖」は有るものの、正直ステージPVを作るならAviUtl+exeditと言う選択肢は今のところ最も手軽で最も器用で、最も高性能であると言える。余程重いフィルタを掛けたりしない限りはプレビューもかなり頑張って追従するし、そもそも本体が軽く出来ているため、ハードをそれほど選ばないと言う特質もある。そもそもフッテージさえ自由に設定できないPremire Elementsを使うことを考えたら、圧倒的にパフォーマンスに優れている。
■ NiVE(Nico Visual Effects)
NiVEは現在既に開発は２系列が主体で、従前の１系列はバグフィックスに関するメンテナンスのみ行われている。そのため、本項ではNiVE2について触れていくこととしたい。
NiVE2のコンセプトは、いわゆるAfter Effectsに代表されるようなモーショングラフィックスエディタとしての機能を目指している。もっともAEのオルタナティブを目指しているわけではなく、あくまでNiVEはNiVEであると言うスタンスだが、インタフェースは２系列になってかなり洗練された。もっとも、１系列との後方互換性を全く捨てたこともあり現在でもプラグインが豊富に公開されている１系列を使用しているユーザも多いのかも知れないが。
と言うわけで、NiVEのコンセプトは「動画編集」ではない。編集された動画への「加工」を主目的としている。さらに言えば、動画素材のない状態から動画を作る、マテリアライザとしての役割も強い。もっとも、AEがほぼ単独で動画編集も出来るように、NiVEもまた動画編集が出来ないわけではない。ただ、単純に動画編集を行うのであれば、別のツールで予め組み上げて、中間出力に対してフィニッシングを行う、と言うつもりで考えておくべきであろう。NiVEも、後述するJavieも、そういう傾向のツールである。
さて。NiVEもまた国産であり、Windows環境で動くことも手伝ってユーザはそれなりにいるが、間口こそ広いものの敷居はかなり高い。まず初心者にとっては「何をどうすれば何ができるのか」も見当がつかないだろう。ただ、マニュアルもちゃんと付いているし、細かい点については有志解説サイトも存在する。NiVEは発祥が「２ちゃんねる」であることもあり、比較的ユーザは多いはずであるが、まだまだこれからさらに発展の余地があるソフトウェアであることは間違いない。
もっとも「加工」に特化したソフトである以上、一からすべてNiVEで、と言うのはどちらかと言うと作業効率は悪い。素材は揃った、あとはこのシーンなりこのカットなりの分を並べればOK、と言う状態に来て初めて威力を発揮するのが、こうした加工ツールの類なのである。
AEを意識している部分が大きいので、当然3Dレイヤも有る。ライトレイヤも有る。ガベージマットだトラックマットだと言う、加工処理に欠かせない機能はざっとプリセットにて揃っている。ただ、初心者には「これは何をするときに使うものなの？」と言う部分が大きすぎるため、直観的に操作して何か出来ると言う類のソフトではない。これは別に、NiVEが悪いのではなく、モーショングラフィックスツールと言うものは「得てしてそういうもの」なのである。なので、複数コンポジションだヌルオブジェクトだなんだかんだと言う機能のメリットは、非常に伝えづらい。
またNiVEの特徴は、AEを意識して作られているのであろうエクスプレッションと言う、キーフレームによらないプロパティ操作が可能であること、デフォルトで導入されているエフェクトが豊富であることなどが有る。さすがにプラグインを自作するとなるとかなりハードルは高まるかも知れないが、だいたいのことはプリセットで賄える。
さらにNiVEの大きな特徴としては、レンダラがプラグインとして設計されていると言う点がある。これによって、フィニッシュを出力する際にのみ、レンダラプラグインの内部で特殊操作を行うことも「可能っちゃ可能」である。この辺りまでくるとだいぶ敷居の高い話なのだが、それでもその拡張性の豊かさ、良い意味での奔放さはNiVE独自のものであろうと思われる。もっとも、NiVEはオープンソースではなく、無料だがあくまでプロプライエタリ・ソフトウェアであるため、あくまでユーザの範囲で拡張を行える、と言う要素を幅広く取っていると言うことであるが、それが逆にどれだけ便利であるかは、ある程度習熟してくると有難味が非常に分かる。そんなツールである。
難癖としては、とにかく「学習曲線が最初から急」であること、「まだ不安定である」と言うことだろうか。不安定と言っても、あまり無茶をさせなければちゃんと動く。オブジェクトがコンポジション中に200や300普通に並ぶこともザラだが、それでもスコーンと落ちたり、だんまりこくったりしないところは、だいぶこなれてきた印象がある。あと、32bitOS専用プラグインが多いのも、現状で64bitOSを使用している人間には少し切ないものがある。せめてソースだけでも公開されていればなぁ、と思うことは有るのだが。
とは言え、Windows環境下に限定して考えればだが、NiVEは非常にハイパフォーマンスである。各種エフェクトのもたらす効果、マテリアルとトランスフォーム、アンカーポイントの意味など、学習すべきことが多々あるが、それだけの成果を得られることは保証できるだろう。
■ Javie
物凄くざっくりした言い方をするとJavaで作られたNiVEである。
ただ、Javaで作られていると言うことは畢竟マルチプラットフォームでもある。
AviUtlもNiVEも、結局Windowsに依拠している。AviUtlは主にWin32APIやDirectXに、NiVEは.net FrameworkやGDI+（標準レンダラにおいて）に依拠している。が、JavieはJavaVMが動作する環境なら、基本マルチプラットフォームである。ゆえにMacでもLinuxでも動くのである。「なんでそんなことが！？」と思うかも知れないが、それはDirectXでもGDI+でもない、業界標準のグラフィックスライブラリ、OpenGLに依拠しているからだ。
OpenGLはいわゆる緻密な精度のグラフィック描画を要求される、コンピュータグラフィックのプロユースの現場における標準であり、DirectXはあくまでゲーム用のライブラリである。従って、精度はOpenGLのほうが高いのだが、民生品レベルで購入するようなVGAは、まったくOpenGLに対応していないわけではないが、だいたいはDirectXがより高速に動くようにGPUが最適化されている。nVIDIAであればGeForceシリーズなんてのは、だいたいDirectXへの強化がされている。だが、同じnVIDIA製品でもプロユースであるQuadroシリーズはOpenGLに対する最適化が施され、さらにラックマウントユニットとして分散レンダリングを行うインテグレート・システムも販売されている。細かな精度と品質、そして同時に速度を求められる高ポリゴン・高密度テクスチャを要求するような現場のために、OpenGLが存在していると言っても過言ではない。
そんなわけで、OpenGLに対応するVGAとJavaのランタイム環境が有れば、NiVEっぽいモーショングラフィックスツールが動作する。これが、Javieの真骨頂である。もともとJavieを開発されたらくさんPが「MacでもNiVEみたいなのが欲しい」と言う自らの要求を元に制作されていることを考えれば、マルチプラットフォームであることは全く不自然ではない。そればかりか、Javieはオープンソースである。
らくさんPは元々、数多くの動画制作関連ツールを手掛けていて、アイマス動画に付き物であるいわゆる「抜き」を一発で行うツールの制作などでも名高く、特にアイドルマスター２の発売後に作られた「nukim@s3」は非常に重宝する。ただ、驚くなかれ。
「nukim@s3」は、Javieのプラグインとしても動く。
先ほどNiVEに付いて触れた際に、カスタムプロパティやエクスプレッション、さらにはプラグインと言った各種拡張方針の多彩さに付いて触れたが、Javieにもそういう側面がある。と言うより、そもそもJavieがオープンソースであることを考慮すれば何も不思議はない。プラグイン、と言う拡張要素が如何に強力なものかわかるだろう。
さらに、後述するMMDのカメラ軌道データをJavieと相互乗り入れで使うことができる。MMDはAEと連繋するためのツールが、主にMMD側の要請として作られたが、JavieはMMD側の受け口としても機能するのである。もしかしたら今はNiVEでも出来るのかも知れないが、比較的初期にJavieでサポートされてしまったため、もうそれで良いやと言う気分になってしまった。そのくらい、先取的な機能を意欲的に取り込んでいる。
ただ、最大の難点は、マニュアルらしいものが全くないことだ。
現状最新が0.5.11と言うこともあり、メジャーバージョンが１になる、つまり正式版になるまでは公式にマニュアルを作る予定がないのかも知れないが、このことは全くの初心者がJavieを利用する上で物凄い障壁になる。もっとも、画面構成や機能そのものは、非常にNiVEに似ているので、先にNiVEを触ってインタフェース的な部分を習得した上で、と言うコースをお勧めする。
そして、日曜プログラマを含めた、現役プログラマ諸君。Javieは何よりオープンソースだ。Ecripseをさっさとインストールして、矯めつ眇めつソースを追い掛け、どこで何をしているのか、インタフェースは何なのか、そういった解析をしながら自力でソースを追い掛け、画像処理と言うテクニカルな課題に対峙しながら、自分なりのプラグインを構築する、或いは画像処理部分だけ抜き出してバッチ処理的に加工をぶん投げるツールを作るなど、あらゆる可能性がJavieのソースの中には詰まっている。
そういう可能性は確かにあるが、本線としての「動画をどうこうする」と言う部分に対するフォローはまだ完全であるとは言えない。そう言った意味でも、Javieはまだまだ敷居の高いソフトウェアであると言えよう。
■ MMD/MME
MMDとMMEは本来別のものであるが、関連するもの、さらに言えば今や動画制作においては必需品となった感のあるMMEをバラで説明するのもホネであることを考え、一括りにさせていただいている。
まず、本線であるMMDだ。もう名前もやることも広く知られているだろう。ボーン付きモデルに時間軸からモーションを与え、自在に画面の中でモデルを動かすことができる、まさに夢のようなツールである。基本的な機能解説は書籍でも売られているし、ネット上でも多くの解説記事を目にすることができる。そう言った意味では、これまで述べたツールよりも学習曲線はなだらかである。
具体的にモーションをどう付ければ良いか、などは既に公開されているモーションを借用して、実際にタイムライン上でどう設定されているのかをつぶさに観察することで、雰囲気を掴むことはできる。また、既に動画媒体として存在するものが有るのなら、それらをトレースすることで新たなモーションを作ることも可能だろう。ただ、作業そのものは比較的単純だが、そのぶん手間は膨大である。だからこそ、秀逸なモーションは珍重されるわけだが、一からモーションを起こして、一通りの動きをさせると言うのは非常に大変な作業である。
なんとなれば、踊る対象は主にヒトをモデルとしたボーン構成をしているわけで、各種関節の動きを意識して、かつナチュラルに、重心を意識したモーション作りができなければ、どこまで行っても出来るのは「借り物の動き」でしかない。借り物を元に編集するにしても、編集した途端におかしな動きをする、などと言うことは枚挙に暇がないほどである。それだけMMDにおけるモーションと言う問題は、単純でありながら複雑怪奇にして膨大な作業量を要求する。無論、それを乗り越えて完成した暁には、非常に幸福な結末が待っているであろうが、そこまで辿り着く前に倒れ伏した者たちの数を考えれば、どれだけそれが決死の作業であるかは想像に難くない。
ただ、ツールとしての「お手軽さ」は非常に素晴らしい。取りも直さず3Dレンダラとしての側面も併せ持っているわけで、例えばステージだけMMD上にオブジェクトとして組んで、カメラを動かした状態を記録することで、まずステージを背景として取得でき、さらにカメラ軌道はAEやJavieに取り込むことができる。Javie側では抜いた動画を同一平面として一度配置し、MMDのカメラ画像・カメラ軌道と合成しながら位置合わせをすると言うまぁそっちもそっちで手間は手間だが、と言う処理が可能である。
もっとも最後に問題になるのは「モデル」なのであるが、これはもうどうしようもない。メタセコイアなどのモデリングツールを使って、現在有るモデルをカスタマイズしていくほうが現実的であろう。ただ、それもやっぱり膨大な手間暇を掛けてようやく辿り着けるのである。公開されているモデルにいちゃもんを付ける前に、自分でそういう作業をしてみれば、彼らがどれだけ苦労してモデルに辿り着いたかが実感できるはずだ。
次、MME。こちらはいわゆるシェーダをカスタマイズすることで（MMDはDirectXベースであることを今思い出した）レンダリングに効果を与える、いわばプラグイン的なものであると考えておいて良い。ただ、シェーダプログラミングができることが大前提だ。正直なところ、今まで述べてきたあらゆるプログラミング要素の中で、もっとも敷居の高いのは、MMEのシェーダである。これを自作するのは「いい勉強」にはなるかも知れないが、さっさと結果が欲しい人間には耐え難い苦痛である。
そんなわけで、多数公開されているMMEスクリプトから、適宜抜粋して使ってみて「ああ、これなんかいい感じじゃん？」と思えるものを探す、と言うのが初心者ベースでは正しい在り方である。勢いシェーダプログラミングに足を突っ込むくらいなら、そのほうが正しい。もちろん足を突っ込んでも良いのだが、例えば草野球に誘われたら、スポーツ用品店で金属バット買って素振りを始めるか、もっと地味に下半身強化のために走り込みをするかの違いである。どちらかと言えば、金属バット買ったほうが「何となくそれっぽい」ことをしている気になるであろう。つまりは、そういうことだ。
総じて言うと、MMD/MMEは根本的に3Dグラフィックを理解していないとかなり厳しい。これはMMD/MMEに限らず、例えばモデラーとしてのメタセコイアやBlenderにも同様のことが言える。また、理解はしても手数が減らない類の作業になることも多く、当然覚えることも多い。メタセコイアはともかくBlenderのインタフェースの複雑さはもはや戦慄を覚えるレベルである。
■ AviSynth
まず最初に、AviSynthそのものは動画編集ツールではない。AVSと呼ばれるスクリプト言語を解釈し、その処理を実行するためのフレームワークサーバであるに過ぎない。
もっとも、その解釈対象となる言語であるAVSの持っている機能の多くは、AviSynth自身が内包する機能ではあるが、それ以外にも膨大な量の「フィルタ」（AviSynthにおける処理の基準）が公開されており、やろうと思えばかなり多彩な処理は可能だ。
だが、最大の問題はAVSが書けないと何も出来ないことだ。
AviSynth自体はフロントエンドを持たない。そのため、フロントエンドとなるアプリケーションが別途必要になる。その最右翼は、国内におけるチュートリアルの先駆けとなったサイトにて紹介されたVirtualDubMod（VirtualDubの修正版）なのだが、これとて決して使い勝手の良いフロントエンド足り得ることはない。また、AviUtlの入力プラグインとしてAviSynthのAVSファイルを扱うことはできるが、結局AVSファイルと言うプログラムを書くと言う作業からは逃れ得ない、と言う問題を抱えている。
じゃあプログラミングとかに抵抗のない人なら大丈夫だよね、と思うかも知れないが、残念ながらそんなことはない。首尾一貫したプログラム言語に習熟していればしているほど、AVSの荒削りでごっちゃなシンタックスに、げんなりするだけだ。とにかく痒い所はずっと痒いままで、特筆すべきは「データ構造と言う考え方がない」ことだ。そりゃあ確かに動画編集するのにデータ構造もへったくれもねぇだろ、と言うことであれば確かにその通りではあるのだけれど、配列もないのは何とかならなかったのか？（一応外部フィルタとして、AVSに配列を拡張するパッケージがあるが、こいつも正直クソだ）。
では、なぜ紹介するのか。
さっきも申し上げた通り、AviSynthはフロントエンドを持たない。AVSと呼ばれるスクリプト言語を介して、与えられた処理を実行するだけのソフトだ。ソフト屋ならこの表現でピンと来るだろうけど、業界関係者以外はどうだろうか。「バッチ処理」をさせるならAviSynthが一番てっとり早いのだ。
要は、全く同じようなことを手作業で一本一本やるのは、正直ただの苦行なのである。ただの苦行も報われれば良いが、報われないことを何度も何度もやるのは精神衛生上よくない。なので、そういうある意味「編集前の下ごしらえ」のような作業を快適に行うためには、こうした「バッチ処理」に向いている処理系と言うのは非常に有り難いのだ。時間が掛かるようなら、寝る前に走らせておいててめぇは寝てれば良いのだから、まことにコンピュータとして正しい使い方である。
ついでに言えば、フィルタ自体もC++とWin32APIの習いが有ればできる。ああ、もうそれは完全な障壁だけれどね！ 逆に言えば、そこまで分かっている人間が使って真価を発揮するツールだと思って欲しい。確かにその可能性は莫大だが、あまりに莫大過ぎて現在位置を見失わないよう、ツールとしての本質の見極めが必要になってくる、そんなツールである。
なお、AviUtlと一時期よく比較されていたのは、どちらも基本的に一本のAVIをどうこうするツールであるからだ。AVSは同時に複数枚の動画を扱うことはできるが、それはレイヤーとして時間ごとに可変させたりするような器用なものではなく、単に「オーバーポーズした結果」として、一本の動画に帰着させることしか出来ないため、AviUtlがexeditを得てしまった今となっては、積極的に利用するイメージがわかない。ゆえに、前述したような「バッチ処理」であるとか、自力で積極的にフィルタを書いてカスタマイズしまくるか、そのどちらかである。いずれにせよ、このツールについてはほぼ「初心者お断り」なツールであると言えるだろう。この初心者、と言うのは動画初心者と言うより「コンピュータ初心者」である。
