DVDRip-2

правильный DVD-Rip своими руками,\\ лапами, хвостом и усами II\\ (окончание)

крис касперски, ака мыщъх (серый, пещерный), no-email

сегодня мы продолжим углубление в тонкости «ручного» DVD-Rip'а, созданного по всем правилам науки, искусства и техники, который занимает минимум места, максимально совместим со всем и который при этом приятно смотреть

В прошлый раз мы остановились на том, что создали d2v-проект, описывающий структуру сграбленного VOB-файла и отделили звуковой трек (треки) от видео-потока, сделав им demux (не путать с харакири).

Теперь, необходимо задать настройки сжатия видео-потока: тип кодека, разрешение, битрейт и т. д. На выбор влияют множество обстоятельств как объективного, так и субъективного характера. На автоматику в этих вопросах полагаться нельзя. Ведь не она же будет смотреть сжатый фильм! Так что дело за нами!

Находясь на закладке «Ripping» основного окна GordianKnot нажимаем кнопку «open» и открываем ранее созданный d2v-проект. При этом на экран выпрыгнет окно предварительно просмотра (см. рис. 1), а GordianKnot автоматически перейдет к закладке «Bitrate» (см. рис. 2), высвечивая в окне «FPS» частоту кадров, а в секции «Duration» — расчетную продолжительность фильма.

Проверьте: совпадает ли она с заявленной продолжительностью, напечатанной на DVD-коробке. Если нет, значит FPS выставлен неверно и мы получаем несинхрон звука с изображением — практически незаметный вначале, но быстро нарастающий со временем. И таких кривых рипов встречается достаточно много! У некоторых уже на середине фильма звук отстает/обгоняет изображение на несколько секунд, а то и минут! Естественно, никакого удовольствия от просмотра мы не получим.

К счастью некоторые кодеки имеют опцию «videodelay» задающую смещение звуковой дорожки относительно видео-потока в миллисекундах. В кодеке ffdshow этот параметр можно менять «налету» непосредственно в процессе просмотра фильма, горячими клавишами ↔/<+>, но какой же геморрой постоянно их давить… Так что проблему с FPS нужно решать сразу и всерьез.

Рисунок 1 рабочий стол после открытия d2v проекта

Впрочем, коробкам верить нельзя. Часто там пишут совсем не то, да и по любому округляют длительность до минут, а ведь видео и звук должны быть синхронизованы с точностью до долей секунды! Самое простое, что можно сделать — воткнуть DVD в плеер и посмотреть реальную продолжительность и, если она отличается больше, чем на секунду от указанной в «Duration», то это уже косяк и чтобы его исправить нажимаем на «Close» и повторяем создание d2v проекта еще раз _внимательно_ следуя рекомендациям, данным в предыдущей статье. Если FPS равен 29.970 и у вас помечено, что необходимо сделать обратное IVTC-преобразование, меняем FPS на 29.976, не обращая внимание на то, что продолжительность осталась неизменный. Это глюк GordianKnot'а и рассчитать реальную продолжительность можно умножив поле «seconds» 29.970/29.976 или, закрыв проект, поменять FPS непосредственно в самом d2v-файле (благо он текстовой), тут же открыть его вновь. Тогда GordianKnot рассчитает продолжительность автоматически.

К слову сказать, из доступности полей «Duration» на редактирование еще ничего не следует. Они носят чисто информационный характер, и их прямое изменение абсолютно ни на что не влияет.

Рисунок 2 Gordian Knot – закладка «Bitrate»

Кодек DivX, долгое время остававшийся неофициальным народным стандартом, сейчас испытывает сильное давление со стороны конкурентов, у которых преимуществ (явных) намного меньше, чем яростных поклонников. Чтобы там ни писали разные журналы и ни показывали «независимые» тесты, ощутимого выигрыша ни в качестве, ни в степени сжатия, на среднестатистическом видеоматериале _не_ наблюдается. Какой-то фильм лучше сжимается одним кодеком, какой-то — другим, но если проблем с просмотром DivX ни у кого не возникает, то поддержка остальных кодеков только появляется из-за горизонта. Передавая фильм другу, сжатый «революционным» кодеком, мы вынуждены передавать и сам кодек, помещая его на диск (а ведь он место занимает!), при этом рискуя здорово огрести в случае каких-нибудь конфликтов. Далеко не все пользователи любят устанавливать новые программы в систему, тем более кодеки. Стационарные плееры — это вообще тема. Новый кодек на них не установишь и прошивку просто так не зальешь. И не нужно говорить, что нормальные хакеры смотрят фильмы только на компьютере, а все остальные — не мужики. Риппер должен думать не только о себе, иначе это не риппер, а кал.

