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

zettt

Active Member
17 Янв 2005
177
26
28
51
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:
Но мы слегка отошли от темы, предлагаю вернуться!
 

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
zettt написал(а):
В инструкциях к процессорам уже давно не пишут четкого
времени выполнения в тактах, из-за изменения в архитектуре процов.
Я и не говорил про четкое время, а дал возможный диапазон. Из него как раз и видно, что fsin в десятки раз медленнее даже при наилучшем раскладе.

zettt написал(а):
А проверять мне нечего, поскольку года два назад, желая написать самую быструю процедуру FFT на ассемблере, я перепробовал все возможное, включая табличные SIN, COS, и SSE команды.
Вы хотя бы знаете, что скорость FFT не зависит от скорости вычисления синусов и косинусов? :girl_sigh: А зависит от скорости вычисления "бабочек" и планирования работы с кэшем. Если бы fsin вычислялся быстрее взятия из таблицы, то самые быстрые FFT на ассемблере (давно уже, кстати, написанные, в том числе - и программистами Intel!) не считали бы таблицы поворачивающих множителей заранее.
Не стоит свой неудачный эксперимент использовать для таких глобальных выводов. Тут некоторые и разницу между 24 и 32 битами "слышат" - это из той же серии...
 
Последнее редактирование:

new user

yankees
11 Фев 2007
774
80
28
43
kyiv
Посетить сайт
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
 

lotas

Well-Known Member
23 Апр 2008
361
606
93
49
Украина
violinmaking.pro
Ifrit написал(а):
Нет. Частота дискретизации 44100 выбрана была потому, что с ней было удобно записывать материал на видеоносители - мастера для отправки на заводы.
:shok: Кому удобно?
Теорема отсчетов гласит: сигнал, спектр частот которого занимает область от -B до +В (низкочастотный сигнал), может быть полностью представлен своими дискретными отсчетами с интервалом Т, если Т больше или равно 1/В. Другими словами, частота дискретизации f=1/Т должна быть как минимум вдвое больше частоты аналогового сигнала Fmax, т.е, F больше или равно 2Fmax. Если это условие не выполняеться, то спектры дискретизации взаимно перекрываються (накладываються один на другой), и адекватно восстановить исходный аналоговый сигнал не возможно.
 

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
lotas,
Ifrit и Vladis Udler правильно написали, почитайте хотя бы Википедию.
Зачем вы нам пересказываете [с ошибками] теорему Котельникова?
 

Ifrit

Злой я
31 Окт 2007
4.153
3.399
113
lotas,
поверьте мне, я хорошо знаком с теорией вообще и с теорией цифрового звука, в частности. Помимо выполнения условий теории, к сожалению, цифровой звуковой поток должен быть перенесен на физический носитель. В те времена, когда разрабатывался КД, самым рациональным носителем такого количества цифровой информации была видеопленка - цифровые отсчеты могли быть записаны на строчные интервалы в виде (грубо говоря) вспышек белого. Количество отсчетов, умещавшихся в количестве ТВ полей в секунду для ПАЛ и НТСЦ было одинаковым и определило частоту семплирования. К тому времени уже существовали цифровые звуковые системы с Fs=48 kHz. Но для изготовителей мастер-лент было УДОБНО использовать видеоносители, которые определяли Fs = 44100.
Кроме теории есть ее практическое воплощение. К тому же, если Вы настолько хорошо "подкованы", объясните мне, почему 44.1, а не 40кГц ровно? ;) Ведь и 40000 будет достаточно, нет?
 

Serg196

Без ансамбля. Сам, бля.
Я не очень понял фразу Serg196...
Поясняю: я говорил о программной эмуляции мат. сопроцессора: при использовании FPU 8087 вычисление тригонометрических функций особого выигрыша не давало по сравнению с его программной эмуляцией. Вот по этим временам я и не испытываю сожаления.
 

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
С этим я согласен, 8087 был медленным. К слову, синусы с косинусами он и не умел считать, они появились в 80387.
 

W@D

New Member
4 Июл 2008
248
47
0
Россия (переферия)
Ifrit написал(а):
Кроме теории есть ее практическое воплощение. К тому же, если Вы настолько хорошо "подкованы", объясните мне, почему 44.1, а не 40кГц ровно? ;) Ведь и 40000 будет достаточно, нет?
В истории сказано: "Взято с запасом..." Некоторые люди слышат выше 20 кГц...
 

Ifrit

Злой я
31 Окт 2007
4.153
3.399
113
W@D написал(а):
Некоторые люди слышат выше 20 кГц.
Нет, не поэтому. Производителям, откровенно говоря, наплевать на всех, кто выделяется из большинства. Так зачем был взят запас? :)
 

Serg196

Без ансамбля. Сам, бля.
Два килогерца - разве это запас?
Вот семьдесят с лихером - это запас - так запас! Аж в три с гаком раза выше диапазона слышимости... :)
Ifrit, а говоришь - производителей не волнует! Смотри, как о народе заботятси! :)
 

