44100 или 96000?

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

Вы, кажется, обмолвились о знании C++? Так возьмите и проверьте!
Не надо лишних эмоций... В инструкциях к процессорам уже давно не пишут четкого
времени выполнения в тактах, из-за изменения в архитектуре процов. Это уже RISC а не CISC структура, и скорость увеличивается уже не пропорционально рабочей частоте. А проверять мне нечего, поскольку года два назад, желая написать самую быструю процедуру FFT на ассемблере, я перепробовал все возможное, включая табличные SIN, COS, и SSE команды. И был просто поражен, таким казалось бы нелогичным фактом, когда набор fsin, работает быстрее чем выборка из массива const_sin[x] . Но природу вещей к сожалению изменить нельзя.:victory:
Но мы слегка отошли от темы, предлагаю вернуться!
 
zettt написал(а):
В инструкциях к процессорам уже давно не пишут четкого
времени выполнения в тактах, из-за изменения в архитектуре процов.
Я и не говорил про четкое время, а дал возможный диапазон. Из него как раз и видно, что fsin в десятки раз медленнее даже при наилучшем раскладе.

zettt написал(а):
А проверять мне нечего, поскольку года два назад, желая написать самую быструю процедуру FFT на ассемблере, я перепробовал все возможное, включая табличные SIN, COS, и SSE команды.
Вы хотя бы знаете, что скорость FFT не зависит от скорости вычисления синусов и косинусов? :girl_sigh: А зависит от скорости вычисления "бабочек" и планирования работы с кэшем. Если бы fsin вычислялся быстрее взятия из таблицы, то самые быстрые FFT на ассемблере (давно уже, кстати, написанные, в том числе - и программистами Intel!) не считали бы таблицы поворачивающих множителей заранее.
Не стоит свой неудачный эксперимент использовать для таких глобальных выводов. Тут некоторые и разницу между 24 и 32 битами "слышат" - это из той же серии...
 
Последнее редактирование:
There are reports of better sound with higher sampling rates. No doubt, the folks that like the "sound of a 192KHz" converter hear something. Clearly it has nothing to do with more bandwidth: the instruments make next to no 96KHz sound, the microphones don't respond to it, the speakers don't produce it, and the ear can not hear it. Moreover, we hear some reports about "some of that special quality captured by that 192KHz is retained when down sampling to 44.1KHz. Such reports neglect the fact that a 44.1KHz
sampled material can not contain above 22.05KHz of audio.
Some claim that that 192K is closer to the audio tape. That same tape that typically contains "only" 20KHz of audio gets converted to digital by a 192K AD, than stripped out of all possible content above 22KHz (down sample to CD). “If you hear it, there is something there” is an artistic statement. If you like it and want to use it, go ahead. But whatever you hear is not due to energy above audio. All is contained within the "lower band". It could be certain type of distortions that sound good to you.
Can it be that someone made a real good 192KHz device, and even after down sampling it has fewer distortions? Not likely.

The same converter architecture can be optimized for slower rates and with more time to process it should be more accurate (less distortions). The danger here is that people who hear something they like may associate better sound with faster sampling, wider bandwidth, and higher accuracy. This indirectly implies that lower rates
are inferior. Whatever one hears on a 192KHz system can be introduced into a 96KHz system, and much of it into lower sampling rates. That includes any distortions associated with 192KHz gear, much of which is due to insufficient time to achieve the level of accuracy of slower sampling.

Operating at 192KHz causes a very significant increase in the required processing power, resulting in very costly gear and/or further compromise in audio quality.
Dan Lavry, Lavry Engineering, Inc
 
Ifrit написал(а):
Нет. Частота дискретизации 44100 выбрана была потому, что с ней было удобно записывать материал на видеоносители - мастера для отправки на заводы.
:shok: Кому удобно?
Теорема отсчетов гласит: сигнал, спектр частот которого занимает область от -B до +В (низкочастотный сигнал), может быть полностью представлен своими дискретными отсчетами с интервалом Т, если Т больше или равно 1/В. Другими словами, частота дискретизации f=1/Т должна быть как минимум вдвое больше частоты аналогового сигнала Fmax, т.е, F больше или равно 2Fmax. Если это условие не выполняеться, то спектры дискретизации взаимно перекрываються (накладываються один на другой), и адекватно восстановить исходный аналоговый сигнал не возможно.
 