GordianKnot 0.35 поддерживает следующие кодеки: DivX 3.11 (низкое качество, но высокая совместимость), DivX5 (отличное качество, хорошая совместимость), XviD (отличное качество, совместимость хуже чем у DivX5), x265 (отличное качество, будущий индустриальный стандарт, но в настоящий момент играется далеко не везде). Как видно, для рипа лучше всего подходит DivX5, который мы и будем использовать. Несогласные могут выбирать любой другой кодек — никто же не запрещает!

Теперь определимся с выбором контейнера, за который отвечает раздел «container», предлагающий меню из трех блюд: avi, ogm и mkv. Контейнер — это то, во что будет складирован видео-поток, звуковой трек (треки), субтитры (опционально), служебная информация, необходимая для осуществления перемотки, синхронизации и т. д. О преимуществах разных нестандартных контейнеров говорить можно долго, но… они нивелируются одним-единственным недостатком: нестандартностью. В целях совместимости лучше всего всегда выбирать avi. Любителей поэкспериментировать со всем новым и нестандартным было бы полезно изолировать от общества. Сколько раз так бывало — добытый файл отказывается воспроизводится и хрен его знает — что ему надо, и откуда это качать.

Битрейт (bitrate) определяет удельную информационную емкость потока и выражается в битах в секунду. Чем битрейт выше, тем выше и качество изображения, но тем больше размер занимает видео-файл и тем большей процессорной мощности он требует для своей обработки. Отсюда — в погоне за битрейтом главное не переборщить! На низких битрейтах качество изображения быстро растет вместе с битрейтом, но затем достигает «насыщения» и разница становится совершенно незаметной, а при дальнейшем увеличении битрейта качество не только не увеличивается, но даже начинает… падать. Если привод не успевает поставлять данные (а процессор — их распаковывать), умные кодеки выкидывают кадры (и мы теряем информацию о фазах движения), а глупые — дико тормозят, сотрясаясь в конвульсиях и зачастую теряя синхронизацию звука с изображением. Поэтому, выбор правильного битрейта — намного более сложное дело, чем может показаться вначале.

Битрейт бывает постоянным (constant) и динамическим (average). В последнем случае, кодек может опускать битрейт на статических сценах (сжимающихся лучше всех) и поднимать его, когда экран приходит в движение и ни хрена не сжимается. Однако, сам по себе битрейт еще не показатель качества, поскольку он не учитывает размер изображения и частоту кадров, варьирующийся в широких пределах. Более объективной характеристикой качества будет соотношение bits/(pixel*frame).

Если это соотношение ниже 0.15 фильм превращается в кал; фильмы ужатые до ~0.20 уже смотрится без особого отвращения и умещается на 1CD; ~0.3 практически не теряют качества, занимая 2CD (3CD если фильм длиться свыше двух часов); > 0.35 имеет смысл выставлять только эстетам или при просмотре на большом экране. Разумеется, «более объективную характеристику» не следует воспринимать как «объективную вообще», поскольку, оценка качества по определению субъективна и связана с кучей индивидуальный психофизических особенностей восприятия. Кто-то и 0.15 смотрит без рвотных позывов, а кто-то морщиться даже от 0.33… К тому же все зависит от фильма. Чем меньше в нем взрывов, тем выше степень сжатия, и, соответственно, выше качество при том же битрейте. Ориентировочное значение bits/(pixel*frame) приведено в одноименной секции (см. рис. 2), однако, оно рассчитано без учета степени сжимаемости фильма и верить ему нельзя, во всяком случае до тех пор пока не будет проведет тести сжимаемости, который мы опишем чуть позже, а пока сосредоточим свое внимание на секции «Mode», предлагающей выбор между «CalculateAverageBitrate» и «CalculateAviFileSize».

