44100 или 96000?

[Vladis Udler]

Я в 32 бита раньше переводил.(точнее сразу записывал):girl_sigh: Но только лишь потому,чтобы уменьшить количество вычислений на компе..т.е. хосту уже не надо "налету" конвертить файл 24-32-24 так как он файл уже 32 битный. По моим наблюдениям компу работалось легче(вроде как) ,но место на HD занималось больше. Сейчас это уже не актуально в виду того ,что мощности процесоров и их количества заметно подросли.
Как то вот разницы звучания особой то и не было,что 24 что 32.
В итоге 24 бита и 44100 и трава не расти, трава лучше курить.

 

[P00H]

Но только лишь потому,чтобы уменьшить количество вычислений на компе..т.е. хосту уже не надо "налету" конвертить файл 24-32-24 так как он файл уже 32 битный. По моим наблюдениям компу работалось легче(вроде как)

вот именно что (вроде как), т.к. в реальности при исходных 32 битных треках компу работается гораздо тяжелее чем при 24 битных, чтобы это выяснить достаточно запустить проект из нескольких десятков аудио треков вообще без всяких обработок и посмотреть на загрузку проца в случае чтения с винта 24 битных исходников и в случае 32 битных rankster2:
з.ы. а насчёт дополнительной нагрузки на процессор от конвертации на лету кстати распостранённое заблуждение, т.к. при конвертации что на лету, что в офлайне из 24 в 32 нет вообще никаких вычислений, просто нули добавляются в конце слова и всё.

 

[lotas]

Частота дескретизации сигнала влияет только лишь (или почти только) на верхнюю воспроизводимую частоту, так при 44100 верхняя частота будет 22500 Гц, при 96000 - 48000 гц, поэтому в CD стандарте и выбрана частота дескретизации 44100.

 

[Vladis Udler]

вот именно что (вроде как), т.к. в реальности при исходных 32 битных треках компу работается гораздо тяжелее чем при 24 битных, чтобы это выяснить достаточно запустить проект из нескольких десятков аудио треков вообще без всяких обработок и посмотреть на загрузку проца в случае чтения с винта 24 битных исходников и в случае 32 битных rankster2:
з.ы. а насчёт дополнительной нагрузки на процессор от конвертации на лету кстати распостранённое заблуждение, т.к. при конвертации что на лету, что в офлайне из 24 в 32 нет вообще никаких вычислений, просто нули добавляются в конце слова и всё.

