結論からいうと

ここでいう「微妙な音ずれ」はサンプルレート48kHzで、1分あたり18サンプル(=0.4ms)のもので、普通は気になるものではない。

これは原理的になくせないずれである。

経緯

OBSで複数のUSBオーディオデバイスからの音声をマルチトラック化して録画データにくっつけている。アナログで同じ音声を入力している別々のデバイスの2つのトラックの音を細かくあわせてみると、デバイス間で徐々に広がる遅延があることに気付いた。あまり大きい量ではないが、気持ち悪いので一旦調べてみることにした。(詳しい人はこの時点でそりゃダメじゃんと思うだろうが……)

だいたい1分で18サンプル(=0.4ms)ぐらい進んでいる。2分ならもっとすすむ (数えるのが面倒だけどだいたい倍ぐらい)。

追試として、同じアナログ入力をしている2つのインターフェイスを同時にOBSで録音して、録画開始直後に同期をとり、その後の1時間ぐらい波形のずれを見た。メトロノームを鳴らして音声入力にした。

  • 26分後ぐらいに急に3フレームぐらい前にずれた
  • 35分後ぐらいに1フレームぐらい後ろにずれた

前にずれる・後ろにずれるということが起こる。ずっと一定でずれていくわけではない。実時間録音してるのだからどこかで補正(音トビ)しないとおかしいのは当然ではあるが……

クロック誤差を考える

何も考えず、サンプルレートを変えたり、設定を変えたり ASIO にしてみたり、いろいろ試行錯誤してみたがこの現象は消えなかった。最終的にクロック誤差ではないかと思いはじめた。

クロック誤差が通常の水晶を想定して±50ppm なら、48kHz のサンプルレートとしても、実際は±2.4Hz (48e3 * 50e-6) となり、最悪 (48002.4Hz vs 47997.6Hz) で考えると1秒あたり4.8サンプルずつずれていくことになる。

1分で18サンプルなら、逆算するとデバイス間に0.3Hz (18/60) 差があることになる。(0.3 / 48e3 * 1e6=6.25ppm) これは水晶の精度から考えると少ない誤差といえる。

クロックソースはホストPCとオーディオデバイスどちらもあり、完全に同期していない。リアルタイム処理だと、原理的にサンプルパーフェクトで処理することはできない。実時間に対してずれていってしまう (PCやデバイスのクロックの1秒と実時間の真の1秒の誤差) から仕方ない。

デバイスクロックがPCクロックより早い場合、PCからすれば余計にデータが送られてくるので、少しずつデータが伸びていく (その音声はPCから見れば遅れていく)。伸びていくといっても実装によって限界が生じる(バッファオーバーラン)のでそのうち音飛びする。

逆にデバイスがPCよりクロックが遅い場合、PCからすればデータが足りない(バッファアンダーラン)ので一定時間ごとに音飛びする。

複数のオーディオデバイスがある場合、この現象がそれぞれのデバイスに対して生じる。

USB Audio の仕様

https://www.edn.com/fundamentals-of-usb-audio/
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/audio/usb-2-0-audio-drivers

USB Audio 的にはクロックソースの選択や、クロックの同期について部分的に書かれてはいるが、ずれた結果どうすべきかは書いてない。そもそもリアルタイムの非同期転送だと送りっぱなしで再送とかもないので実は伝送エラーが起きてもそのままである (訂正されたりしない)。

アンダーランやオーバーランをどうすべきかはアプリケーションの用途によるだろうからそういうもんかとは思う (配信ソフトなら音ズレが少ないほうが好ましいが、録音ソフトなら音トビが少ないほうが好ましい、というような)

OBSの実装に関するメモ

OBS のサンプリングレート

OBS は設定の「音声」にあるサンプリングレート (48k または 44.1k) が内部ではプライマリーとなっている。オーディオソースのサンプリングレートがこれと違う場合は常にリサンプリングされて統一される。ビット深度はOBS内部では常に float (=float 32bit) で処理されている。

(出力ビット深度は出力の話なのでエンコーダ設定にある)

サンプルが余るような場合どうなるか

OBS自体はオーディオ信号がきた時刻(PC内のカウンタ)を基準にサンプルを整列させていく実装になっているように見える。リサンプリングして余計なサンプルがでてきた場合、あとから生成されたサンプルで上書きされている。

