То, что частоты не известны, как раз не страшно, мы их и определяем.
Там метод по сути состоит из 2х частей:
1 - это определение частоты, амплидуды и фазы для одной синусоиды и ее вычитание из исходного сигнала. Estimate делается через FFT, на основе того, что актуальная частота расположена в окрестности пика FFT спектра.
Этот шаг можно проделывать несколько раз, определяя каждый раз по синусоиде. Получаем набор параметров.
2 - оптимизация этого набора параметров.
Что то мне подсказывает что для задачи гитарного тюнера даже в таком виде должно работать, можно еще вначале отфильтровать все частоты выше скажем 4KHz чтоб снизить вероятность ошибок. Наверно можно еще применить фильтр 1го порядка прям начиная с 300-500Hz, чтоб еще поднять приоритет захвата основного тона.
Можно усложнить и повысить точность если делать оптимизацию после каждого шага выделения синусоиды, то есть 1) получили синусоиду с параметрами Ki, 2) добавили ее в существущий набор синусоид K, 3) прогнали оптимизацию для этого набора K, 4) проверили какой то критерий останова, 5) если не готово то переходим к шагу 1
Примерно так я у себя и делаю. На современных CPU это все еще работает в реальном времени даже без SIMD оптимизаций на 1м ядре. Хотя да, это кажется несколько расточительно в плане CPU.
Есть вот такая достаточно подробная статья, даже с кодом http://www.apsipa.org/proceedings_2009/pdf/WA-L3-3.pdf ну и моя попытка использовать предложенный там метод на практике https://github.com/dcherednik/libgha/ Работает достаточно хорошо, dtmf тоны определяет за менее чем 256 отсчетов (при 8000Гц). Сейчас я использую этот алгоритм в реализации AT3Plus совместимого кодека.
Еще подобной задачей занимались ребята из xiph при проектировании кодека ghost до того как переключились на опус. Но ghost так и не вышел, так что тут можно только изучать их материалы https://people.xiph.org/~xiphmont/demo/ghost/demo4.xhtml
update: проверьте, на всякий случай, правильно ли спектр построен, может там квадрат забыли)
Большая проблема при тунелировании через TCP - алгоритм Нагла, особенно в сочетании с отложенным ACK (а обычно это так и получается). Если выставить TCP_NODELAY на сокете, то уже будет сильно лучше. Применительно к openvpn кажется надо tcp-nodelay написать в конфиг.
К слову, стабилизаторы переменного напряжения на магнитных усилителях то же были, и даже сейчас еще можно найти Б2-2 или Б2-3 при желании, схемотехника у них простая и в то же время интересная.
Кажется так не сработает. Если на эмиттере vt2 0.63 в, то на его базе будет где то 1-1.2 в зависимости от примененного транзстора. Его база соеденена непосредственно с коллектором vt1. Однако для работы vt1 нужно чтоб напряжение на эмиттере было меньше чем напряжение на коллекторе. При подключении R6 к верхнему R4, напряжение в этой точке станет примерно (не учитывая ток через r3) то есть 1.2 вольта. Получается vt1 работает при практически нулевом, если не обратном напряжении э-к. Возможно при каких то транзисторах оно и заработает (нужно учитывать уже реальные Uбэ), но выглядет экстримально.
Тут скорее надо использовать на месте v1 pnp транзистор, соответственно перевернув весь этот узел - тогда это будет почти что класическая схема 70x.
Какую то вы совсем неудачную схему для повторения выбрали, разве что использовать ее как для работы над ошибками. Из того что бросается в глаза сразу:
vt5 vt7 - с одной стороны они управляются током vt4 vt6, что хорошо и несколько повышает линейность. С другой стороны нет пути для разряда емкостей переходов бэ и бк у выходных транзисторов, что скажется на быстродействии, приведет к сквоздным токам.
Глубина ООС по постоянному току никакая, термостабильность обеспечивается за счет RC цепей местных обратных связей
Чувстительность к питанию - все подавление пульсаций по питанию сводится к C9 R13.
Я не знаю какое там напряжение на эмиттере vt2, но нужно понимать что это напряжение уменшает максимальный размах на выходе усилителя напряжения.
нагрузкой vt2 в основном является достаточно низкое сопротивление R7, оно сильно ограничит коэффициент петлевого усиления.
Собственно вы и сами написали что для работы этой схемы тредуется 40ma тока покоя, что поверьте ооочень много)
Круто! Но ведь подобным образом были устроены двигатели ЛПМ магнитофонов с прямым приводом, тот же БС-02 от Веги или двигатели флоповодов. Или есть принципиальное отличие?
Я же не знаю устройства вашей проводки. Но чудес не бывает. Может у вас рядом с этой розеткой пол лучше ток проводит и поэтому вы чувствуете покалывания в этом месте, а в других местах не чувствуете. А может у вас в других розетках PE соединен с N (ни в коем случае нельзя так делать!). А может в других розетках потребители подключены через тройники и одни из других потребителей "заземлены" через кабель антенны, или как то еще. Можно много придумывать вариантов, вплоть до криворукого электрика. Но в пластик (если конечно он не обгорел) дающий заметную утечку верится слабо. В любом случае это легко проверить.
При чем тут напряжение на корпусе и производитель розетки?
В импульсных блоках питания на входе стоят 2 конденсатора, средней точкой соединенные с общим проводом (соответственно и с металическим корпусом) компьютера. Через них и образуется цепь через которую проходит ток при прикосновении к корпусу.
По хорошему если бы у вас был PE проводник (то самое заземление), то эта средняя точка была бы с ним соединена через третий контакт в розетке, и было бы все хорошо. Но сами написали что нет PE проводника - упс, в квартире ничего не поделаешь.
Тут нужно ставить x2 конденсатор, или какой другой предназначенный для работы в подобных цепях. Но есть шанс что по габаритам могут и не пройти. Китайские пленочные будут быстро "выгарать" теряя емкость.
Как автор atracdenc, могу чуть рассказать про ATRAC. Действительно, ничего прям особенного в ATRAC1 (это тот который SP) нет, там просто достаточно большой битрейт, более удачный чем у mp3 фильтрбанк, в частности он позволяет переключать размер окна в каждом из 3х полос. А в остальном ATRAC1 разрабатывался в то время когда каждый такт был на счету, в нем даже нет никакого энтропийного кодирования после квантования MDCT коэффициентов.
ATRAC3 чуть интереснее, уже есть кодировние Хаффмана, вместо переключения размера окна там используется нормализация уровня перед mdct - коэффициент аттенюации передается так же в потоке для последующего восстановления на декодере. Однако полностью реализовать эту фичу у себя мне не удалось. В остальном кодек очень похож на ATRAC1.
ATRAC3+ (не реализован в atracdenc) вот он имеет уникальную для аудиокодеков технологию - Generalized Harmonic Analysis, с ней было бы интересно поэкспериментировать. С другой стороны HiMD устройства, использующие этот кодек, я использовал, обещания Sony что на битрейте 64Kbit а ATRAC3+ достигнуто кажество SP режима не сбылись.
Эксперименты с фильтрбанками для которых я могу найти заведомо корректную реализацию говорят что да. Для фильтрбанка DTS кодека (реализация есть в ffmpeg), например, ошибка где то в 5м знаке после запятой была.
Предыстория? Я как то порывался статью написать, но все не мог себя заставить)) Аудио и видео кодеки всегда были мне интересны, еще до того как программировать стал. Потом как то сидел в отпуске и захотелось попробовать себя в чем то новом (по работе я не связан с DSP никак), стал читать код ffmpeg, увидел что там есть декодер для ATRAC, а когда то я был фанатом минидиска, ну тут все и совпало - решено написать енкодер по коду декодера из ffmpeg. ATRAC1 мне показался достаточно простым (стек из 2х QMF + MDCT + квантование в частотной области, ну еще опционально переключение размера окна), ну и стал постепенно изучать область и реализовывать. Особых сложностей с ATRAC1 в общем то не было, и достаточно быстро получился рабочий код, дающий в целом не плохой результат. Ну так и втянулся.
Потом взялся за ATRAC3 - он не сильно сложнее, другой фильтрбанк, но все еще имеющий в основе стек из QMF + MDCT, есть кодирование хаффмана. Из интересного, нет переключения размера окна, но есть gain modulation - возможность изменить уровень сигнала в пределах окна перед mdct в кодировщике и соответственно обратным образом изменить его после imdct в декодере, эта фича, кстати, до конца мной не была реализована. Тем не менее для LP2 режима (это что то в районе 132Kbit/s) качество получилось сравнимым с mp3 - 128.
Тем временем код на github заметили другие любители минидиска, и с удивлением для себя я обнаружил, что оказывается проект используют в том числе для заливки треков на минидиск теми кто по каким то причинам до сих пор ими пользуются)) А кто то собрал его под WebAssembly и предлагал как web сервис))
Тем не менее мне интереснее разбираться дальше, и ATRAC3Plus тут как раз интересен тем что использует Generalized Harmonic Analysis (GHA) для извлечения информации о тональных составляющих - в других кодеках такого подхода я не встречал, и было бы интересно поиграться с этим. Но ATRAC3Plus использует pqf для разбивки входного сигнала на 16 суб-полос перед mdct, и подозреваю что разные прототипы для синтеза и анализа, и тут я застреваю, поскольку дальше без понимания математики происходящего в pqf никак.
Анализирующий pqf это первое преобразование при кодировании, и соответственно синтезирующий pqf - последнее при декодировании. Все потери происходят сильно позже, уже после перехода в частотную область. Таким образом потерь я пока просто не допускаю, просто подаю результат работы своего анализирующего фильтрбанка на вход синтезирующего из ffmpeg. И ожидаю как минимум "near perfect reconstruction".
Коэффициенты часто записываются не последовательно для более простого кода их применения, так почти во всех кодеках, в том числе и opensource. Там же хитрое прореживание совмещенное со сверткой с частью прототипа. В dcaenc боле понятно https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/dcaenc.c#L319-L367 И вот форма этого прототипа сильно влияет на свойства фильтрбанка. В том же dca есть 2 фильтрбанка, для PR и NPR.
Попытка "с наскоку" взять и адаптировать код pqf из другого кодека для моего случая (M=16, 384 fir коэффициента) не очень сработала - хотя для DC или синуса результат очень похож на правду, и после обратного синтеза получилось что то похожее на near perfect reconstruction, но для дельта функции или просто прямоугольного фронта после синтеза получается уже совсем не похожий на входной сигнал.
Что хочется для себя прояснить.
Как по прототипу понять является ли фильтрбанк near perfect reconstruction или perfect reconstruction?
Из разных статей понял, что есть случаи когда анализирующий и синтезирующий фильтрбанк используют разные прототипы. Есть подозрения что это именно мой случай. Можно ли это как то узнать из анализа прототипа? И как получить из одного другой?
Ну и в целом тема интересная, есть много вопросов, но к сожалению математику происходящего понимаю плохо (
То, что частоты не известны, как раз не страшно, мы их и определяем.
Там метод по сути состоит из 2х частей:
1 - это определение частоты, амплидуды и фазы для одной синусоиды и ее вычитание из исходного сигнала. Estimate делается через FFT, на основе того, что актуальная частота расположена в окрестности пика FFT спектра.
Этот шаг можно проделывать несколько раз, определяя каждый раз по синусоиде. Получаем набор параметров.
2 - оптимизация этого набора параметров.
Что то мне подсказывает что для задачи гитарного тюнера даже в таком виде должно работать, можно еще вначале отфильтровать все частоты выше скажем 4KHz чтоб снизить вероятность ошибок. Наверно можно еще применить фильтр 1го порядка прям начиная с 300-500Hz, чтоб еще поднять приоритет захвата основного тона.
Можно усложнить и повысить точность если делать оптимизацию после каждого шага выделения синусоиды, то есть 1) получили синусоиду с параметрами Ki, 2) добавили ее в существущий набор синусоид K, 3) прогнали оптимизацию для этого набора K, 4) проверили какой то критерий останова, 5) если не готово то переходим к шагу 1
Примерно так я у себя и делаю. На современных CPU это все еще работает в реальном времени даже без SIMD оптимизаций на 1м ядре. Хотя да, это кажется несколько расточительно в плане CPU.
Есть вот такая достаточно подробная статья, даже с кодом http://www.apsipa.org/proceedings_2009/pdf/WA-L3-3.pdf ну и моя попытка использовать предложенный там метод на практике https://github.com/dcherednik/libgha/ Работает достаточно хорошо, dtmf тоны определяет за менее чем 256 отсчетов (при 8000Гц). Сейчас я использую этот алгоритм в реализации AT3Plus совместимого кодека.
Еще подобной задачей занимались ребята из xiph при проектировании кодека ghost до того как переключились на опус. Но ghost так и не вышел, так что тут можно только изучать их материалы https://people.xiph.org/~xiphmont/demo/ghost/demo4.xhtml
update:
проверьте, на всякий случай, правильно ли спектр построен, может там квадрат забыли)
Большая проблема при тунелировании через TCP - алгоритм Нагла, особенно в сочетании с отложенным ACK (а обычно это так и получается). Если выставить TCP_NODELAY на сокете, то уже будет сильно лучше. Применительно к openvpn кажется надо tcp-nodelay написать в конфиг.
К слову, стабилизаторы переменного напряжения на магнитных усилителях то же были, и даже сейчас еще можно найти Б2-2 или Б2-3 при желании, схемотехника у них простая и в то же время интересная.
Кажется так не сработает. Если на эмиттере vt2 0.63 в, то на его базе будет где то 1-1.2 в зависимости от примененного транзстора. Его база соеденена непосредственно с коллектором vt1. Однако для работы vt1 нужно чтоб напряжение на эмиттере было меньше чем напряжение на коллекторе. При подключении R6 к верхнему R4, напряжение в этой точке станет примерно (не учитывая ток через r3)
то есть 1.2 вольта. Получается vt1 работает при практически нулевом, если не обратном напряжении э-к.
Возможно при каких то транзисторах оно и заработает (нужно учитывать уже реальные Uбэ), но выглядет экстримально.
Тут скорее надо использовать на месте v1 pnp транзистор, соответственно перевернув весь этот узел - тогда это будет почти что класическая схема 70x.
Какую то вы совсем неудачную схему для повторения выбрали, разве что использовать ее как для работы над ошибками. Из того что бросается в глаза сразу:
vt5 vt7 - с одной стороны они управляются током vt4 vt6, что хорошо и несколько повышает линейность. С другой стороны нет пути для разряда емкостей переходов бэ и бк у выходных транзисторов, что скажется на быстродействии, приведет к сквоздным токам.
Глубина ООС по постоянному току никакая, термостабильность обеспечивается за счет RC цепей местных обратных связей
Чувстительность к питанию - все подавление пульсаций по питанию сводится к C9 R13.
Я не знаю какое там напряжение на эмиттере vt2, но нужно понимать что это напряжение уменшает максимальный размах на выходе усилителя напряжения.
нагрузкой vt2 в основном является достаточно низкое сопротивление R7, оно сильно ограничит коэффициент петлевого усиления.
Собственно вы и сами написали что для работы этой схемы тредуется 40ma тока покоя, что поверьте ооочень много)
Он же исорически был на C, только в 2013 его перевели на сборку c++ компилятором.
Интересно, а как у полуторавольтовых литиевых обстоят дела я глубоким разрядом?
Проблема почти всех алкалиновых - текут - дети забывают включенную игрушку и через пару дней все оказывается в утекшем электролите.
Круто! Но ведь подобным образом были устроены двигатели ЛПМ магнитофонов с прямым приводом, тот же БС-02 от Веги или двигатели флоповодов. Или есть принципиальное отличие?
Я же не знаю устройства вашей проводки. Но чудес не бывает. Может у вас рядом с этой розеткой пол лучше ток проводит и поэтому вы чувствуете покалывания в этом месте, а в других местах не чувствуете. А может у вас в других розетках PE соединен с N (ни в коем случае нельзя так делать!). А может в других розетках потребители подключены через тройники и одни из других потребителей "заземлены" через кабель антенны, или как то еще. Можно много придумывать вариантов, вплоть до криворукого электрика. Но в пластик (если конечно он не обгорел) дающий заметную утечку верится слабо. В любом случае это легко проверить.
При чем тут напряжение на корпусе и производитель розетки?
В импульсных блоках питания на входе стоят 2 конденсатора, средней точкой соединенные с общим проводом (соответственно и с металическим корпусом) компьютера. Через них и образуется цепь через которую проходит ток при прикосновении к корпусу.
По хорошему если бы у вас был PE проводник (то самое заземление), то эта средняя точка была бы с ним соединена через третий контакт в розетке, и было бы все хорошо. Но сами написали что нет PE проводника - упс, в квартире ничего не поделаешь.
Строки. Оптимистические блокировки работают на уровне строк.
Peertube попробовать?
Тут нужно ставить x2 конденсатор, или какой другой предназначенный для работы в подобных цепях. Но есть шанс что по габаритам могут и не пройти. Китайские пленочные будут быстро "выгарать" теряя емкость.
Как автор atracdenc, могу чуть рассказать про ATRAC. Действительно, ничего прям особенного в ATRAC1 (это тот который SP) нет, там просто достаточно большой битрейт, более удачный чем у mp3 фильтрбанк, в частности он позволяет переключать размер окна в каждом из 3х полос. А в остальном ATRAC1 разрабатывался в то время когда каждый такт был на счету, в нем даже нет никакого энтропийного кодирования после квантования MDCT коэффициентов.
ATRAC3 чуть интереснее, уже есть кодировние Хаффмана, вместо переключения размера окна там используется нормализация уровня перед mdct - коэффициент аттенюации передается так же в потоке для последующего восстановления на декодере. Однако полностью реализовать эту фичу у себя мне не удалось. В остальном кодек очень похож на ATRAC1.
ATRAC3+ (не реализован в atracdenc) вот он имеет уникальную для аудиокодеков технологию - Generalized Harmonic Analysis, с ней было бы интересно поэкспериментировать. С другой стороны HiMD устройства, использующие этот кодек, я использовал, обещания Sony что на битрейте 64Kbit а ATRAC3+ достигнуто кажество SP режима не сбылись.
Если он включен между сетевыми проводами (что скорее всего судя по емкости), то такой https://www.chipdip.ru/product0/9000549311
Дело в том что в сети возможны переходные процессы и выбросы напряжения до киловольта, конденсатор должен их выдерживать.
Эксперименты с фильтрбанками для которых я могу найти заведомо корректную реализацию говорят что да. Для фильтрбанка DTS кодека (реализация есть в ffmpeg), например, ошибка где то в 5м знаке после запятой была.
Предыстория? Я как то порывался статью написать, но все не мог себя заставить)) Аудио и видео кодеки всегда были мне интересны, еще до того как программировать стал. Потом как то сидел в отпуске и захотелось попробовать себя в чем то новом (по работе я не связан с DSP никак), стал читать код ffmpeg, увидел что там есть декодер для ATRAC, а когда то я был фанатом минидиска, ну тут все и совпало - решено написать енкодер по коду декодера из ffmpeg. ATRAC1 мне показался достаточно простым (стек из 2х QMF + MDCT + квантование в частотной области, ну еще опционально переключение размера окна), ну и стал постепенно изучать область и реализовывать. Особых сложностей с ATRAC1 в общем то не было, и достаточно быстро получился рабочий код, дающий в целом не плохой результат. Ну так и втянулся.
Потом взялся за ATRAC3 - он не сильно сложнее, другой фильтрбанк, но все еще имеющий в основе стек из QMF + MDCT, есть кодирование хаффмана. Из интересного, нет переключения размера окна, но есть gain modulation - возможность изменить уровень сигнала в пределах окна перед mdct в кодировщике и соответственно обратным образом изменить его после imdct в декодере, эта фича, кстати, до конца мной не была реализована. Тем не менее для LP2 режима (это что то в районе 132Kbit/s) качество получилось сравнимым с mp3 - 128.
Тем временем код на github заметили другие любители минидиска, и с удивлением для себя я обнаружил, что оказывается проект используют в том числе для заливки треков на минидиск теми кто по каким то причинам до сих пор ими пользуются)) А кто то собрал его под WebAssembly и предлагал как web сервис))
Тем не менее мне интереснее разбираться дальше, и ATRAC3Plus тут как раз интересен тем что использует Generalized Harmonic Analysis (GHA) для извлечения информации о тональных составляющих - в других кодеках такого подхода я не встречал, и было бы интересно поиграться с этим. Но ATRAC3Plus использует pqf для разбивки входного сигнала на 16 суб-полос перед mdct, и подозреваю что разные прототипы для синтеза и анализа, и тут я застреваю, поскольку дальше без понимания математики происходящего в pqf никак.
Вот такая история)
Анализирующий pqf это первое преобразование при кодировании, и соответственно синтезирующий pqf - последнее при декодировании. Все потери происходят сильно позже, уже после перехода в частотную область. Таким образом потерь я пока просто не допускаю, просто подаю результат работы своего анализирующего фильтрбанка на вход синтезирующего из ffmpeg. И ожидаю как минимум "near perfect reconstruction".
Коэффициенты часто записываются не последовательно для более простого кода их применения, так почти во всех кодеках, в том числе и opensource. Там же хитрое прореживание совмещенное со сверткой с частью прототипа. В dcaenc боле понятно https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/dcaenc.c#L319-L367 И вот форма этого прототипа сильно влияет на свойства фильтрбанка. В том же dca есть 2 фильтрбанка, для PR и NPR.
NPR обеспечивает подавление алиасинга только в соседних полосах, часто этого достаточно, так как за пределами соседних полос ослабление уже обычно более 90db, и этим можно пренебречь для задач аудио. Например вот тут https://www.researchgate.net/publication/221380083_A_method_to_convert_near-perfect_into_perfect_reconstruction_FIR_prototype_filters_for_modulated_filter_banks
описано получение из near perfect reconstruction, perfect reconstruction. Забавно, что perfect reconstruction уже не выглядит как sinc(x)/x а имеет некоторые "резкие изломы".
Почитаю еще раз, вашу предыдущую статью может какие идеи возникнут...
Ух. Есть у меня pet project - открытая реализация atrac кодека. Для atrac3plus нужно реализовать анализирующий фильтрбанк для вот такой реализации синтезирующего https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/atrac3plusdsp.c#L502-L645
Попытка "с наскоку" взять и адаптировать код pqf из другого кодека для моего случая (M=16, 384 fir коэффициента) не очень сработала - хотя для DC или синуса результат очень похож на правду, и после обратного синтеза получилось что то похожее на near perfect reconstruction, но для дельта функции или просто прямоугольного фронта после синтеза получается уже совсем не похожий на входной сигнал.
Что хочется для себя прояснить.
Как по прототипу понять является ли фильтрбанк near perfect reconstruction или perfect reconstruction?
Из разных статей понял, что есть случаи когда анализирующий и синтезирующий фильтрбанк используют разные прототипы. Есть подозрения что это именно мой случай. Можно ли это как то узнать из анализа прототипа? И как получить из одного другой?
Ну и в целом тема интересная, есть много вопросов, но к сожалению математику происходящего понимаю плохо (