Странные формулировки. Если кто-то, кто просто владеет русским языком, сделает обзор и выложит его в Instagram. При этом его никто не просил (иными словами, рекламу не заказывал), то владелец бренда все равно получит штраф?
Не уверен, что вы услышите именно шумы квантования )
А интермодуляционным искажениям взяться в кодеке такого типа негде, они проявляются при применении какой-либо нелинейной функции к широкополосному сигналу целиком.
Хотя я тут не совсем правильно выразился. У SBС просто очень грубый квантователь, и он почти не учитывает эффект маскирования, для анализа сколько бит выделить на кодирование диапазона. При таком подходе, часть компонент просто грубо вырезается, и это визуально (в спектре) и на слух, похоже на ситуацию «отключения» под-диапазонов.
Хотя самих под-диапазонов у SBC мало, поэтому технически то, что я выше написал, не верно ) Но, повторюсь, на слух так и есть.
И, как заметил ValdikSS, даже при снижении битрейта на 1-2 ступеньки вниз (300/229), качество заметно проседает. А слушал я как раз на реальном приемнике, со всеми прелестями конфликтов в 2.4 ГГц, и соответственным снижением полосы пропускания.
Если честно разница на слух есть: SBС немного шепелявит, и он попроще будет, чем MPEG 1 layer II, на который сослались в статье.
На MPEG 1 layer II при битрейте 224+ кбит/сек на слух все ок, а тут при 345 таки есть вопросы. Просто SBC был заточен под малое энергопотребление, оттого его упростили донельзя.
На сколько я понял из его спецификации, он не умеет кодировать данные в каждом диапазоне с разной точностью (что дает просто нелинейные искажения и повышенный шум, который будет замаскирован), а просто тупо режет некоторые из них. А на слух частое «отключение/включение» какого-либо sub-band и слышится как «булькающие/шепелявящие» артефакты.
Кроме того тут забыли про Apple, которая никаких AptX не умеет (вернее Mac умеет, а iPhone/iPad — нет), только SBC и AAC, а наушники, что умеют AAC еще поискать надо, посему для iDevice выбор крайне ограничен!
По поводу железа — согласен, много очень спорных решений (touchBar — наверное самое спорное), поэтому и не обновляюсь, пока не пофиксят.
А по поводу web — пусть бледнеет, я остаюсь при своем мнении.
Да я не занимаюсь web-разработкой, а смотрю лишь как пользователь и вижу, что
Chrome/FF на маках требуют много ресурсов, а мне это категорически не подходит.
Кроме того на iOS есть только Safari и если сайт там нормально не работает и нет нативного приложения, то я просто ищу другой, который работает. Очень часто это касается всяких магазинов/каталогов — мучаться, чтобы купить именно у них обычно желания нет (исключение если вариант всего один, он очень надо и/или цена отличается в разы — но вот прям такое бывает 1-2 раза в год).
Использование самых самых последних стандартов — это проблема разработчика.
Если брать другую область, то например C++17 имплементирован не полностью и у всех по разному, а уже как бы 2018, но на 99% реализован пока лишь С++14.
Соответсвенно если разработчик выбрал самый-самый стандарт и огреб проблем — это только его косяк, так как обычно не стоит задачи использовать самое последнее, а чтобы работало — а результата нет!
Обсуждение совсем не по теме, но не могу сдержаться!
Что такого супер-нового нужно веб-страничке, чего нет в Safari?
Хватит наворачивать веб!
Для двух абзацев текста тянется куча JS библиотек (порой на несколько мегабайт), все это долго загружается, а после жутко тормозит — я понимаю это и есть «современные веб-стандарты»?
Спасибо, не надо!
Всякие Properties и Extensions вещь конечно нужная, но жить без них вполне можно. И как уже было сказано выше, те же Properties реализуемы текущими средствами языка, кому нужно, тот допишет.
А вот поддержка UNICODE из коробки, так чтобы fopen (понятно, что он еще из C, но ведь из C++ никуда не делся), да что там, fstream::open принимал UTF8 на всех платформах, а не только на UNIX.
Хотелось бы, что-бы std::string умел работать с UNICODE, без проблем поддерживал композицию/декомпозицию и банальное сравнение без учета регистра (с учетом текущей локали), и поиск по строке (естественно с учетом разных форм записей одной и той же строки в UNICODE).
И после Objecive-C с их подсчетом ссылок, std::enable_shared_from_this кажется жесточайшим костылем. Я понимаю, что RAII важная и удобная концепция языка (чего не хватает многим java/C#/JS), но есть 2 проблемы:
— как быть, если объект с std::enable_shared_from_this создается на стеке?
— в целом хранение счетчика ссылок «далеко» от самого объекта существенно снижает производительность.
Я бы предложил создавать счетчик прямо в объекте (так быстрее и не нужны костыли), и запретить создавать такие объекты на стеке, еще на этапе компиляции!
Меня всегда удивляло стремление отдельных людей выдумывать «правила», а потом героически их преодолевать!
Инкапсуляция на 100% — это утопия, так не бывает в жизни. ООП — лишь средство более элегантно решить некоторые (но далеко не все) проблемы, но не нужно его идеализировать и обожествлять! Если предоставить «клиенту» посмотреть на «внутренности» — это не плохо, просто «клиент» (пользователь библиотеки), принимая решения, должен осознавать последствия сделанного им выбора. Я уверен, что разумный доступ к внутренностям объекта (и одновременным пониманием, чем это чревато) позволяет писать более эффективный код, и делать это быстрее, а не тратить время на героическое преодоление правил. Правила должны помогать осуществлять задумки, а не мешать им. А вот ответственность за сильное связывание, спагетти-код и т.д. лежит не на языке, и даже не на библиотеке, а на конкретном разработчике ее использующем.
И если библиотека хорошо выполняет свою задачу, пусть она трижды вся public, я буду ее использовать, и скажу ее разработчику лишь спасибо!
Странные формулировки. Если кто-то, кто просто владеет русским языком, сделает обзор и выложит его в Instagram. При этом его никто не просил (иными словами, рекламу не заказывал), то владелец бренда все равно получит штраф?
А интермодуляционным искажениям взяться в кодеке такого типа негде, они проявляются при применении какой-либо нелинейной функции к широкополосному сигналу целиком.
Хотя самих под-диапазонов у SBC мало, поэтому технически то, что я выше написал, не верно ) Но, повторюсь, на слух так и есть.
И, как заметил ValdikSS, даже при снижении битрейта на 1-2 ступеньки вниз (300/229), качество заметно проседает. А слушал я как раз на реальном приемнике, со всеми прелестями конфликтов в 2.4 ГГц, и соответственным снижением полосы пропускания.
На MPEG 1 layer II при битрейте 224+ кбит/сек на слух все ок, а тут при 345 таки есть вопросы. Просто SBC был заточен под малое энергопотребление, оттого его упростили донельзя.
На сколько я понял из его спецификации, он не умеет кодировать данные в каждом диапазоне с разной точностью (что дает просто нелинейные искажения и повышенный шум, который будет замаскирован), а просто тупо режет некоторые из них. А на слух частое «отключение/включение» какого-либо sub-band и слышится как «булькающие/шепелявящие» артефакты.
Кроме того тут забыли про Apple, которая никаких AptX не умеет (вернее Mac умеет, а iPhone/iPad — нет), только SBC и AAC, а наушники, что умеют AAC еще поискать надо, посему для iDevice выбор крайне ограничен!
А по поводу web — пусть бледнеет, я остаюсь при своем мнении.
Да я не занимаюсь web-разработкой, а смотрю лишь как пользователь и вижу, что
Chrome/FF на маках требуют много ресурсов, а мне это категорически не подходит.
Кроме того на iOS есть только Safari и если сайт там нормально не работает и нет нативного приложения, то я просто ищу другой, который работает. Очень часто это касается всяких магазинов/каталогов — мучаться, чтобы купить именно у них обычно желания нет (исключение если вариант всего один, он очень надо и/или цена отличается в разы — но вот прям такое бывает 1-2 раза в год).
Использование самых самых последних стандартов — это проблема разработчика.
Если брать другую область, то например C++17 имплементирован не полностью и у всех по разному, а уже как бы 2018, но на 99% реализован пока лишь С++14.
Соответсвенно если разработчик выбрал самый-самый стандарт и огреб проблем — это только его косяк, так как обычно не стоит задачи использовать самое последнее, а чтобы работало — а результата нет!
Что такого супер-нового нужно веб-страничке, чего нет в Safari?
Хватит наворачивать веб!
Для двух абзацев текста тянется куча JS библиотек (порой на несколько мегабайт), все это долго загружается, а после жутко тормозит — я понимаю это и есть «современные веб-стандарты»?
Спасибо, не надо!
А вот поддержка UNICODE из коробки, так чтобы fopen (понятно, что он еще из C, но ведь из C++ никуда не делся), да что там, fstream::open принимал UTF8 на всех платформах, а не только на UNIX.
Хотелось бы, что-бы std::string умел работать с UNICODE, без проблем поддерживал композицию/декомпозицию и банальное сравнение без учета регистра (с учетом текущей локали), и поиск по строке (естественно с учетом разных форм записей одной и той же строки в UNICODE).
И после Objecive-C с их подсчетом ссылок, std::enable_shared_from_this кажется жесточайшим костылем. Я понимаю, что RAII важная и удобная концепция языка (чего не хватает многим java/C#/JS), но есть 2 проблемы:
— как быть, если объект с std::enable_shared_from_this создается на стеке?
— в целом хранение счетчика ссылок «далеко» от самого объекта существенно снижает производительность.
Я бы предложил создавать счетчик прямо в объекте (так быстрее и не нужны костыли), и запретить создавать такие объекты на стеке, еще на этапе компиляции!
Инкапсуляция на 100% — это утопия, так не бывает в жизни. ООП — лишь средство более элегантно решить некоторые (но далеко не все) проблемы, но не нужно его идеализировать и обожествлять! Если предоставить «клиенту» посмотреть на «внутренности» — это не плохо, просто «клиент» (пользователь библиотеки), принимая решения, должен осознавать последствия сделанного им выбора. Я уверен, что разумный доступ к внутренностям объекта (и одновременным пониманием, чем это чревато) позволяет писать более эффективный код, и делать это быстрее, а не тратить время на героическое преодоление правил. Правила должны помогать осуществлять задумки, а не мешать им. А вот ответственность за сильное связывание, спагетти-код и т.д. лежит не на языке, и даже не на библиотеке, а на конкретном разработчике ее использующем.
И если библиотека хорошо выполняет свою задачу, пусть она трижды вся public, я буду ее использовать, и скажу ее разработчику лишь спасибо!