https://github.com/obsproject/obs-studio/blob/ba4f17e1143dd769f55bce6b1595c6704aa7a44d/libobs/obs-source.c#L1471-L1489

つまりOBS的には、基準クロックがPC内のカウンタということになる。PCのクロックはそれほど高精度ではないという問題がある。(PC内は温度変化が激しい。TCXO積むような意味は普通ない)

メモ: OBS の「デバイスのタイムスタンプを使用する」ってなんなのか

この設定は Windows のみ。

  • オンの場合、OBS 内にサンプルが届いたタイミングでカウンタを読む
  • オフの場合、Windows 側で (ドライバ or WASAPIが) サンプルをコピーする直前にカウンタを読む

結論からいえばデバイスドライバの実装が壊れていない限りオフにする必要はない。

UseDeviceTiming https://github.com/obsproject/obs-studio/blob/4b138f674f982c1b85487ff0cf6e3cabd27a76b4/plugins/win-wasapi/win-wasapi.cpp#L1142-L1148 というフラグ

UseDeviceTiming なら
https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudiocaptureclient-getbuffer でとれる pu64QPCPosition (これはWASAPI )

パフォーマンスカウンタ (OS内の高精度でプロセッサ共通のカウンタ) から求められるタイムスタンプを算出して使う

UseDeviceTiming なら、この処理時点の os_gettime_ns を使う。os_gettime_ns は実際のところ https://github.com/obsproject/obs-studio/blob/4b138f674f982c1b85487ff0cf6e3cabd27a76b4/libobs/util/platform-windows.c#L481 QueryPerformanceCounter を使っている。

https://github.com/obsproject/obs-studio/blob/4953c5d517c899517a49360463ad7b70c91dea14/plugins/win-wasapi/win-wasapi.cpp#L1206-L1258 ProcessCaptureData

asio plugin は、ASIO にパフォーマンスカウンタをどうこうする仕組みはないので、コールバック時点の os_gettime_ns を使う。https://github.com/Andersama/obs-asio/blob/asio-juce/src/asio-input.cpp#L317


https://docs.obsproject.com/backend-design#general-audio-pipeline-overview
https://github.com/obsproject/obs-studio/blob/2c58185af3c85f4e594a4c067c9dfe5fa4b5b0a9/libobs/obs-source.c#L1203 MAX_TS_VAR = 2000000000ns = 2秒
ts の処理、sync_offset の追加

サンプリングレートが違うと音がずれる?

OBSの実装上、リサンプリングが入るので、サンプリングレートがオーディオソースごとに異なるからといって音がずれていくということはない。言いかえるとサンプリングレートが原因で音ずれるというのはOBS内では起こらない。

動画と音は、なぜずれるか

動画と音の場合、バッファサイズの違いが問題になる。動画はフレームを飛ばしたり重複させて時間調整しても気付きにくい。音声は動画(60Hz)に対して(48kHz)とケタ違いの分解能を持っており、数サンプル飛んでだけでもプチという高周波音で気付いてしまう。

連続して録音していく場合、オーディオインターフェイス側のクロックがホストより早いとサンプルが余り、徐々に遅れていく。余ったサンプルがどうなるかはインターフェイス側のバッファの実装による。

オーディオインターフェイス側のクロックがホストより遅いと、サンプル数がPCの想定より足りないので、定期的に音が途切れて同期する。バッファを超えて長い時間で「ずれ」はしない。

究極的にずれないようにするためには音声クロック(マスタークロック)に同期した動画のフレーム調整が必要になる。

Windows の時刻精度

ハードウェアクロックが複数ある場合補正して精度を高めると書いてある。どの程度の精度があるかはわからない。
https://learn.microsoft.com/ja-jp/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#absolute-clocks-and-difference-clocks

  1. トップ
  2. tech
  3. クロックによるOBSの微妙な音ずれはなおせない

増設した直後は起動し (未フォーマットの状態)、Windows が起動後「ディスクの管理」でドライブを初期化し、シンプルボリュームを追加した。

そのあと再起動したら起動しなくなった。具体的には起動時に「オプションの選択」画面となり「続行」が表示されない状態。起動させることができないので「トラブルシューティング」するしかない。

