Доброго времени суток всем антропоморфным читателям Хабра! Если вы совершенно случайно тут оказались и совершенно не понимаете о чём идёт речь, то категорически советую ознакомиться со статьёй @AndrewKuprin, которая неплохо объясняет общие принципы оцифровки подобного плана и чем она отличается от «традиционной». По просьбе Андрея я добавил в заметку несколько пунктов, а вообще надеемся на продолжение банкета ближе к лету 🤙
Так получилось, что почти весь материал имеет англоязычное происхождение и мне тяжело писать/говорить по-русски на некоторые темы. По этой причине все не переведённые слова, аналоги которых в русском я не знаю, будут по возможности снабжены ссылками на вики. Несмотря на «средний» уровень сложности, я постарался дать как можно больше расшифровок для сокращений. Для сохранения общей целостности, практически все наименования величин даны на английском.
Везде, где возможно, я постарался расположить вопросы, рассматриваемые в частях так, чтобы сложность постепенно росла по мере приближения к следующей логической части…
Кому НЕ подойдёт VHS Decode
Хочется начать данную заметку с небольшого дисклеймера – перечисления, кому VHS Decode не подходит.
На первом месте, внезапно, окажутся люди, занимающиеся архивной оцифровкой ТВ архивов в странах, где использовалась система цветности SÉCAM. К сожалению, на момент написания этого текста полноценно реализованного декодера SECAM не существует (как для direct color, так и color under форматов), а даже текущий вариант MESECAM (где используется гетеродинная запись цвета, а не делители как во «френче») далёк от идеала (насколько мне известно, компенсатор выпадений работает только по яркости) и не имеет явных киллер-фич по сравнению с «традиционным» захватом.
На втором месте – те, кто видит в декоде способ быстрого заработка. В текущей ситуации стоимость часа с учётом трудозатрат и скорости декодирования не может опуститься ниже отметки примерно в 1000р. Возможно для кого-то это будет открытием, но типичным (95%+) клиентам всё равно на качество записи (иначе давно «вымерли» бы те, кто делают сгоны на DVD рекордерах без TBC), а цена в 1к/час приведёт в ужас любого обитателя бетонных джунглей (кроме нескольких городов).
Следующий отрывок может звучать высокомерно, но для успешного использования декода вам обязательно потребуются базовые знания аналогового видео (для постобработки), а также понимание примерного устройства магнитофона и основных принципов его работы (для корректной настройки под ленты/профилактики).
Пара слов о формате
В первом приближении VHS Decode ld-decode кажется чем-то новым и необычным, но это не так. Несмотря на такой нетрадиционный (для пользователя) вариант захвата, под капотом там нечто, сильно черпающее вдохновение* у композитного формата 4fsc, который использовался в цифровых системах D2 и D3. Само название 4fsc как бы намекает, что сэмплирование происходит с частотой в 4 раза выше частоты поднесущей (4 times sub carrier), что означает ~14.3MHz для NTSC и ~17.7MHz для PAL.
* несмотря на схожесть, формат не является полностью совместимым.
Nerd only
В PAL ld-decode используется ортогональное сэмплирование и длина строки 1135px вместо 1135 + 4/625. 4/625 появляются из-за наличия одной 1137px строки на каждое поле (на линиях 313 и 625)
Таким образом выходит, что для конечного пользователя нет никакого rocket science, и те же данные находятся просто в другом представлении. Сильная сторона ld-decode в том, что он даёт возможность работы с целым полем, а не только с видимой областью, и позволяет делать тонкую настройку при декодировании/в посте благодаря высокой «пластичности» источника.
Необходимые инструменты
Несмотря на кажущуюся сложность вхождения, процедуры подготовки видака и деплоя выбранного захвата не вызовут трудностей при внимательном прочтении вики.
Совершенно не лишним будет наличие неплохого сетапа (TBC + кадровый синхронизатор) для «традиционного» захвата чтобы контролировать происходящее, однако сборка подобного – это уже совсем другая история…
Для успешной сборки системы захвата и модификации магнитофона вам обязательно потребуются мультиметр, паяльная станция (либо паяльник с контролем температуры), а также осциллограф (хотя бы цифровые 2 канала с полосой выше 20MHz). Последний крайне желателен для первоначальной отладки, а также донастройки видеомагнитофона.
Осциллограф – это тот инструмент, который сохранит ваши нервные клетки и предотвратит выкипание мозговой жидкости при попытках отладки «вслепую».
Положение точки переключения видеоголовок (headswitch) также лучше всего контролировать через осциллограф. Для наиболее чистого захвата необходимо сдвинуть точку переключения (физически, путём поворота статора БВГ, или с помощью PG shift) так, чтобы она находилась под последней видимой строкой. Таким образом при оцифровке оригиналов (при перезаписи всё равно наложится headswitch воспроизводящего магнитофона) вы получите полностью чистый от помех кадр.
Важно не переусердствовать и не залезть в КГИ (VBI), что приведёт к сложностям при декодировании.
Кроме этой очевидной причины, осциллограф также критически важен при индивидуальной подстройке траектории ленты. Эта подстройка заключается во вращении (выставлении по высоте) P2/P3 постов и нацелена на получение максимально равномерной отдачи с ленты, что увеличивает С/Ш на краях полей и снижает риск появления артефактов на Hi-Fi дорожке (с её крайне примитивным компенсатором выпадений).
Процедуры выше прекрасно описаны в сервис-мануалах магнитофонов, так что настройка своей деки не составит труда.
Выбор видеомагнитофона
Практически все «новички в декоде» считают, что любой ВМ подойдёт в качестве основного – и их можно понять: метод отличается тем, что обходит внутренние блоки обработки и позволяет сделать практически точную копию записанного на ленте.
Возвращаясь к вопросу: «можно ли использовать любой магнитофон?» – однозначно НЕТ, и ниже я приведу причины такого ответа.
Перед покупкой ВМ необходимо оценить его по ряду критериев:
Наличие физических неисправностей (в том числе скрытых)
Хороший захват невозможен на частично неисправном магнитофоне. Это касается и специфичных вещей, вроде отсутствия щётки для снятия статики с БВГ, что приводит к появлению точек на изображении (привет Philips VR355 и 897 на механизмах JVC)Удобство и скорость использования
Предпочтительнее «быстрые» механизмы, так как вам придётся отсматривать ленты на ускоренном воспроизведении до захвата, чтобы потом сэкономить время (отмечая ненужные врезки, смены систем цветности, режимов и т.п.)Качество линейного (linear) аудио
Самый недооценённый пункт. Однако без него невозможна хорошая оцифровка бытовых лент, где FM аудио (Hi-Fi режим) практически не встречается. Вам необходимы максимально возможные полоса пропускания и SNR. Линейная дорога – это не то, что можно легко «поправить в посте» без применения сильного шумодаваЛёгкость доступа к точкам с аудио/видео FM сигналом
Тут всё очевидно: вам необходимо найти на платах необходимые точки (на некоторых поздних деках FM аудио вообще может не появляться в открытом виде) и оценить, насколько легко оттуда можно вытащить сигнал.Качество УВ видеоголовок и возможность его работы в нагрузку 75Ohm.
Здесь вас интересует высокий SNR (С/Ш), а также потенциальное поведение предусилителя в низкоомную нагрузку (если не предполагается использование внешнего усилителя с согласовани��м). Да, можно использовать TBC stacking, но это в корне неверный подход к решению проблемы (лечение симптомов, а не причины)
Возникает закономерный вопрос: а как же выбрать из сотен моделей? Я не знаю, лол. Скажу больше – никто не знает…
Лучше всего себя показывают деки из середины/конца 90-ых, кроме JVC (это прям no-go в комьюнити декода). В плане высокого SNR и адекватной работы в низкоомную нагрузку хорошо показывают себя деки Sony. Более поздние модели обычно являются удешевлёнными кусками фольги и пластика (что неудивительно). Всё ещё осложняется тем, что внутри европейской модели может оказаться совсем отличающаяся (от «нашего» варианта) начинка (привет Panasonic с Z/R4 мехами), поэтому нельзя спереть выборку лучших от зарубежных коллег.
Для примера приведу свой Panasonic NV-HV60EE, который способен выдавать ~43dB SNR с внешним предом, в то время как более ранний SD400EU без особого напряга выдаёт столько же при прямом подключении (200mV против 1.6V). Особенно страдает линейное аудио, про которое производители полностью забыли с приходом 2000-ых.
Для понимания масштабов проблемы я приведу свои же графики измерения АЧХ (при записи «в себя») линейной дорожки в SP режиме для нескольких совершенно разных магнитофонов – как по функционалу, так и по цене.
Как можно видеть, в некоторых случаях SP настолько мусорный, что не отличается от LP на хороших ВМ. Ниже приведён «относительный шум» (т.е. шум при одинаковой громкости на всех магнитофонах).
Как выясняется, не такой уж плохой по АЧХ SR55 оказывается совершенно негодным для использования из-за леса наводок в линейном тракте. Даже HV60 неприменим из-за высокого собственного шума, который хорошо слышен при воспроизведении.
Даже Hi-Fi режим имеет свои «особенности», которые я обнаружил при измерении 5 видеомагнитофонов, поэтому для действительно архивного копирования целесообразнее использовать Hi-Fi Decode.
Вот так мы и подошли к теме выбора устройств захвата для этой кучи декодов…
Грабберы
Актуальные данные в этой части меняются чаще, чем настроение у среднестатистической лисы, поэтому обязательна сверка на сервере Domesday (в одной из запрещённых соц. сетей), а также консультация с вики.
Для начала нужно обозначить, что в подавляющем большинстве случаев вам будет требоваться выделенный предварительный усилитель для согласования нагрузки в виде 50/75Ohm входа АЦП и предварительного усилителя видеоголовок. Сейчас для подобного используется двухканальный пред на ADA4857 от Rene Wolf. Совсем недавно появилась идея JFET-буфера, который потенциально будет проще и дешевле в изготовлении, однако на момент написания статьи существует лишь прототип от пользователя MarcA(NZ). От буфера требуется:
Находиться близко к источнику
Быть «невидимым» для источника
Обеспечивать согласование источника и приёмника
На текущий момент имеются 2 основных подхода к решению доставки сырых данных АЦП в систему: непосредственный захват платой или захват промежуточным устройством с передачей сигнала, обёрнутого в HDMI поток (HSDAOH). В обоих случаях используются кастомные драйверы, позволяющие делать вычитку сырых данных и последующий их пайпинг в ffmpeg/flac/etc. для сжатия/даунсэмплинга. Domesday Duplicator (DdD) мы вообще не рассматриваем, т.к. он слишком дорог и неудобен для захвата VHS и прочих бытовых ленточных форматов.
Представителями первого подхода являются платы на определённых чипах Conexant CX, далее CXADC. На данный момент это самый простой и бюджетный вариант «вкатиться» в декод, так как цена в 18$ и доступность уже собранных плат перебивают их минусы (а их несколько). Для плат этой категории доступен ряд модов, таких как заглушка входов (для увеличения SNR), а также замена кристалла с 28 на 40MHz (для увеличения SNR и уменьшения искажений). Проблема дрифта аудио (из-за разных источников тактирования) в таком случае решается либо ручной/автоматической подгонкой дорожек, либо апгрейдом до Clockgen, который представляет собой систему из одной или более CXADC, тактированных вместе с аудио АЦП от DDS генератора с помощью Pi Pico.
Следующую группу представляют сразу два крайне похожих продукта: 12 бит АЦП, построенный на Pico 2 и его вариации, а также MISRC, в разработке которого участвуют контрибьюторы VHS Decode. Оба продукта имеют теоретические и практические преимущества над CXADC/Clockgen подходом (и я это говорю как пользователь последнего): более низкий уровень шума за счёт 12 бит квантования и лучшего аналогового frontend’а + лёгкость интеграции (необходимость только в USB и 0 последующих модификаций). Интересной особенностью HSDAOH варианта также является отслеживание и сигнализация о пропущенных сэмплах, чего нет в случае CXADC…
Для MISRC в настоящий момент разрабатывается GUI софт с поддержкой realtime даунсэмплинга (официально пока он присутствует только для FM Hi-Fi на 40->10MSps, а конверсия из 40MSps для видео происходит «на свой страх и риск») и мониторинга. Т.к. фундаментально оба подхода производят одинаковые по структуре данные, то портирование графического приложения под CXADC не должно составить труда.
Несмотря на подобные различия в архитектурах, от любого захвата требуется высокий SNR и наличие anti-aliasing фильтра (привет граббер на Pico 2). Именно по этой причине СXADC платы тактируют от 40MHz, а потом в цифровом домене делают даунсэмплинг до 16/20MSps (8/10MHz полосы соответственно), ибо встроенный AA фильтр обеспечивает слабое подавление.
В реальности, в VHS RF сигнале полезный спектр заканчивается на отметке в ~6.5MHz, что вполне согласуется с теоретическими выкладками.
Многие уже увидели в этом возможность ускорить процесс путём отрезания «ненужного», и они абсолютно правы.
Возможности ускорения
На момент написания статьи ускорение достигается следующими способами:
Параллельное декодирование
Несколько процессов декода запускаются параллельно, таким образом используя все потоки CPU. Каждый процесс при этом должен использовать не более четырёх потоков для достижения максимальной скорости. ld-decode архитектурно не способен к полноценной многопоточности из-за последовательной природы декодирования/TBC и слабой оптимизации FFT-преобразований под многопоток.Даунсэмплинг
У данных 40/28.6MSps понижается частота дискретизации до 16/20MSps (в зависимости от полосы формата) и декодирование производится с флагомno_resample, который пропускает внутренний апсэмплинг до 40MSps (при этом точность ресэмплинга линий в блоке TBC незначительно падает). Понижение частоты дискретизации также важно при хранении, так как в сочетании с компрессией приводит к существенному уменьшению размера файловИспользование специальных флагов
В случае наличия одинаковых по природе записей (сделанных на одном магнитофоне) имеет смысл пробовать добавление флагаuse_saved_levels, который пропускает часть кода для определения уровней импульсов синхронизации (sync pulses) в КГИ (VBI), а также СГИ (HBI)Bit crush
Если мы не используем старший(е) бит(ы), то можно без зазрения совести нормализовать общий уровень так, что младшие биты отсекутся при переходе в 8 бит формат. В исключительных случаях допускается уменьшение глубины квантования вплоть до 6 бит без значительного падения качества изображения. В первую очередь это актуально для 10/12 бит захватов, где не весь динамический диапазон может быть задействован
Все варианты, кроме параллельного декодирования, следует применять только с пониманием того, что именно они делают, и исключать даже потенциальную порчу материала (читаем - потерю вашего времени)
Постобработка
Этот раздел посвящён порой неочевидным моментам, которые полезно знать при работе с декодом. Вы и без меня, наверное, знаете про отличия limited и full уровней, деинтерлейсинг, а также структуру кадра с его VBI, HBI и прочими словами из трёх букв.
Начать хотелось бы с простого, а именно – небольшой напоминалки про цифровые стандарты видео. В случае трансфера аналогового видео нам крайне желательно иметь на выходе rec.601 совместимый файл, т.е. как минимум limited уровни, правильное (для стандарта) разрешение, а также цветовой охват (gamut). Именно последний пункт нас интересует больше всего, так как в части софта, ручная настройка цветового охвата затруднена/спрятана от глаз юзера.
Хочется заострить внимание на Davinci Resolve, который вообще не умеет работать в rec.601 PAL… Самое забавное то, что он прекрасно понимает затеганный rec.601 и делает автоматическую трансформацию цветового пространства при импорте, однако не позволяет создавать rec.601 таймлайн. На форумах Blackmagic писали, что rec.601 экспорт начинает работать правильно если создать PAL/NTSC таймлайн, но на моих кодеках подобное не прокатило( В текущий момент Resolve умеет выводить только rec.601 видео в цветовом охвате NTSC (SMPTE-C), но не PAL...
Нужно понимать, что такая конверсия не является чем-то запрещённым или публично осуждаемым, однако, любые поползновения в сторону от стандарта убирают совместимость, которая важна для архивного хранения/вывода и т.п. Некоторые софтверные плееры (типо VLC) вообще не обращают внимание на теги и принудительно интерпретируют видео только по его вертикальному разрешению.
Несмотря на большую степень интеграции инструментов в пакете и использование .json для хранения метаданных, тип декодера цветности (chroma decoder) и его параметры необходимо вводить вручную при вызове tbc-video-export.
По умолчанию используется декодер PAL2D, что само по себе не является плохим решением. Однако даже для бедных по полосе цветности color-under форматов вроде VHS и S-VHS может оказаться полезным применение Transform 2D декодера с ручной настройкой порога.
Говоря простым языком: чем «круче» декодер, тем больше деталей яркости (Y) удаётся отделить от цветности (C).
Стандарт VHS/VHS HQ подразумевает Y/C разделение при помощи простых ФНЧ/ФВЧ (low-pass/high-pass) фильтров. В SVHS к этому добавляется логический гребенчатый фильтр (logical comb filter), который используется (или не используется) в зависимости от фазы записанного на ленту пилот-сигнала. Этот сигнал присутствует только в SVHS и служит индикатором качества композитного источника.
На практике настройка порога декодера предельно проста: необходимо включить отображение только хрома-составляющей (C), выбрать нужный декодер и перемещать ползунок порога до тех пор, пока на изображении не исчезнут цветовые артефакты. Для большей простоты можно выставить отображение только одного поля, а не кадра, чтобы не мешал эффект интерлейсинга (чересстрочности).
Успешность разделения напрямую будет зависеть от качества записи и возможны случаи, когда более продвинутый декодер окажется бесполезным. Необходимо также заметить, что бо́льшая цифра != лучшее декодирование. Transform 3D (также известный как BBC Transform PAL Decoder), являющийся лучшим PAL декодером (и существующий в железе в количестве <20 штук) предназначен в первую очередь для более качественных композитных источников, таких как D2/D3.
После определения подходящего декодера и опционального значения порога необходимо будет записать/запомнить эти значения, а потом использовать соответствующие флаги при вызове tbc-video-export.
Перед следующим пунктом полезно вспомнить последовательность приведения материала bt.601 к квадратным пикселям для публикации в соцсетях и других современных платформах.
Согласно EBU R92-1999 видимая строка занимает 720px по горизонтали, из которых только 702 несут в себе полезное изображение (active picture). Для bt.601 корректный PAR составляет 128:117 (
), что эквивалентно преобразованию 702->768 (768x576) или 720->786 (786x576) для получения квадратных (PAR 1:1) пикселей.
Для распространения на торрент трекерах или создания "правильных" SD файлов итоговый вариант либо кропят до 704 с PAR 12:11 (кодеки плохо дружат с 702 так как оно не делится на 8 или 16), либо оставляют 720.
Одна особенность экспорта буквально вывела меня из себя: по умолчанию для вывода используется длина строки, равная 922px, что аналогично 702 для bt.601… Если не знать о таком приятном подарке, то при любом ручном перегоне в известное разрешение у вас получатся неправильные пропорции (будет установлен некорректный PAR).
Тут нужно немного отвлечься от непосредственного экспорта и посмотреть на структуру цифровой строки: длина digital active line в системе 4fsc равна 948px, но при этом аналогом 720px для bt.601 будет являться длина в 946px (да, именно так).
Любой здравомыслящий человек (или лиса) будет ожидать, что вывод по умолчанию производится с длиной строки, аналогичной 720px (которая является стандартом и выдаётся почти любым захватом). Таким образом, для создания bt.601 compliant файла нам сразу лучше сделать конверсию 946->720px, чтобы избежать проблем с совместимостью.
Пример выше был записан с шириной активного изображения в 720px, поэтому 8px по краям могут быть обрезаны на «традиционных» захватах.
* - см. спойлер
Nerd only
Формат 4fsc по EBU 3280 не имеет стандартизированного начала строки, поэтому на фрагменте левой части 0H – начало аналоговой строки может не совпадать с началом total digital line. В workflow ld-decode за начало цифровой строки принято начало аналоговой строки – 0H, что максимально логично.
* - в 4fsc формате, также как и в bt.601, нумерация сэмплов начинается с digital active line и получается, что технически HBI, куда входят front/back porch, hsync и burst (PAL/NTSC), текущей строки «принадлежит» предыдущей total digital line (так как он занимает сэмплы 948-1134). В ld-analyse это показывается в более человечном формате, где начало total digital line – это тот самый конец (948-1134) прошлой цифровой строки
Вывод???
Надеюсь, что эта заметка заран��е ответила на некоторые вопросы, которые так или иначе возникнут у новичков. Несмотря на все минусы, ld и vhs-decode являются крайне мощными и уникальными инструментами. Нужно ли это всем? Отнюдь. В первую очередь это – инструмент для создания максимально точных копий ленты с упором в функционал, а не простоту использования.
Хочется думать, что в ближайший год-два наконец-то реструктурируют вики и добавят отдельный «путь» для новичков, а также решат вопрос с SECAM декодером. Как минимум, Win инструменты для захвата, а также GUI версии потихоньку выходят в релиз и недавно в очередной раз поднимался вопрос о переносе вики в отдельный репозиторий (для возможности простого предложения правок).
P.S. Если у кого-то появится желание поболтать на тему декодирования, то меня можно найти по этому (r3dfx) нику в Discord (запрещён) или Telegram (скоро будет запрещён)
