СРАВНИТЕЛЬНЫЙ АНАЛИЗ ПРОГРАММ EDIT* И LIQUID CHROME
Читатель вправе задать вопрос – почему для сравнения взяты именно эти программы?
Вроде бы Edit* уже два года как «закрыт», чем существенно отличается от активно
развивающегося Chrom’a. Так стоит ли «бить лежачего»?
Сразу хочу предупредить – бить автор никого не собирается, а целью данного материала
ставит выявление хороших сторон (слабые – они сами вылезут) у обоих софтов.
Edit* имеет широкое распространение, как в столице, так и в регионах. Если система
способна решать поставленные задачи, то нормальный производственник вряд ли
будет менять ее только потому, что она «вышла из моды». К тому же многие вещи,
которые были заложены в Edit* сначала фирмой DVision, а потом и Discreet, еще
долго будут вспоминать монтажеры, которым приходится пересаживаться на другие
программы для видеомонтажа.
А что касается Edit* и конкретно Liquid Chrome, то у них есть одна общая деталь
– «железо». Последняя версия Edit* устанавливалась с платой TARGA-3000, которая
является базой и для Liquid Chrome. С некоторой натяжкой можно найти и вторую
«общую деталь» - общая ценовая категория. Такие программные продукты принято
рассматривать особенно тщательно. В июньском номере журнала «625» вы можете
найти практическое сравнение алгоритмов работы в Edit* и Chrome на примере сюжета
для новостей. Сейчас же поговорим об особенностях интерфейсов, не имея цели
искать, кто лучше, а кто - хуже. Просто автор, после нескольких лет работы на
Edit* стал переходить на Chrome и в результате имел ряд проблем «идеологического»
характера. Поэтому очень хочется помочь коллегам, которым, вполне возможно,
предстоит совершить аналогичный шаг. Для остальных данный материал будет поучительным
туром для расширения кругозора.
Итак, задачи обеих программ – монтаж исходников с качеством, максимальным для
платы TARGA-3000. Несмотря на различные расширения в формируемых файлах – avi
и 2vuy – с изобразительной точки зрения они совершенно одинаковы. Это чтобы
отсечь «идеи фикс» по поводу «улучшения» картинки за счет работы в Edit* или
Chrome. Вся разница только в интерфейсе и алгоритмах получения задуманного результата.
Ну еще, может, в наборе базовых эффектов – переходов и фильтров. Некоторые из
них, подобно цветокорректору, относятся к пост-обработке исходника, что улучшает
не только технические показатели, но и художественную целостность конечного
продукта. Но как ни крути, это не «монтаж», а больше «функция, доступная в монтажной
программе». Edit* и Chrome будут по-разному позволять данным инструментам вмешиваться
в исходный материал. И вообще оговорюсь, что буду отдельно разбирать эффекты
«железячные» (в т.ч. «софтово-аппаратные») и возможности подключения plug-in’ов,
потому что за первые отвечает производитель монтажного софта. Значит, и спрос
строже…
Модули или «форточки»?
Итак, первые особенности интерфейса видны даже «невооруженным» взглядом. В
Edit’е вас встречает обычная оконная структура, подправленная четырьмя пресетами,
которые можно редактировать и потом менять горячими клавишами (одно из немногих
удобств, добавленных в программу «напоследок», в последней версии 6,5). Масштабирование
мониторов несколько затруднено – подтормаживает реакция программы. Получить
два окна одинакового размера можно, но придется потрудиться.
Работа в Edit* ориентирована на двухмониторный Рабочий стол.
На одном мониторе работать можно, если активно пользоваться переключением между
пресетами, но в список «запоминаемых» окон не попадает библиотека эффектов.
Меняешь вид – и оно аккурат перекрывает активную зону. Приходится её всё время
закрывать. Аналогичная беда с некоторыми другими элементами интерфейса (аудиомонитор,
отчасти аудиомикшер). Кроме того, если вы расположите рядом три библиотеки,
смена вида соберет их «стопкой».
К единственному плюсу оконной структуры я могу отнести только возможность одновременно
держать открытыми несколько монтажных последовательностей для сравнения версий
или копирования клипов.
Интерфейс программы Liquid базируется не на окнах, а на модулях, жестко привязанных
к монитору поверх Рабочего стола. Рабочий стол, в свою очередь, способен размещать
на себе иконки библиотек и клипов - по аналогии с Рабочим столом Windows. В
форме окон можно открыть только Главное окно Проекта, Паспорт клипа, Проигрыватель
клипов, Аудио монитор и Библиотеки (если делать это из иконок на Рабочем столе).
Эти окна запоминают свое последнее расположение. Все рассчитано на то, что библиотеки
не могут оказаться поверх модулей. Последние, открывая все необходимое для работы,
исключают загромождение Рабочего стола. А библиотеки, оказываясь под модулем,
сохраняют свое положение, чтобы вы, вернувшись к прежнему виду, нашли их на
том же месте.
Перечень видов расположения модулей рискну назвать исчерпывающим: они автоматически
учитывают, сколько компьютерных мониторов – один или два, обслуживает программу,
и, соответственно, состав списка меняется.
Модульная структура требует от разработчиков гораздо большей продуманности интерфейса.
Здесь на хромой козе… Это как раз в другом случае можно «услышать»: «Мы вам
инструмент дали? – Дали... Ну а располагать его уж как-нибудь сами. Что?.. Мешается!?..
Так закройте!..» - ну и т.п. Стоит признать, что в Chrome модули вполне удались.
Особенно вариации с монтажной секцией, когда в Проекте меняешь пропорцию кадра
(4:3/ 16:9). А специальный Проект-менеджер, открываемый на участке Монтажной
последовательности, сжимая её вправо, - быстро становится незаменимым помощником
при работе в одномониторном режиме. Из него не только удобно вызывать клипы
в просмотровое окно, не меняя вида модулей, но также можно переносить объекты
мышью сразу на треки – ширина таймлайн при этом может регулироваться «по вкусу»
(мышью за разделительную линию).
В этой хвалебной оде все же найдется «ложка дегтя»: окна Clip
Properties (Паспорт клипа) и аудио монитор не встраиваются в Монтажный модуль,
занимающий обычно полный размер одного компьютерного монитора, и вынуждены что-либо
закрывать. Работа в двухмониторном режиме не улучшает ситуацию. Подходящее место
для них все равно найти очень трудно. Вы будете ощущать дискомфорт от необходимости
их постоянно закрывать. А долго держать открытым Clip Properties вообще не получается
– его присутствие приводит к странным "затыкам": вдруг клип перестает
отвечать на команду Play, или дроп-меню не открывается и т.п.
Работа с медиаданными.
То, как программа формирует и обслуживает свою базу данных, порой перевешивает
многие «эффектные» возможности того или иного программного продукта. Проекты,
находясь в работе по нескольку месяцев, должны выдерживать переустановки Windows,
некачественные исходники и настоящую карусель из переплетений медиа, полученных
как из соседних Проектов, так и от других компьютеров, работающих над тем же
Проектом. Поэтому позвольте мне подробнее коснуться этой темы.
Edit*.
Его подход к структуре медиаданных тесно связан с понятием
«метадата» как уникальной основы для того или иного клипа. На схеме показано,
как материал с видеокассеты воспринимается программой.
Клип – рабочий элемент программы. Каждый клип
адресуется ко всему медиа (Метадате): Clip In/ Clip Out всегда равны Media In/
Media Out. Внутри он может иметь метки входа/ выхода, которые используются для
ограничения зоны воспроизведения или переноса на таймлайн. Копия клипа становится
самостоятельным элементом: там можно менять положение меток и содержание текстовых
строк.
Метадата – обобщенное понятие для служебной
информации к группе файлов, представленных одним клипом. Поскольку она хранит
таймкоды исходников и номер кассеты, информацию о скачках таймкода и проч.,
медиафайлы без нее в Edit'е перестают восприниматься, а будучи импортированы
с диска – действуют разрозненно и имеют только файловый таймкод (отсчет от ноля).
Медиафайлы – непосредственно файлы (расширения
avi, wav и другие, которые проигрываются программой без пересчета в другой формат).
На что я особо хочу обратить внимание:
для Edit*’а «единицей отсчета» служит именно Метадата. От
Метадаты направляются стрелки подчиненности к клипам, а не наоборот, как может
показаться в процессе работы.
Попробуйте сдвинуть границы клипа за пределы метадаты. Как это сделать? Да,
собственно, никак... Нет для этого инструментария! Даже переоцифровкой с установкой
дополнительных захлестов нельзя будет выскочить за рамки однажды назначенных
границ. А если вы махнете рукой и начнете цифровать новый файл, задав ему нужный
хронометраж, то здесь следует помнить – уже существующие в библиотеках клипы
жестко привязаны к своей Метадате. Поэтому ни библиотеки, ни Монтажные последовательности
обновляться не будут. Только операция Recapture (Восстановление) заставит исчезнуть
кресты на месте иконок. Повторение оцифровки (не Recapture) просто создаст в
базе данных новую Метадату и новую группу видео-аудио файлов, которая может
дать начало только новому семейству клипов. Вот и говорите, что метадата здесь
не первая скрипка!
Обратная сторона этой медали – хорошая. Например, сделаем переоцифровку смонтированного
сюжета, удалив исходные файлы. Новые короткие файлы «привяжутся» к метадате,
которая разложит их по своим местам подобно тому, как это делается во время
монтажа с клипами, когда их расставляют на временной шкале, перемежая кусками
черного поля. Таким образом, мы получим возможность, загрузив в Окно просмотра
исходника любой клип, прокручивать все файлы, которые относятся к данной метадате.
Выбрав масштаб отображения «File» (по смыслу точнее будет «Media» или "Metadata"),
можно включить воспроизведение и по очереди их просмотреть. Как только закончится
один файл и, пока не начнется другой, на экране будет отображаться «крест» с
надписью «Неизвестное медиа». И так можно дойти до конца кассеты, если изначально
вы ее цифровали или логировали целиком!
По такому же пути будет проходить воспроизведение, если не
удалять исходники - просто в качестве примера это было нагляднее. Например,
мы проводили черновой монтаж с компрессированными файлами, а переоцифровывались
в Uncompress. В таком случае вы получаете уникальную возможность даже после
переоцифровки спокойно вносить любые изменения в монтаж. Если вы потянете край
склейки на расстояние, превышающее размер заданных при переоцифровке захлестов,
у вас начнет на этих местах проигрываться черновое видео. По окончании работы
черновые участки можно автоматически найти и оцифровать в Uncompress. Ограничением
для подобной операции будет, опять-таки, только длина Метадаты.
Если переоцифрованную (фрагментами) метадату мы захотим просматривать в Окне
исходника, как это описывалось выше, то мы увидим непрерывный видео поток, у
которого скачками меняется качество. Если поставить метку In, то в паспорте
клипа можно увидеть, видео какого качества здесь приходится. Это будет показывать
и специальная колонка в библиотеке, но скачки качества внутри Mark In – Mark
Out в виде текстовых сообщений не отражаются... Только снова затребовав переоцифровку
для клипа или монтажной последовательности, можно в ней обнаружить, например,
закравшийся черновой фрагмент.
Оцифровка в Edit ведется на выделенный медиа диск в папку, по умолчанию носящую
имя Проекта. Сюда же поступают все просчетные файлы, но им можно указать иной
путь – индивидуально для каждого проекта. Вместе с видео может оцифровываться
до четырех аудио файлов (зависит от типа внешнего Breakout Box). Кроме того,
образуются еще служебные файлы, несущие информацию, например, о форме звуковых
колебаний, чтобы ускорить прорисовку на временной шкале в процессе монтажа.
Потеря этих служебных файлов несущественна, т.к. они возобновляются автоматически.
Обмен данными.
В специальном браузере – JobNet, который встраивается в Проводник Windows
и служит для навигации и обмена между проектами клипами и другими рабочими элементами
(библиотеками и монтажными последовательностями) – так вот в нем можно открыть
метадату и просматривать все слои медиа-«пирога» отдельно.
Информация библиотеки EDIT, представленная в JobNet посредством
иконок и текстовыми строками. Чем-то это напоминает структуру таймлайн в AfterEffects.
Именно отсюда можно проводить выборочное удаление, т.к. другой механизм предусматривает
лишь общее удаление, максимум – с сортировкой по качеству
Окно просмотра клипа (или таймлайн). Отсюда можно удалить ненужный
лаер.
В таком окне можно просмотреть отдельный лаер (т.е. отдельный
файл).
И несмотря на достаточно хорошую организацию окна сортировки,
данный модуль реализован в Edit с ошибкой: удаляет не более чем по 15 файлов
за один раз. Так что если возникло желание удалить файлы высокого качества,
образовавшиеся после переоцифровки Проекта, а оставить для работы «черновые»,
то процесс может затянуться: тысяча клипов еще не предел для обычной работы!
Порой думаешь, пользоваться ли этим окном, или сразу залезать в JobNet и удалять
слои вручную.
JobNet, призванный обеспечивать обмен данными между проектами как одной машины,
так и сетевые обмены, устойчиво справляется только с библиотеками и копированием
связанных с клипами файлов. Правда, окно для этого организовано не очень наглядно
- вместо копирования можно легко получить простой линк или вообще убить файл
"донора". А вот с Монтажными последовательностями явная недоработка
- стоит сделать что-либо сложнее простой склейки - и она может просто не открыться
в таймлайн-менеджере! Копирование файлов, имеющих внутри себя сбои по таймкоду,
- тоже головная боль для пользователя: переоцифровать такой клип невозможно.
В этот скорбный список, к сожалению, придется добавить еще одну ошибку, появившуюся
с версии Edit 6.0.
В результате сбоя таймкода, а порой и без явной причины, в медиа закрадывается
ошибка, жертвой которой может стать метадата. Тогда восстановление медиафайлов
или возможности их переоцифровки в Монтажных последовательностях будут существенно
ограничены, хотя во время работы вы не будет сталкиваться с какими-либо проблемами.
Только сравнивая информацию о файлах в библиотеке программы и в JodNet'е, можно
найти несоответствие. Ваш файл, имея между метками In/Out где-нибудь около получаса,
с точки зрения JobNet будет адресоваться к метадате... в три секунды! И беда
заключается в том, что только эти три секунды вы и сможете переоцифровать!
В результате, при работе с большим количеством кассет на черновом монтаже приходится
сверять полученные данные с JobNet и повторно вгонять спорные материалы.
Следуя логике построения базы данных Edit'а, если вы удаляете Проект, оставив
без изменения его медиа директорию, файлы внутри нее становятся "мертвыми":
для всех других проектов они не будут отличаться от обычных файлов с жесткого
диска и функция переоцифровки для них будет недоступна. Запомним этот момент,
т.к. в Chrome мы встретим совершенно другую картину.
Слабым оправданием некорректной работы JobNet'а может служить тот факт, что
очень долго, вплоть до четвертой версии, проекты Edit вообще были закрыты друг
для друга. Появление JobNet стало значительным облегчением - ведь это была одна
из первых систем сетевой работы среди монтажных программ рассматриваемого класса.
Но для нового пользователя такой набор недочетов уже может стать критичным при
выборе ПО - "сеть" становится чуть ли не обязательным атрибутом в
организации работы монтажных станций.
Chrome
Здесь погоду делает Клип и две его главные характеристики:
Clip In и Clip Out, а логическая схема построения базы данных кардинально отличается
от Edit’а.
Дело в том, что все кассеты Liquid Chrome оцифровывает в определенную
папку, которая прописана в специальном окне – Медиа Менеджере. При необходимости,
здесь указываются пути к другим медиа-директориям, в том числе сетевым, а также
права, распространяемые на содержащиеся там файлы (только чтение или чтение/запись).
Если в Edit все файлы проекта лежат кучей в «именной» папке, а их принадлежность
той или иной кассете прописывается только в специальном файле базы данных, где
закравшуюся ошибку отредактировать может только очень подготовленный пользователь,
то в Chrome все на виду: если что-то пошло криво, исправить ситуацию «ручками»
намного проще. Спросите - почему? Так ведь база данных Chrome - не что иное,
как набор структурированных папок в Проводнике Windows!
Внутри «базовой» FS_MEDIA_AV основную нагрузку
берет на себе папка Reels, которая группирует кассеты со всех
проектов Liquid Chrome. В конце имени папки вы обнаружите добавленный программой
цифровой код, а среди медиафайлов будет особый Индекс-файл с объемом 0 KB, который
на иллюстрации замыкает список файлов в правой части Проводника. Он будет подсказывать
программе, что права на папку сейчас закреплены за проектом «РЕПОРТАЖ».
Распознование программой кассет с одинаковыми именами.
Цифровой код в конце названия кассеты поможет программе понять,
что другая папка, имеющая такой же индекс-файл "РЕПОРТАЖ", будет принадлежать
уже другому Проекту - ведь было бы крайне неудобно пользователю иметь какие-либо
ограничения на имена - в работе бывает всякое... Скопируйте индекс-файл и подставьте
цифровой код - и "чужая" кассета станет "вашей"! С такой
двойной защитой вы можете вести одновременно несколько Проектов на одной машине
- путаницы в кассетах не будет! Имея прописанные в Медиа менеджере сетевые пути
к медиа папкам, вы сможете легко открывать Проекты даже находящиеся в работе
(!) (т.е. в данный момент открытые) на других компьютерах. Если скорости сети
позволят - вы проиграете содержимое клипов и смонтированные фрагменты. Или сможете
помочь коллеге - не прерывая его работы, сделаете исправления в монтаже. И откуда
только пошло мнение, что база данных - это что-то супер сложное? Если только
вы не столкнулись с такой ситуацией:
Клип продолжает поддерживать адресацию к исходной проектной
папке до тех пор, пока не попадёт на Пакетную переоцифровку !
Новый клип будет адресоваться к кассетной папке текущего проекта и запись в
Паспорте клипа будет отредактирована. Когда кассеты в телекомпании имеют единую
нумерацию, этого избежать легко. В других случаях спасает пара- тройка первых
букв от названия Проекта, добавленная к номеру кассеты. Заодно это поможет,
если вы захотите измерить объем занятого Проектом дискового пространства. Медиаданные
хоть и раскиданы по нескольким папкам, но самые объемные файлы, как правило,
оказываются здесь.
Окно, аналогичное по форме с Проводником Windows, но находящееся
уже внутри программы (имеется в виду закладка Media Основного окна Проекта),
позволит вам увидеть эти же папки-кассеты, но сгруппированные по именам проектов.
Представленная здесь информация не принадлежит Проекту (т.е. не
запоминается в файл Проекта Liquid Chrome), но им структурируется и отслеживается
в "реальном времени". Например, кассета «№5» оцифровывалась кусками
сперва на диск D, а потом на диск E, но в закладке MEDIA вы будете общаться
с одной виртуальной папкой кассеты «№5», объединяющей информацию
со всех дисков.
Программа считывает только коды,
добавленные к именам папок в Проводнике Windows. Кассеты с одинаковым кодом
группируются в одну папку в закладке Media. Название для корневой папки берется
из файлов-индексов.
При наличии одинаковых индексов внутри папок, но разных кодов в их именах, в
закладке Media появится несколько проектных папок с одинаковым названием. Открытый
Проект может иметь первичные права только на одну проектную папку: именно в
нее он будет оцифровывать новую кассету – иными словами, генерировать такой
же код к ее имени – и удалять файлы, если в окне удаления Проектов поставлена
галочка на запросе «Удалять с Медиа».
Еще одна отличительная черта, дающая понять, что это все же не
копия Проводника, а специальное окно: при выделении имени Проекта (а не его
папки-кассеты), мы увидим все медиа (медиаклипы), на которые данный Проект ссылается.
Выделение строки All Streamed Media (или All Still Media) расширит базу просмотра
до всех файлов, охваченных структурой Chrom'а. И, соответственно,
сортировки в колонках могут вестись как по всей базе данных, так и по признаку
«Проект», а внутри Проекта по каждой кассете в отдельности.
Представленные в закладке Media материалы (форма представления может быть «клип»,
«файл» или «смешанный») разрешено проигрывать, удалять - всей папкой или индивидуально,
а можно вводить в проект на правах нового клипа,
на первом этапе равного по длине медиафайлу.
Чем данный алгоритм принципиально отличается от Edit'а: клип можно
создать, обратившись к папке любого Проекта, даже того, который
вы удалили, но перед удалением сбросили галочку на строке "Удалять медиа"!
А то, что полученный клип продолжает нести информацию о кассете и таймкоде исходника
будет долго казаться делом совершенно невероятным - вспомните, что в данной
ситуации делается в других ПО! Когда же вы решите, что необходимости в этих
медиафайлах нет, вы всю папку удалите прямо из закладки Media. Подсказкой вам
будет всегда служить имя Проекта.
По своим правам и возможностям клип, полученный через обращение
к закладке Media, будет абсолютно совпадать с другими клипами библиотеки, которые
попали туда через Модуль оцифровки. Стоит особенно подчеркнуть, что в рабочих
библиотеках Chrome все клипы могут менять Clip In/Clip Out (через Паспорт клипа
или операцией Condense), и если они иногда совпадают с In/Out файла – это можно
назвать делом почти «случайным», и легко «поправимым». Специальной операцией
можно проверить востребованность всех медиаклипов существующими рабочими клипами
данного Проекта (в библиотеках или Монтажных последовательностях). При отсутствии
таких связей, медиафайлы можно безболезненно удалить. Имя файла содержит начальный
и конечный таймкод по исходнику. Это не только упрощает поиски материала через
Проводник Windows для импорта в программы компоузинга, но и допускает ручное
исправление имен. Например, вы получаете возможность подставить файл взамен
удаленного, который цифровался без таймкода (режим Live). Для этого надо высчитать
сдвиг таймкода у одинаковых кадросмен и отредактировать цифры в именах медиафайлов
С точки зрения базы данных Edit, в Chrome просто не существует
понятия Метадаты, т.к. каждый клип проекта
самостоятельно ищет подходящий файл или группу файлов для синхронного воспроизведения.
Образовавшаяся связь запоминается внутри свойств клипа и, при необходимости,
она же будет использована для восстановления видео и аудио компонент.
За основу восстановления может браться как Clip In/Out, так
и Mark In/Out. В последнем случае автоматически сокращается размер восстанавливаемого
клипа, т.к. ему необходимо в конце процедуры быть равным файлу (или короче него),
иначе вместо видео на экране будет отображаться восклицательный знак. Кстати,
даже при обычной процедуре импорта с жесткого диска программа Edit будет класть
группу файлов в библиотеке индивидуальными клипами, а Chrome, если рядом обнаружит
файл с аналогичным именем, но с другим расширением, автоматически объединит
их в один клип. Именно так, ориентируясь на имена, программа поступает и со
«штатными» файлами: оцифрованными с видеокассет звуком и изображением.
Обратная сторона этой медали: каждый клип, как уже говорилось, самостоятельно
цепляется за медиафайлы. Даже если он "рожден" посредством копирования
внутри библиотеки от другого клипа - это ровным счетом ничего не меняет. Так
что если вы обнаружите неправильный номер кассеты после оцифровки, само собой
напрашивающийся путь – изменение имени кассеты в Clip Properties (Паспорт клипа)
– может вызвать удивление: медиафайлы «пропадут» и в углу клипа отобразится
восклицательный знак. Но произойдет это только в одном клипе, не затрагивая
остальные (включая копии).
Рассудим иначе. Клип – это ссылка на виртуальное место в одной
из папок с индексом данного Проекта, ограниченное таймкодами, которое может
быть "заполнено" файлом, а может и нет. Клип же - объект независимый
и самостоятельный. Как доказательство – если вы в Модуле оцифровки залогируете
клип и отправите его в библиотеку, не начиная сам процесс оцифровки, то при
наличии в Проекте подходящего файла (т.е. больше или равного Clip In/Out), клип
сразу наполнится содержанием. Второе - ваши действия в Проводнике Windows (удаление,
перенос) никак не будут блокироваться Chrom’ом, а результаты – обновляться сразу
или простой командой “Rescan Directories”, без перезагрузок программы.
То, что мы сделали с изменением названия кассеты в Clip Properties (строке Reel)
– так это просто адресовали клип к другой папке и тому медиафайлу, который должен
занимать виртуальное «место», например, «с таймкода 01:00… по таймкод 01:02:0…».
Но по указанному в Паспорте адресу может не только отсутствовать непрерывный
файл (а это обязательное условие), но даже сама папка-кассета – отсюда и восклицательные
знаки в углу иконок. Исправить ситуацию можно, если всю группу одноименных медиафайлов
(и их служебные дополнения) вручную переложить в другую папку-кассету. Или же,
если других медиафайлов нет, - исправить в Проводнике Windows имя кассеты целиком.
Но если вы на базе этого медиафайла уже успели создать несколько библиотек клипов
или несколько монтажных последовательностей – изменения придется вносить в каждый
клип - в т.ч. и на таймлайн! К сожалению, в программе пока недоступны групповые
переименования. Так что аналогичные трудности возникнут и с другими текстовыми
строками, заполняемыми пользователем.
Операции удаления.
Процедура удаления клипов и медиафайлов – настоящая проверка
для базы данных. Например, в Edit нельзя удалить последний
клип, ссылающийся на метадату, - т.е. с ним должен быть связан хотя бы один
клип в Проекте. Иначе – необратимые последствия: медиа автоматом удаляется и
уже без права восстановления! Если случайно выбрали "Удалить
все" - та же история... На практике такое происходит редко – просто, для
перестраховки, удалениями занимаются как можно реже. Но опасность все же есть,
особенно в «долгоиграющих» Проектах. Остается полагаться только на внимание
монтажера. Архивное сохранение тоже поможет, но головой и руками поработать
придется... Удаление медиафайлов разрешается делать по ссылке от одного или
нескольких выделенных клипов в библиотеке (через активизирование строк в открывающейся
панели Delete). "Индивидуальный подход" возможен только через JobNet,
как уже упоминалось выше. Там же говорилось и про варианты сортировки по качеству...
В Chrome удаление клипов - дело абсолютно безопасное. Для начала
все они попадают в Корзину, подобно той, что можно видеть на Рабочем столе Windows.
Конечно, там сохраняется только клип, без медиафайла, - поэтому ежеминутно чистить
Корзину не требуется. Кроме того, еще раз повторюсь - каждый клип самостоятельно
цепляется за файл. Т.е. удаление клипа, например, в библиотеке никак не скажется
на воспроизведении монтажной последовательности. И наоборот. Без вариантов!
А имеете клип - пусть даже восстановленный из корзины - сможете восстановить
и его файлы, если, конечно, этот клип цифровался с кассеты в режиме считывания
таймкода. Но и с остальными тоже можно "договориться".
А Корзина вам еще поможет, к примеру, осуществить групповые удаления просчетных
файлов (с их сортировкой по степени задействования в Проекте) и оптимизировать
объем файла Проекта. Доступ к непосредственному удалению медиафайлов в Liquid
Chrome открыт через закладку Media Основного окна Проекта.
Делать это можно в любое время и, что особенно ценно, - удалять медиаклипы из
любого Проекта, т.к. сама закладка является окном межпроектным.
Примечание: Если вы удалили все рабочие клипы из всех библиотек - вы можете
обратиться к закладке Media и на базе выбранного медиаклипа создать новый рабочий
клип. При необходимости – ограничить его (операция Condense), т.е. сделать короче
медиафайла.
Медиафайлы можно удалять одновременно с рабочим клипом библиотеки.
Для этого потребуется в открывающемся окне Delete активизировать дополнительные
строки, которые отвечают за категорию выделенных клипов (рабочий
клип медиафайла, Монтажная последовательность и т.д.) и способ получения
исходных файлов (импорт, оцифровка с таймкодом или без). Полезная вещь
не только для сортировки перед совершением операции, но и для проверки, что
же реально будет в данный момент удаляться.
И Edit, и Chrome позволяют удалять сопутствующие медиафайлы
во время удаления Проекта целиком. Edit ориентируется на название папки (по
имени выбранного для удаления Проекта). Chrome ищет нужный индекс-файл, пробегая
по всем папкам-кассетам, сверяется с кодом, добавленным программой к ее названию,
после чего приступает к их удалению. Но папку, в которую Проект формировал просчетные
файлы, придется удалять вручную. Как это не покажется ужасным, но на самом деле
- вещь полезная, т.к. именно сюда аккумулируются файлы, которые очень трудно
будет восстановить, в отличие от взятых с исходных кассет, имеющих таймкод.
Представьте, что нажав "Удалить Проект, включая медиа и просчеты"
вы вдруг вспоминаете о проектах AfterEffects или музыкальных треках! Но для
паники нет причин: из папки, что в группе Render, уберутся только временные
файлы. Все привнесенное вами материалы сохранятся. То, что осталось, можно всей
папкой перенести для архивного хранения.