「トラブルシューティング」からいろいろやったがダメ

  • 「スタートアップ修復」→何も起こらない。ログのパスも表示されない
  • 増設したSSDを外してみる → はずしてもダメで、つけたりはずしたり全パターンやったがダメ
    • これが結構ひどくて、現状復帰というのが不可能に
  • 「コマンドプロンプト」でなんとかする
  1. まずオペミスで起動ファイルが消えてないから確認する。→ あった
  2. しかしドライブレターがおかしい
  3. なぜかわからないが、このコマンドプロンプト上だと起動ディスクのドライブレターがCではなくFになっている

ディスクが生きているし、回復画面は出るので、Windows Boot Manager までは起動して、Windows Boot Loader が起動できないということのようだ。結局、こうなると修復コンソールのコマンドラインから以下を行うとなおる。

まず修復対象のシステムパーティション(EFIボリューム)を見つける。

> diskpart
DISKPART> list volume
# 同じディスクのボリュームが近くに表示されるみたいなことはないので
# 勘で見つけるしかない

DISKPART> select volume 6
ボリューム 6 が選択されました。

DISKPART> assign letter B
DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。

DISKPART> exit
> B:
> cd \EFI\Microsoft\Boot
# バックアップを一応とっておく
> copy BCD BDC.bak

> bcdboot  f:\windows /l ja-jp /s b:


bcdboot これは「ソース」を「f:\windows」として、ロケールを ja-jp とし、システムパーティション(ESP)として b: を指定している。

これでBCDというブートに必要なファイルが作りなおされる。

コマンドプロンプトからディスクにアクセスする方法

一度 diskpart を起動すると、それだけでドライブレターが割り当てられるみたい。割り当てられたら普通に cd や dir で見れる。もしかして間違えてフォーマットしていないか? ということの確認はできる。

ref.

原因は? ドライブレターが問題?

結構調べたがよくわからなかった。前述した F: というドライブレターは回復コンソール上のコマンドプロンプトの話なので、Windows起動前であり、ここで違っていても、そこまでおかしくない。Windows起動後はレジストリエントリからドライブレターを解決するが、この段階だとまだレジストリは読まれていないはずだからだ。

まず BCD ってなんだ

BCD (Boot Configuration Data) は Windows Boot Manager で使われる設定ファイルであり、実体としては小さいレジストリファイル形式のデータベースである。

起動状態の Windows の BCD は bcdedit コマンドで見ることができる (管理者権限が必要)。ただし raw な情報を出力する方法はなく、「親切な」情報しか表示されない。なのでトラブルシューティングにはとても使いにくい。

BCD を bcdedit で見ると、device というパラメータには partition=c: とか書かれている。が、実際は partition=c: という内容が BCD に記録されているわけではない…… 現在実行中の環境のドライブレターなどを参照してそれっぽく表示している。レターの割当をなくしたりすると partition=\Device\HarddiskVolume1 みたいな形式になったりする。

BCD は Windows Registory 形式 (バイナリ) なので、Linux 向けのツールとかで、なんやかんやして読める状態のテキストファイルである .reg 形式になおすと、以下のようになっている。

11000001 というのが device にあたるエントリ。内容は、たぶんディスクの GUID やパーティションのGUIDが書かれている。

[\Objects\{6f0fb257-f0af-11ee-a710-b12de9d2818d}\Elements\11000001]
"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
  00,00,00,48,00,00,00,00,00,00,00,67,5e,ec,72,84,4c,7f,4d,a5,74,08,9e,22,5c,\
  38,fc,00,00,00,00,00,00,00,00,6e,22,e2,de,e4,ec,50,40,bb,b7,79,4a,a3,72,c7,\
  8d,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

疑問: GUID で指定されているなら、増設したぐらいでおかしくならなくない?

そうなんだよな~ 結局なんでなのかはわからなかった。BCD の差分とか眺めてみたけどわからない。

起動しなくなるのは割とショックがでかいので勘弁してほしい。

  1. トップ
  2. tech
  3. ディスクを増設したらWindowsが起動不能に

Windows は EFI が入っているパーティションのことを ESP: EFI System Pertition と呼んでいるようだ。diskpart で list volume したときに「システム」と書かれているボリュームが起動中のシステムの ESP になる。通常、ESP は FAT32 フォーマットになっており、トップレベルに EFI というディレクトリがある。通常は自動的にドライブレターがつくことはなく、非表示のボリュームとなっている。