Во..во. Вроде как
тогда атлон у меня был 2ух ядерный и самплитуда с недоделаными функциями работы с многопроцессорными системами,т.е. одно ядро всё время стояло,вот и переводил в 32 бита(в этом случае 2-ое ядро начинало пахать создавая иллюзию разгрузки .... я знаю,что заблуждался.

 

[Serg196]

Ну как же не нужна? Если делать много операций нормализации (усреднения) сразу - часть информации пропадает(вар.24 бита карта - 24бита запись), поэтому лучше нормализировать в конце, а до этого сохранять без изменений(24карта - 32бита запись). И какая разница микширование это или другая обработка? Все те же операции с числами.

Мы говорим о разных вещах.
В современных хостах применяется недеструктивная обработка аудиоданных.
Теперь скажи мне, зачем мне иметь ИСХОДНЫЙ аудиотрек с 32-х разрядной размерностью, если все операции с ним будут производиться вне него?
Для уменьшения накопления ошибок я могу применять какой угодно метод, исходная разрядность треков-то здесь при чем?
Речь-то идет о том, сколько разрядов использовать для хранения аудиоданных на треках, а не о том, сколько из использовать внутри хоста!

... А про теоретический факт - надо рассмотреть некий алгоритм ресемплинга, но это слегка долго... Ну например он может быть таким: исходный фрагмент сигнала, представленный выборками с частотой дискр. 48000 кГц помещается в буфер и интерполируется неким полиномом, допустим сплайном - получаем при этом искусственную функцию F(t), описывающую наш фрагмент. Далее мы подставляем в эту функцию t-соответствующие нашим 44100кГц и получаем на выходе необходимые нам пересчитанные амплитуды. Ну так вот - кубический сплайн попадает во все отсчеты нашего первоначального сигнала - но что ему делать на концах буфера - он же не может точно знать какое следующее значение будет за пределами буф.!? Он может только предполагать об этом (прогнозировать с некоторой вероятностью). Конечно можно усреднять на концах - но это уже источник погрешности... И думаю сплайн они дают токо в медленных и высококачесвенных алгоритмах, поскольку он использует тучу вычислений....Вообще при некратных частотных переносах возникают комбинационные частоты типа n(F1+F2) и n( F1-F2). Например 48000-44100 очень хорошо попадает в звуковой диапазон.... Если кому то очень хочется может Баскакова "Радиотехнические цепи и сигналы" почитать, там слегка есть об этом.

Я не о том. Теоретически и там и сям возникают искажения (разного рода, но не в этом дело). Я имел в виду, насколько заметны эти искажения?
Алексей Лукин как-то выкладывал здесь тесты ресемплеров разных хостов, так вот заметность искажений была чрезвычайно невелика, зачастую ниже уровня слухового восприятия.

 

[Serg196]

Смысл может быть в том, чтобы частично обойти менее качественный SRC, встроенный в звуковую карту / АЦП (который осуществляет сигма-дельта преобразование в PCM). Если позволить ему работать на 96 кГц, а потом понизить частоту программно, то это может привести к более качественному результату (в зависимости от соотношения качества SRC в АЦП и программного).

Например, в каких-то старых карточках - то ли Live, то ли Audigy - был только один клок 48 кГц и плохой встроенный ресамплер.

В таком случае исходную фразу нужно отредактировать в таком виде:

"Поэтому записывать и обработку всю вести с частотой дискретизации, оптимальной для аудиокарты, а потом преобразовать в нужное с помощью хорошего ресемплера,например Izotope RX,Voxengo r8brain."

Кстати, а может быть для аудиокарт оптимальной частота 88,2 кГц? Частота нестандартная - скорее всего при записи вначале произойдет аппаратная конвертация в частоту 88,2, а затем вторично - программная в 44,1.

 

[zettt]

...как-то выкладывал здесь тесты ресемплеров разных хостов, так вот заметность искажений была чрезвычайно невелика, зачастую ниже уровня слухового восприятия

Согласен, просто выше счет вроде шел "на микроны"

Речь-то идет о том, сколько разрядов использовать для хранения аудиоданных на треках, а не о том, сколько из использовать внутри хоста!

Согласен, если хост не имеет подводных особенностей. ********** Об аппаратных средствах для ресемплинга - никакой разницы быть не должно. Все равно используются те же алгоритмы - только будучи исполненными на DSP они должны работать существенно быстрее.

 

[Novation]

"...только будучи исполненными на DSP они" ОБЯЗАНЫ работать исключительно в реал-тайме... Вот и всё...

 

[Serg196]

Feomothar,
бред полный пишешь, какая разница в каком там виде лежит файл на диске, внутри хоста он всёравно обрабатывается как 32битный, лажа произойдёт тока если ты эти треки начёшь баунсить, фризить и т.п. сохраняя исходный формат.
а у тебя грубо говоря такая цепочка получается:

v.1 есть исходный 24 битный файл
1111 1111 1111 1111 1111 1111
переконвертированый в 32 бита он приобретает вид
1111 1111 1111 1111 1111 1111 0000 0000
а т.к. весь процессинг внутри хоста 32 битный то и внутри хоста он обрабатывается как
1111 1111 1111 1111 1111 1111 0000 0000

v.2 есть исходный 24 битный файл
1111 1111 1111 1111 1111 1111
а т.к. весь процессинг внутри хоста 32 битный то внутри хоста он обрабатывается как
1111 1111 1111 1111 1111 1111 0000 0000

ну и в чём между ними разница? :rtfm:

з.ы. вариант ответа - "я слышу разницу между побитно идентичными файлами" у нас тут не прокатывает, изволь выложить доказательства.

Маленькая ремарка - ты привел пример для целочисленного 32-разрядного числа (кроме того, старшие разряды принято указывать слева, независимо от того, как они располагаются в памяти); для числа с плавающей точкой отображение будет несколько иное, что, впрочем, совершенно не меняет смысл твоего сообщения (это я уже из чистого занудства).

 

[loDJica]

НАРОД!!!!
давайте топ прикроем, реально уже начали впадать в маразм, надо еще и запретить в правилах сравнивание частот записи, иначе докатимся, до того что мол при черном цвете монитора звук более насыщенный

 

[P00H]

да последние страницы хоть реальная инфа идёт, а не из области "я так слышу" , пущай народ просвещается rankster2:

 

[Serg196]

Об аппаратных средствах для ресемплинга - никакой разницы быть не должно. Все равно используются те же алгоритмы - только будучи исполненными на DSP они должны работать существенно быстрее.

а как же:

Смысл может быть в том, чтобы частично обойти менее качественный SRC, встроенный в звуковую карту / АЦП (который осуществляет сигма-дельта преобразование в PCM). Если позволить ему работать на 96 кГц, а потом понизить частоту программно, то это может привести к более качественному результату (в зависимости от соотношения качества SRC в АЦП и программного).
Например, в каких-то старых карточках - то ли Live, то ли Audigy - был только один клок 48 кГц и плохой встроенный ресамплер.

Впрочем. к новым картам это может и не относиться.
А интересно, есть какая-нибудь инфа по тестам аппаратных ресэмплеров?

 

[Alexey Lukin]

Кстати, а может быть для аудиокарт оптимальной частота 88,2 кГц? Частота нестандартная - скорее всего при записи вначале произойдет аппаратная конвертация в частоту 88,2, а затем вторично - программная в 44,1.

Вполне может быть. Так некоторые и делают, если для них это лучше звучит.

Впрочем. к новым картам это может и не относиться.

К новым картам это тоже относится, но в меньшей степени. Стоит ли париться - зависит от конкретной карты и ситуации.

А интересно, есть какая-нибудь инфа по тестам аппаратных ресэмплеров?

По тем, что встроены в звуковую карту - только косвенные данные. А по некоторым железным - есть на том же src.infinitewave.ca. Там есть тесты приборов Weiss и Z-Systems.

 

[olegsound]

просто возьмите проэкт в 24 и 32ух битах, и послушайте его, для меня разница слышна даже на бытовой аппаратуре

Вот так слух у людей - завидую!
У меня мониторы за 4500 баксов, а я не слышу разницу даже если аудио файлы в проекте из 16 бит перевести в 32. Наверно, нужна ещё хорошая аккустическая обработка комнаты...:whistle3:

 

[Ulysses65]

olegsound,

Вот видишь...оказывается дело не в цене rankster2:...а то понакупают себе всяких разных дорогущих моников. а потом 16 от 32 отличить не могут :lol:

 

[zettt]

а как же:

Цитата:
Сообщение от Alexey Lukin




Смысл может быть в том, чтобы частично обойти менее качественный SRC, встроенный в звуковую карту / АЦП (который осуществляет сигма-дельта преобразование в PCM). Если позволить ему работать на 96 кГц, а потом понизить частоту программно, то это может привести к более качественному результату (в зависимости от соотношения качества SRC в АЦП и программного).

Ну я такого не утверждал. Если АЦП плох - то никакие улучшайзеры не помогут. Да и насчет преобразования 24/32 - действительно 32 - это флоат а не целое, поэтому преобразование занимает время а не просто дописывание 0. Кроме того, к сожалению прошли времена, когда простая запись в память, была быстрее мат.исчислений - сейчас сопроцессор считает cos(x) БЫСТРЕЕ, чем ,проц. берет из памяти готовое табличное значение. Поэтому не все так просто. Кроме того, для желающих ознакомится с миром музыкального программирования могу порекомендовать качнуть ASIO SDK из Steinberg-a, и почитать их мануал к библиотеке. Правда нужно немного С++ знать.

 

[Alexey Lukin]

Да и насчет преобразования 24/32 - действительно 32 - это флоат а не целое

Необязательно. Для аудио используется и целочисленный 32-битный формат.

Кроме того, к сожалению прошли времена, когда простая запись в память, была быстрее мат.исчислений - сейчас сопроцессор считает cos(x) БЫСТРЕЕ, чем ,проц. берет из памяти готовое табличное значение.

Не быстрее. Косинус на сопроцессоре по-прежнему считается в десятки раз медленнее, чем берется значение из таблицы.

 

[timbo]

Необязательно. Для аудио используется и целочисленный 32-битный формат.

Но общепринятый (и прописанный в стандарты IEEE) single-presicion floating-point это именно 32 бита. В редакторах насколько знаю в PTHD 48 целочисленный, а вот в микшере М-Аудио Дельты вроде как 36 бит))), логично предположить, что целочисленный.
А вообще у Сонара и Рипера 64 битная математика. Честно скажу, рендерил проекты в 32 и 64 варианте в Сонаре - разницы особой в суммировании не заметно. другое дело для компрессоров/сатураторов 64-бита это полезно.

 

