Abletonの結合・クロップ・分割
Ableton の細かい話は以下にまとめてます。
***
「結合はくっつけるだけ、分割は分けるだけ」。実はそれだけではない。正しくはこうだ。
結合
色々な調整を取り込んだクリップを新規作成する
クロップ
Start/End だけ調整したクリップを新規作成する
分割
Start/End だけ調整したクリップを複製する
「結合」と「分割」なんて言葉は真逆の意味に思えるけど、じつはこの3つはできることが結構似ている。しかしもちろん違いもある。それを説明していく。
(クリップには MIDI とオーディオがあるけど、違いがわかりやすいので、オーディオクリップに特化して話していく。)
結合 ⌘J
難しいやつからいこう。
結合というと「2つ以上のクリップをくっつけて1つのものにする」用途と思われがちだ。それももちろん正解ではあるけど、こいつは一番複雑で、以下の3つのポイントがある。
「選択範囲を1つのクリップにする」
これが基本概念。
選んでいるのが「2つのクリップ」なら、その2つぶんの範囲を1つのクリップにする。結果的に、2つのクリップが結合する。
選んでいるのが「たった1つのクリップ」でも、結合は実行できる。1つのクリップが1つのクリップになる。細かい違いは生まれるけど、見かけ上は変わらない。
選んでいるのが「クリップと、クリップの無い範囲まで」なら、その範囲を無音区間として取り込んだクリップが生成される。
逆に、選んでいるのが「クリップの一部分だけ」だと、選ばれてなかった前後の範囲を切り捨てたクリップが生成される。
「新規オーディオファイル化する」
DAW 上のデータだけでなく、実際に .wav ファイルがフォルダに生成される。バウンスみたいなもの。ロケートは、Project/Samples/Processed/Consolidate。
「調整がファイルに反映される」
わかりやすいのは音量。結合を実行すると、「波形をノーマライズ (注1) して保存した上で、クリップボリュームを元の音量と合わせたクリップ」に置き換わる。
どういうことかというと、たとえば最大音量が -6 dBFS しかない .wavフ ァイルを、クリップボリュームで +4 dB した状態で、結合を実行する。そうすると、結合wavファイルは最大音量がピッタリ 0 dBFS の状態で生成され、Ableton 上のクリップとしてはボリュームが -2 dB になっている。
結合を実行しても Ableton 上で鳴る音量は変わらないんだけど、ファイルそのものの大きさが変わった分、帳尻が合うようにクリップボリュームも調整されている。
音量だけでなく、クリップ端のフェードや、クリップエンベロープ、ピッチ変更や WARP 等もすべて、反映済みの .wav ファイルになる。
↓の動画では、まったく同じ波形をそのまま結合した場合と、フェードインをつけてから結合した場合をくらべている。
もともと音量小さめの波形だったので、そのまま結合した真ん中の波形は、見た目一緒なのにクリップボリュームが -5.53 dB になっている。0 dB に戻すと、波形の縦幅がちょうど画面いっぱいの高さになったのがわかる。
フェードインをつけてから結合した右の波形は、元の波形の一番うるさい部分にフェードをつけ小さくしていたので、次にうるさい部分 (-14.2 dBFS) にあわせて音量調整が行われている。
まとめると
クリップの編集や変更を反映したうえで、選択範囲を、ファイルとしてバウンスする。
元のファイルを編集した上でバウンスするので、「素材として極力劣化させたくない」「あとで編集前に戻したい」って時は注意!
おすすめの利用シチュエーション
2つのクリップを結合したい
短いキックを4つ打ちで置いてみたけど、これを1小節のループ素材にしちゃえば、ドラッグでどんどん伸ばせるよね。
逆再生シンバルを作ったけど長さが半端だから、クリップの始まる位置が気持ち悪い。頭に無音を足して位置合わせしやすくしたい。
さっき録音したクリップ、パパっと下処理だけ済ませたい。フェードかけたり長さ揃えたりして結合すれば、ノーマライズ済の .wav ファイルになる
アレンジメントでオーディオ直貼りで作ったドラムを、セッションビューでも使えるステムループにしたい↓
クロップ
結合よりはずっとシンプルなので、比較しながら見ていこう。
こいつは、選択範囲ではなく「1つのクリップを、1つのクリップとしてバウンスする」。
なので結合と違い、複数クリップを選んでもそれぞれ別々にクロップされるし、無音区間を含んで選んだり、クリップの一部を選んでいてもとくに関係ナシ。
「新規オーディオファイル化する」のは結合と同じ。.wav ファイルが Project/Samples/Processed/Crop に生成される。
「調整は基本反映されない」。音量もフェードもエンベロープもそのまま。
「Start/Endだけは反映される」
……じゃあ元のファイルがコピー生成されるだけじゃないか!と思いきや、クリップの "Start/End だけは反映される" のがミソ。
つまり、元のファイルの頭とお尻のいらないところを縮めてからクロップすると、そこが取り除かれた新しいファイルが生成される。
おすすめの利用シチュエーション
録音をしたんだけど、音を鳴らすまでの待機時間とか、録音止めるまでのおしりの余白とか、無音なだけだからいらないな。まだ編集はしたくないけど、無音だけ捨てとこう。
録音で、回しっぱなしのまま何テイクか録ったんだけど、この3テイク目以外いらないな。あとで「成功テイクって3番目だったっけ?4?」とか迷わないようにもう捨てとこう。
Start/End の位置調整をめっちゃ厳密にやった。あとでうっかりドラッグしたり予想外の操作で戻しちゃったりしないように、確定させたい。
古いサンプリングCD って、1つの .wav ファイルに音ネタが6種類とか並んでる。これを別々に切り出したい。
分割 ⌘E
これは更に単純。カーソルに合わせてクリップを分割するのみ!
上の動画では、"Flexatones" という1つのクリップを4つに分割した。つまり、4つの "Flexatones" クリップができている。
これらはどれも同じ .wav ファイルを指しているし、分割しただけならピッチやボリュームの設定も同じ。ただ、Start/End だけが違う。1つめの Flexatones は波形の一番最初から Start するけど、2つめの Flexatones は途中からだ。
なので分割とは、特殊な"複製" (duplication。⌘D) とも言えるだろう。
「オーディオファイルを生成しない」
フォルダに.wavファイルが生成されることはなく、ただDAW上のデータとして、「Start/Endだけが違う、同じ設定のクリップ」が並ぶことになる。それらのクリップは同じファイルを指したままだ。
「いっさい破壊編集しない」
さっきの動画のように、クリップの一部を範囲選択で 分割 したときと、同じように 結合 したときを比べてみよう。
どちらも DAW 上では選択範囲で分割されたように見えるんだけど、分割だと Start/End の外側が失われていない。分割したあとも、クリップをドラッグで引っ張れば元に戻せる。結合だと、一度やったらもうその範囲だけのクリップ/ファイルになっちゃってるからね。
ここまでの3つで一番「なにも起こらない」ので気軽に使える。
MIDIクリップの場合
MIDI クリップでも、基本的にはオーディオクリップと同じ。
オーディオだと分割と結合の違いは、「ファイルを生成するか否か」「破壊編集するか否か」と言えた。
しかし、MIDI だとオーディオファイルの生成なんてしないので、前者は関係ない。後者の「破壊編集するか否か」がちょっと関わってくる。
例えば、「MIDI 鍵盤をだらだら弾いて、演奏を録った。上手くできた一部分だけ残して、あとはいらないな」という時、分割と結合の違いは……
残す範囲を選んで分割 ⌘E:
元の長いクリップの範囲を縮めただけ。全演奏データはクリップ Start/End 外に残っている。「いらない」けども一応取っておきたいならこちら。残す範囲を選んで結合 ⌘J:
選んだ範囲の外側、使わない部分は完全に消し去ったクリップになる。「いらない」部分は失われるので、思い切りがよい。
……以上ように、字面から想像つかない使い方が、特に結合にはあるので、特徴をおさえておくと作業効率が上がるかもしれないし、何の役にも立たないかもしれません!
***
注1:
結合でのみノーマライズされる理由は、論理的に説明できる。
「複数のクリップを結合する際には、ボリューム設定を統合しながら破壊編集する必要がある。"0 dBFS を越えているが 32f の内部処理上音割れしていなかった"クリップも含まれうる。24 bit でバウンスするなら「peak を 0 dBFS にノーマライズし、クリップボリュームで結合前の音量に合わせる」ルールが最もシンプルで整合する。32f で吐くならこの困りはないが、予告無く float型で吐くことで起きそうなデメリットの方が勝つと判断された。」と思われる。
以下詳しく言う。
クロップ・分割と違って、結合では「複数のクリップが1つに」なる処理を行うことができる。
たとえば同じキックを2つ並べて結合する時に、1つめがボリューム 0 dB で、2つめは -10 dB にしていたとしよう。「ドン!トン…」。これを結合した時には勿論この音量差は反映されてほしい。「結合したら「ドン!ドン!」になっちゃった」じゃいけないわけだ。
とはいえ、1つのクリップに結合したらボリュームパラメータは1つしか無い。少なくともどちらかの波形そのものを変更する処理が挟まってくる。
これを破壊編集というが、基本的にこーいう音や画像などの編集ソフトは、可能な範囲で非破壊編集を好む。「元データは変更せず、"変更したというパラメータ"を保存するほうが、あとでやっぱり戻せたりするし、データとして失われるものがない」からだ。結合においては、やむをえず破壊編集になっていることがわかる。
さて、破壊編集されるのはわかったが、なぜ基準が 0 dBFS (ノーマライズ) なのか? 「データが音割れせず、一番明快な基準がここだから」だ。
いったん Ableton から離れて、デジタル音声データの基礎の話をする。
左から右に進んでいく音の波形のイメージを思い浮かべてほしいのだが、そのときの上下とは波形の音量だ。これの単位を dBFS (デシベル・フルスケール) という。
この音量には上限があって、0より大きい音は記録できない。無限にちっちゃい音から上限ギリまで…… -∞ 〜 0 dBFS の間に波形が描かれる。
この0の天井を超える大きい音を作っちゃったとき、そのまま .wav ファイルなどに書き出すと、音割れデータになってしまう。
しかし、音作り中につねに 0 dBFS を超えないように気を配るのは大変だ。とくにディストーションやサチュレータを使ったり、沢山のトラックをミックスするたびに、いちいち意図しない音割れを気にしたらストレスすぎる。
そこで、「DAW 内での処理の過程で音がデカくなりすぎても、最後だけ下げて最終的に収まってればセーフとする」しくみがある。浮動小数点演算だ。
ビット深度とは、デジタル音データの音量方向の解像度のことだ。ビット深度には int型と float型がある。たとえば 24 bit int は、音量を約1678万段階 (= 2^24)で記録できる。これを 32 bit float にすると、解像度は 24 bit で同じなのだが、加えて 8 bit の指数を記録できる。
この増えた 8 bit は何かというと、ズーム機能のようにイメージしてほしい。ビデオを撮ってて、撮ってるものが大きくなりすぎて画面に収まらない!時にズームアウトすると収まる。逆にちっちゃすぎ!という時にズームインする。
で、DAW内の処理過程ではつねに 32 bit float で扱われている。音がでかすぎて音割れしそうになったらズームアウトするので、音割れを気にせずすいすいと作業ができる。
最後にレンダリングでファイルに書き出す (= 16 bit や 24 bitといった int型に変換する) 時までに、音量を 0 dBFS 以下に収めておけば良い。
Ableton に戻ってこよう。そういうわけで、DAW 上でてきとうに +24 dB などにしても音割れしない。float型で処理されているから。
しかし、結合 によって生成される音声ファイルは 24 bit int (なぜかは後述する) なので音割れする。ファイルを生成する際は、音割れしないところまで音量を下げる必要がある。つまりそれは最高でも 0 dBFS だ。なので、一番音の大きい箇所 (peak) が 0 dBFS に合うように音量調整しよう。これをノーマライズという。
いっぽう、peak が 0 dBFS に満たない小さめの音については、音割れとは無縁だ。別にノーマライズする必要はない。
しかし、「音割れするほど大きいか否かを、いちいち判定・場合分けして、該当する場合のみノーマライズをする」よりも、一律にノーマライズしてしまうほうがルールとしてシンプルだ。シンプルなルールはユーザの勘違いの可能性を減らして、使いやすさに貢献する。
よって結合では必ずノーマライズが発生する。
クリップ端フェードが反映されるのも同様の理由で、「複数のクリップを1つにする時に、フェード情報を破壊編集として適用しなければ、DAW 上でそのフェードを表現することができない」からだ。
クロップ・分割では、単一クリップのみを相手にしているこの問題は起きないため、非破壊編集が許され、ノーマライズは発生しない。
結合による書き出しが 32f ではなく24である理由は、やや推測になるが、総合的にいって24の方が便利だし混乱が少ないからである。float を float と知らずに扱ってしまうと、ソフトや機器によって対応していないことがある。intの方が汎用性が高くサイズも小さい。.wav を生成する以上、Ableton の外のどこでそのファイルが利用されるかわからないので、広く使えるに越したことはない。
結合でノーマライズが発生することはべつに大したデメリットではない。破壊編集はイヤかもしれないが、ボリューム設定が1つに統合される時点で破壊編集からは逃れられないので、ノーマライズのデメリットではない。float のデメリットを回避できるならば、24が最善なのではないか。
投げ銭いただけたら、執筆頻度が上がるかもしれません