変なディスクがシステムパーティションになっているときの変更方法

先日、Windows が起動しなくなったときになんやかんやしていたら、以下にように D: ドライブがシステムパーティションになってしまった。NTFS でも ESP になれるんか、という発見もありつつ、気持ちが悪いので是正したいと思った。別にそのままでも問題はないが……

以下の手順でやるのが比較的安全だと思われる。

  1. 本来のEFIパーティションに対し bcdboot で EFI ファイルを作る
  2. マザーボードのUEFI画面(BIOS画面)に入り、ブート対象に表示されている Windows Boot Manager を、インストールしたものに切り替える
  3. 起動したら diskpart で list volume して、意図したボリュームが「システム」になっているか確認する
  4. 古いほうのEFIを消す

本来のEFIパーティションに対し bcdboot で EFI ファイルを作る

bcdboot についての公式ドキュメント: https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/bcdboot

まず、本来の EFI パーティションをマウントしなければならない。diskpart でドライブレターを割当る。

> diskpart
DISKPART> list volume
# 同じディスクのボリュームが近くに表示されるみたいなことはないので
# 勘で見つけるしかない

DISKPART> select volume 6
ボリューム 6 が選択されました。

DISKPART> assign letter B
DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。

DISKPART> exit
> B:

そして、割当たドライブレターを /s オプションの引数として渡して bcdboot を実行する。以下のようにする

bcdboot  c:\windows /l ja-jp /s b:

これで b: に割当てたパーティションはESPとして現在のシステムを起動するようになったはず。

マザーボードのUEFI(BIOS)画面で起動順を変更する

マザーボードの設定に入り、起動ディスクを変更する。新たに ESP を作っているので、少なくとも2つの Windows Boot Manager と名前がついたものを起動対象として選べるはず。なので、新しく作ったほうの Windows Boot Manager を選ぶ。

そして起動させてみる。

一応、ブートの挙動を書いておくと

  1. マザーボードのファームウェア(UEFI/BIOS)がディスクをスキャンしてEFIアプリケーションを探す
    • これがマザーボードの設定の起動ディスクに表示される
  2. マザーボードは選択されたEFIアプリケーションを起動する。Windows では Windows Boot Manager
  3. Windows Boot Manager は BCDストアを読み、起動すべきシステムを選択する。 (通常起動や、休止からの起動、メモリテストなど)。ここでは通常起動 (Windows Boot Loader )
  4. Windows Boot Loader は Windows OS 本体をブートさせる

起動して確認する。

diskpart で list volume して、意図したボリュームが「システム」になっているか確認する。

この状態で古いほうの ESP は不要になったので、とりあえずリネームとかして置いておけば良い。

  1. トップ
  2. tech
  3. 変なディスクがシステムパーティション(ESP: EFI System Pertition)になっているときの変更方法

書き出しするとき、YouTube 設定でマーカーをチャプターにしてくれる機能がある。書き出したあとに再生成とかしたいので、どこかから普通にテキストとして書き出して欲しいが、たぶんできない? ので他の方法でなんとかした。

  1. マーカーのあるタイムラインを選択して右クリック
    • [タイムライン] → [書き出し] → [タイムラインマーカーからEDL…] を選択して保存
  2. 以下のスクリプトを実行する
#!/usr/bin/env ruby

TC_POS = 0
TARGET_COLOR = "ResolveColorBlue"

chapters = []
tc = nil
while l = gets
    l.chomp!
    case l
    when /(\d\d):(\d\d):(\d\d):(\d\d) (\d\d):(\d\d):(\d\d):(\d\d) (\d\d):(\d\d):(\d\d):(\d\d) (\d\d):(\d\d):(\d\d):(\d\d)/
        tc = Regexp.last_match.captures.each_slice(4).to_a[TC_POS].map(&:to_i)
    when / \|C:(.+?) \|M:(.+?) \|/
        color, name, *_ = *Regexp.last_match.captures
        if color == TARGET_COLOR
            chapters << {
                name: name,
                color: color,
                tc: tc,
            }
        end
    end
end


remove_hh = chapters.map {|c| c[:tc][0] }.uniq.size == 1