При выборе «CalculateAverageBitrate», GordianKnot позволит нам задавать размер avi-файла, образующегося после сжатия, что очень удобно, если фильм планируется записывать на один, два или даже три CD. Под этот размер и подгоняется битрейт, который часто получается неоправданно велик, но… какой смыл сокращать его, освобождая на CD, положим, 100 Метров, если покласть туда все равно ничего не удастся? Не, ну можно, конечно, забить это клипами или MP3, но в коллекции из десятка таких CD уже черт ногу сломит, пока найдет нужный файл. Напротив, если фильмы планируется хранить на HDD или выкладывать их в сеть, то избыточный битрейт это реальный shit и разумнее ориентироваться не на размер, а на соотношение bits/(pixel*frame).

Начнем с режима «CalculateAverageBitrate»: в секции «TotalSize» выбираем необходимый размер, задавая его либо в Кило (Мега)байтах, либо в количестве CD/DVD. Если CD больше одного, то avi-файл можно сразу разбить путем взведения галочки «SplintfinalfileintoCDs», в противном случае это придется делать вручную в видео-редакторе. Поскольку, помимо видео в avi входит еще и звуковая дорожка, ее размер должен как-то учитываться при калькуляции. Выбираем в секции «Audio A» ранее отделенный от VOB'а трек, записанный, как правило в AC3 формате, или указываем желаемый битрейт, если мы собираемся конвертировать его в mp3. При желании сделать диск с двумя звуковыми треками, выбираем следующий файл в секции «Audio B» (только помните, что стандартный windows медиа-плеер поддерживает только avi с одной дорожкой!). В секции «Files» задается размер дополнительных файлов, выкладываемых на CD (например, нестандартных кодеков, readme и проч.). Наконец, в секции «Interleaving & AVI-Overhead» указывается тип звуковой дорожки и количество кадров, через которые она синхронизуется с видео (только для AC3). По умолчанию это значение равно одному и лучше его не менять, чтобы потом не разводить ластами.

В режиме «CalculateAviFileSize» секция выбора количества CD погасает, зато становится возможным выбирать желаемый битрейт (но прежде, чем его выбирать изображение необходимо обрезать, чем мы в самом скором будущем и займемся, а так же провести тест сжимаемости фильма). Секции «Audio A/B», «Interleaving & AVI-Overhead» и «Files» в этом режиме теряют смысл, хотя остаются полезными, если мы хотим узнать какой же все-таки получится размер у финального видео-файла. Важно понять, что _реального_ подключения звуковой дорожки при этом не происходит и всего лишь учитывается ее размер!

Разрешение и аспект (aspectratio – соотношение ширины изображения к его высоте), напечатанные на коробке с DVD, далеко не всегда соответствуют действительности. Допустим, мы имеем дело с PAL'овским видеоматериалом, записанным с разрешением 720х576 и аспектом 16:9 (см рис. 1). Собственно говоря, аспект (по стандарту) может быть либо 4:3 (обычный фильм), либо 16:9 (широкоформатный). Простой подсчет показывает, что 720/576 == 1.25, что совсем не соответствует 16/9 == 1.78, к тому же сверху и снизу изображения присутствуют черные полосы, которые требуют для своего хранения место и раздражают при просмотре фильма в оконном (не полноэкранном) режиме, поэтому лучше всего их будет обрезать.

Переходим к закладке «Resolution» (см. рис. 3), где в секции «InputResolution» выбираем тип видеоматериала с которым мы работаем (PAL или NTSC), определенный при подготовке d2v-проекта, но, к сожалению, не устанавливающийся автоматически (точнее, устанавливающийся, но не всегда). В окне «InputPixelAspectRatio» выводим аспект, так же определенный при подготовке d2v-проекта. Неверный выбор приведет к нарушению пропорций, портящих все удовольствие от просмотра (хотя почти все плееры позволяют менять аспект, но… увы! не без потери скорости и качества).

Рисунок 3 Gordian Knot – закладка «Resolution»

Теперь, когда исходные параметры заданы, самое время приступить к обрезке. Нажимаем кнопку «AutoCrop» и даем программе обрезать все ненужное самостоятельно. В данном случае, она оттяпываем 74 пиксела с каждой стороны по вертикали и 4 пиксела по горизонтали. В отсутствии косяков нам поможет убедиться предварительный просмотр (см. рис. 4).