zettt

Active Member
17 Янв 2005
177
26
28
51
Alexey Lukin написал(а):
Вы хотя бы знаете, что скорость FFT не зависит от скорости вычисления синусов и косинусов? А зависит от скорости вычисления "бабочек" и планирования работы с кэшем. Если бы fsin вычислялся быстрее взятия из таблицы, то самые быстрые FFT на ассемблере (давно уже, кстати, написанные, в том числе - и программистами Intel!) не считали бы таблицы поворачивающих множителей заранее.
Не стоит свой неудачный эксперимент использовать для таких глобальных выводов. Тут некоторые и разницу между 24 и 32 битами "слышат" - это из той же серии...
.:smile: Ну ща начнется, кто из нас профессор :whistle3: Знаю, конечно. Обычно я пишу только о том, о чем знаю, а так больше привык читать... Но перейдем от слов к делу - я тут наваял тестовую прожку, которая считает тучу косинусов табличным и "сопроцессорным" методом.(Там весь проект, желающие могут откомпилить). Извольте взглянуть - при большых обьемах данных fcos работает БЫСТРЕЕ табличного метода. Мы ведь работаем с большими обьемами данных, не так ли? А 32 бита народ более угадывает а не слышит, и угадывает довольно правильно...
 

Вложения

olegsound

Moderator
4 Май 2004
5.762
2.657
113
48
Украина, Львов
А 32 бита народ более угадывает а не слышит, и угадывает довольно правильно...
Ну сколько можно, уже ж вроде все знают, что загрузи в хост хоть 24, хоть 8-ми битный файл - он в проге всё равно обрабатывается как 32 битный.
 

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
zettt написал(а):
я тут наваял тестовую прожку... Извольте взглянуть - при большых обьемах данных fcos работает БЫСТРЕЕ табличного метода.
Ну вот я и говорю: неумело поставленный эксперимент приводит к неверным выводам! Вы просто не умеете реализовывать табличный метод достаточно быстро. Наваяли что-то на Паскале, заработало медленно - и вы теперь утверждаете, что сопроцессор быстрее - пудрите другим мозги... А для программистов, которые умеют пользоваться табличным методом, косинусы вычисляются в 10 раз быстрее вашей ассемблерной вставки (я только что это проверил на всякий случай на C++).
 

timbo

Well-Known Member
3 Окт 2007
1.627
641
113
olegsound написал(а):
Так зачем был взят запас?
Вы извините, если это из разряда "академики шутят", но раз уж тут вопрос повторяется, постараюсь ответить:scratch_one-s_head:

В общем нужен запас, чтобы обеспечить нормальную работу анти-алиас фильтров. Чтобы цифровой фильтр давал крутую кривую среза, ему нужен длинный kernel. А это DSP и задержка. Т.е. можно было например взять 42000, но чтобы оставить такую же полосу пропускания (20-20000 Гц) нужны гораздо более трудные для реализации фильтры.
 
  • Like
Реакции: olegsound

Serg196

Без ансамбля. Сам, бля.
.:smile: Ну ща начнется, кто из нас профессор :whistle3: Знаю, конечно. Обычно я пишу только о том, о чем знаю, а так больше привык читать... Но перейдем от слов к делу - я тут наваял тестовую прожку, которая считает тучу косинусов табличным и "сопроцессорным" методом.(Там весь проект, желающие могут откомпилить). Извольте взглянуть - при большых обьемах данных fcos работает БЫСТРЕЕ табличного метода. Мы ведь работаем с большими обьемами данных, не так ли? А 32 бита народ более угадывает а не слышит, и угадывает довольно правильно...
В картах это называется передергивание.
Разумеется, в больших массивах при таком сравнении разница будет тем больше, чем более массив.
 

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
Да не, это не страшно. Если и влияет - то не сильно. Там просто сам доступ к таблице сделан очень медленный, можно раз в 10 быстрее.
 

zettt