lotas,
Ifrit и Vladis Udler правильно написали, почитайте хотя бы Википедию.
Зачем вы нам пересказываете [с ошибками] теорему Котельникова?
 
lotas,
поверьте мне, я хорошо знаком с теорией вообще и с теорией цифрового звука, в частности. Помимо выполнения условий теории, к сожалению, цифровой звуковой поток должен быть перенесен на физический носитель. В те времена, когда разрабатывался КД, самым рациональным носителем такого количества цифровой информации была видеопленка - цифровые отсчеты могли быть записаны на строчные интервалы в виде (грубо говоря) вспышек белого. Количество отсчетов, умещавшихся в количестве ТВ полей в секунду для ПАЛ и НТСЦ было одинаковым и определило частоту семплирования. К тому времени уже существовали цифровые звуковые системы с Fs=48 kHz. Но для изготовителей мастер-лент было УДОБНО использовать видеоносители, которые определяли Fs = 44100.
Кроме теории есть ее практическое воплощение. К тому же, если Вы настолько хорошо "подкованы", объясните мне, почему 44.1, а не 40кГц ровно? ;) Ведь и 40000 будет достаточно, нет?
 
Я не очень понял фразу Serg196...
Поясняю: я говорил о программной эмуляции мат. сопроцессора: при использовании FPU 8087 вычисление тригонометрических функций особого выигрыша не давало по сравнению с его программной эмуляцией. Вот по этим временам я и не испытываю сожаления.
 
С этим я согласен, 8087 был медленным. К слову, синусы с косинусами он и не умел считать, они появились в 80387.
 
Ifrit написал(а):
Кроме теории есть ее практическое воплощение. К тому же, если Вы настолько хорошо "подкованы", объясните мне, почему 44.1, а не 40кГц ровно? ;) Ведь и 40000 будет достаточно, нет?
В истории сказано: "Взято с запасом..." Некоторые люди слышат выше 20 кГц...
 
W@D написал(а):
Некоторые люди слышат выше 20 кГц.
Нет, не поэтому. Производителям, откровенно говоря, наплевать на всех, кто выделяется из большинства. Так зачем был взят запас? :)
 
Два килогерца - разве это запас?
Вот семьдесят с лихером - это запас - так запас! Аж в три с гаком раза выше диапазона слышимости... :)
Ifrit, а говоришь - производителей не волнует! Смотри, как о народе заботятси! :)
 
Alexey Lukin написал(а):
Вы хотя бы знаете, что скорость FFT не зависит от скорости вычисления синусов и косинусов? А зависит от скорости вычисления "бабочек" и планирования работы с кэшем. Если бы fsin вычислялся быстрее взятия из таблицы, то самые быстрые FFT на ассемблере (давно уже, кстати, написанные, в том числе - и программистами Intel!) не считали бы таблицы поворачивающих множителей заранее.
Не стоит свой неудачный эксперимент использовать для таких глобальных выводов. Тут некоторые и разницу между 24 и 32 битами "слышат" - это из той же серии...
.:smile: Ну ща начнется, кто из нас профессор :whistle3: Знаю, конечно. Обычно я пишу только о том, о чем знаю, а так больше привык читать... Но перейдем от слов к делу - я тут наваял тестовую прожку, которая считает тучу косинусов табличным и "сопроцессорным" методом.(Там весь проект, желающие могут откомпилить). Извольте взглянуть - при большых обьемах данных fcos работает БЫСТРЕЕ табличного метода. Мы ведь работаем с большими обьемами данных, не так ли? А 32 бита народ более угадывает а не слышит, и угадывает довольно правильно...
 

Вложения

  • ScreenSht.PNG
    ScreenSht.PNG
    5,1 KB · Просмотры: 71
  • test_fcos.rar
    test_fcos.rar
    164 KB · Просмотры: 11
А 32 бита народ более угадывает а не слышит, и угадывает довольно правильно...
Ну сколько можно, уже ж вроде все знают, что загрузи в хост хоть 24, хоть 8-ми битный файл - он в проге всё равно обрабатывается как 32 битный.
 
zettt написал(а):
я тут наваял тестовую прожку... Извольте взглянуть - при большых обьемах данных fcos работает БЫСТРЕЕ табличного метода.
Ну вот я и говорю: неумело поставленный эксперимент приводит к неверным выводам! Вы просто не умеете реализовывать табличный метод достаточно быстро. Наваяли что-то на Паскале, заработало медленно - и вы теперь утверждаете, что сопроцессор быстрее - пудрите другим мозги... А для программистов, которые умеют пользоваться табличным методом, косинусы вычисляются в 10 раз быстрее вашей ассемблерной вставки (я только что это проверил на всякий случай на C++).
 
