Я отказался от кофе в пользу пуэра (без насилия, естественным образом), хотя кофе тоже очень сильно любил. Кофе будоражит, имеет короткое по времени действие и выраженный отходняк, простирающийся на следующие несколько дней. Действие пуэра сильнее, чем обычного чая, но не такое агрессивное, как от кофе, и длится дольше. Кофе пью теперь иногда только в качестве удовольствия от вкуса (натуральный, естественно).
А мне всегда было непонятно, почему влияние дерева сравнивается на электро, а не акустических гитарах, где они оно проявляются не то чтобы в разы, а в десятки раз больше. Равно как и разница между транзисторным/ламповым комбиком ощущается много сильнее, чем смена гитар, к ним подключенным.
Я сейчас занимаюсь подобной задачей, только для акустики. OpenCL показался мне предпочтительнее CUDA, потому что даже без GPU он способен распараллелить задачу по ядрам.
(а взялся за самостоятельную реализацию, потому что интересует решение на гексагональной сетке).
Добавленные нули, это фактически расширение спектра в этих местах до бесконечности
Спектр дискретного сигнала ограничен по определению.
что должно восприниматься как щелчки
Не должно. В частотном домене «щелчок» — это всплеск в широком диапазоне частот, из чего следует, что для восприятия перепадов амплитуд как щелчков они должны быть достаточно далеко разнесены во времени.
соотвественно вместо нулей в итоге должны получиться не гладенькие участки плавно соединящие изначальные точки квантизации а биения с частотой до 20 КГц включительно, можете показать тот же график в увеличенном виде
Линии между точками я нарисовал сам, и это тоже не совсем корректно, потому правильнее было бы интерполировать их sinc-ом, но на небольшом масштабе это не принципиально, поскольку разницы не видно. Соответственно и масштаб графика увеличивать нет смысла.
Люди, не доверяющие Котельникову, даже не пытались почитать его работу. Иначе очень быстро бы выяснилось, что их недоверие вступает в конфликт с объективной реальностью, в которой имеет место быть теле- и радио-вещание.
Ошибка в постановке задачи, что вы делаете, как вы это делаете, и в интерпретации результатов.
Если задача показать, что для 20кГц не нужно 192кГц — так это Котельников/Шеннон/Найквист давно доказали.
Если задача показать, что человек не слышит выше 20 кГц — так это надо фокус-группу собирать и двойное слепое прослушивание устраивать.
Если задача показать, что в HD-записях нет частот выше 20 кГц — так их фильтровать не надо и собрать достаточное количество записей для репрезентативного анализа.
Если задача показать несовершенство алгоритма передискретизации в конкретно взятом аудио-редакторе — так надо его импульсную характеристику анализировать, а не какую-то конкретную аудиозапись.
Для понимания этого нужно вспомнить о том, как именно происходит восстановление сигнала, и что sinc(x) это sin(x)/x. Поделить на x. После того, как мы поделим квантованную амплитуду на значение, превышающее количество уровней квантования, полезного сигнала не останется. И это легко проверяется на практике.
Всё не так просто. Маркетинг в 192/24 действительно имеет место быть. 44.1/16 достаточно, если он воспроизводится идеально. А вы возьмите осциллограф и посмотрите, что ваша звуковая карта выдаёт на частот 10кГц.
Об условиях работы получить представление можно по картинкам ДСП, МНЛЗ, сталевоз, а также классической аудио-записи. Компьютеры раскиданы по всему цеху, помимо рабочих станций используются также в качестве терминалов, на весах или считывателей для вагонов. Единой серверной также нет, сервера привязаны каждый к своему агрегату и расположены как бог на душу положил где свободное место нашлось при строительстве/реконструкции очередного агрегата. Всё это собрано в одну сеть на коммутаторах CISCO.
Программист, как и любой другой инженер на производстве, несёт персональную ответственность за подшефное оборудование вне зависимости от того, кто виноват — глючный софт, deadlock в СУБД, сбой питания или ошибки операторов. Поскольку производство непрерывное, 24/7, очень быстро надоело постоянно приезжать по ночам и спросонья выяснять, почему программы не запускаются, процедуры не выполняются, а потом ещё вручную данные в СУБД вбивать и к консистентному виду её приводить.
Со временем ещё некоторые базы данных стали безбожно тормозить, а некоторое вообще перестали работать из-за «закончилось свободное место», потому его автоматическое освобождение не было предусмотрено. Тут уже перезагрузка очевидно не поможет, пришлось вникать, отлаживать и дорабатывать.
Помимо SQL, одним из ключевых технологий является OPC, для связи с низкоуровневыми устройствами, то ещё удовольствие. Сама по себе задумка была неплохая, но реализация традиционно хромает. Плюс ещё OPC Server для контроллеров Simatic — штука платная, дорогая и как служба не работает.
Однако недостаточно просто взять и переписать всё с нуля. Это должно быть сделано
а) быстро и с минимумом кода,
б) работать более надёжно чем то, что есть,
в) быть лёгким/удобным в настройке/эксплуатации/сопровождении.
Поэтому сначала я очень долго и тщательно продумывал архитектуру. В итоге всё вылилось в
1) своя библиотека для СУБД с поддержкой переподключения,
2) своя библиотека для обмена сообщениями через TCP с поддержкой переподключения,
3) своя библиотека для обмена данными с контроллерами, используя libnodave (также поддержкой переподключения),
4) своя надстройка над SQL для единого синтаксиса описания автоматизированных потоков данных,
5) реализованный на уровне службы (чтобы работать без входа в систему и автоматически перезапускаться при сбоях) универсальный трансфер данных, не теряющий их при потерях связи/ошибках запросов/переполнении памяти, написанный с использованием многопоточности и автоматного программирования,
6) парсер проектов Step7 для извлечения адресов/имён переменных/структур/комментариев к ним,
7) свой веб-сервер с шаблонизатором html,
8) клиент для просмотра архивных данных, с загрузкой/подгрузкой их в фоновом режиме, автоматической сортировкой/группировкой,
9) АРМ для операторов ОКП/технологов,
10) пара небольших утилит для инженеров-электроников,
11) система для отслеживания новых сообщений в журналах событий windows на всех подшефных компьютерах/серверах.
Что касается причин.
Поначалу я пришёл работать временно, чтобы получить опыт. Но со временем к сложностям/грязи/пыли привыкаешь, и это перестаёт быть проблемой. Движуха и адреналин в цеху вызывает зависимость и без этого (в отпуске) через некоторое время становится скучно. На контрасте с цеховыми условиями пребывание на природе/открытом воздухе доставляет много больше удовольствия. Как программист, я делаю всё как сам считаю нужным и правильным, проблем с «тупыми» заказчиками не возникает. Отдельное удовольствие доставляет видеть, что твой софт не просто работает — а люди им пользуются и им нравится. Коллектив хороший — люди слабые/чёрствые долго не держатся, сами уходят. Хорошие тоже бывает уходят, не без этого. Зарплата не такая уж и маленькая, особенно по сравнению с зарплатой учителя (коим я и являюсь по образованию) — выше средней по городу. Если не влазить в ипотеку, её достаточно, чтобы ни в чём себе не отказывать. Да и не всё упирается в деньги.
Да, теорема Найквиста верна, но если даже по двум точкам можно восстановить частоту периодического сигнала
Я Найквиста не читал, но у Котельникова речь идёт именно о бесконечном сигнале. На практике, конечно же, в этом необходимости нет, поскольку необходимое количество точек ограничивает сама функция sinc — для 16-битного сигнала это 65536 точек, и даже оно является излишеством. А также шумы/искажения в исходном сигнале, в цапе (+ джиттер), в усилителе, акустике, комнате.
1. А действительно ли мы улучшили качество звука, добавив семплы, которые в оригинале (живом звуке) могли отличаться от тех, которые мы придумали(интерполировали)?
В оригинале (живом звуке) никаких семплов нет, потому что он непрерывный, а не дискретный. Мы не улучшаем качество звука как таковое, мы снижаем уровень шумов.
Ведь, то что мы записали с частотой 44.1 КГц — было реально зафиксировано микрофоном, а то что было между записанными семплами нам не известно.
Известно согласно теореме Котельникова или Шеннона. Сигнал перед дискретизацией обязательно фильтруется, причём с некоторым запасом. Более того, чувствительность микрофонов, используемых для записи, редко превышает 15кГц.
2. На сколько далеко наша фантазия (прошу прощения, интерполяция :) может нас завести? Т.е. теоретически, мы можем интерполировать и 8битный звук и 4х…
Битность мы не интерполируем, т.к. шумы квантования удалению не подлежат, только маскировке. А частоту дискретизации можно увеличивать хоть до бесконечности.
Для человека средний порог частоты воспринимаемого звука 20 кГц, мы воспроизводим с частотой 44.1 КГц — есть ли смысл в дальнейшем увеличении?
Это вопрос снижения погрешности при восстановлении исходного непрерывного сигнала, а не человеческой чувствительности.
а кто-нибудь знает сколько разрядов может различать человеческое ухо? ;)
Ухо отличает не разряды, а перепад в децибелах. Разряды определяют шумы квантования. По поводу чувствительности — множество научных статей можно найти при желании как-то так.
Всё-таки в профессиональной среде он больше известен как «фильтр 1-го порядка».
(а взялся за самостоятельную реализацию, потому что интересует решение на гексагональной сетке).
Не должно. В частотном домене «щелчок» — это всплеск в широком диапазоне частот, из чего следует, что для восприятия перепадов амплитуд как щелчков они должны быть достаточно далеко разнесены во времени.
Линии между точками я нарисовал сам, и это тоже не совсем корректно, потому правильнее было бы интерполировать их sinc-ом, но на небольшом масштабе это не принципиально, поскольку разницы не видно. Соответственно и масштаб графика увеличивать нет смысла.
С моим примером эти частоты не пересекаются.
Если задача показать, что для 20кГц не нужно 192кГц — так это Котельников/Шеннон/Найквист давно доказали.
Если задача показать, что человек не слышит выше 20 кГц — так это надо фокус-группу собирать и двойное слепое прослушивание устраивать.
Если задача показать, что в HD-записях нет частот выше 20 кГц — так их фильтровать не надо и собрать достаточное количество записей для репрезентативного анализа.
Если задача показать несовершенство алгоритма передискретизации в конкретно взятом аудио-редакторе — так надо его импульсную характеристику анализировать, а не какую-то конкретную аудиозапись.
как бог на душу положилгде свободное место нашлось при строительстве/реконструкции очередного агрегата. Всё это собрано в одну сеть на коммутаторах CISCO.Программист, как и любой другой инженер на производстве, несёт персональную ответственность за подшефное оборудование вне зависимости от того, кто виноват — глючный софт, deadlock в СУБД, сбой питания или ошибки операторов. Поскольку производство непрерывное, 24/7, очень быстро надоело постоянно приезжать по ночам и спросонья выяснять, почему программы не запускаются, процедуры не выполняются, а потом ещё вручную данные в СУБД вбивать и к консистентному виду её приводить.
Со временем ещё некоторые базы данных стали безбожно тормозить, а некоторое вообще перестали работать из-за «закончилось свободное место», потому его автоматическое освобождение не было предусмотрено. Тут уже перезагрузка очевидно не поможет, пришлось вникать, отлаживать и дорабатывать.
Помимо SQL, одним из ключевых технологий является OPC, для связи с низкоуровневыми устройствами, то ещё удовольствие. Сама по себе задумка была неплохая, но реализация традиционно хромает. Плюс ещё OPC Server для контроллеров Simatic — штука платная, дорогая и как служба не работает.
Однако недостаточно просто взять и переписать всё с нуля. Это должно быть сделано
а) быстро и с минимумом кода,
б) работать более надёжно чем то, что есть,
в) быть лёгким/удобным в настройке/эксплуатации/сопровождении.
Поэтому сначала я очень долго и тщательно продумывал архитектуру. В итоге всё вылилось в
1) своя библиотека для СУБД с поддержкой переподключения,
2) своя библиотека для обмена сообщениями через TCP с поддержкой переподключения,
3) своя библиотека для обмена данными с контроллерами, используя libnodave (также поддержкой переподключения),
4) своя надстройка над SQL для единого синтаксиса описания автоматизированных потоков данных,
5) реализованный на уровне службы (чтобы работать без входа в систему и автоматически перезапускаться при сбоях) универсальный трансфер данных, не теряющий их при потерях связи/ошибках запросов/переполнении памяти, написанный с использованием многопоточности и автоматного программирования,
6) парсер проектов Step7 для извлечения адресов/имён переменных/структур/комментариев к ним,
7) свой веб-сервер с шаблонизатором html,
8) клиент для просмотра архивных данных, с загрузкой/подгрузкой их в фоновом режиме, автоматической сортировкой/группировкой,
9) АРМ для операторов ОКП/технологов,
10) пара небольших утилит для инженеров-электроников,
11) система для отслеживания новых сообщений в журналах событий windows на всех подшефных компьютерах/серверах.
Что касается причин.
Поначалу я пришёл работать временно, чтобы получить опыт. Но со временем к сложностям/грязи/пыли привыкаешь, и это перестаёт быть проблемой. Движуха и адреналин в цеху вызывает зависимость и без этого (в отпуске) через некоторое время становится скучно. На контрасте с цеховыми условиями пребывание на природе/открытом воздухе доставляет много больше удовольствия. Как программист, я делаю всё как сам считаю нужным и правильным, проблем с «тупыми» заказчиками не возникает. Отдельное удовольствие доставляет видеть, что твой софт не просто работает — а люди им пользуются и им нравится. Коллектив хороший — люди слабые/чёрствые долго не держатся, сами уходят. Хорошие тоже бывает уходят, не без этого. Зарплата не такая уж и маленькая, особенно по сравнению с зарплатой учителя (коим я и являюсь по образованию) — выше средней по городу. Если не влазить в ипотеку, её достаточно, чтобы ни в чём себе не отказывать. Да и не всё упирается в деньги.
Известно согласно теореме Котельникова или Шеннона. Сигнал перед дискретизацией обязательно фильтруется, причём с некоторым запасом. Более того, чувствительность микрофонов, используемых для записи, редко превышает 15кГц.
Битность мы не интерполируем, т.к. шумы квантования удалению не подлежат, только маскировке. А частоту дискретизации можно увеличивать хоть до бесконечности.
Это вопрос снижения погрешности при восстановлении исходного непрерывного сигнала, а не человеческой чувствительности.
Ухо отличает не разряды, а перепад в децибелах. Разряды определяют шумы квантования. По поводу чувствительности — множество научных статей можно найти при желании как-то так.