[Serg196]

Ну я такого не утверждал. Если АЦП плох - то никакие улучшайзеры не помогут.

А при чем здесь АЦП?

Да и насчет преобразования 24/32 - действительно 32 - это флоат а не целое, поэтому преобразование занимает время а не просто дописывание 0.

При использовании инструкций преобразования типов не большее, нежели просто масштабирование.

Кроме того, к сожалению прошли времена, когда простая запись в память, была быстрее мат.исчислений - сейчас сопроцессор считает cos(x) БЫСТРЕЕ, чем ,проц. берет из памяти готовое табличное значение. Поэтому не все так просто.

А это к чему, вообще?
Не испытываю никакого сожаления по тем временам, когда на 8087 сопроцессоре операция вычисления косинуса занимала почти столько же времени, сколько и выполнение этого же действия самим процессором.

 

[Serg196]

Вот так слух у людей - завидую!
У меня мониторы за 4500 баксов, а я не слышу разницу даже если аудио файлы в проекте из 16 бит перевести в 32. Наверно, нужна ещё хорошая аккустическая обработка комнаты...:whistle3:

Ну и нафига тебе такой слух? Будешь потом слышать разницу между бинарно идентичными файлами...

 

[Ifrit]

Частота дескретизации сигнала влияет только лишь (или почти только) на верхнюю воспроизводимую частоту, так при 44100 верхняя частота будет 22500 Гц, при 96000 - 48000 гц, поэтому в CD стандарте и выбрана частота дескретизации 44100.