olegsound написал(а):
Так зачем был взят запас?

Вы извините, если это из разряда "академики шутят", но раз уж тут вопрос повторяется, постараюсь ответить:scratch_one-s_head:

В общем нужен запас, чтобы обеспечить нормальную работу анти-алиас фильтров. Чтобы цифровой фильтр давал крутую кривую среза, ему нужен длинный kernel. А это DSP и задержка. Т.е. можно было например взять 42000, но чтобы оставить такую же полосу пропускания (20-20000 Гц) нужны гораздо более трудные для реализации фильтры.
 
  • Like
Реакции: olegsound
.:smile: Ну ща начнется, кто из нас профессор :whistle3: Знаю, конечно. Обычно я пишу только о том, о чем знаю, а так больше привык читать... Но перейдем от слов к делу - я тут наваял тестовую прожку, которая считает тучу косинусов табличным и "сопроцессорным" методом.(Там весь проект, желающие могут откомпилить). Извольте взглянуть - при большых обьемах данных fcos работает БЫСТРЕЕ табличного метода. Мы ведь работаем с большими обьемами данных, не так ли? А 32 бита народ более угадывает а не слышит, и угадывает довольно правильно...
В картах это называется передергивание.
Разумеется, в больших массивах при таком сравнении разница будет тем больше, чем более массив.
 
Да не, это не страшно. Если и влияет - то не сильно. Там просто сам доступ к таблице сделан очень медленный, можно раз в 10 быстрее.
 
Alexey Lukin написал(а):
Ну вот я и говорю: неумело поставленный эксперимент приводит к неверным выводам! Вы просто не умеете реализовывать табличный метод достаточно быстро. Наваяли что-то на Паскале, заработало медленно - и вы теперь утверждаете, что сопроцессор быстрее - пудрите другим мозги... А для программистов, которые умеют пользоваться табличным методом, косинусы вычисляются в 10 раз быстрее вашей ассемблерной вставки (я только что это проверил на всякий случай на C++).
Ну,ну и где же ваш быстрый вариант? Весьма хочется взглянуть, а то кроме безосновательных высопарных замечаний, ничего больше не видно. Ну и метод не самый медленный, взгляните в дизассемблер. Да и какая принципиальная разница на чем писать? Я написал на Delphi потому что тот был под рукой, но вижу, что напиши я на чем-либо другом, результат был бы тот же, поскольку 1)вы всегда правы 2) если вы не правы то см.п.1....Ну да ладно. Если вы напишите то же на С++, будет просто чуть быстрее, пусть даже и в 10 раз.
Serg196 написал(а):
Разумеется, в больших массивах при таком сравнении разница будет тем больше, чем более массив.
Абсолютно согласен. Увеличиваем выборку в 10 раз- и достигаем того же эффекта. Просто фокус в том, что доступ в память производится на меньшей частоте, нежели частота процессора, поэтому уменьшаем количество обращений к памяти - получаем выиграш в скорости. Если данные полностью попадают в кэш, то табличный метод естественно работает быстрее. И конечно он оправдан, если предварительно считать в таблицу сложные
выражения, которых нет в виде готовых инструкций процессора.
 
Абсолютно согласен. Увеличиваем выборку в 10 раз- и достигаем того же эффекта. Просто фокус в том, что доступ в память производится на меньшей частоте, нежели частота процессора, поэтому уменьшаем количество обращений к памяти - получаем выиграш в скорости. Если данные полностью попадают в кэш, то табличный метод естественно работает быстрее. И конечно он оправдан, если предварительно считать в таблицу сложные
выражения, которых нет в виде готовых инструкций процессора.

Да нет, вы меня оба не поняли - ни Лукин, ни ты.
Я имел в виду, что имхо, эксперимент поставлен некорректно.
Если уж ты для вычисления косинусов сопроцессором применил ассемблерную вставку, то отчего не сделал то же для табличного вычисления?

Нету дома никаких инструментов, выложи дизассемблированный кусочек - цикл, в котором производится вычисление косинуса при помощи таблицы.
 
