Генератор синуса с гармониками

[E.Sokol]

Существует концепция измерения, при которой к синусу подмешиваются его гармоники с небольшой амплитудой в противофазе. Такую задачу и решает эта программа. Помимо гармоник (которые можно выборочно отключать) есть ещё три дополнительные частоты для вспомогательных задач. Также можно округлять частоту синусоиды к значению, нацело укладывающуюся в стандартные размеры FFT (2048/4096/etc), чтобы избежать влияния оконных функций.

Все значения громкости относительно Master`а, режим auto дополнительно подгоняет уровень сигнала под 0 дБ, ориентируясь на измерения пиковых значений при воспроизведении.

Драйвер вывода звука пока только WASAPI, shared/exclusive режимы и выбор частоты дискретизации присутствуют. В режиме shared может происходить неявная передискретизация, если частота дискретизации не поддерживается устройством. В режиме exclusive поддерживаются только частоты от драйвера, в остальных случаях появится сообщение об ошибке.

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

Сама программа: HarmonicSineGeneratorPro.v.2.1.zip, для работы может потребоваться установка .NET Framework 4.

[E.Sokol]

интересно, как REW это решает, там используется Java exclusive WASAPI

Так что секрет оказался простой - просто квантует напрямую из double, минуя float.

[IVX]

можно и с плеера играть синус, но речь же об удобстве частой работы с генератором. Меня в сокол-гене устраивает возможность установки Fs независимо от ацп, чего не делает REW.
У меня сейчас нет такого прямо "золотого" сэмпла данного цапа, а на среднем я на обоих генераторах получаю примерно равные гармоники. Одно могу сказать, сокол-ген давал не Н7, а видимо Н3, которую я вдавливал в пол компенсацией 3й гармоники в ES9039, чем и вызывал артефакт в виде Н7. Однако, тот уровень -164дб Н3, который не меняется при округлении частоты к ффт, явно не тот с чем я боролся. Будет на руках сэмпл получше и я замечу разницу, расскажу.

[E.Sokol]

Еще неплохо было бы добавить шейпер, хотя бы 1-го порядка (особенно для 16 бит вывода).

Как-то так пока получается, для 16-и и 24-х бит соответственно:

Ну и для улучшения рандомности шума можно использовать LFSR со сдвигом на несколько тактов (или на всю длину) перед каждым округлением.

Тут не понял. Каждый следующий бит брать недостаточно, пропускать надо, или что?

[dortonyan]

Как-то так пока получается, для 16-и и 24-х бит соответственно:

Выглядит отлично.

Тут не понял. Каждый следующий бит брать недостаточно, пропускать надо, или что?

А я про бит не понял... Мы же из LFSR берем не один бит, а слово какой-то разрядности.
Это сдвиг выполняется на один бит.
Можно оставить и так, просто теоретически между соседними отсчетами из LFSR может быть какая-то взаимная корреляция. Самый простой способ улучшить рандомность: выполнять не один сдвиг, а несколько.
Скажем, если данные округляются из 32-х битной сетки в 16-битную, то нам нужно перед округлением к 32-х битным данным приплюсовать данные шума, разрядностью 16 бит (т.е. разрядностью, равной длине отбрасываемых бит (амплитуда шума 0,5LSB от 16 бит)). Соот-но из LFSR регистра берется 16 бит (например младших).
После этого выполняем 16 сдвигов LFSR (или сдвигаем на всю длину: например, для 32бит LFSR сдвигаем на 32 бита) и только потом берем из него следующие 16 младших бит для суммирования к 32-х разрядным данным перед округлением.

[s_valentin]

АКФ LFSR до своего полного периода мала и шумоподобна не зависимо от количества сдвигаемых бит - проверялось.
10бит регистр, сдвиг 1 бит:


10бит регистр, сдвиг 2 бит:


Также LFSR одной длины но с разными полиномами - не взаимокоррелированы.
10бит регистр, полиномы [10,7,1] и [10,7,1], разные начальные значения:


10бит регистр, полиномы [10,7,1] и [10,9,7,6,1]

[E.Sokol]

А я про бит не понял... Мы же из LFSR берем не один бит, а слово какой-то разрядности.

Математически LFSR - это последовательность именно 1-битных чисел, конечная (в периоде) и детерминированная. Исходя из способа построения, её можно рассматривать как рекурсивный фильтр и привлечь соответствующий мат.аппарат, чтобы описывать эту последовательность не магией, а многочленами. А для нас она представляет интерес тем, что АЧХ её строго линейна (за исключением постоянной составляющей очевидно). Легко проверить например в Вольфраме:

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

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

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

выполнять не один сдвиг, а несколько.

Это значит прореживать, а именно умножить его на другой сигнал вида (1,0,0,0, 1,0,0,0, 1,0,0,0, ...), в результате чего произойдёт свёртка их спектров. Каким образом это может что-то улучшить? А вот ухудшить - да, свойство линейности АЧХ после этого потеряется. Нельзя улучшить то, что и так идеально.

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

Строго математически мы можем, например, перевести LFSR из белого шума в фиолетовый (дифференцированием, можно упростить до конечной разности). Тогда двоичный бит превратится в троичный - со значениями (-1,0,1). Или же можно масштабировать LFSR из (0,1) в (-1,1) и забить нулями после каждого семпла. Тогда АЧХ просто отзеркалится и гарантированно останется линейной.

[dortonyan]

E.Sokol, все равно не пойму - как выполнить корректное округление скажем из 32-х бит в 24 однобитным дизерингом?

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

Почему "магия"? И при чем здесь интуиция?
В мы же зашумляем не выходной сигнал, а отбрасываемые биты. В этом же и есть принцип восстановления сигнала уровнем ниже 1LSB: чтобы шумом воздействовать на все отбрасываемые разряды.

Математически зашумление младших бит значит прибавить к LFSR ещё один сигнал меньшей амплитуды, и АЧХ результата вовсе не обязательно будет оставаться линейной.

Ну так если этот сигнал меньшей амплитуды есть белый шум, то какая в результате будет АЧХ?
И какова бы эта АЧХ не была, ее изменение в итоговом сигнале все равно не превысит 0,5LSB, "на глаз". Т.е. в децибелах - исчезающе мало.

[E.Sokol]

E.Sokol, все равно не пойму - как выполнить корректное округление скажем из 32-х бит в 24 однобитным дизерингом?

Как "правильно" - рассуждать не возьмусь. Я говорил только о том, что не вижу обоснования заполнять младшие биты после бита дизеринга ничем, кроме нулей. Ну и в контексте темы округление идёт не из 32-х бит, а из 52-х бит.

[s_valentin]

LFSR генерирует псевдослучайный битовый поток длиной 2^N.
При этом из него можно отбирать сэмплы любой разрядности (хоть знаковые хоть беззнаковые), при этом поток сэмплов будет такой-же псевдослучайный (с такой-же статистикой), только его длина немного уменьшится.

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

[E.Sokol]

LFSR генерирует псевдослучайный битовый поток длиной 2^N

2^N-1. 31, например, нацело не делится на слово любой разрядности.

[dortonyan]

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

Если округление выполняется без шейпера и к младшим битам перед отбрасыванием ничего не суммируется, то это означает, что младшие биты просто не используются.
Т.е. если вы перед округлением в 24 бита суммируете к 52-х битному сигналу 1 бит шума амплитудой 0,5LSB от 24-х бит, то это означает, что разрядность исходного сигнала всего 25 бит, а никакие не 52.
И сигналы уровнем ниже, чем 0,5LSB от 24-х бит мы в таком случае просто не увидим. Вместо этого увидим артефакты квантования: "забор" уровнем порядка -150дБ.
Смысл тогда такого дизеринга, если мы увеличиваем разрешение всего на 1 бит?

2^N-1. 31, например, нацело не делится на слово любой разрядности.

А зачем оно должно делиться нацело?
Из регистра LFSR можно брать слово любой длины. В частности, для округления нам нужно слово длинной равной длине отбрасываемых бит.
Причем округлять из 52-битной сетки смысла нет, т.к. избыточная разрядность и в младших битах могут быть погрешности вычислений. Можно сперва от 52-х бит отбросить, скажем, младшие 12 бит. А потом уже из 40 бит округлять в 16 или в 24.
Соот-но из регистра LFSR нам понадобится либо 16, либо 32 бита (любых).

[E.Sokol]

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

Моделирование показывает, что нойз-шейпинг 1-го и 2-го порядка и без дизеринга прекрасно работает, а при низкой разрядности квантования гармоники один фиг видны. Сейчас я задумался о том, а что если существует алгоритм синтеза синусоиды сразу в нужной разрядности, без округления с компенсацией ошибки? Быстрый гуглинг пока ничего не дал правда.

---------- Сообщение добавлено 14:43 ---------- Предыдущее сообщение было 14:20 ----------

Медленный поиск дал: Spectrally pure excitation signals: only a dream? Там чуваки просто через FFT итеративно компенсируют гармоники и не парятся.

[dortonyan]

Моделирование показывает, что нойз-шейпинг 1-го и 2-го порядка и без дизеринга прекрасно работает

Для 2-го порядка да, а вот для 1-го на 16 битах - не очень.
Не помню как в модели, но в "железе" шейпер 1-го порядка для 16-разрядных данных без дизера дает артефакты.
Поэтому я бы все таки сделал 1-ый порядок с дизером.

а при низкой разрядности квантования гармоники один фиг видны

Это потому что неправильно округляете. Как правильно - я описал выше.
При округлении с дизером из 52 бит в 16 бит (и вообще в любую другую) никаких гармоник быть не должно.

Сейчас я задумался о том, а что если существует алгоритм синтеза синусоиды сразу в нужной разрядности, без округления с компенсацией ошибки? Быстрый гуглинг пока ничего не дал правда.

Даже идеально точно посчитанный синус будет иметь гармоники уровнем 0,5LSB разрядной сетки. Т.е. шумы квантования никуда не денутся.
Способ снизить шум квантования ровно один - увеличить разрядность исходного сигнала. Но она у вас и так достаточно большая - 52 бита. Соот-но все артефакты исключительно из-за неправильного округления в меньшую разрядность.

---------- Сообщение добавлено 14:31 ---------- Предыдущее сообщение было 13:25 ----------

Не помню как в модели, но в "железе" шейпер 1-го порядка для 16-разрядных данных без дизера дает артефакты.

Проверил в матлабе, все подтверждается.

16 бит 44к 1кГц тон с шейпером 1-го порядка без дизера:

То же самое с дизером +/-0.5LSB:

[E.Sokol]

Проверил в матлабе, все подтверждается.

Наверно это потому что у вас FFT степени двойки, а я брал простое число для надёжности. У меня так выглядит шэйпинг 1-го порядка без дизера:


---------- Сообщение добавлено 17:21 ---------- Предыдущее сообщение было 17:18 ----------

И это без усреднения между кадрами.

[dortonyan]

Наверно это потому что у вас FFT степени двойки, а я брал простое число для надёжности. У меня так выглядит шэйпинг 1-го порядка без дизера:

А какая разрядность на выходе?

Задал в матлабе 131071, как у вас на скрине.
Никакой разницы.

Где-то у кого-то касяк.
По моему у модулятора 1-го порядка для 16 бит просто не хватает петлевого усиления.

P.S.
Могу ошибаться, но вроде как именно fast FT и не может быть отличным от степени двойки. Т.к. в самом принципе быстрого ПФ используется двоичное распределение семплов.
Ну и мне лично не известен софт для АЦП, который позволяет задавать длину FFT произвольно.

[E.Sokol]

А какая разрядность на выходе?

16, как и у вас. Единственное, что я всё считаю в double, а округлённый результат тоже в double держу, перед FFT. Может где-то и есть косяк, хотя вариант со степенью двойки и выровненной к ней частотой не сильно от вашего отличается. Окончательно можно что-то утверждать только после честного измерения через виртуальный аудио-кабель.

Могу ошибаться, но вроде как именно fast FT и не может быть отличным от степени двойки.

DFT любого размера можно выразить через свёртку по алгоритму Блюштейна, а вот уже саму свёртку можно быстро посчитать через FFT. Я сам писал реализацию на ассемблере из интереса, но вроде бы FFTW тоже это умеет. Также есть варианты для степеней 3,4,5 и всего того, что на них факторизуется, в частности, так делает популярная на фортране библиотека FFTPack. Степень двойки просто наиболее простая в реализации.

[Meta|_]

если да, то как лучше - сделать галочку "дизеринг" и отдельно номер бита с нуля, или без галочки, а биты нумеровать с 1 (а ноль будет значить отсутствие дизеринга)?

Инженерам думаю пофигу, а с точки зрения сферического usability однозначно надо отдельную галочку.

в качестве источника шума я выбрал LFSR, но может есть другие варианты, мне неизвестные

Когда я учился в аспирантуре, по соседству занимались анализом генераторов псевдослучайных чисел применительно к криптографии. LFSR по некоторым тестам смотрелся посредственно. Вроде бы даже графически, при выводе результатов в bitmap на экран было видно какие-то неоднородности. Может ли оно влиять на субъективное восприятие на слух? - А пёс его знает. Но если всё равно считать на ПК, то можно воткнуть что-то криптогрпфически стойкое и закрыть вопрос. Например, любой блочный шифр (AES, DES, ГОСТ-89, "Кузнечик", тысячи их) в режиме OFB или CTR - это из пушки по воробьям, но вполне подойдёт. Собственно там умные дядьки годами бьются над тем, чтобы результирующую последовательность было невозможно отличить от истинно случайной перестановки. Но правда период будет таким, что синхронизироваться со спектроанализатором не выйдет...

[dortonyan]

16, как и у вас. Единственное, что я всё считаю в double, а округлённый результат тоже в double держу, перед FFT. Может где-то и есть косяк, хотя вариант со степенью двойки и выровненной к ней частотой не сильно от вашего отличается. Окончательно можно что-то утверждать только после честного измерения через виртуальный аудио-кабель.

А целочисленные семплы в int16 нельзя подать на FFT?
Мне кажется что у вас там с конверсией через double что-то не то.

Может ли оно влиять на субъективное восприятие на слух? - А пёс его знает. Но если всё равно считать на ПК, то можно воткнуть что-то криптогрпфически стойкое и закрыть вопрос.

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

[s_valentin]

Может ли оно влиять на субъективное восприятие на слух? - А пёс его знает. Но если всё равно считать на ПК, то можно воткнуть что-то криптогрпфически стойкое и закрыть вопрос.

Наш слух очень чувствителен к различным паттернам. Когда озадачился данным впросом - просто послушал шум LFSR с нормальной громкостью, ни чего не услышал...
Криптостойкость для аудио - по моему излишне. АКФ LFSR я приводил - до полного периода чистый шум.

[E.Sokol]

А целочисленные семплы в int16 нельзя подать на FFT?
Мне кажется что у вас там с конверсией через double что-то не то.

Потому что моя система для моделирования работает через double, это удобно. Чистый эксперимент проведу обязательно.

---------- Сообщение добавлено 04.06.2024 в 08:57 ---------- Предыдущее сообщение было 03.06.2024 в 22:18 ----------

Мне кажется что у вас там с конверсией через double что-то не то.

Ну не нахожу пока багов, сорян, может у вас получится. Отдельно сделал .csv, .wav и картинку со стационарного спектроанализатора без масштабирования: Quantized Sine.zip. Если найдёте инструмент, способных корректно переваривать FFT подобного рода - вэлком. Единственное, что хочется попросить - убедиться, что этот инструмент действительно корректен и сделать хотя бы парочку элементарных тестов. На ассемблере я свой не от нефиг делать писал - в ходе тестирования выяснилось, что для алгоритма Блюштейна точности double недостаточно и после 10K он начинает нагло врать.