Нажимаем «Play» и смотрим: не осталось ли где-нибудь темных полос, отчетливо видных на светлых сценах и не было ли оттяпано ничего лишнего? Вращая ползунки мышью, уменьшаем количество отрезанных пикселей в секции «Crop» до появления черной полосы и тут же увеличиваем их вновь до полного ее исчезновения. В 99% случаев автоматика не врет и даже к умному Smart-Crop'у прибегать нет никакой необходимости.

По умолчанию, GordianKnot уменьшает размер изображения до 640 пикселей по горизонтали, вычисляя размер по вертикали исходя из аспекта, реального размера (после обрезки) и H-модуля. Начнем с размера. Значение в 640 пикселей это ровно половина от 1280 — наиболее распространенного разрешения на сегодняшний день, что позволяет растягивать изображение на всю ширину с максимальной производительностью и минимальными потерями качества. Тем не менее, при урезании исходных 720 пикселей до 640, потеря качества все-таки происходит, причем весьма значительная. Не лучше ли вообще отказаться от ресайза, сжимая изображение в том разрешении, в котором оно было записано? А что! Некоторые так и поступают, но это не лучше решение.

Аргументы «контра»: человеческий глаз с нормального расстояния от монитора отдельные пикселы не различает, так зачем их хранить с таким разрешением, если все равно потом придется делать растяжку до 1280? А 720 пикселей (точнее, в данном случае, 712 — оставшихся после оттяпывания черных полос) никак не кратно 1280, следовательно, избежать потери качества все равно не удастся. Так не разумнее ли для достижения гармонии обрезать изображения _до_ сжатия, отвоевав некоторое количество дискового пространства, за счет которого можно увеличить битрейт?!

Вообще-то, исходное разрешение на размер финального файла влияет не так уж значительно, и уменьшение изображения вдвое сокращает файл в среднем на 30% (что совсем неудивительно, т. к. степень сжимаемости падает с разрешением), поэтому отступать от размера в 640 пикселов стоит только тогда фильм планируется смотреть на мониторах с нестандартным разрешением (например, 1152х864). Рипы с шириной более 640 пикселей сильно раздражают, поскольку, при увеличении размеров изображения вдвое на стандартный экран они уже не помещаются и приходится либо терять края, либо делать растяжку. Ни качества, ни скорости это не добавляет.

Самое главное, что ширина должна делиться нацело на 32 (W-модуль), иначе некоторые кодеки/проигрыватели либо вообще не смогут проигрывать фильм, либо начнут тормозить, что на медленных машинах приводит к необходимости выброса кадров. Высота изображения должна быть кратна 16 (H-модуль), из чего с неизбежностью следует тот малоприятный факт, что после обрезки изображения скорее всего нарушится аспект, поскольку его придется выравнивать по границе 16 пикселей за счет растяжки. Ошибки аспекта отображаются в окне «AspectError» и чем они меньше (по модулю), тем лучше. Если отклонение составляет более 3.5% это окно загорается злобным красным цветом, сигнализирующим о том, что смотреть такой фильм будет не очень приятно. Ну… это еще как сказать. Разные люди по разному реагируют на искажения аспекта и некоторые вполне «переваривают» даже до 200% (!), хотя «морды» всех героев при этом становятся вытянутыми как у верблюда, но после нескольких минут просмотра человеческий мозг все компенсирует. Ладно, это уже пошли отмазки. Лучше поговорим о том как бороться с искажениями, а не как к ним привыкать.

Бороться можно двумя путями — либо меняя разрешение (но, как уже говорилось, от 640 пикселей лучше не отступать!!!), либо обрезая черные полосы по краям больше, чем это необходимо. Несколько пискелей с каждой стороны уже способы значительно повлиять на ситуацию, при этом практически без потерь значимой информации, правда, если перестараться, то легко «обрезать» затылки у всех героев по самые глаза и такой уродский рип никому не нужен.

Рисунок 4 окно предварительного просмотра

На первых порах тест сжимаемости можно не проводить, особенно если фильм предполагается записывать на целое число CD, когда битрейт можно брать с запасом. Лишь при точной подгонке соотношения bits/(pixel*frame) имеет смысл тратить время на тест сжимаемости, чтобы определить до какого размера можно жать avi-файл, не сильно проигрывая в качестве.