Active Member
17 Янв 2005
177
26
28
51
Alexey Lukin написал(а):
Ну вот я и говорю: неумело поставленный эксперимент приводит к неверным выводам! Вы просто не умеете реализовывать табличный метод достаточно быстро. Наваяли что-то на Паскале, заработало медленно - и вы теперь утверждаете, что сопроцессор быстрее - пудрите другим мозги... А для программистов, которые умеют пользоваться табличным методом, косинусы вычисляются в 10 раз быстрее вашей ассемблерной вставки (я только что это проверил на всякий случай на C++).
Ну,ну и где же ваш быстрый вариант? Весьма хочется взглянуть, а то кроме безосновательных высопарных замечаний, ничего больше не видно. Ну и метод не самый медленный, взгляните в дизассемблер. Да и какая принципиальная разница на чем писать? Я написал на Delphi потому что тот был под рукой, но вижу, что напиши я на чем-либо другом, результат был бы тот же, поскольку 1)вы всегда правы 2) если вы не правы то см.п.1....Ну да ладно. Если вы напишите то же на С++, будет просто чуть быстрее, пусть даже и в 10 раз.
Serg196 написал(а):
Разумеется, в больших массивах при таком сравнении разница будет тем больше, чем более массив.
Абсолютно согласен. Увеличиваем выборку в 10 раз- и достигаем того же эффекта. Просто фокус в том, что доступ в память производится на меньшей частоте, нежели частота процессора, поэтому уменьшаем количество обращений к памяти - получаем выиграш в скорости. Если данные полностью попадают в кэш, то табличный метод естественно работает быстрее. И конечно он оправдан, если предварительно считать в таблицу сложные
выражения, которых нет в виде готовых инструкций процессора.
 

Serg196

Без ансамбля. Сам, бля.
Абсолютно согласен. Увеличиваем выборку в 10 раз- и достигаем того же эффекта. Просто фокус в том, что доступ в память производится на меньшей частоте, нежели частота процессора, поэтому уменьшаем количество обращений к памяти - получаем выиграш в скорости. Если данные полностью попадают в кэш, то табличный метод естественно работает быстрее. И конечно он оправдан, если предварительно считать в таблицу сложные
выражения, которых нет в виде готовых инструкций процессора.
Да нет, вы меня оба не поняли - ни Лукин, ни ты.
Я имел в виду, что имхо, эксперимент поставлен некорректно.
Если уж ты для вычисления косинусов сопроцессором применил ассемблерную вставку, то отчего не сделал то же для табличного вычисления?

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

zettt

Active Member
17 Янв 2005
177
26
28
51
Все я четко понял....Ладно ребята, замучился я уже с вами спорить, время даром терять, да и другим это читать уж влом. Не хотите видеть очевидного - дело ваше. Просто для массивов компилятор генерит достаточно оптимальный код, и переписывать его на асме большого смысла нет, поскольку всегда можно увеличить N до такой степени, что любой оптимальный табличний алгоритм на два часа загнется. Хотелось бы заценить творение мсье Лукина, тем более если оно у него готово, и если уважаемые модераторы не прикроют эту ветку, увязшую в мелочах программирования, то после ознакомления с его кодом, я отвечу.
 

Vladis Udler

Poorly Known Member
31 Июл 2006
5.623
3.919
113
58
Tomsk
Отчего же..занимательное чтиво. Косинусы-синусы -это все в тональности крести козыри (Am) надеюсь.:whistle3:
 

Испанский ГалстоГ

▬▬▬▬▬▬▬▬
20 Янв 2006
2.871
909
113
43
г. Саратов
в чем полемика то... хосты все изначально в 32 крутят - так в ней и надо работать, что конвертить туда-сюда. дисковое пространство сейчас дешевое. а 192 и 44100 оборудование ценовой категории до xx xxx баксов пишет одинаково ))) а серьезно работать в 192 как уже сказали - дорого, да и 100 раз уже перетерли что смысл имеет только когда выводят в аналог дорогой или пишут на носитель 192 в таком формате. А для сиди наххх... эти огороды городить. ))) Притом ХА ХА ХА ГЫ ГЫ самое смешное: у кого качественное оборудование и в 44 100 пишут нормально, а на "хоум студиях" залупившись на 192 получите только то... что половина единственного инвентаря - халявных вст - будет глюкаво работать и звучать не правильно. и больше чем уверен что ориентированы на выхлоп в 128 Kbps в инет )))))
 

Alexey Lukin

Well-Known Member
11 Июн 2003
1.983
1.446
113
42
audio.rightmark.org
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

Serg196

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

NB прошу пардону за офтоп,
Alexey Lukin, а что, декремент есх и условный переход выполняются быстрее инструкции loop?
зы ай-яй-яй, а сопроцессор у тебя все-таки используется :)
 
Последнее редактирование:

Испанский ГалстоГ

▬▬▬▬▬▬▬▬
20 Янв 2006
2.871
909
113
43
г. Саратов
Serg196 смысл есть имхо. Раз нуендо работает в 32 и только в 32 есть смысл сразу организовать проекты в этом формате. Плаги тоже, согласно того же SDK обмениваются даными с хостом только на 32* и незная чего там не творится. А вот если пихать в хост разные форматы - то 24, то 16 то как раз незнай чего и будет происходить ) А скорости и объема винтов более чем хватет, чтобы не экономить на этом. Ну... я предпочитаю чтобы все было четко ))
 

Serg196

Без ансамбля. Сам, бля.
Да, в несколько раз (на современных процессорах).
Ага, в самом деле, поискал инфу в сети - удивлен...
Впрочем, на асме давно уже не пишу, пусть с машинными инструкциями компиляторы сами разбираются...
 

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