Upload DESCRIPTION.txt
Browse files- models/DESCRIPTION.txt +50 -0
models/DESCRIPTION.txt
ADDED
|
@@ -0,0 +1,50 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
[GENERAL]
|
| 2 |
+
|
| 3 |
+
SSLZip представляет собой пост-процессор для признаков self-supervised speech моделей (в даннном случае, HuBERT Base). Он берёт последовательность скрытых состояний HuBERT размерности 768 и прогоняет через простой автоэнкодер, выдавая более компактный латентный код (16 или 256 каналов). Цель: сжать признаки и одновременно выкинуть из них информацию о спикере, оставив в основном фонемно-контентную и часть просодической информации.
|
| 4 |
+
SSLZip работает только с признаками, уже извлечёнными upstream-моделью.
|
| 5 |
+
|
| 6 |
+
[PAPER]
|
| 7 |
+
|
| 8 |
+
По статье авторов, логика такая:
|
| 9 |
+
> Автоэнкодер обучают восстанавливать исходные SSL-признаки; узкое "бутылочное горлышко" вынуждает латенту хранить только важное (контент), а менее важное (speaker id) теряется;
|
| 10 |
+
> Опционально добавляют CLUB-лосс (Contrastive Log-ratio Upper Bound) - это взаимная информация между латентой и меткой спикера, которую во время обучения минимизируют через дискриминатор спикеров, это дополнительно "выдавливает" спикера из латенты.
|
| 11 |
+
|
| 12 |
+
[USE CASES]
|
| 13 |
+
|
| 14 |
+
1. Универсальная "контент-лента" для инфилинга
|
| 15 |
+
|
| 16 |
+
В процедуре инфилинга речи, если использовать HuBERT/WavLM-признаки напрямую (768-d), в них заметно сидит идентичность спикера. Это мешает, когда требуется вырезать/вставить слова, а затем синтезировать их в другом голосе: генератору нужно "разучиться" слышать оригинального спикера в контент-коде. SSLZip как раз создан для снижения speaker leakage.
|
| 17 |
+
|
| 18 |
+
2. Снижение размерности = меньше вычислений и памяти
|
| 19 |
+
|
| 20 |
+
768->16 или 768->256 уменьшает нагрузку на всё после энкодера: хранение промежуточных представлений, скорость обучения/инференса downstream моделей (VC/TTS/patch-генераторы). Это особенно важно, если требуется делать многодорожечные монтажи и хранить кэши латент.
|
| 21 |
+
|
| 22 |
+
3. Более стабильная работа на "сборных" аудио речи
|
| 23 |
+
|
| 24 |
+
Если downstream модель видит более инвариантный контент-код, ей проще обобщать на разные голоса и стили, а значит меньше артефактов при склейках между спикерами. Это основной мотив статьи.
|
| 25 |
+
|
| 26 |
+
4. Потенциальная просодическая полезность (ограниченно)
|
| 27 |
+
|
| 28 |
+
256-мерная латента обычно сохраняет больше нюансов (интонации/темпа), чем 16-мерная. Но это палка о двух концах: часть этих нюансов может оказаться tied к спикеру. В таких кейсах, где "голос" обычно задаётся отдельно, например в композиции речи из фрагментов речей разных спикеров, лишняя просодика в контенте может вредить.
|
| 29 |
+
|
| 30 |
+
[ONNX MODELS]
|
| 31 |
+
|
| 32 |
+
Характеристики:
|
| 33 |
+
> SSLZip-16-CLUB: вход [B, T, 768], выход [B, T, 16]
|
| 34 |
+
> SSLZip-256: выход [B, T, 256]
|
| 35 |
+
> SSLZip-256-CLUB: выход [B, T, 256], но обучено с CLUB-лоссом
|
| 36 |
+
|
| 37 |
+
В статье авторы прямо показывают компромисс:
|
| 38 |
+
> 16-мерный вариант даёт почти ту же натуральность речи, что и более тяжёлые варианты, и даже лучший DMOS, потому что спикер "естественно" вылетает через узкую латенту.
|
| 39 |
+
> CLUB-обучение улучшает именно случаи, где нужно сильнее убрать спикера (например cross-gender VC), но в среднем не всегда превосходит базовый SSLZip по натуральности.
|
| 40 |
+
|
| 41 |
+
Выбор под задачу:
|
| 42 |
+
> Если нужен максимально "контент only" код для патчинга/VC и склеек (а голос, стиль, эмоция задаётся другими каналами/эмбедами), то следует использовать SSLZip-16-CLUB.
|
| 43 |
+
Минимальный размер, максимальная инвариантность к спикеру, по статье 16-d достаточно для качественной генерации и даёт лучший баланс в сложных случаях.
|
| 44 |
+
> Если downstream-генератор опирается на сам контент-код ещё и для части просодики/стиля (например, когда нет отдельного style-encoder или требуется меньше "плоской" речи), то логичнее использовать SSLZip-256-CLUB
|
| 45 |
+
Это компромисс: больше информации + попытка подавить спикера. Согласно статье авторов, CLUB помогает именно там, где обычный 256 чуть "тащит" голос.
|
| 46 |
+
> SSLZip-256 без CLUB имеет смысл только если вы сознательно хотите сохранить больше исходной информации HuBERT и готовы мириться с большей долей speaker leakage. Для реализации композиции речи из фрагментов речей разных спикеров это выглядит хуже двух вариантов выше.
|
| 47 |
+
|
| 48 |
+
------------------------------
|
| 49 |
+
ИСТОЧНИК: https://www.isca-archive.org/ssw_2025/yoshimura25_ssw.pdf (SSLZip: Simple Autoencoding for Enhancing Self-Supervised Speech Representations in Speech Generation)
|
| 50 |
+
|