Все я четко понял....Ладно ребята, замучился я уже с вами спорить, время даром терять, да и другим это читать уж влом. Не хотите видеть очевидного - дело ваше. Просто для массивов компилятор генерит достаточно оптимальный код, и переписывать его на асме большого смысла нет, поскольку всегда можно увеличить N до такой степени, что любой оптимальный табличний алгоритм на два часа загнется. Хотелось бы заценить творение мсье Лукина, тем более если оно у него готово, и если уважаемые модераторы не прикроют эту ветку, увязшую в мелочах программирования, то после ознакомления с его кодом, я отвечу.
 
Отчего же..занимательное чтиво. Косинусы-синусы -это все в тональности крести козыри (Am) надеюсь.:whistle3:
 
в чем полемика то... хосты все изначально в 32 крутят - так в ней и надо работать, что конвертить туда-сюда. дисковое пространство сейчас дешевое. а 192 и 44100 оборудование ценовой категории до xx xxx баксов пишет одинаково ))) а серьезно работать в 192 как уже сказали - дорого, да и 100 раз уже перетерли что смысл имеет только когда выводят в аналог дорогой или пишут на носитель 192 в таком формате. А для сиди наххх... эти огороды городить. ))) Притом ХА ХА ХА ГЫ ГЫ самое смешное: у кого качественное оборудование и в 44 100 пишут нормально, а на "хоум студиях" залупившись на 192 получите только то... что половина единственного инвентаря - халявных вст - будет глюкаво работать и звучать не правильно. и больше чем уверен что ориентированы на выхлоп в 128 Kbps в инет )))))
 
zettt написал(а):
Ну,ну и где же ваш быстрый вариант?
Пожалуйста. Вот ваш код:
__asm {
mov esi, pCosineArgs
mov ecx, 10000000
cycle:
fld qword ptr [esi]
fcos
fstp res
add esi, 8
loop cycle
}
Выполняется 550 мс.

Вот мой код:
__asm {
mov ecx, 10000000
mov esi, pCosineArgs
mov edi, pCosineTable
fld qword ptr fScaleFactor
cycle:
fld st(0)
fmul qword ptr [esi]
add esi, 8
fistp ind
mov ebx, ind
mov eax, dword ptr [edi+ebx*8]
mov edx, dword ptr [edi+ebx*8+4]
mov dword ptr res, eax
mov dword ptr res[4], edx
dec ecx
jnz cycle
fstp st(0)
}
Выполняется 50-60 мс при разумных размерах таблицы (10000-100000 элементов, больше никто не использует).

zettt написал(а):
Весьма хочется взглянуть, а то кроме безосновательных высопарных замечаний, ничего больше не видно.
Безосновательные?? Я привел время выполнения инструкций в циклах, я сослался на опыт передовых разработчиков. Какие еще вам доказательства нужны? Ваши 500-мегабайтные таблицы, для которых выполнение моего и вашего кода сравнимо по времени, не имеют никакого отношения к реальности.

Замечу, что в реальных процедурах FFT нет необходимости даже в таком табличном коде, и все выполняется еще в разы быстрее.
 
Последнее редактирование:
  • Like
Реакции: SoNick
Испанский Галстог,
хосты все изначально в 32 крутят - так в ней и надо работать, что конвертить туда-сюда.
Э-э... рендерить в файл тоже в 32, чтоль?
Да и треки хранить в 32 не вижу особого смысла... Точнее, вообще не вижу смысла... Все равно при обработке происходит черт те что с содержимым, никакая конвертация и близко не лежит...

NB прошу пардону за офтоп,
Alexey Lukin, а что, декремент есх и условный переход выполняются быстрее инструкции loop?
зы ай-яй-яй, а сопроцессор у тебя все-таки используется :)
 
Последнее редактирование:
Serg196 смысл есть имхо. Раз нуендо работает в 32 и только в 32 есть смысл сразу организовать проекты в этом формате. Плаги тоже, согласно того же SDK обмениваются даными с хостом только на 32* и незная чего там не творится. А вот если пихать в хост разные форматы - то 24, то 16 то как раз незнай чего и будет происходить ) А скорости и объема винтов более чем хватет, чтобы не экономить на этом. Ну... я предпочитаю чтобы все было четко ))
 
Да, в несколько раз (на современных процессорах).
Ага, в самом деле, поискал инфу в сети - удивлен...
Впрочем, на асме давно уже не пишу, пусть с машинными инструкциями компиляторы сами разбираются...
 

Сейчас просматривают