chapters.each do |c|
    c[:tc].pop # frame
    if remove_hh
        puts "%02d:%02d %s" % [ *c[:tc][1..], c[:name] ]
    else
        puts "%02d:%02d:%02d %s" % [ *c[:tc], c[:name] ]
    end
end
  1. トップ
  2. tech
  3. DaVinci Resolve のマーカーから YouTube のチャプターを書き出した後に生成する



ステレオ・バランスド経路を排他的に2分岐するスイッチが欲しかったが見つからず、仕方ないので作った。

GND もスイッチしたかったが6回路の物理スイッチというのはかなり入手しにくいので諦めてHOT/COLDだけスイッチとした。それでも4回路2接点スイッチが必要なため面倒くさい。今回は4回路3接点のロータリースイッチ を2接点に制限して使っている。

電源が必要でいいならリレーでいいが、電源の用意がめんどくさい。やるとしたらラッチングリレー(切り替え時だけ通電させるリレー)を使いたいが高価……

やりたかったこと

スピーカーがオンのままヘッドフォンをつけてしまい、スピーカーが鳴っていることに気付かないことが時々ある。これが嫌なので物理的になんとかする。

こんなことしなくても出力するインターフェイスを分けてPCから切り替えれば普通はいいはずだけど、アナログミキサーへ出力していて、そのモニター出力からスピーカーとヘッドフォンを出しているので、そうできなかった。

  1. トップ
  2. tech
  3. ステレオ・バランスド経路 (4ch) 切り替えスイッチ

Studio One の MIDI デバイス設定は相対メッセージ (1 と -1 =127 だけ扱う) が、なぜか GUI からは設定できない。しかし対応はしている。

.surface.xml を編集するとできるらしい

ヘルプから 「設定フォルダーを開く」すると C:\Users\[User]\AppData\Roaming\PreSonus\Studio One 6 が開く。User Devices 以下にファイルができる。ただ Studio One は終了時に設定ファイルを書きこむようなので、一度設定したら終了しないとファイルが見つからない。

type="knob"type="relative" にする。方向が逆という場合、子要素になっている MidiMessageoptionsreversed を指定する。

GUI上もそれっぽいノブが表示されるようになる。

ref. https://forums.presonus.com/viewtopic.php?p=218622#p218622

  1. トップ
  2. tech
  3. Studio One の MIDI で相対値を扱う

ウェブページ上からDAWへ簡単にノート入力できないかというのを考えた。結局 Web MIDI API でできた。わかってから検索すると同様のことをしている人も見つかる。

クリップボードは使えるか

MIDI をコピペする仕様ってあるのだろうか? ウェブ上からコピーできたら便利ではないか → 以下の理由で無理

  • コピペする仕様はなさそう
  • MIDI ファイルとしてコピーしてもトラックにペーストする形で使い勝手がよくない
  • そもそも Web Clipboard API は任意のデータ型は扱えない

MIDI デバイス

Web MIDI API があるので、JavaScript が仮想的にMIDIキーボードとして振舞えば入力できそう。ソフトウェア間のMIDIメッセージのやりとりなので、中継する仮想MIDIデバイスが必要になる。

Mac の場合は仮想 MIDI デバイスが OS 組込みでできるのに対し、Windows にそういった機能はない。

Ableton がいいドキュメントを出している。ここで紹介されている loopMIDI を使うと Windows でも仮想MIDIデバイスをつくれる。

Web MIDI API を使いブラウザから DAW へ入力を行う

Web MIDI API 自体はかなり使うのが簡単で不安になる。適当に出力可能なMIDIポートすべてにメッセージを投げつけるなら以下のようにしてできる。

async function midiDeviceSend(notes) {
	function noteOn(note, velocity) {
		return [0x90, note, velocity];
	}

	function noteOff(note) {
		return [0x80, note, 0];
	}

	const midi = await navigator.requestMIDIAccess();
	const outputs = midi.outputs;

	if (outputs.size === 0) {
		console.log('no output devices are found');
		return;
	}

	for (let output of outputs.values()) {
		console.log(output);
		for (let note of notes) {
			output.send(noteOn(note, 100));
			output.send(noteOff(note), window.performance.now() + 500);
		}
	}
}

なおページをリロードしたりする際に接続されている全MIDIチャンネルに all note off とかが送られるみたい。

  1. トップ
  2. tech
  3. ウェブページ(JavaScript)からDAWへのノート入力

