"Kontakt" больше - лучше?
Создатели библиотек для популярного сэмплера Kontakt приучили нас, что библиотеки должны быть большими. Очень большими. Чем больше - тем лучше.
Технологии не стоят на месте, и если раньше 400 мегабайтная Windows XP вызывала уныние по поводу отсутствия свободного места, то сейчас народ качает музыку во FLAC'е, фильмы - в BluRay и терабайтными «винтами» уже никого не удивишь. Так стоит ли беспокоиться, что библиотеки для Kontakt'а давно перешагнули стогигабайтный рубеж?
В конечном итоге, любая программа располагается где-то на отрезке «память»-«процессор», балансируя между ними. Можно алгоритм сделать шустрым и не нагружающим процессор за счет использования большего объема памяти. А можно сделать компактную, не требовательную к памяти программу за счет использования большего количества вычислений.
Виртуальные инструменты - классический пример.
На одной стороне - генераторные инструменты, то есть «синтезаторы» в прямом значении этого слова. Здесь звуки именно синтезируются с помощью различных алгоритмов.
На другой стороне - сэмплеры. Здесь используются заранее созданные/записанные инструменты. Задача сэмплера - просто воспроизвести нужный звук в нужное время, плюс наложение некоторых эффектов при необходимости.
Понятно, что сэмплеры должны быть требовательны к памяти. И, разумеется, чем точнее мы хотим передать звучание, тем больше нужно сэмплов - с разной громкостью, разной динамикой, разной исполнительской техникой итд
Проблема, однако, возникает, если посмотреть не на количество файлов - которое в фирмовых библиотеках достигает сотни тысяч - а в их размере. По идее, 16 бит 44100 сэмплов в секунду было и остается стандартом де-факто в мире музыки. С другой стороны, производители один за другим спешат сообщить, что их сэмплы - круче некуда, и записаны в адских 192к 32 бита на сэмпл. Хотя, чаще это 96к 24 бита. В чем прикол, спрашивается, если разница на слух не слышна? Обычно, апеллируют к потере точности при обработке. Поскольку на инструменты накладываются разные эффекты, желательно иметь некоторый запас точности. Даже старый добрый VST использует 32 или 64 битный float "внутри", независимо от того, в каком формате были входные или требуются выходные данные. Это понятно. Но вопрос - стоит ли хранить данные в таком формате - остается.
Казалось бы - ладно, хочется людям крутой формат - их дело. Но даже тут создатели библиотек не останавливаются. Нужно показать, что у твоей библиотеки огромные размеры, чтобы народ поверил, что все и правда круто. И идет борьба за каждый мегабайт... причем в обратную сторону. Есть настоящие спецы этого дела в мире Kontakt'овских библиотек.
Самый простой и «законный» вариант - это напихать сэмплов, которые не особо нужны и в данном инструменте идут как бонус. Например, возьмем Albion от Spitfire. В целом, он воспринимается как оркестровая библиотека: струнные, духовые итп. Но в добавок там идет куча непонятных синтезированных и живых эффектов, занимающая треть объема. Придраться, однако, не к чему - Spitfire нигде не говорил, что это чисто оркестровая библиотека. Другой вариант - воткнуть сэмплов, которые никто толком не будет использовать. В String Quartet от Spitfire есть куча записей неких «дополнительных» микрофонов, которые люди, обычно, удаляют. А это почти четверть объема, между прочим.
Можно использовать более хитрый подход - оставить сэмплы, которые вообще не используются. То есть, что бы вы не делали с инструментом - эти звуки издаваться не будут. Но они есть, и они занимают объем. В принципе, такие не используемые сэмплы часто встречаются в крупных библиотеках, но, обычно, их количество - невелико. Связано это с тем, что по ходу тестов и проверок какие-то сэмплы отбрасываются, как неудовлетворительные по звучанию, или просто избыточные. При этом в куче из десятка тысяч файлов легко забыть удалить пару-другую. По крайней мере, такова была отмазка Impact Soundworks по поводу наличия неиспользуемых сэмплов в Shreddage. Хотя, процесс сборки-то более-менее автоматизирован... ну да ладно. А вот тот же Spitfire в своем String Quartet умудрился оставить пару тысяч неиспользуемых файлов. Ну... забыли... что скажешь.
Причем, борьба за мегабайты - это не обязательно удел только крупных производителей. Тот же Mauro Pacella любит 32-битную точность. Хотя и ежику понятно, что 24 бит более чем достаточно, ан нет. «Нужно больше золота!»
Один из парадоксов, в том, что даже Kontakt'овские инструменты, имитирующие олдскульный 8-битный звук (а такие есть), обычно используют 16 или 24 бита для хранения.
Но поедем дальше. Что можно придумать еще для раздутия своей библиотеки? Можно использовать совсем хитрые ходы. Так Marcos Ciscar использует особенности формата WAV. Дело в том, что WAV формат, будучи частным случаем RIFF формата, позволяет хранить внутри самые разные данные, не обязательно только звук. Пользу из этого можно извлечь, если хранить там, скажем, имя автора и название композиции. Но можно использовать это и в стиле темной стороны. У вышеупомянутого Marcos Ciscar внутри WAV фалов хранятся не-звуковые куски размером около десятка килобайт. Они бесполезны, не содержат никакой информации - забиты нулями - но они есть, и прибавляют вес его библиотекам, создавая ощущение солидности. Как же так? Разве это честно? Ну, у рынка свои законы. Народ как велся на цифры, так и будет вестись. Потому что нам нужны хоть какие-то объективные показатели, которые можно сравнить. Объем библиотеки - один из них, и худо-бедно коррелирует, если и не с качеством звучания, то хотя бы с проделанной работой.
Вот и рождаются сто-, двухсот гигабайтные монстры, при этом оценить - насколько реально нужен такой объем - проблематично. Для этого нужно библиотеку переконвертировать, проредить, затем устроить слепые тесты от разных создателей музыки, чтобы они оценили разницу в качестве в уже готовом материале итд итп. Куча работы, которой никто не будет заниматься. Проще докупить еще один винт.
небольшой апдейт к статье
Во-первых, упомянутый выше метод с «дутьем» WAV файлов, оказывается, невероятно популярен. Скажем так, найти библиотеку с WAV файлами, которая не использовала бы данный метод - проблематично. Обычно, этим не занимаются крупные компании. Впрочем, крупные компании, как правило, используют NCW формат. Да и вообще, одно только использование WAV вместо NCW уже увеличивает размер библиотеки. Почему? Потому что NCW - формат со сжатием.
Во-вторых, еще один метод увеличения размера. Его я обнаружил случайно, до этого внимания не обращал, так что не могу сказать - насколько он популярен. Идея простая: берется один и тот же сэмпл, копируется под другим именем... и все. То есть звук тот же, файл совпадает один в один, но поскольку имена файлов разные - проблем нет.
И, наконец, красивое решение от библиотеки Drumvolution. Тоже не знаю, насколько этот метод популярен, но внимания он заслуживает. Я уже говорил о запихивании в WAV файл незвуковой информации - это понятно. Такие файлы чистятся просто - пересохраняются любой доступной программой. Можно тем же «sox». А вот в Drumvolution решение красивее. Они берут и вставляют паузу. Идеальную такую - сплошные нулики в WAV файле. Затем, в самом инструменте настраивается так, чтобы воспроизведение начиналось не с начала файла (где пауза), а с той точки, где, собственно, звук идет. Ну, красота же! И работа ведь какая проделана!
Самое интересное, что от этой штуки уже сложнее избавиться. Во-первых, эта пауза - информация звуковая, то есть простым пересохранением от нее не избавишься. Во-вторых, даже если использовать какой-нибудь обрезатель пауз (есть такие) или написать свой (делал такое), то все пойдет наперекосяк. Потому что нужно теперь в инструменте удалять этот заданный сдвиг (делать его нулевым). А если это мультиинструмент... а если это еще и скриптом прописано... Короче, данному решению я апплодирую.