Покончив с обрезкой и определившись с разрешением, выбираем желаемый битрейт в режиме «CalculateAviFileSize», подгоняя оценочное значение bits/(pixel*frame) до требуемой величины и давим на кнопку «Save & Encode» в окне предварительного просмотра (см. рис. 4), на экране тут же появляется диалог «Save .avs» (см. рис. 5), содержащий среди прочего секцию «Compressibility Check», поумолчаниюстоящуюв «Off». Переводим ее в «Use» и указываем какой процент от исходного фильма мы будем тестировать. По умолчанию берется 5%, чего обычно бывает достаточно. Однако, если фильм крайне неоднороден по своей структуре (например, состоит преимущественно из статичных сцен в начале и динамичных в конце), это значение лучше увеличить, иначе полученные данные окажутся совсем далеки от реальности.

Нажимаем кнопку «Now» и даем компьютеру некоторое время поработать (а сами идем покурить). По завершению тестирования в окне «CompressibilityTest», расположенном в секции «bits/(pixel*frame)», появится истинное значение bits/(pixel*frame), а слева от него — отклонение от оценочного значения в процентах. Подкручивая битрет (разрешение), уменьшаем отклонение до разумного минимума или… оставляем все как есть, если результат нас устраивает.

Рисунок 5 диалоговое окно Saveas

Нажимаем кнопку «Save & Encode» еще раз, заставляя диалог «Save .avs» появится опять (перед этим еще можно нажать «Set Credits Starts», установив время начала титров, которые можно кодировать с более низким битрейтом, но выигрыш от этого получится совсем невелик, а вот впечатление от рипа портит изрядно, ведь кое-кто титры все-таки смотрит, так что к этому стоит прибегать только в случае острой нехватки пространства, да и то… лучше не прибегать).

Секция «Resizing» позволяет подогнать разрешение под формат VCD/SVCD, но никакого смысла в этом нет, так что оставляем разрешение как есть, т. е. в «SelectedOutputResolution».

Секция «NoiseFiler» позволяет подмешать в изображение некоторое количества шума, служащего своеобразным фильтром и улучшающим качество паршивого исходного материала (увы, такой материал не редкость даже на лицензионных DVD), однако, в подавляющем большинстве случаев шум только мешает.

Секция «Subtitles» служит для вставки субтитров в видео-поток и на хрен не нужна. Субтитры получаются не отключаемыми и сильно ухудшают сжимаемость файла. Лучше подключать текстовые субтитры в кодеке типа ffdshow или самом плеере типа BSPlayer.

Секция «Resizefilter» задает алгоритм для изменения разрешения с «родного» на 640xXXX. При увеличении размера (если вдруг кому это приспичит) следует использовать bilinear-фильтр, при уменьшении — все остальные. Какие именно — определяется битрейтом и вкусом. Лично мне нравится Lanczos, другие же предпочитают бикубические фильтры. Между «soft» (мягкий) и «sharp» (резкий) разница довольно значительна и лишняя резкость сценам с плавными переходами от света к тени только вредит. Впрочем, опять-таки, все дело вкуса.

Секция «FieldOperation» используется лишь в том случае, если необходимо выполнить обратное IVTC-преобразование, при этом мне больше всех нравится SmartBob, другие же рекомендуют TomsMoComp. Что поделаешь! Сколько людей — столько и вкусов.

Покончив с настройками нажимаем «Preview» для предварительно просмотра видео (но реально мы увидим только аспект и обрезку, ни фильтры, ни что другое не окажет на предварительный просмотр никакого влияния), и, убедившись, что нигде ласт нет, давим «Save & Encode», подтверждая запрос о желании начать сжатие немедленно.

