7で何か適当なQTファイルを開いて、そのファイルの様子を探ります。探り方は、以下のようなスクリプトを書いて、調べます。1」とは、一番手前に表示されているムービーの事です。すると、以下のような「ドキュメント」情報が返されます。state:complete}....いっぱいありますネ。1080}になっています。ナチュラルディメンションとは、自然な寸法、つまりQTファイルの「素の状態の」ピクセル寸法が解るわけです。540}になっています。これはつまり、現在表示している状態のピクセル寸法です。私が1/2の大きさで表示してたので、この値になっているのですネ。scaleとdurationの項です。scaleは「24」、durationは「2640」となっています。scaleに基づいてムービーの尺を表したのがdurationです。このドキュメントの尺は「2640/24」で110秒です。今回流用したムービーファイルは、前にフリッカー参考例で出したファイルなのですが、確かに1分50秒です。Effectsで、24.0fpsでレンダリングしたので、とても歯切れの良い簡単な数値「24」になってくれたのです。fpsが23.976の場合は、ちょっと状況が変わってきます。scaleは整数で扱う」事と決められているので、そうはなりません。24000....でした。1001....でした。1フレームの長さが1001という設定なのです。「24000/1001」=23.976024....です。末尾の「024」という端数にそこはかとない不安が残りますが、概ね....。計算しやすいように、今度は1分ジャストの23.976fpsムービーを開いて調べてみます。23.976fpsの1分のQTファイルのdurationは、1441440でした。scale」なんていう計算をすると、めっちゃ誤差が出ます。1441440/24000=60.06結果は「60.06秒」....たしかに。現場ではあくまで60秒として扱わなければなりません。ドロップフレームではなく、ノンドロップフレームの「ご都合」をちゃんと考慮して計算式を組み立てましょう。scale/フレームのデュレーション))「round」とは四捨五入の事です。今回の場合は「23.976024を四捨五入」という事ですネ。1441440/1001/24=60.00で、正しいデュレーションが返ります。「ビデオ上の時間軸」の....ですネ。こんな感じで、QTから様々な情報を得て計算すると、映像制作の各場面で用いる事ができます。....、こういう計算をしていると、心が荒んでくるのよネ。30fpsが29.97になったいきさつ、そして、29.97のノンドロップが生まれた背景....。(60p)に拡大して....。「29.97DF」「29.97NDF」「30.0」の3つが混在する状況って....。それらの経緯を踏まえて、今回のような「23.976と24.0の二枚舌」のスクリプトを作らなければなりません。仕方ない事とは言え....ねえ。96fpsも「どうせ」96.0fpsにはならんのでしょうね。アソシエーションの偉いさんたち、どこかで一回、リセットしてくれませんかネ。....ハードの互換性とか言ってたら、この先何百年もずっと呪いから逃れられないよ。アレな廃棄物と同じで「解決は未来の人間に任せばよい」ってか。その場しのぎの結果オーライ。面倒な運用を延々と引きずる。....プロの現場が理路整然としているのでは決して無い....事の証ですネ。怪しい尺を知らせるスクリプトアニメの制作現場では、作画が2コマ3コマでタイミングを作る事がほとんどで、ゆえに、カットごとムービーの尺(デュレーション)の傾向は偏ってきます。....というのは、前にも書いたとおりです。「4秒19コマ」とか、「5秒23コマ」なんていう尺は、かなり変わった尺です。コンポジットを担当している作業者は、「うわ〜、妙な尺だなあ」と記憶に残ります。記憶に無いのに、「5秒23コマ」なんていう尺が存在した場合、「何かの不具合により1コマレンダリングできてない」などの「障害の可能性」が高くなります。今はQTでレンダリングする事が多くなったので、あまり「23コマ」などの「間違った尺」は見かけなくなりましたが、連番レンダリングではたまに発生する障害です。レンダリングが中途でエラーで止まり、再スタートした際に、1コマ欠落するのです。まずいことに、尺の間違いはラッシュチェック(カットごとのムービーを上映してスタッフでチェックする)では見つけにくく、編集さんに渡った時点で初めて「発覚」する事がほとんどです。間違った尺のムービーを度々、編集さんに渡していると、「いい加減な仕事しやがって」と信用を失います。事前に尺間違いがないか、ちゃんと検査してから渡すのがベストです。厳密な検査は、やはり、確固としたデータベースと照合するのが必定ですが、レンダリング時の障害から発生した類いの尺間違いは、コマ数を調べるだけでも結構「見分けられ」ます。文頭で書いた、現場の慣習による「尺の定番」が存在するからです。今回は、尺のコマ数をチェックするスクリプトを書いてみます。現場では、実際のファイルから読み出して尺のチェックするのですが、まずは、架空の尺のリストを用意して、「検査エンジン」がうまく動くかを試してみます。今回はちょっと長めですが、構造自体は簡素です。--ここから--架空のカットの尺のリストです。実際には、QTから取得したり、連番ファイル数から取得します。--....のように書き込みます。--危険度別のコメントを書き込みます。テキスト色も危険度レベルに合わせた色にします。tell--テキストエディットの表示を確認してください--以上でメイン部分は終了です。writeTextEdit--ここまでAppleScript初心の場合は、読み切れないかも知れませんが、詳細な解説はいずれ。上記スクリプトを実行すると、以下のような検査結果がテキストエディットを用いて表示されます。危険度が増すほどに、テキスト色が赤に近づいていきます。架空ではなく、本番の作業では、上記のようには色とりどりにはならないでしょう。大体、黒か緑の文字で埋まるはずです。その中にあって、たまに赤い文字が1行あると、その行だけが異様に目立って、ユーザ(例えば撮影監督)に知らせてくれます。コンピュータはあくまで「判断をユーザに求めてくる」だけです。意図された「5+23」なのか、意図しない「5+23」なのかは、人間が判断します。タイムシートが「5+23」だったら、「うん、そうなんだよ。中途半端な尺なんだよなぁ」と自分の中で念押しできます。スクリプトのプログラム文を読むと、コマ番号に対する危険度レベルとコメントを設定しているのが解ります。その「からくり」通りに、スクリプトは尺を判断し、テキストエディットでユーザに告知します。これは、「作業の内容」や「作業の慣習」をもとに、当該の様々な「値」を、プログラムで処理して判断する、初歩的なスクリプトです。した事をどんどん積み重ねていけば、コンピュータは、まるで介護犬のように、ユーザに色々と「尽くして」くれる存在になります。少なくとも、私はこのようなプログラムを作業に取り入れたおかげで、格段にミスを減らし、格段に「映像表現に専心」できるようになりました。映像作りは1枚絵を描くのに比べて、煩雑で事務的な作業が多過ぎます。....で、それは減らせません。その雑務を「どう処理するか」を考えれば良いのです。映像を作りたいのなら、思いのままに映像を作れるよう、環境を整えるのが「当たり前の事」です。雑務に自分の時間を搾取されっぱなしに放置しておくと、いつまでたっても本腰を入れて取り組めないのですヨ。久テキストエディットを操作してみる少人数で映像制作をしていると、手弁当で各自が適宜制作管理して....なんて考えがちですが、全くのナンセンス、「やるべき事」と真逆の行動です。少人数グループは、制作進行と呼ばれる制作を管理するスタッフが立てられない事が多いので、実は一番、その「制作」部分が甘くなり脆弱になるのです。その甘さはまんま、映像のクオリティに影響します。少人数制作ほど「誰も制作を管理していない」状況に陥り、土壇場になって「あれがない」「これが抜けてた」などの醜態をさらす事になります。プロ集団が「制作スタッフ」と呼ばれる人員を配置するのは、ちゃんと大きな意味があるのです。私は2〜3人で作業する事がありますが、「人数が少なくて小回りが利く」のは確かにそうですが、代償として「誰も面倒を見てくれない」状況が待っています。私が編み出したのが「コンピュータに面倒を見てもらう」制作手法です。不完全なシステムではありますが、コンピュータに管理を委任するようになって、何よりもまず随分楽になりましたし、ミスも大幅に減りましたし、精神的にも余裕が出るようになりました。コンピュータによる創作サポート体勢が必要なのは、まずは個人、少数人数の制作規模なのです。世間では全く逆に考えられていますが、ネ。制作システムって、大所帯の会社が導入するものだとタカを括っていませんか。大所帯の会社は、いざとなればマンパワーでこなせますが、少人数・個人のマンパワーは悲劇的とすら表現できます。制作システムの「守護」が必要なのは、むしろ、個人や少人数なんですヨ。ちなみに....コンピュータを制作上の強い後ろ盾にする....わけですから、その制作システムが「日々、何でもかんでも、いちいち手で入力しないとうまく動かない」ようでは「本末転倒」も甚だしいです。作業の中にとけ込むようなシステムでなければなりません。現在のコンビニ・スーパーのレジをイメージすると、どういう事か、想像できるんじゃないでしょうか。面倒な作業を肩代わりしてくれるツールが、実はデータベースなどと連携して強いシステムをどんどん作っていく....というのが、好ましいのです。制作システムにこき使われるようじゃアウトです。実は、この「今さらAppleScript」は、各個人が自分なりの作業システムを作るためのきっかけになればと想い、書き綴っているのです。....まあ、ちょっと遠い気もしますが、ちまたには、あまりにも文献が少ないからネ。今回は手短に、MacOSX付属の「テキストエディット」のスクリプトをちょい、紹介します。コンピュータが処理している様子は、人間からはまったく伺い知る事はできません。空冷ファンの音が大きくなると、「あ、大変なんだ」とか解る程度です。スクリプトプログラムの文中に「見ている人間がわかるように、文字を表示する」仕掛けを作るのが一般的です。AppleScriptで文字を表示する手段は、いくつもありますが、今回はテキストエディットを使って、遊んでみます。以下がスクリプト文です。tell--ここまで上記スクリプトを動かすと、以下のYouTubeムービーのようになります。....まあ、これ自体に有用性はありません。文字を書き換えて動かす段取りはわかるかと思います。次に紹介する予定の、尺のコマ数をチェックして「怪しいかどうかを告知する」スクリプトでも、テキストエディットを使います。尺とフレーム数、全部入り前回書いた「尺からフレーム数への変換」は、実際に使ってみると実用性に乏しい事がわかります。Effectsのテキストレイヤーに流し込む際に、秒とコマの情報を別々に欲しい場合もあります。そんな時は、自作のルーチンを強化して、機能アップを図れば良いのです。ユーザが「00+00」「00+00+00」の書式で入力した場合と、「0000」のフレーム数を入力した場合の、2つの場面に対応できるルーチンに改良します。「どうやってみわけんの?桁数?」「IFで分岐?」....とか考えがちですが、実は何も見分けなくても、前回書いたルーチンは「フレーム数の入力に対応」しています。前回のルーチンは、6+00+1441443+72....のどれでも、正しく処理します。Effectsもそうで、人間が繰り上がりを計算しなくても、自動で繰り上げを計算するようプログラムされているのです。「1+18」のカット尺にボールド8コマを足した「1+26」と入れても、ちゃんと「2+2」に変換してくれます。要は、ベタなフレーム数を計算した後、改めて「00+00」の書式を生成するルーチンに仕立てておけば、「行儀の悪い」入力でも「清書」した値を返してくれます。ルーチンが返す値も単に「フレーム数」だけでなく、様々な情報を返すように強化します。AppleScriptでは「ラベル付きリスト」とか呼ばれるデータで、今回作ったルーチンは以下の値をまとめて返してくれます。秒フレーム秒の表示(端数を除いた総秒数)フレームの表示(2ケタ)計算に用いたFPSルーチンを利用する際、上記の中から、ニーズに適合するものを取り出して使います。ルーチンを走らせるだけでなく、対話式のプチ「尺とフレームの変換計算」アプリケーションに仕立て上げます。以下がAppleScriptのスクリプト文です。calcFrames2--ここまで上記スクリプトを「アプリケーション形式」で書き出すと、いつでも尺の変換計算を確認できるプチAppができます。実行してみると、ここに何か、尺を入力します。6秒ジャストの尺を色々な書式で入力してみましょう。結果は、....とちゃんと正確に計算しております。違う書式で........とか、....などでも、やはり以下の通り、正確に計算して返します。別の尺でも、ちゃんと変換します。こんな表記もイケちゃいます。1時間0分0秒0コマ。結果は、....ですネ。3600秒は1時間ですから、バッチリ、処理できてます。以下のようにエラー警告をおこないます。dialog」のGUIをくっつけて、1つの小さなアプリケーションにする事もできます。尺の変換ルーチンは、それそのものは何らUIを持ちませんから(というか、そのように作ったので)、対話式のアプリにしたい場合は、AppleScriptの他の機能と組み合わせてアプリを作ります。Effectsのレンダーオートメーションと連携して、コンポジションの尺や、テキストレイヤーの内容を書き換える事も可能ですネ。次回は、尺の変換の体勢も整ったので、「尺が怪しくないか、判断してユーザに知らせる」スクリプトを作ってみます。以下のような「素敵なお知らせ」をMacがテキストエディットを使って知らせてくれます。dialogだけでなく、テキストエディットを用いて告知板にしたり、HTMLファイルを書き出してFireFoxやSafariで表示する事もできますから、ユーザへの「お知らせ方法」の手段はそれなりに豊富です。尺からフレーム数への計算アニメ制作現場では、2コマ3コマで動きのタイミングをとる事が多いので、都合、タイムシートでの尺は「傾向が偏って」きます。「3+12」(つまり3秒半)なんていう尺は、それこそ耳にタコができるくらいお馴染みの数値です。そんな中、QTファイルのPDF伝票で「3+11」とか「5+23」とか言う尺を見ると、「なんかやらかしたか?」と直感します。「何かの障害で、尺が足りてない」的な「危険予測」です。....まあ、危険予測と言っても、既にレンダリング済みのムービーファイルの尺なので、実際は「現物を確認する前の、状況予測」なんですけども。シートを確認してみると、「うわー、変な尺。ほんとに5+23だよ。1コマ伸ばして6+0にしときゃいいじゃん....」という珍しい状況もあったりします。そんな変な尺の大体は、レンダリングの何らかの不具合による途中終了、もしくはオペレーション上のミスの場合が大半です。カットを管理するデータベースと連携しなくても、尺を見るだけで尺の不具合を発見する事ができます。全て発見できるわけではないですが、ソフトウェア上で発生したような障害は、大体検出できます。レンダリングしたムービーの尺を取得して、「変なコマ数」か否かをチェックするスクリプトを作れば、作業者がいちいちファイルをチェックしなくても、コンピュータが「やばそうな尺を教えて」くれる....というわけです。やって、コンピュータを自作ツールで「育てて」いくと、次第に「作業上のパートナー」「ヘルパー」的な役割へとコンピュータが変わってきます。今回はまず、その土台となる、尺とフレーム数の変換スクリプトを、AppleScriptにて書いてみます。やる事自体は、そんなに難しくないのは、考えればお分かりかと思います。24コマで1秒....というのを、計算すれば良いのですからネ。アニメ現場の場合、尺は通常、1秒24コマ換算で、「秒+コマ」の書式で書きます。3秒なら「3+0」、5.5秒なら「5+12」です。12....の要素に分けます。132....という計算をしてやれば良い訳です。Effectsではコンポジション設定のデュレーションの欄に、「5+12」と入れると、「5秒12フレーム(コマ)」としてちゃんと認識します。「1+30+0」と入力すると、「1分30秒0フレーム」と認識します。どこまでプラス(+)の連結を受け入れるのか、怖くてやってませんが、AppleScriptでも似た構造で処理してみます。図にのって、「日+時+分+秒+フレーム」という5段階まで受け入れるように作ってみました。....まあ、「日」単位の需要があるとは思えませんが。calcFrames...」以下が尺をフレーム数に変換する「自作ルーチン」です。...」でルーチンを呼び出して処理させます。1行名の「my...」のかっこ内の「"5+12"」を、「"7+0+0+0+0"」(7日0時間0分0秒0フレーム)に書き換えると、7日=1週間のフレーム数が計算できます。ちなみに7日間のフレーム数は、1451万5200フレームみたいです。きりがないので、「1+0+0+0+0+0」(=1年)などの6つ以上の連結の場合は、「false」(偽の値〜「もうダメよ」的な)を返すようにしてあります。こんな感じで、「処理ルーチン」を自作して、そのルーチンに値を投げ込むと、処理された値が戻ってきます。このやり方は、スクリプトが複雑化する際に、必須となります。久ファイルの分別(後)AppleScriptでファイルの分別をする後半です。大量処理の場面ではFinderを使わず、高速化するカット名らしき文字列を含むファイルだけを対象とする特定のファイル形式(今回はDPX)だけを対象とする....です。PSDやQT、JPEGは対象から自動的に外し、さらにはDPXファイルと言えどもカット名を含まないものも自動的に対象外とします。長いスクリプト文なので、まずは下記に記します。--検索ファイルの最終カウントを結果として戻すコメントを入れたおかげで、余計、長く感じられますが、まだシンプルなほうだとは思います。やっている事が、単にファイルの分別ですからネ。テスト用の偽物ファイルを作るところからやっているので、長くなっているのですネ。動作中のスクリーンショットは、こんな感じ。スクリプトを実行すると、デスクトップに日付のフォルダが自動生成され、その中に数秒後、テスト用のダミーファイルが大量生成されます。5040個の連番ファイルと、故意に混ぜた関係のないファイル6個。変更日でソート表示されてるので、並びはバラバラですが、ウィンドウ下部の項目数に注目してください。...実際に作ったのは、上記の通り、5040+6で5046ファイル。「分別を処理してみる」ボタンをクリックすると、数秒後........のような感じで、思惑通り、カット名を持つ連番ファイルだけが、分別されました。イジワルな名前の混在にもメゲず、ちゃんとカット名連番だけを見分けて、新規フォルダを作って格納しています。種類でソートすると、こんな感じ。5046項目のごちゃまぜファイルが、数秒で、スッキリ、13項目に整理されました。以前にレンダリングしたQTファイルや、とりあえず置いといたJPEGファイルがあっても、「カット名を含む、DPX」以外は処理対象から外すので大丈夫なのです。作品や話数がごっちゃになっていても、「カット名の命名規則に準じて」ファイルを選別するので、問題無いのです。スクリプトの文中に目を通すと、AppleScript独特の表現もちらほら見えます。delimiters」なんてのは、その最たるもので、私はこれが面倒でイヤなんですが、要は「テキストの要素を分解する文字」の事です。これを操作すると、文字列を任意の文字で分解できるようになります。ファイルを分別するくだりは、目の前にあるものを処理して、もし対象外のものだったら、一歩進む....という、何とも可愛い動作にしてあります。みたいにして、地道に書きます。Finderは言わば窓口。そこに大量の物品を持ち込んでもパニックになるだけです。窓口で簡単な手続きを済ませたら、後は頼りになるバックヤードでドカンと大量処理するのです。AppleScriptに馴れていない人が、上記スクリプト文を読んでも、理解できないかも知れません。コメントだけ読んで、流れを汲んでもらえればと思います。文中の細かい説明はまたいずれ。今回はダミーファイルまでも作るデモ的なスクリプトですが、文中後半の「ファイル分別ルーチン」を抜き出してちょっと手直しすれば、汎用性があって何度でも使い回しのできる、連番分別アプリケーションに育てる事ができます。次回は、似たようなスクリプトを使って、「作業者にツッコミをいれる」スクリプトを作ってみます。データベースを使わなくても、スクリプト自身が判断して、「ほんとに、その尺で合ってる?」とユーザに確認してくるのです。Effectsで出力した連番やQTを整理するスクリプト。実は、運用やワークフローがどれだけ考え抜かれているかを示す「試金石」のようなものです。スクリプトでうまく処理できない運用ルールやワークフローは、未発達で穴が多い、もしくは、理路整然としてなくて複雑である証拠です。複雑怪奇な運用ルールは、コンピュータだけでなく、人間も往々にしてミスを連発します。「IF分岐が多過ぎる」と言いますか。誰もが短時間でルールを理解できる運用方針は、その運用の過程で働く人間に優しいのはもちろんの事、コンピュータでも処理しやすいのです。複雑で大風呂敷を広げたフローは、素人さんは「すげー」とか関心しがちですが、多様な現場に接してきたプロの目からすると、「メンテが大変そう。シンプルにできなかったんだろうか....」と気の毒になるフローです。複雑なフローはそれだけで、時間やお金、体力とメンタルに、負荷を及ぼすからです。*納得ずくで背負い込む覚悟の作品もあるでしょう。その場合は金と人と時間に対して覚悟する....という事ですネ。シンプルで澱みがなく、INOUTが明確であるのが理想ですが、「一生懸命取り組むほどに、フローや運用を複雑にしてしまう」事も少なくありません。運用上の笑い話で「チェックが甘いからこのようなミスが出るのだ。チェックしたか、さらにチェックするようにしよう。」なんてのがあります。「なぜミスが出たか」を解消しようとはせず、チェックだけを何重にも上乗せしていく....のは、誰もが「馬鹿っぽいやり方」だと感じるはずなんですが、結構、ありますよネ、そういうの。「地獄絵図のようなごちゃ混ぜのフォルダ」内から、連番ファイルを抜き出し、カットごとのフォルダにまとめるスクリプトですが、まずはファイル名から「カット名」(今回の場合「クリップ名」と呼んでも)を抜き出す方法から。anime_01_123_t1_0001.dpx上記のファイル名は、「anime」という作品略号の、「01」話、カット「123」、テイク「1」の、連番1フレーム目のDPXファイルです。t1....のように、カットの情報をカテゴリで分解できます。今回の分別処理は、「作品、話数、カット番号、テイク」をひとかたまりとして扱い、分別しようと思います。抽出したい....わけです。何が入っているか特定できない状況において、ファイル名から「作品_話数_カット番号_テイク」を抽出し、その文字列をキッカケにしてファイルを収集する....わけですネ。files」なんてやったら、またレインボーカーソルかも知れません。ここはひとつ、「ファイルの総数なんて数えないで、先頭のファイルからどんどん喰っていく」やりかたで処理します。「わんこそば」のように、「目の前にある項目を処理していく」やりかたです。何度も書いてきた通り、大量の項目を処理しようとすると、Finderは破綻するわけですから、Finderには項目を1つだけ渡して順次処理するようにすれば、破綻せずに済みます。「使いよう」を考えます。処理ルーチン上で、ファイルをひとつずつ処理し、条件に合った場合は、ファイルを収集して新規フォルダに移動します。これを、ファイルに全部目を通しきるまで、繰り返して処理します。処理に適合する条件は、DPXファイルであることカット名を含んでいると予測できるもの....の2種です。条件を増やしても良いでしょうが、カット名(らしき)を含んでいて、DPXファイルであれば、かなり特定できますから、今回はシンプルなこの2つの条件だけで処理します。DPXファイル→ファイル名が「.dpx」で終わるカット名を含んでいる→アンダーバーで文字列分解して要素数が5以上のもの....まあ、条件が甘いような気もしますが、運用とワークフローの前提が「そこそこ、要素を絞り込んでくれてる」ので、これでも充分上手くいきます。....と思ったら、またこんなに文がかさんでおる。久ファイルの分別(前)AppleScriptは映像制作で役立てようとすると、結構、使い方に「コツ」が要ります。「コツ」なんていう言い方をするのは、「基本に忠実で、理屈にかなっていても、うまく動かない時がある」からです。5,000項目を取り扱うような場合は、市販参考書に書いてあるやりかたではダメです。市販参考書は、まさか5,000項目なんて処理するとは想定していないのですから。「anime_01_065_t1_」で名前が始まるファイルを抽出せよ....などの時は、普通は「フィルタ参照形式」という方法で抜き出すのが基本ですが、相手が5,000項目ともなると、レインボーカーソルが回ったまま、Finderが応答しなくります。ビジー状態による、事実上のフリーズですネ。Finderは、数千項目などの処理には「全く向かない」と考えて、他の手段で抜き出します。"MacHD:testfolder2:")なんのヒネリもないmvコマンドですが、AppleScriptと組み合わす事によって、様々なアプリケーションと連携が可能です。上記の例だと、AppleScriptのうまみはほとんどない....ですネ。ターミナルでやりゃ良いんだもん。AppleScriptを使う以上、汎用性の高い、「カットごとの分別はおまかせ」的なツールに仕立て上げたいですよネ。....、今回(と次回)のテーマは、「ファイルの分別」です。AppleScriptは、「大量のファイルを捌くのは苦手」....とされてきました。Finderの挙動が、誤解を招いてきたのかも知れません。使い方次第で、いくらでも高速化できる事を、実践してみたいと思います。EffectsでESTKスクリプトを実行して、「連番ファイルの親フォルダを作る」のを自動化すれば良いんでしょうが、それはまた別の機会に。地獄絵図のようなフォルダの中から、「アンダーバーで区切られたカット名を持つファイルを、それぞれカットごとにフォルダを新作して分別する」ミッションを、AppleScriptにてクリアしたいと思います。カット名の規則は....作品名_話数またはシーン_カット番号_tテイク番号_連番.ファイル拡張子という運用がなされているものとします。別の命名方法でも良いんですが、今回はこの命名規則を用います。ちなみに....「いや....。バラバラで....」....とか言う場合は、「運用のところ」から見つめ直しましょう。決まった法則でファイル名を運用出来てないのは、すなわち、「私(私たち)は価値ある時間を、混乱の収拾のために、無駄に費やしたいのです」と宣言しているようなもんです。最低でも「各作業セクション内では統一した規則で運用」すべきで、「自動処理以前に、まず運用の基本を形成して楽になろう」....ですネ。ワークフローを軽視せず、命名規則もキチンと規定してあれば、AppleScriptは守護天使のように、作業者・クリエーターに力を授けてくれます。