Нужны звуковые эффекты из Batty побитно

[Barmaley_m]

Это разве что в плохом эмуляторе не будет никакого ФНЧ. В том же старом добром Unreal он вполне приличный (свертка по х64 оверсемплинга)

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

В обоих случаях звуковой редактор не нужен.

Звуковой редактор может пригодиться для монтажа звука или наложения спецэффектов. А улучшить с его помощью исходно плохое качество звука невозможно.

- - - Добавлено - - -

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

Если в звуковом редакторе можно сделать лучше, чем делает эмулятор - то это значит, что эмулятор нуждается в улучшении обработки сигнала.

Нет таких секретных волшебных методов обработки сигнала, которые можно было бы реализовать в звуковом редакторе и нельзя - в эмуляторе.

[ZXMAK]

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

В обоих случаях звуковой редактор не нужен.

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

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

Если в звуковом редакторе можно сделать лучше, чем делает эмулятор - то это значит, что эмулятор нуждается в улучшении обработки сигнала.

Нет таких секретных волшебных методов обработки сигнала, которые можно было бы реализовать в звуковом редакторе и нельзя - в эмуляторе.

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


Чтобы было понятней, можно сравнить процесс с сохранением видеофайла. Если программа сохраняет файл со сжатием с потерями, то такое сжатие добавляет артефакты в изображение. Поэтому восстановить исходное изображение и перекодировтаь более качественно уже не получится - информация потеряна. Однако если программа сохраняет видео в формате без потерь, то вы всегда можете перепаковать в видеоредакторе видео гораздо более качественее, чем это можно сделать при записи видеофайла из программы в реальном времени.

Также точно и со звуком. Децимация - это по сути сжатие с потерями.

[Barmaley_m]

...гораздо более качественные фильтры и более сложную обработку, чем это возможно в эмуляторе, где важна скорость эмуляции.
В эмуляторе не может быть высококачественного фильтра, т.к. эмуляторы заточены на скоростную обработку в реальном времени. Применять тяжеловесные высококачественные фильтры в эмуляторе нет возможности.

Думаю, что есть. Я делал в 2002г эмулятор звука Atari800 - проект "mzpokeysnd". Не знаю, что осталось от моего кода в текущей версии эмулятора, но на тот момент это был прорыв, т.к. ранее использовалась лишь линейная интерполяция.

Переходная полоса ФНЧ была от 17000 до 22050 Гц, отклонение в полосе пропускания не более 1% (0.07дБ), подавление в полосе подавления сейчас точно уже не помню, но не менее 80дБ. И это все работало на том Pentium III, где я это все налаживал, без большого напряжения вычислительных ресурсов. Работало у многих людей и на вторых пентиумах. На первом пентиуме 133МГц тормозило, но 8кГц моно еще вытягивало. При этом общая частота дискретизации была в районе 1,7 МГц, 4 AY-подобных канала.

С тех пор я узнал о еще более мощных методах оптимизации фильтров и вообще все прошедшие годы профессионально занимался цифровой обработкой сигналов.

Думаю, что для современных компьютеров не представляет проблемы такая эмуляция бипера и AY в реальном времени, чтобы выходной сигнал на частоте дискретизации 44100 или 48000Гц был полностью свободен от заметных (объективными измерениями, а не только на слух) искажений Aliasing. Могу конкретно помочь с твоим эмулятором. Исходники вроде есть в открытом доступе. Могу посмотреть на новогодних каникулах и (если увижу возможность улучшения) помочь.

[ZXMAK]

Думаю, что есть. Я делал в 2002г эмулятор звука Atari800 - проект "mzpokeysnd". Не знаю, что осталось от моего кода в текущей версии эмулятора, но на тот момент это был прорыв, т.к. ранее использовалась лишь линейная интерполяция.

Переходная полоса ФНЧ была от 17000 до 22050 Гц, отклонение в полосе пропускания не более 1% (0.07дБ), подавление в полосе подавления сейчас точно уже не помню, но не менее 80дБ. И это все работало на том Pentium III

Это зависит от того, что вы понимаете под "качественным фильтром".

Для сравнения вот хороший FIR ФНЧ фильтр с указанными вами параметрами (17000-22050, 80 дБ), длина фильтра 3476 тапов:


А вот более качественный на (20000-21000, 200 дБ), длина фильтра 46807 тапов:


Первый и так тяжеловесный для эмулятора, но второй требует в десять раз большую производительность. А добавить сюда еще ФВЧ... Для обработки в аудиоредакторе это не имеет значения, а вот для эмулятора критично, т.к. он не может отдавать всю мощность процессора только на фильтр для звука, нужно еще выполнять основную задачу...

[Barmaley_m]

Первый и так тяжеловесный для эмулятора, но второй требует в десять раз большую производительность. А добавить сюда еще ФВЧ...

Такие фильтры "в лоб", прямым методом считать, к счастью, не нужно. Даже порядок фильтра имеет мало значения, если реализация использует соответствующие трюки. Я выше упоминал "использование кусочного постоянства входного сигнала", который применил для Atari. Есть и другие. Можно даже без умножения сделать фильтр с весьма впечатляющими характеристиками. В общем, погоди немного, я гляну в твой эмулятор, что там можно сделать, и приду с конкретными предложениями.

С ФВЧ вообще легко, он работает на выходной частоте (44100Гц), рекурсивный фильтр первого порядка. Можно реализовать без умножения, только с битовыми сдвигами.

