44100 или 96000? (1 онлайн

Vladis Udler

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

P00H

New Member
12 Мар 2004
8.192
2.789
0
57
Moscow
Vladis Udler написал(а):
Но только лишь потому,чтобы уменьшить количество вычислений на компе..т.е. хосту уже не надо "налету" конвертить файл 24-32-24 так как он файл уже 32 битный. По моим наблюдениям компу работалось легче(вроде как)
вот именно что (вроде как), т.к. в реальности при исходных 32 битных треках компу работается гораздо тяжелее чем при 24 битных, чтобы это выяснить достаточно запустить проект из нескольких десятков аудио треков вообще без всяких обработок и посмотреть на загрузку проца в случае чтения с винта 24 битных исходников и в случае 32 битных :prankster2:
з.ы. а насчёт дополнительной нагрузки на процессор от конвертации на лету кстати распостранённое заблуждение, т.к. при конвертации что на лету, что в офлайне из 24 в 32 нет вообще никаких вычислений, просто нули добавляются в конце слова и всё.
 

lotas

Well-Known Member
23 Апр 2008
361
606
93
49
Украина
violinmaking.pro
Частота дескретизации сигнала влияет только лишь (или почти только:)) на верхнюю воспроизводимую частоту, так при 44100 верхняя частота будет 22500 Гц, при 96000 - 48000 гц, поэтому в CD стандарте и выбрана частота дескретизации 44100.
 

Vladis Udler

Poorly Known Member
31 Июл 2006
5.622
3.919
113
58
Tomsk
вот именно что (вроде как), т.к. в реальности при исходных 32 битных треках компу работается гораздо тяжелее чем при 24 битных, чтобы это выяснить достаточно запустить проект из нескольких десятков аудио треков вообще без всяких обработок и посмотреть на загрузку проца в случае чтения с винта 24 битных исходников и в случае 32 битных :prankster2:
з.ы. а насчёт дополнительной нагрузки на процессор от конвертации на лету кстати распостранённое заблуждение, т.к. при конвертации что на лету, что в офлайне из 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

Active Member
17 Янв 2005
177
26
28
51
Serg196 написал(а):
...как-то выкладывал здесь тесты ресемплеров разных хостов, так вот заметность искажений была чрезвычайно невелика, зачастую ниже уровня слухового восприятия
Согласен, просто выше счет вроде шел "на микроны":)
Serg196 написал(а):
Речь-то идет о том, сколько разрядов использовать для хранения аудиоданных на треках, а не о том, сколько из использовать внутри хоста!
Согласен, если хост не имеет подводных особенностей. ********** Об аппаратных средствах для ресемплинга - никакой разницы быть не должно. Все равно используются те же алгоритмы - только будучи исполненными на DSP они должны работать существенно быстрее.
 

Novation

Несміла
17 Ноя 2006
2.267
2.235
113
45
Еквестрія
"...только будучи исполненными на 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

Moder-Inquisitor
16 Янв 2003
5.055
925
113
49
Москва
www.adapter.su
НАРОД!!!!
давайте топ прикроем, реально уже начали впадать в маразм, надо еще и запретить в правилах сравнивание частот записи, иначе докатимся, до того что мол при черном цвете монитора звук более насыщенный
 

P00H

New Member
12 Мар 2004
8.192
2.789
0
57
Moscow
да последние страницы хоть реальная инфа идёт, а не из области "я так слышу" , пущай народ просвещается :prankster2:
 

Serg196

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

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

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
Serg196 написал(а):
Кстати, а может быть для аудиокарт оптимальной частота 88,2 кГц? Частота нестандартная - скорее всего при записи вначале произойдет аппаратная конвертация в частоту 88,2, а затем вторично - программная в 44,1.
Вполне может быть. Так некоторые и делают, если для них это лучше звучит.


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


Serg196 написал(а):
А интересно, есть какая-нибудь инфа по тестам аппаратных ресэмплеров?
По тем, что встроены в звуковую карту - только косвенные данные. А по некоторым железным - есть на том же src.infinitewave.ca. Там есть тесты приборов Weiss и Z-Systems.
 
  • Like
Реакции: Novation и Serg196

olegsound

Moderator
4 Май 2004
5.762
2.657
113
48
Украина, Львов
просто возьмите проэкт в 24 и 32ух битах, и послушайте его, для меня разница слышна даже на бытовой аппаратуре
Вот так слух у людей - завидую!
У меня мониторы за 4500 баксов, а я не слышу разницу даже если аудио файлы в проекте из 16 бит перевести в 32. Наверно, нужна ещё хорошая аккустическая обработка комнаты...:whistle3:
 
  • Like