Нет. Частота дискретизации 44100 выбрана была потому, что с ней было удобно записывать материал на видеоносители - мастера для отправки на заводы.

 

[Vasya12341]

"Лучше" - понятие субъективное. Я могу сказать, что с помощью хороших программных можно получить сколь угодно малый уровень тех или иных искажений. У аппаратных я такой гибкости не видел, хотя среди них тоже есть хорошие модели.

И какой на данный момент самый лучший программный ресемплер?
Именно с психоакустической точки зрения?
Чтобы по минимуму фазу крутил,звона меньше всех чтобы было и т.д.

 

[Vasya12341]

Нет. Частота дискретизации 44100 выбрана была потому, что с ней было удобно записывать материал на видеоносители - мастера для отправки на заводы.

Не поэтому.Просто компания "Sony" в целях борьбы с пиратством выбрала такую частоту несовместимую с большинством видеооборудования.Чтобы по цифре перегнать не смогли.

 

[Vladis Udler]

В соответствии с книгой John Waktinson'а _The Art of Digital Audio_, 2-е издание, страница 104, выбор частоты есть артефакт оборудования, используемого при ранних исследованиях цифрового аудио. Хранение цифрового аудио на жестком диске было непрактичным, поскольку емкость, необходимая для значительного количества аудио 1Мб/сек была еще очень дорогой. Вместо этого использовались видеомагнитофоны, на которых сэмплы записывались как уровни черного и белого. Общая частота дискретизации 44.1 КГц была установлена как для формата NTSC, так и для формата PAL (видеостандарты, используемые в США/Японии и Европе соответственно). Эта частота перешла и в определение компакт-диска.

 