И еще, я считаю, что 200дБ подавление и переходная полоса 20000-21000Гц - это перебор. -200дБ лежит гораздо ниже разрешающей способности 16-битного сигнала - поэтому искажения Aliasing будут много меньше погрешности квантования. Также и подавление с 21000Гц вместо 22050 - это излишне. До 22050 мы имеем полное право оставить сигналы, тем более, что они там частично подавлены. 20000 полосу пропускания можно оставить, хотя это только для юных слушателей. В 18 лет я такое слышал, а сейчас - уши уже не те.

Для практической разработки, думаю, надо задаться разумными требованиями, а не такими, которые и проверить-то не на чем будет, ибо нету таких усилителей, наушников или колонок, доступных для простого смертного. И ушей таких тоже почти ни у кого нет. А вот разумные требования стандартов Hi-Fi или даже Hi-End в эмуляторе реализовать без чрезмерной нагрузки на проц будет вполне возможно.

[Titus]

С ФВЧ вообще легко, он работает на выходной частоте (44100Гц), рекурсивный фильтр первого порядка. Можно реализовать без умножения, только с битовыми сдвигами.

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

- - - Добавлено - - -

И еще, я считаю, что 200дБ подавление

Да и 100Дб это несколько перебор.
Тем более, что гармоники того же меандра хоть и распространяются на весь спектр, но являются затухающей последовательностью, да и сами по себе слабее порождающего их сигнала.

- - - Добавлено - - -

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

[Barmaley_m]

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

Это так. Но не всегда фильтры реализуются на PC-процессорах. Иногда нужно их реализовать на микроконтроллере без умножителя, на дискретной схеме или на FPGA. В любом случае возможность реализации без умножителя достойна упоминания. Например, если взять ARM-процессор - несмотря на наличие умножителя, ФНЧ первого порядка, который является составной частью ФВЧ, можно реализовать всего одной ассемблерной командой вида:

sub r0, r0, r0 asr 9

А с умножением будет больше команд - загрузить в регистр коэффициент фильтра, перемножить, сложить.

Да и 100Дб это несколько перебор.
Тем более, что гармоники того же меандра хоть и распространяются на весь спектр, но являются затухающей последовательностью, да и сами по себе слабее порождающего их сигнала.

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

Согласен со всем вышесказанным. При таком конструктивном настрое обязательно получится хороший результат!

[Barmaley_m]

Это зависит от того, что вы понимаете под "качественным фильтром"

Привет. Я тебе в личку написал по звуку для эмулятора. Можешь ответить?

[Barmaley_m]

Я завершил анализ системы передискретизации, применяемой в эмуляторе ZXMAK. В комментариях написано, что она позаимствована из UnrealSpeccy - если так, то и синтез звука UnrealSpeccy должен иметь те же достоинства и недостатки.

Код передискретизации находится в файле SoundDeviceBase.cs. Реализуемый алгоритм передискретизации (с точки зрения ЦОС) таков:

1) Сначала происходит интерполяция методом удержания (Hold Interpolation) с исходной частоты дискретизации (равной тактовой частоте Z80) на промежуточную частоту, которая в 64 раза выше выходной. Если выходная 44100Гц - то промежуточная частота будет около 2,82МГц. Это делается в строках 313 и 323 SoundDeviceBase.cs

2) Затем применяется ФНЧ, FIR-фильтр 127 порядка (128 коэффициентов). Прилагаю графики его АЧХ. Общий вид, область перехода между пропусканием и подавлением, и отдельно полоса пропускания. Фильтр реализован, главным образом, в функции FlushFrame().

3) После фильтра частота дискретизации уменьшается в 64 раза, т.е. приводится к стандартной частоте звуковой карты. Это также происходит в функции FlushFrame().

Применяются некоторые трюки. Автор кода воспользовался кусочным постоянством входных сигналов для оптимизации. В буферах хранятся не сами сигналы, а только их фронты. Поэтому и происходит вычисление частичных сумм коэффициентов фильтра в конструкторе SoundDeviceBase().

Что за тип фильтра применяется - не могу точно сказать. Если вывести график его коэффициентов - то получится что-то похожее на приподнятый косинус или обрезанную функцию Гаусса. Можно выяснить точно с помощью методов нелинейной аппроксимации, но в этом может быть разве что исторический интерес.

Теперь по поводу возможностей улучшения:
1) Интерполяция методом удержания до фильтра - существенный источник алиасинга. Если применить ее не до, а после фильтра - то уже искажений станет меньше. А если применить вместо неё интерполяцию многочленом или структурой фильтра Фарроу - то станет намного лучше.

2) Можно пересчитать и оптимизировать коэффициенты фильтра даже без повышения его порядка. Фактически, сейчас фильтр имеет частоту среза по уровню -3дБ около 15кГц. Его переходная полоса идет от 15 до примерно 50кГц. Подавление в полосе подавления - около 46дБ. Остаточные сигналы от 22050 до 50кГц отражаются в слышимую область в виде алиасинга.

Фильтр можно существенно улучшить без или с незначительным повышением вычислительных затрат на его работу.

Я готов все это сделать, но C# - не мой язык программирования. Я бы написал алгоритмы объектно-ориентированно на Си

ZXMAK: ты мог бы потом перевести их на C# или вызывать через интерфейс на Си, и встроить потом в свой эмулятор?

[ZXMAK]

Я бы написал алгоритмы объектно-ориентированно на Си

ZXMAK: ты мог бы потом перевести их на C# или вызывать через интерфейс на Си, и встроить потом в свой эмулятор?

не вопрос, главное, чтобы новый вариант не сильно больше процессора кушал

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