Мы будем использовать двухпроходное сжатие (выбираемое GordianKnot'ом по умолчанию). В первом проходе никакого сжатия не осуществляется, а лишь определяется степень сжимаемости каждого из кадров и полученные данные пишутся в лог, позволяющий во втором проходе распределить битрейт по файлу с учетом реальных потребностей, то есть забирать битрейт у статичных сцен, отдавая его туда, где он конкретно нужен.

Однопроходное сжатие вдвое быстрее, но принципиально неспособно обеспечить высокое качество при минимальном размере файла. Двухпроходному режиму соответствует радио-кнопка «Multi-Pass» (см. рис. 6), позволяющая задавать не только два, но три и даже четыре прохода (количество которых задается боксе «Numberofpasses»), но по большому счету это пустая трата времени, совершенно не стоящая мизерного улучшения качества.

Рисунок 6 Gordian Knot, окно «Encoding Control Panel»

Давим на кнопку «FirstPass» и подкручиваем настройки кодека по своему усмотрению (см. рис. 7). Настройки — это все! От ни них зависит скорость, степень, качество сжатия, а так же совместимость с различными проигрывателями. На эту тему написано много статей, поставлено множество экспериментов, но начинающим тут делать нечего — это однозначно и обсуждению не подлежит! Чтобы ненакосячить лучше всего использовать «сертифицированные профили» с уже готовыми настройками от самих разработчиков кодека, среди которых наилучшее (разумное) качество обеспечивает «HomeTheater».

Бокс «EncodePerformance» позволяет выбрать желаемый компромисс между качеством, степенью и скоростью сжатия. Кажется, что скорость сжатия не такой уж важный критерий, но… если в «Standard mode» на 3 ГГц P-4 обычный полнометражный фильм сжимается в среднем за полтора часа, то на том же оборудование «slowmode» отнимает до четырех часов! На старых компьютерах разрыв еще более заметен и производительность рипа «один фильм за ночь» вряд ли кого может устроить. В идеале, конечно, для сжатия можно приобрести отдельный компьютер (лично я так и поступил), но… мир, в котором мы живем, далек от идеала, так что…

Ползунок «Bitrate» устанавливается GordianKnot'ом на нужную позицию автоматически (исходя из заданных ранее настроек) и трогать его нужно только тогда, когда GordianKnot глючит и устанавливает его неправильно (а такое с ним довольно часто случается).

Кнопка «NthPass» задает настройки сжатия для второго прохода и параметры DivX'а здесь должны быть такие же, как и в первом, иначе на выходе получится кал.

Рисунок 7 свойства кодека

Закладки «Audio 1/2» (см. рис. 6) подключают одну или две звуковые дорожки, выбираемые кнопкой «Select». Для подключения звука «как есть» (а есть он, обычно, в формате AC3), переводим радио-кнопку в положение «JustMux», при этом не забыв, что кодек AC3 имеется не у всех и его придется класть на диск (из бесплатных AC3-кодеков можно порекомендовать ffdshow), что есть bad и пожертвовав небольшой потерей качества (все равно фильм случать через бластер) его можно пережать в MP3, выбрав постоянный или динамический битрейт.

Рисунок 8 подключение звуковой дорожки

Покончив со звуком, возвращаемся к первой закладке (с параметрами кодека) и жмем кнопку «AddJobToEncodingQuery» (добавить задачу в очередь сжатия). Нас спрашивают: хотим ли мы начать работу немедленно? Ну что за вопрос! Конечно хотим!

Собственно, в самом сжатии ничего интересного нет. В свернутом окне VirtualDubMod'а отображается процентаж (см. рис. 9), который при развороте окна исчезает, зато появляется возможность залезть в статус и отрыв вкладку «Video» понаблюдать как меняется степень сжимаемости фреймов, да и то только со второго прохода. Ну а в первом неплоха слегонца покурить, чтобы смотреть порипанный филь уже на волне прихода.

Рисунок 9 наблюдение за процессором сжатия фильма

Прочитав все это, можно понять, какое это непростое дело — правильный рип, а ведь мы рассмотрели только основные моменты, рассказав о важнейших пунктах меню GordianKnot, который есть ни что иное как FrontEnd, то есть графическая «морда», скрывающая от пользователя массу более тонких настроек управляемых им утилит, полное описание которых заняло бы увесистый том.

Тем не менее, первый шаг в мир рипперства уже совершен. Если исходный DVD был не косой, то никаких проблем возникнуть не должно, ну а если они все-таки возникли, просто отложите диск на полку до лучших времен и возьмите другой. DVD-диски (как лицензионные так и пиратские) зачастую создаются с грубейшими нарушениями всех стандартов. Они могут нормально воспроизводиться на DVD-плеере, но сильно косячить в финальном avi. И никакая 'nj не защита, как некоторые говорят (хотя и защиты встречаются тоже), а просто кривизна рук производителя. Универсальных советов по выходу из ситуации, к сожалению, дать невозможно, во всяком случае не в этот раз…