Реакции: bruno_banano

zettt

Active Member
17 Янв 2005
177
26
28
51
Serg196 написал(а):
а как же:

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




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

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
zettt написал(а):
Да и насчет преобразования 24/32 - действительно 32 - это флоат а не целое
Необязательно. Для аудио используется и целочисленный 32-битный формат.

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

timbo

Well-Known Member
3 Окт 2007
1.627
641
113
Alexey Lukin написал(а):
Необязательно. Для аудио используется и целочисленный 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

Злой я
31 Окт 2007
4.153
3.399
113
lotas написал(а):
Частота дескретизации сигнала влияет только лишь (или почти только:)) на верхнюю воспроизводимую частоту, так при 44100 верхняя частота будет 22500 Гц, при 96000 - 48000 гц, поэтому в CD стандарте и выбрана частота дескретизации 44100.
Нет. Частота дискретизации 44100 выбрана была потому, что с ней было удобно записывать материал на видеоносители - мастера для отправки на заводы.
 

Vasya12341

Active Member
22 Дек 2007
174
28
28
Alexey Lukin написал(а):
"Лучше" - понятие субъективное. Я могу сказать, что с помощью хороших программных можно получить сколь угодно малый уровень тех или иных искажений. У аппаратных я такой гибкости не видел, хотя среди них тоже есть хорошие модели.
И какой на данный момент самый лучший программный ресемплер?
Именно с психоакустической точки зрения?
Чтобы по минимуму фазу крутил,звона меньше всех чтобы было и т.д.
 

Vasya12341

Active Member
22 Дек 2007
174
28
28
Ifrit написал(а):
Нет. Частота дискретизации 44100 выбрана была потому, что с ней было удобно записывать материал на видеоносители - мастера для отправки на заводы.
Не поэтому.Просто компания "Sony" в целях борьбы с пиратством выбрала такую частоту несовместимую с большинством видеооборудования.Чтобы по цифре перегнать не смогли.
 
Последнее редактирование:

Vladis Udler

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

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
Vasya12341 написал(а):
И какой на данный момент самый лучший программный ресемплер? Именно с психоакустической точки зрения? Чтобы по минимуму фазу крутил,звона меньше всех чтобы было и т.д.
С психоакустической точки зрения - не скажу. А по объективным (измеренным на src.infinitewave.ca) параметрам лучшим получается iZotope SRC (из RX, Wave Editor или Sample Manager). В нем можно настраивать крутизну фильтра (влияющую на количество звона) и степень кручения фазы (влияющую на соотношение пред- и пост-звона).
 

Ifrit

Злой я
31 Окт 2007
4.153
3.399
113
Vasya12341 написал(а):
Не поэтому.Просто компания "Sony" в целях борьбы с пиратством выбрала такую частоту несовместимую с большинством видеооборудования.Чтобы по цифре перегнать не смогли.
Вам уже Vladis Udler ответил цитатой из Уоткинсона. Читайте информативные источники. Пиратство на тот момент не играло определяющей роли в выборе частоты семплирования. И как раз-таки с БОЛЬШИНСТВОМ видеооборудования эта частота совместима. :)

Alexey Lukin написал(а):
А по объективным (измеренным на src.infinitewave.ca) параметрам лучшим получается iZotope SRC
Он очень неплох и по субъективным оценкам - множество пользователей отмечают его качество.
 

zettt

Active Member
17 Янв 2005
177
26
28
51
Alexey Lukin написал(а):
Не быстрее. Косинус на сопроцессоре по-прежнему считается в десятки раз медленнее, чем берется значение из таблицы.
Прежде чем такое утверждать, советую попробовать. Будете неприятно удивлены.
 

zettt

Active Member
17 Янв 2005
177
26
28
51
Serg196 написал(а):
Не испытываю никакого сожаления по тем временам, когда на 8087 сопроцессоре операция вычисления косинуса занимала почти столько же времени, сколько и выполнение этого же действия самим процессором.
Ну это уже вооще:ireful1: Если бы это было так, сопроцессоров бы несущесвовало.
 

Feomothar

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

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
zettt написал(а):
Прежде чем такое утверждать, советую попробовать. Будете неприятно удивлены.
А мои утверждения как раз и основаны на личном опыте. Операция доступа к памяти занимает 1-5 тактов - как на 8086, так и на Core 2 Duo. А вычисление косинуса - порядка 100-200 тактов, как на 80387, так и на FPU Core 2 Duo.

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



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

Сейчас онлайн (Пользователей: 0, Гостей: 1)