[Alexey Lukin]

И какой на данный момент самый лучший программный ресемплер? Именно с психоакустической точки зрения? Чтобы по минимуму фазу крутил,звона меньше всех чтобы было и т.д.

С психоакустической точки зрения - не скажу. А по объективным (измеренным на src.infinitewave.ca) параметрам лучшим получается iZotope SRC (из RX, Wave Editor или Sample Manager). В нем можно настраивать крутизну фильтра (влияющую на количество звона) и степень кручения фазы (влияющую на соотношение пред- и пост-звона).

 

[Ifrit]

Не поэтому.Просто компания "Sony" в целях борьбы с пиратством выбрала такую частоту несовместимую с большинством видеооборудования.Чтобы по цифре перегнать не смогли.

Вам уже Vladis Udler ответил цитатой из Уоткинсона. Читайте информативные источники. Пиратство на тот момент не играло определяющей роли в выборе частоты семплирования. И как раз-таки с БОЛЬШИНСТВОМ видеооборудования эта частота совместима.

А по объективным (измеренным на src.infinitewave.ca) параметрам лучшим получается iZotope SRC

Он очень неплох и по субъективным оценкам - множество пользователей отмечают его качество.

 

[zettt]

Не быстрее. Косинус на сопроцессоре по-прежнему считается в десятки раз медленнее, чем берется значение из таблицы.

Прежде чем такое утверждать, советую попробовать. Будете неприятно удивлены.

 

[zettt]

Не испытываю никакого сожаления по тем временам, когда на 8087 сопроцессоре операция вычисления косинуса занимала почти столько же времени, сколько и выполнение этого же действия самим процессором.

Ну это уже вооще:ireful1: Если бы это было так, сопроцессоров бы несущесвовало.

 

[Feomothar]

Вот я и вернулся) сколько тут понаписано во время моего отсутствия, прям удивило))
Про разницу в звучании файлов при переводе из 24 бит в 32 это конечно я загнул, и в них действительно нет никакой разницы.
Изменение битности проекта с 16 на 32 или с 24 на 32 тоже не приводит к слышимым результатам.
Но тем не менее при массивной обработке разница имеется, которая на слух заметна в той или иной степени. Слышат ее другие или не слышат это не так важно)) Даже если и нет никакой разницы, на душе спокойнее)) работать проще)
Согласитесь, многие из присутствующих сидя на своем рабочем месте, думали, на сколько больше и лучше они моглибы сделать, еслибы мониторы были получше, пуль помягче, много факторов. И какое облегчение, когда нужная вещь приобретается)) вот тут тож самое))

 

[Alexey Lukin]

Прежде чем такое утверждать, советую попробовать. Будете неприятно удивлены.

А мои утверждения как раз и основаны на личном опыте. Операция доступа к памяти занимает 1-5 тактов - как на 8086, так и на Core 2 Duo. А вычисление косинуса - порядка 100-200 тактов, как на 80387, так и на FPU Core 2 Duo.

Вы, кажется, обмолвились о знании C++? Так возьмите и проверьте!

Если бы это было так, сопроцессоров бы несущесвовало.

Я не очень понял фразу Serg196, но на ваш-то вопрос легко ответить: вычисление косинуса на сопроцессоре дает гораздо большую точность, чем таблицы. Я уж не говорю про удобство: одна команда вместо целой подпрограммы.