Интерполяция недостающих пикселей в фш — в применении ко звуку это увеличение частоты дискретизации, тут да, интерполировать не только можно, но и нужно.
Вы же предлагаете (в терминах изображений) — размыть цвета на контурах областей одного цвета, это не то же самое
Но вообще стоит взять да и посмотреть, что со спектром становится при откидывании младших бит, мб наоборот появляются лишние гармоники — их тогда можно будет и убрать, причем они по идее должны будут зависеть от того, сколько и из какого начального формата бит выкинули
Если так поокруглять — изменится спектр сигнала, предположение класса «пальцем в небо» — съест высокие гармоники (мало ли там меандр, причем и исходно было 51 51 59 59 59 59 71 71, а вы его к чему-то более пологому приводите)
В любом случае фарш невозможно провернуть назад — инфа уже потеряна, чтобы что-то восстановить — нужно что-то знать об исходном материале
если пользоваться родными картриджами — типа удобно
если не пользоваться — история примерно как с принтерами, когда девайс субсидируется в надежде нагреть на картриджах
Из текста не понятно был это один и тот же пак для всех или все-таки разные, в первом случае bias все равно может быть из-за фиксированного порядка файлов (уставание/адаптация слуха)
Плюс нет гарантии, что весь тракт респондентов это дело нормально воспроизводит (включая достаточно тихое помещение)
ДД оркестра считается 70-80дБ, только это уровень между самыми громкими и тихими звуками, а не тишиной.
В пиках оркестр может выдать до 115дБ spl — собственно это и есть 95дБ над считающим тишиной 20дБ фоновым шумом, в аккурат 16-бит должно хватать, но стоит самую малость ошибиться с уровнем сигнала — и кранты, клиппинг
Хотя стоит отметить, что в большинстве городских квартир фоновый шум 35+ дБ, и такой ДД в записи не нужен (собственно его оттуда и убирают компрессией при мастеринге ровно по этой причине)
Почему тогда среди них результат 30% вместо ожидаемого 50%, который должен был быть, если бы ничего не слышали и соотвественно выбирали случайно?
Предположительно причина где-то в районе bandpass-фильтра и дитеринга, которые в случае 192@24 -> ?@16 -> 192@24 -> 44.1/48@16 были точно применены на первом шаге и уже были в записи, и неясно как применены в случае тупого преобразования 192@24-> 44.1/48@16 в дровах
Второе возможное объяснение — из-за адаптации слуха первый трек из прослушиваемых может казаться чуть громче, а громче всегда подсознательно воспринимается как более качественное -> опять косяк в проведении теста, надо было выдавать участникам в рандомном порядке, чтобы этот эффект тоже статистически нивелировать (а респонденты похоже качали один и тот же пак)
В обоих случаях исследование некорректно и максимум говорит о том, что на современном среднем уровне техники у людей — нет смысла доставлять контент в более высоком качестве, чем пожатое без потерь cdaudio
Частота дискретизации и битность ортогональны, может быть и 192khz 8bit и 22050 32bit.
А вот про железо и 48khz внутри простеньких чипов — верно (собственно ниже уже об близкой проблеме писал — даже если есть хороший цап, операционка все равно не факт что до него сигнал в исходном виде доведет)
Эта мелодия может вообще до цапа не доходить из-за дефолтных настроек операционок (или слетания кастомных) — мало кто перед включением каждого трека их проверяет :)
Нет упоминания, что авторы просили людей проверить, что хотя бы частота дискретизации по пути не портится на всем пути от микрофона до ушей.
В макоси по умолчанию, не зависимо от того, какого качества играется исходник — на железо уходит 16бит 44.1, чтобы это было не так — надо специально лезть и переключать (причем если выставить «с запасом» — то будет апконверт, тоже фигово ибо погрешности в любом случае)
Винды вне виртуалки нету, но есть подозрение, что там похожая петрушка.
Это объясняет ошибку музыкантов: маков у них в среднем больше, слух тренированный — они могли услышать что преобразование, которое делали авторы в профессиональном софте (с дитерингом и тп) по качеству оказалось лучше, чем то, что делает сама операционка и дрова
Отличная библиотека — заставляет задуматься над внутренностями стандартной библиотеки и железа, оставшись в терминах ардуины (ну или отталкиваясь от них)
Но вообще родные avr-мапинги доступны и в ардуино среде, ничто не мешает посмотреть arduino.cc/en/Hacking/PinMapping168 и использовать их.
Скетч для первого примера целиком —
int main(){
DDRB |= _BV(PORTB5); // set output mode of pin13 (pin 5 of port B)
label:
PORTB |= _BV(PORTB5);
PORTB &= ~_BV(PORTB5);
goto label;
}
Получается 140 байт и те же 2.7МГц на 13-м пине
Причем кроме возможности перейти с ардуины на другой toolchain еще будет мотивировать правильнее проектировать железо и софт: например зная про порты/регистры — можно выводить данные одной операцией, а не попиново, выставлять режимы сходу битовыми масками и тп.
А для чего внешние pull-up резисторы? Можно же включить на соответствующих ногах встроенные
Светодиоды в идеале лучше было бы зажигать программно — желаемый стейт и так виден по положению тумблера, а какой он на деле — от софта зависит, пинов под это хватает
Ясное дело, что не всегда есть смысл слишком заморачиваться с полной реализацией, но оставить такую возможность в железе было бы в тему, а в прошивке зажечь леды по текущей схеме
А так можно было бы в будущем добавить веселую индикацию типа мигания при каких-то неполадках, во время переключения и тп
Вместо пустого цикла имхо лучше уводить мк в idle — таймеры и прерывания в нем останутся, а потребление меньше и в целом красивее
Вы же предлагаете (в терминах изображений) — размыть цвета на контурах областей одного цвета, это не то же самое
Но вообще стоит взять да и посмотреть, что со спектром становится при откидывании младших бит, мб наоборот появляются лишние гармоники — их тогда можно будет и убрать, причем они по идее должны будут зависеть от того, сколько и из какого начального формата бит выкинули
В любом случае фарш невозможно провернуть назад — инфа уже потеряна, чтобы что-то восстановить — нужно что-то знать об исходном материале
если не пользоваться — история примерно как с принтерами, когда девайс субсидируется в надежде нагреть на картриджах
Btw, сайт похоже лег :)
Плюс нет гарантии, что весь тракт респондентов это дело нормально воспроизводит (включая достаточно тихое помещение)
В пиках оркестр может выдать до 115дБ spl — собственно это и есть 95дБ над считающим тишиной 20дБ фоновым шумом, в аккурат 16-бит должно хватать, но стоит самую малость ошибиться с уровнем сигнала — и кранты, клиппинг
Хотя стоит отметить, что в большинстве городских квартир фоновый шум 35+ дБ, и такой ДД в записи не нужен (собственно его оттуда и убирают компрессией при мастеринге ровно по этой причине)
Предположительно причина где-то в районе bandpass-фильтра и дитеринга, которые в случае 192@24 -> ?@16 -> 192@24 -> 44.1/48@16 были точно применены на первом шаге и уже были в записи, и неясно как применены в случае тупого преобразования 192@24-> 44.1/48@16 в дровах
Второе возможное объяснение — из-за адаптации слуха первый трек из прослушиваемых может казаться чуть громче, а громче всегда подсознательно воспринимается как более качественное -> опять косяк в проведении теста, надо было выдавать участникам в рандомном порядке, чтобы этот эффект тоже статистически нивелировать (а респонденты похоже качали один и тот же пак)
В обоих случаях исследование некорректно и максимум говорит о том, что на современном среднем уровне техники у людей — нет смысла доставлять контент в более высоком качестве, чем пожатое без потерь cdaudio
А вот про железо и 48khz внутри простеньких чипов — верно (собственно ниже уже об близкой проблеме писал — даже если есть хороший цап, операционка все равно не факт что до него сигнал в исходном виде доведет)
В макоси по умолчанию, не зависимо от того, какого качества играется исходник — на железо уходит 16бит 44.1, чтобы это было не так — надо специально лезть и переключать (причем если выставить «с запасом» — то будет апконверт, тоже фигово ибо погрешности в любом случае)
Винды вне виртуалки нету, но есть подозрение, что там похожая петрушка.
Это объясняет ошибку музыкантов: маков у них в среднем больше, слух тренированный — они могли услышать что преобразование, которое делали авторы в профессиональном софте (с дитерингом и тп) по качеству оказалось лучше, чем то, что делает сама операционка и дрова
Но вообще странно, что до сих пор никто не додумался сделать tzdata обновляемым отдельно от всей оси, как настройки оператора например
Но вообще родные avr-мапинги доступны и в ардуино среде, ничто не мешает посмотреть arduino.cc/en/Hacking/PinMapping168 и использовать их.
Скетч для первого примера целиком —
int main(){ DDRB |= _BV(PORTB5); // set output mode of pin13 (pin 5 of port B) label: PORTB |= _BV(PORTB5); PORTB &= ~_BV(PORTB5); goto label; }Получается 140 байт и те же 2.7МГц на 13-м пине
Причем кроме возможности перейти с ардуины на другой toolchain еще будет мотивировать правильнее проектировать железо и софт: например зная про порты/регистры — можно выводить данные одной операцией, а не попиново, выставлять режимы сходу битовыми масками и тп.
Светодиоды в идеале лучше было бы зажигать программно — желаемый стейт и так виден по положению тумблера, а какой он на деле — от софта зависит, пинов под это хватает
Ясное дело, что не всегда есть смысл слишком заморачиваться с полной реализацией, но оставить такую возможность в железе было бы в тему, а в прошивке зажечь леды по текущей схеме
А так можно было бы в будущем добавить веселую индикацию типа мигания при каких-то неполадках, во время переключения и тп
Вместо пустого цикла имхо лучше уводить мк в idle — таймеры и прерывания в нем останутся, а потребление меньше и в целом красивее