ZOOM ズーム USBオーディオインターフェース 2イン/2アウト32bitフロート入力対応 2023年発売 UAC-232 - ZOOM(ズーム)

ZOOM(ズーム)

5.0 / 5.0


ZOOM UAC-232 を買って気に入って使っている。ただ、入力が2チャンネルしかない。今のところ必要はないが、もし複数ある場合接続したらどうなるのだろうか、と思った。

取説などには複数台繋いだ場合の挙動についての記載はなかった。結局問合せたところ、同一のPCに複数台接続するのは想定されておらず、Mix Control は複数台の UAC-232 を同時に認識できない仕様とのことだった。

  1. トップ
  2. tech
  3. UAC-232 は1台のPCに複数接続はできない

ちょうど1年前からギターの練習をしている。別の日記つくって記録している

https://itisnevertoolatetolearn.hatenadiary.jp/

関連してつくったもの

100万回ぐらい再発明されていると思うけど、いまいちウェブ上で使えるこれだというのがないので自分でかいたやつ

  • Lookup chord from fretboard
    • 指板ポジションからコード求めるやつ
    • スケールをオーバーレイさせて、同じ構成音で別のおさえかた探すときにも使ってる
  • 指板のボックスポジション一覧
    • CAGEDの各ポジション覚える用。なんか拾ったPDFを印刷していたが、他のパターンが欲しくなったのでつくった。
    • ボックスは覚えたのでほぼ使ってない
  • Lookup scale from notes or chord
    • コードか構成音からどのスケールか推定するやつ
    • キーがよくわからんとき、いろいろ情報量増やして推定できるようにつくった
    • 進行を入力すると度数表記で出すので、この数字をググると似た進行があるかわかる

チェルブ Cherub 充電式クリップチューナー 何度でも充電可能 USB Type-C充電 見やすいディスプレイ 複数のチューニングモード ウクレレやベースモードも搭載 コンパクトサイズ CPSチューニング搭載 オートON機能搭載 自動パワーオフ機能 WST-645 - Cherub

Cherub

5.0 / 5.0

ZOOM ズーム USBオーディオインターフェース 2イン/2アウト32bitフロート入力対応 2023年発売 UAC-232 - ZOOM(ズーム)

ZOOM(ズーム)

5.0 / 5.0

ミキサーダイアグラム https://zoomcorp.com/manuals/uac-232-ja/image/UAC-232_diagram.svg

入力が Dual ADC でダイナミックレンジが非常に広くとられており、さらに32bit float にAD変換することで入力のクリッピングという概念はほぼなくなる、というもの。最大入力レベルがあるのでクリッピングが完全になくなるわけではないし、SNRを考えればあまり小さな信号も入力できない。しかし、実際のマイクやライン入力に対しては十分なので、録音したものを、あとからなんとかできる範囲はかなり広がる。

こういう変なものにしては意外と値段が安いので買ってしまった。ちょいちょい無駄にオーディオインターフェイス買ってしまう。

いじれるレベルの一覧

INPUT から OUTPUT まででいじれる範囲のメモ。32bit float の場合 USB 入力に関してはどこでいじっても(録音後にいじっても)デジタルなので気にする必要はない。スペック上、入力換算ノイズが-127dBuらしいので、これよりも低ノイズのアナログアンプでなければ前段に繋いでもSNRの向上もない 。とにかく普通のマイクなら直接繋げってこと。

MUSIC モード時 (各入力ソースが個別にUSB入力になり、ダイレクトモニターもチャンネルごとに分離)

1. 入力レベル (デジタル) → Mix Control の左側のやつ。Mix Control の波形から後に影響。USB 入力に関係するのはここだけ。
2. 出力レベル (デジタル) → Mix Control の Level ノブ。ダイレクトモニターの出力に影響する。上げすぎると出力がクリッピングする。
3. 出力レベル (アナログ) → 本体の OUTPUT ノブ。OUPUT 端子の出力電圧を制限する形で働く。フルスケールが 0dBFS 時に +18dBu (=6.153V)

STREAMING モード時 (入力信号がミックスされてUSB入力になる。ダイレクトモニターもミックス結果を聞く)

