А в чем вообще на данный момент преимущество 32fp? Интересно, почему тот же штайнберг так активно навязывает его пользователям?
Сведение и мастер в 24 / 96
- Автор темы freel
- Дата начала
@smack, для начала определись в чем разница между целыми числами и дробными числами в цифровом представлении, тогда и поговорим. Можно наговорить чего угодно, но long утверждает, что "32fp - это НЕ 32 бита". Я не считаю больше = лучше, 24 бита более чем достаточно, чтобы покрыть динамический диапазон многих цап.
[DOUBLEPOST=1429183250,1429182881][/DOUBLEPOST]
[DOUBLEPOST=1429183250,1429182881][/DOUBLEPOST]
Только маркетингом. Они этот FP могли лет 20 назад ввести, и представление громкости в FP уже давно существует.
Интересно насколько хорошо вы слышите тихие участки микса ниже -60db особенно в тяжелых направлениях музыки?) Да вот только все чето смотрят на цифры, но у многих ведь миксы даже эти 96db разумно не могут использовать, и разница между тихими и громкими участками не большая.
@TonyAlien, в качестве формата хранения данных вне (!) DAW 32 бита fp хороши тем, например, что можно выливать миксы или стемы не глядя на возможный клиппинг на выходе.
Т.е. если что-то в какой-то момент полыхнёт хоть в +20 - ничего страшного не случится.
Т.е. если что-то в какой-то момент полыхнёт хоть в +20 - ничего страшного не случится.
После трекинга, при микшировании и прохождении через компрессор -60 децибел легко превращаются в -20, например. А если, к примеру, вы не обратили внимания на гейн одного из каналов и пиковый уровень при записи составил - 30 dB (при записи ударных, к примеру, обычно дело)? В -60 - это уже не шум или затухание хвоста, а вполне себе рабочий диапазон динамики инстурмента.
@fakeitback, согласен, что рабочий диапазон инструмента, но спектры нескольких инструментов складывают при микшировании, представим 2 синуса одной частоты(два инструмента) - 75db оба, что будет в итоге? И еще раз, разницы 32 fp и 32 int нету, они в цифровом виде одинакового представлены, все дело лишь какими цифрами удобнее вам оперировать с дробной частью и меньшими по значению, или более крупными целыми, относительные значения у них у всех будут одинаковые)
Последнее редактирование:
@xlt, повторю мысль: у вас прописался на барабанном мультитреке рум, например, с пиками в -30, пусть даже -20. Рум этот нередко жмётся в жесткую колбасу... обычная технология со времён цеппелинов.... что у вас там вылезет от хвостов тарелок, например, при записи в 16 бит? Только какахи цифровые... которые смешаются с шумом премпов и прочего...
То же самое с параллельной компрессией оверов и т.п. И много еще с чем.
Да с любым инструментом с большим динамическим диапазоном 16 бит при записи противопоказаны, если только не через компрессор сразу писать.
ps. А ещё DI хайгейновых гитар на реампинг можно вспомнить. Пусть -6 на пиках при рубке рифами на выкрученной ручке громкости. Потом пишем соляг мягкий убрав ручку гейна - пики в -20, основной диапазон динамики - сильно ниже.... что там вылезет после четырёх каскадов 5150, если у нас 16 бит по недоразумению выставлено на панели аудиоинтерфейса???
Вот именно)
То же самое с параллельной компрессией оверов и т.п. И много еще с чем.
Да с любым инструментом с большим динамическим диапазоном 16 бит при записи противопоказаны, если только не через компрессор сразу писать.
ps. А ещё DI хайгейновых гитар на реампинг можно вспомнить. Пусть -6 на пиках при рубке рифами на выкрученной ручке громкости. Потом пишем соляг мягкий убрав ручку гейна - пики в -20, основной диапазон динамики - сильно ниже.... что там вылезет после четырёх каскадов 5150, если у нас 16 бит по недоразумению выставлено на панели аудиоинтерфейса???
Вот именно)
Последнее редактирование:
@fakeitback, понял вас, 16 бит для вычислений мало с этим согласен, но для конечного экспорта достаточно. Проблема записи 16 бит, это скорее проблема конкретного АЦП, а не DAW и цифровых вычислений.
Тем, что там разница между соседними значениями увеличивается с ростом сигнала экспоненциально. То есть около нуля сгруппировано гораздо больше отсчетов чем около максимума. Точность представления уменьшается с ростом амплитуды
Это в теории...
Пробовали? На практике? Например, Призмовские AD, не самые позорные из конверторов, почему-то имеют DR 111дБ, а не 144, как по вашим вычислениям
Плагины же в сужении DR виноваты не всегда, ошибки возникают еще на этапе оцифровки.
И, товарищи: точность представления разве что позволяет привносить меньше новых ошибок при вычислениях.
Но качество "тела" аудио определяется параметрами оцифровки, поэтому никакое представление амплитуд - ни дробное, ни целочисленное - не исправит ошибок, изначально возникших при АЦП.
Это все равно как улучшать качество звука путем конвертации MP3 128kbps в wav 24/192... )))
Последнее редактирование:
Неверно. В конечном счете мы получим РЕАЛЬНЫЙ выигрыш в качестве только при появлении реальных 32-битных конверторов - за счет оцифровки ))
Поймите же, что ошибки квантизации появляются на этапе ЦАП. Или вы считаете, что 32-битный ПЕРЕСЧЕТ сделает исходник, оцифрованный 16-битным конвертором, лучше, чем 24-битный файл, не подвергающийся пересчету?
Это было бы наивно... Приведу другую аналогию: если вы разменяете свои деньги на мелкие купюры, пачка станет толще - но сумма ведь не увеличится, и качество (жизни в данном случае) не повысится...
Преобразователь - всему голова. Понятно, что 24-битный может дать лучший результат, чем 16-битный...
Поймите же, что ошибки квантизации появляются на этапе ЦАП. Или вы считаете, что 32-битный ПЕРЕСЧЕТ сделает исходник, оцифрованный 16-битным конвертором, лучше, чем 24-битный файл, не подвергающийся пересчету?
Это было бы наивно... Приведу другую аналогию: если вы разменяете свои деньги на мелкие купюры, пачка станет толще - но сумма ведь не увеличится, и качество (жизни в данном случае) не повысится...
Преобразователь - всему голова. Понятно, что 24-битный может дать лучший результат, чем 16-битный...
Ну что значит - не дает...
24 бита (100-112dBA) лучше, чем 16 бит (87-92dBA), не говоря уже о забытых 12-битном и 8-битном аудио )))
Ну, а дальше - есть такие понятия как целесообразность и т.п.
Можно, конечно, брать готовые 16-битные сэмплы, импортировать их в проект 192кГц, а смысл? Особенно если затем наваливать кучу ухудшайзеров. Я уж оставляю за скобками художественную ценность некоторых "проЭктов"...
НМВ хороший совет дал камрад @TonyAlien - что от вас требуется в итоге, то и ставьте в качестве параметров проекта.
Это касается и разрешения, и SR.
@akaabd, используйте 24 бита, их достаточно для записи сигнала. Более высокоразрядный сигнал полезен только в вычислениях, тем что мы можем складывать значения и не боятся, что мы вылезем за максимальный предел и не придется отбрасывать значимые биты, и относительно занижать громкость, чтобы уложится в разрядность. Например в 16 бит максимальное число 65536, в 24 бита - 16777216, что в 256 раз больше 16 битного максимума, то есть мы можем взять например 256 16битных максимальных чисел, добавить спереди нули расширив до 24 бит, сложить их в 24 битах, и не боятся, что предел будет переполнен. При переполнении старшие биты сбрасываются в ноль, а младшие начинают считать с 0. Например макс число у нас 1000, в результате вычислений мы получили 1024, тоесть будет переполнение и в записи будет только число 24. Описал все условно, для более легкого понимания, все немного по другому.
А что, на сегодняшний кто-то может записывать сигнал с разрешением выше 24 бит? )))
А что, есть выбор? Он был бы полезен и при записи, но см.выше )))
Меня, кстати, умиляют заявления типа "Я пишу в 32 битах". Ну-ну...
Это всё Влад понятно,из плохого хорошего не сделаешь,компрессором на записи пользуюсь,с разрешением разобрался,перейду с32флоат на 24,давайте с частотой дискретизации одни камрады говорят прозрачность улучшается за счёт лучшей работы плагинов,другие польза только для лимитера,если баунс цифровой,я бы хотел не 96,а 88,2,так как конечный продукт у нас пока 16/44,100.
Уж и не знаю, что написать - OMG или WTF. Жаль, в новом движке нет подходящего смайлика.
С каких пор 64-битный клок означает 64-битное аудио?!
Ну не надо ересь вещать...
@akaabd прозрачность-не прозрачность - дело весьма неоднозначное. Вы уверены, что не потеряете больше при излишней переконвертации? К тому же, многие современные плагины умеют оверсемплить, но тут уж только ваш практический опыт поможет принять решение, где и как целесообразно это использовать. Однозначно при экспорте мастера желательно включать оверсемплинг на лимитере. Но во время работы, например, я его не задействую ради экономии ресурсов. Ресь, понятное дело, о проектах в 44.1
@akaabd, насчет прозрачности - крепость цепи определяется слабейшим из звеньев.
Если тракт полностью или хотя бы частично не способен обеспечить эту самую прозрачность - никакой SR не спасет...
А еще человеческий фактор способен намутить и замутить даже самые чистейшие исходники - приходилось наблюдать такое не раз.
Так что если у вас единственная проблема - это SR, тогда повышайте ее до тех пор, пока оборудование тянет )))
Если тракт полностью или хотя бы частично не способен обеспечить эту самую прозрачность - никакой SR не спасет...
А еще человеческий фактор способен намутить и замутить даже самые чистейшие исходники - приходилось наблюдать такое не раз.
Так что если у вас единственная проблема - это SR, тогда повышайте ее до тех пор, пока оборудование тянет )))
Здесь один моментик есть,апсэмплинг и изначально оцифровывать с высокой частотой не одно и тоже ведь.
Чистосердечное признание смягчает вину ))))
Да? А как вы отнесетесь к факту, что даже древний SMPTE имеет разрядность? В нем каждый фрейм описывается 80 битами, ЕМНИП.
короче понаписали всякого... я хз как вы там записываете все, тока вот че: крест-фактор любой современной записи (не берем во внимание оркестры, записанные живьем, а не библы, канеш) дб примерно 6 в хорошем случае, в лучшем - 10 (не видел лично, хотя кучу фирмовых и наших записей прослушал с анализатором в мониторе, зато читал, что они есть где-то в параллельном мире), ну и че рассуждаем тогда? не понимаю, реально. где взять хотя бы 30 дб разницы в песне какой-нить? покажите хоть, штоле