Ошибка в постановке задачи, что вы делаете, как вы это делаете, и в интерпретации результатов.
Если задача показать, что для 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 КГц — есть ли смысл в дальнейшем увеличении?
Это вопрос снижения погрешности при восстановлении исходного непрерывного сигнала, а не человеческой чувствительности.
а кто-нибудь знает сколько разрядов может различать человеческое ухо? ;)
Ухо отличает не разряды, а перепад в децибелах. Разряды определяют шумы квантования. По поводу чувствительности — множество научных статей можно найти при желании как-то так.
Чисто математически это одно и тоже, поскольку sinc в теореме Котельникова как раз и играет роль идеального фильтра низких частот с линейной фазой. Разница только в реализации — программно FIR-фильтрацию эффективнее делать через FFT, в железе — линейной свёрткой, но используя специальную архитектуру для распараллеливания вычислений. Аналоговыми (IIR) фильтрами высокого порядка тоже можно получить приемлемые результаты, но они фазу вращают. В некоторых случаях используют гибридные решения, когда FIR-ом компенсируют фазовые сдвиги от IIR.
Логичнее было бы делать либо повтор предыдущего значения, либо интерполяцию между соседними значениями
Не логичнее, поскольку это приведёт к искажению АЧХ исходного сигнала (за исключением sinc-интерполяции). Математически интерполяция в данном случае будет равна свёртке сигнала с интерполируемой функцией (в случае линейной интерполяции — с треугольной, при повторе предыдущего семпла — прямоугольной и т.д.).
Спустя лишь пару дней на хабре появилась статья со схожим содержанием, только вместо массива там — шашки. И как можно убедиться, никакой злобы в комментариях к ней нет.
Оптимальное расположение звукопоглотителей зависит от интерференционной картины помещения. Его можно замерить, можно рассчитать, можно определить методом тыка.
На англоязычном форуме в обсуждении научной (!) статьи, мне попадался комментарий «Stop smoking crack/heroin!». Тоже ведь добро — забота о здоровье ближнего.
Вот именно. Программируя в стерильных условиях в офисе непросто представить, как делать то же самое в условиях цеха в окружении вундерваффе, которые потребляют электричества в половину города, а над головой ковши с горячим металлом весом в 200 тонн проезжают. Бывает, и протекают. И причины, по котором специалисты работают в таких условиях, существуют. Хотя бы потому, что «обезьянки» не выживают.
Ничего странного. Мы все здесь — конкуренты. Что по критике, то:
1) если вы смогли что-то полезное вынести, то неважно, в какой форме она была.
2) наличие деструктивной критики значит, что по делу никто ничего сказать не может. Значит у вас — всё хорошо.
3) негатив пишут не потому, что плохие, а потому что — завидуют. Психология.
Ваш комментарий — наглядный пример того, в котором желание показать свою правоту и осведомлённость превосходит всё остальное. Иначе вы бы написали «я тоже работаю на производстве и у нас таких полно».
Если задача показать, что для 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кГц.
Битность мы не интерполируем, т.к. шумы квантования удалению не подлежат, только маскировке. А частоту дискретизации можно увеличивать хоть до бесконечности.
Это вопрос снижения погрешности при восстановлении исходного непрерывного сигнала, а не человеческой чувствительности.
Ухо отличает не разряды, а перепад в децибелах. Разряды определяют шумы квантования. По поводу чувствительности — множество научных статей можно найти при желании как-то так.
Не логичнее, поскольку это приведёт к искажению АЧХ исходного сигнала (за исключением sinc-интерполяции). Математически интерполяция в данном случае будет равна свёртке сигнала с интерполируемой функцией (в случае линейной интерполяции — с треугольной, при повторе предыдущего семпла — прямоугольной и т.д.).
Дан сигнал с частотой дискретизации 4кГц (зелёный — во временном домене, синий — в частотном — АЧХ):
Увеличиваем частоту дискретизации до 16кГц, для чего добавляем по 3 промежуточных нулевых отсчёта:
Отфильтровываем гармоники фильтром нижних частот от 2 кГц (так как их не было в исходном сигнале) и получаем
Профит.
1) если вы смогли что-то полезное вынести, то неважно, в какой форме она была.
2) наличие деструктивной критики значит, что по делу никто ничего сказать не может. Значит у вас — всё хорошо.
3) негатив пишут не потому, что плохие, а потому что — завидуют. Психология.