# Дуальный монтаж: камера плюс запись экрана

Ты снимаешь себя, параллельно идёт захват экрана, звук есть в обоих файлах.

## Синхронизация по звуку

```bash
python scripts/sync_dual_sources.py camera.mp4 screen.mp4 --out dual_sync.json
```

Кросс-корреляция огибающих **атак** энергии, а не самих волн: как только микрофоны
различаются по АЧХ или один сжат компрессором, корреляция волн перестаёт работать.
Огибающая подъёмов энергии цепляется за тайминг слогов, который у обеих записей один.

### Уверенность важнее самого смещения

Пик корреляции сам по себе ничего не значит. Значение имеет то, насколько он выше
следующего по величине пика. Отношение около 1 означает, что в файлах, скорее всего,
разный звук — и отчёт скажет это, вместо того чтобы уверенно вернуть неверное число.
Порог по умолчанию 1.6.

На проверке с известным смещением 6.4 с: определено −6.400 с, уверенность 24.2.

### Проверка дрейфа

Смещение измеряется отдельно в начале и в конце **общей** части — после применения
глобального сдвига. Сравнивать одни и те же индексы невыровненных огибающих нельзя:
на паре со сдвигом 6.4 с такая проверка «находила» десять секунд дрейфа, которого не
было.

Если остаточные смещения в начале и в конце расходятся больше чем на 0.25 с,
рекордеры шли с разной частотой сэмплирования: одним сдвигом весь дубль не выровнять,
и отчёт даёт готовый множитель `atempo` для растяжения экрана.

### Какой микрофон брать

Оценка по отношению сигнал/шум плюс **реальная полоса** (частота, ниже которой лежит
95% энергии), минус клиппинг.

Доля речевой полосы 300–3400 Гц для этого не годится и работает наоборот: обрезание
полосы **повышает** эту долю, поэтому худший микрофон получал бы более высокий балл.
На проверке камера (спад на 6192 Гц) правильно выиграла у захвата экрана (3503 Гц),
несмотря на чуть лучшее отношение сигнал/шум у второго.

Вторую дорожку не выбрасывай: в ней звуки интерфейса и страховка при выпадении
основного микрофона.

## Раскладки

```bash
python scripts/render_dual_layout.py out.mp4 --sync dual_sync.json \
  --layout-plan layout_plan.json --canvas reels
```

| Раскладка | Что даёт |
|---|---|
| `screen_focus` | Экран во весь кадр. Основной режим, когда важно, что происходит |
| `camera_focus` | Только ты. Вступление, вывод, эмоция |
| `pip_camera` | Экран во весь кадр, ты в углу. Рабочий режим объяснения |
| `pip_screen` | Ты во весь кадр, экран вставкой. Когда важнее реакция |
| `stacked` | Ты сверху, экран под тобой. Классика вертикального туториала |
| `stacked_screen_top` | Экран сверху, ты снизу |
| `split_even` | Ровно половина на половину |

Раскладки заданы долями канваса, поэтому один план работает для 9:16, 1:1 и 16:9.
`python scripts/render_dual_layout.py --list-layouts --canvas reels` печатает
фактическую геометрию для выбранного размера.

### Экран никогда не кропается

Источник экрана масштабируется режимом `contain`: по краям живут тулбары, строка
терминала и кнопки — именно то, ради чего запись и делалась. Лицо, наоборот,
масштабируется `cover`.

### Слои укладываются по площади, а не по роли

Полнокадровый источник кладётся первым и становится фоном, меньший остаётся сверху.
Сортировка по роли ломала `pip_screen`: полнокадровая камера закрывала вставку экрана
целиком.

### Зум в область экрана

```json
{"at": 22.0, "layout": "screen_focus", "zoom": {"x": 0.05, "y": 0.08, "w": 0.9, "h": 0.55}}
```

Доли исходного кадра. Полезно, когда важен только терминал или одна панель.

## Один проход, не склейка кусков

Каждый интервал раскладки делает собственную масштабированную копию источников и
композитится через `enable='between(t,a,b)'`. Интервалы не перекрываются по времени,
поэтому все живут в одном графе. Альтернатива — рендерить каждый интервал отдельно и
склеивать — перекодирует всё видео по разу на интервал, и именно это делает работу с
длинным туториалом медленной.

Предел — 40 интервалов на проход. Больше — режь таймлайн и рендерь частями.

## Звук

Один источник становится голосом, второй — тихим и задакированным. Захват экрана
обычно держит звуки интерфейса, которые стоит оставить около −18 дБ, но его микрофон
хуже камерного и не должен становиться голосом.

Дакинг второго источника под голос оставляет щелчки интерфейса и убирает
гребенчато-фильтрованный дубль речи из второго микрофона.