1. 入力レベル (デジタル) → Mix Control の左側のやつ。Mix Control の波形から後に影響。
2. ミックスレベル (デジタル) → Mix Control の右側のやつ。実質的には入力レベルとやってることは変わらないが、Mic Control で見れる波形に影響しない。USB 入力に関係するのはここまで
3. 出力レベル (アナログ) → 本体の OUTPUT ノブ。OUPUT 端子の出力電圧を制限する形で働く。フルスケールが 0dBFS 時に +18dBu (=6.153V)

出力

追記: ホワイトノイズは接続していない入力側から発生しているようで、Mix Control で接続していないチャンネルのレベルを最小にしてやれば無音ぐらいまでさがることがわかった。

なので以下書いてあることは割とどうでもよく、セオリー通りで以下のようにすればいい

  • Mix Control のレベルはクリップしないぐらいまで安全を見て下げる
  • OUPUT ボリュームは聞きやすいぐらいまで上げる

ダイレクトモニターに関して、ボリュームをどう設定するか問題がある。

本体の OUPUT ノブはまわしきるとホワイトノイズが結構ある。このOUTPUTはDA後、出力直前のアナログボリュームだと思うが出力ゲインが高すぎるのか、DAのノイズ性能なのかよくわからない。 この OUTPUT ボリュームは最大値(+18dBu)からどれぐらい減らすかというものなので、クリッピングという概念はない。

一方、Mix Control で Level を最大にしても、これはデジタル補正なので、ホワイトノイズはほぼ増えない。しかし DA 前のレベルなので、上げすぎて 0dBFS を超えれば、DAでクリップしてしまう。

よって、Mix Control の Level を優先して上げることでSNRを稼ぎ、本体のOUPUTボリュームを適切に設定するということになる。とはいえモニターのホワイトノイズを気にしないなら Mix Control の Level は下げ気味にして、素直にOUTPUTボリュームの調整だけでもいい。

OBS で 32bit float 録音して DaVinci Resolve へ

(Windows 11)

とりえあえず出力フォーマットは 32bit float にする必要がある。

  • 録画フォーマット .mkv
  • 映像エンコーダ NVIDIA NVENC AV1
  • 音声エンコーダ FFmpeg PCM (32-bit float)
  • 音声トラックを必要なだけ選択

としている。これで DaVinci Resolve はマルチトラックを認識してくれるし、32bit float も正しく扱ってくれる。

この状態で「グローバル音声デバイス」で「2-ZOOM UAC-232 Audio」を設定して、録音してみたところクリップしてしまった。OBS 上で表示されるレベルメータも0dBでクリップしている様子が見える。Windows が悪いっぽい?


obs-asio というプラグインを別途入れて、ASIO で入力するように設定すると、クリップせずに正しく扱えるようになった。

  1. トップ
  2. tech
  3. ZOOM UAC-232 買った

Windows ラップトップをしばらく探していたがThinkpadが不良だった件が尾をひき、選択肢としては DELL XPS ぐらいしかないがこれもまともなスペックだとかなり高価で購入に踏みきれずにいた。

手元にある MacBook はすべて修理不可レベルに古い機種となっており、しかも一番直近で買った (MacBook Pro Retina Late 2013 なのでいうて10年前の) ものはバッテリーが膨張してキーボードが打ちにくいレベルであった。

ということでとりあえずラップトップが1台もないのは困るので、現行 MacBook の最安である M1 MacBook Air にしてみた。M3 まで出てるのにいまさらという気もするが、それほど必要性が高いわけでもないし一旦これでいいのではないかという気持ち。

スペックはメモリを16GBにしたがSSDは256GB。512GB は欲しかったがなんとかなるだろう……

普通にオンラインの Apple Store で買ったが、ものすごく細かいところが作りこまれてて関心した。

  • 配送: 届きそうな当日になると SMS でメッセージがくる (配送はヤマト運輸だけど、ステータスを Apple 側でトラッキングする実装があるのだろう……)
  • 梱包: 開け口の封がカッターなどがいらないようになっていた
  • 内部ラップ: 本体が入っている白い箱はフィルムで覆われているが、これも開けやすいようになっていた (前から?)


届いでちょっとあせったのは MagSafe がなくて Type-C ポート2つのみというところで、そんなの事前にわかっていただろと言われそうだが、なぜか MagSafe はあると思いこんでいた。

  1. トップ
  2. tech
  3. M1 MacBook Air を買った