Я вступил в дискуссию лишь потому, что вы использовали характеристики вроде «не то» и «и так сойдёт». Это предполагает наличие какого-то опыта. Вот он и был мне интересен. Оказалось, его нет.
Мне действительно не важно, какой битрейт будет у потока, который передаётся по Bluetooth. Важно то, что придёт на вход в ЦАП после всех манипуляций при передаче данных.
Занятно слышать это от человека, который вроде согласился с тем, что звук воспринимается субъективно.
Можете убедиться в этом сами, передав любую композицию без сжатия с одного устройства на другое по Bluetooth. Время передачи, подозреваю, будет сильно меньше времени её звучания.
Очевидно, что при передаче аудио используется другой профиль. Почему — не знаю, я написал уже, что не Bluetooth-разработчик. Заниматься спекуляциями не вижу смысла, поэтому предлагаю на этом закончить.
Потому что этого я и не утверждал. Но это, как уже было сказано, «не то».
Решение из области «и так сойдёт».
А, так вы аудиофил-теоретик? Ни одних наушников c aptX или aptX HD вы не слышали, как я понимаю?
Не вижу смысла что-то дальше обсуждать, честно говоря. Абстрактное теоретизирование мне неинтересно. Смартфон-аудиофилов тут полно, найдете с кем поговорить.
Соглашусь. Попробую сформулировать более точно:
Принципиально, получить звук чтобы на входе в ЦАП биты были один в один.
Для меня суть не изменилась. Это всё ещё то, что хотел сказать.
Я перестал вас понимать. Сообщением выше вы писали, что битрейт вам не важен. Теперь говорите про бит-в-бит. Если битрейт не позволяет, бит-в-бит никак не получится, даже используя компрессию.
Так что мешает передавать данный поток без сжатия вообще, если уж сжатие-без-потерь не освоено? Канал-то вроде позволяет.
Я не Bluetooth-разработчик, я не знаю в чем там технические трудности. Могу только предположить, что если не сжимать поток или использовать сжатие без потерь, затраты энергии на принимающей стороне могут быть неприемлемыми для портативного устройства. Just guessing.
Это все неважно, впрочем. Вы так и не рассказали, каким способом вы достигли убежденности, что аудио по aptX/aptX HD — это негодно.
Нужно больше качества? Fiio. Он даст лучше звук, чем любой телефон, на любых наушниках дороже 50 баксов.
А вот это совершенно не факт. И какой именно Fiio вы имеете в виду?
Во многие флагманские телефоны ставят вполне приличные ЦАПы, тем более, что сравнивать вы предлагаете в наушниках «дороже 50 баксов».
Меня вообще не устраивают затычки — уши болят. Но я же не делаю это аргументом.
Вы сейчас точно про затычки, а не вкладыши? Даже у недорогих внутриканальных наушников в комплекте часто идут сменные амбушюры разной формы и размеров.
Ну не ковыряйтесь, как будто вас кто-то заставляет. У вас какой-то странный интерес к aptX для человека, которому он совершенно не нужен. Кому нужен — давно уже пользуются. Фильтры там починили, кстати.
Лицензирование aptX очевидно есть, плюс есть какие-то издержки на программную/аппаратную части. Я же говорю — если технология коммодизируется, она не будет стоить вообще ничего.
Что значит «32 kbps mp3 тоже бывает 16-bit/44.1kHz» — одному богу известно. Оно должно показать, что MP3 — это производная аудиопотока в 16-bit/44.1kHz? Спасибо, кэп.
Битрейт Audio CD — 44100×16×2 = 1,411,200. Вы будете продолжать сравнивать это с вашими 32,000?
А вы не цепляйтесь к этой модели, она для японского рынка. Я ее назвал как то, чем сам пользуюсь. Ищите европейские модели, например ATH-SR5BT.
Слушайте, ну там 19 страниц наушников.
Мысль ваша понятна и имеет основания. Информацию о поддержке aptX не всегда производители приводят. Но я же дал вам готовую ссылку со списком наушников. На этом же сайте и список телефонов есть. Фильтры не работают, это так. Ну, лично мне пролистать пару десятков страниц было несложно. Не могу назвать это квестом.
> В бюджетных телефонах с паршивыми DAC-ами он попросту не нужен.
А какая связь DAC, aptX и «не нужен»?
aptX — это же фактически про Hi-Fi. Обывателю Hi-Fi не нужен. Производителям бюджетных телефонов нет никакого смысла тратиться на всю цепочку для качественного аудио.
Вот когда Apple снюхается с Нилом Янгом и они загрузят всю крутость 24-bit/192kHz в головы консюмеров, тогда aptX/aptX HD или аналогичный кодек будет в каждых вкладышах.
На самом деле, есть эмпирическое правило: хотите просто и существенно улучшить качество аудио — проапгрейдите колонки/наушники. Это, как правило, дает самый существенный прирост на потраченный доллар. Если под 50/100 вы имели в виду некое действительно более высокое качество, то смысл есть.
Впрочем, зачем фантазировать? Можно элементарно пойти в магазин и сравнить.
1. Если бы вы удосужились хотя бы немного изучить ссылку, то обнаружили бы там массу наушников от уважаемых производителей, начиная от Sony и заканчивая Audio-Technica, Sennheiser и Klipsch
2. Вас научить пользоваться поисковиком? Той же Audio-Technica полно в магазинах, даже в вашем дефолт-сити. Это если нравится переплачивать в полтора-два раза.
3. Я сразу написал, что я не говорю за Xiaomi, а отвечаю на странную реплику про aptX. Какие-то проблемы с aptX в гламурном китайском айфоне — абсолютно не показатель поддержки aptX производителями.
Какое ВДНХ? У меня лично Audio-Technica ATH-AR3BT, которые играют с использованием aptX хоть с компьютера, хоть с телефона. И выбирал я их из большого списка, даже с учетом установленных ограничений.
aptX в Android O на самом деле ничего существенно не изменит, кроме, может быть, большей поддержки производителями наушников. В бюджетных телефонах с паршивыми DAC-ами он попросту не нужен.
Ничего не знаю про китайский телефонопром, но aptX сложно назвать «теоретическим достижением». Наушников с поддержкой aptX полно, на любой вкус и кошелек. Как и телефонов, поддерживающих этот кодек из коробки.
Грядущий Android O вообще имеет aptX и aptX HD по умолчанию.
Не уловил пока вашу позицию. Если адекватная модульность для Java EE приложения не нужна, то для чего в нем вдруг появляются OSGi-бандлы? Может, кому-то все-таки нужна?
EAR/WAR/JAR — это такая смешная модульность. В совокупности с иерархичными загрузчиками классов любой залетевший в нее дятел ведет к краху всего приложения. Начинать какой-то holy war не хочу, ничтоже сумнящиеся могут оценить количество вопросов на SO по [java-ee] + [classcastexception].
PS
У меня нет проблем с закрытием моих реальных потребностей. Это либо OSGi-контейнер, либо EAB/WAB в нормальном Java EE сервере вроде Websphere Liberty. Просто тот кровавый enterprise, в котором живет Java EE, привык следовать стандартам. Отсюда частая невозможность выбирать технологический стэк. OSGi — это не стандарт в мире Java EE и никогда им не будет. Но лично у меня нет сомнений, что JPMS пошагает в Java EE.
Какой истории, вы о чем? Java EE до сих пор не имеет вменяемых средств для модуляризации приложений. В грядущем Java EE 8 JPMS никак задействована не будет. Учитывая скорость, с которой идет развитие платформы, ждите православную модульность для Enterprise Java года через три.
Единственный пока положительный результат финализации JPMS — модуляризация JDK. За счет существенного усложнения всей модульной системы, поскольку модульность пришлось впиливать задним числом.
Это при всем том, что аналогичные концепции детально проработаны и реализованы в OSGi с незапамятных времен, а Enterprise OSGi существуют уже лет пять.
Нет, не выяснили. Вы выдвинули гипотезу и предложили мне ее подтверждать.
Вот когда подтвердите, запишете её в факты.
Занятно слышать это от человека, который вроде согласился с тем, что звук воспринимается субъективно.
Очевидно, что при передаче аудио используется другой профиль. Почему — не знаю, я написал уже, что не Bluetooth-разработчик. Заниматься спекуляциями не вижу смысла, поэтому предлагаю на этом закончить.
А, так вы аудиофил-теоретик? Ни одних наушников c aptX или aptX HD вы не слышали, как я понимаю?
Не вижу смысла что-то дальше обсуждать, честно говоря. Абстрактное теоретизирование мне неинтересно. Смартфон-аудиофилов тут полно, найдете с кем поговорить.
Я перестал вас понимать. Сообщением выше вы писали, что битрейт вам не важен. Теперь говорите про бит-в-бит. Если битрейт не позволяет, бит-в-бит никак не получится, даже используя компрессию.
Я не Bluetooth-разработчик, я не знаю в чем там технические трудности. Могу только предположить, что если не сжимать поток или использовать сжатие без потерь, затраты энергии на принимающей стороне могут быть неприемлемыми для портативного устройства. Just guessing.
Это все неважно, впрочем. Вы так и не рассказали, каким способом вы достигли убежденности, что аудио по aptX/aptX HD — это негодно.
Отсюда возникает вопрос: откуда у вас уверенность, что вы не получите «такой же» звук? Вы производили двойные слепые тесты?
Какой именно битрейт вам нужен для передачи ваших супер-FLAC по Bluetooth?
Хотя, я бы еще поискал живого человека, который сможет отличить 352 kbps обычного aptX от CD.
А вот это совершенно не факт. И какой именно Fiio вы имеете в виду?
Во многие флагманские телефоны ставят вполне приличные ЦАПы, тем более, что сравнивать вы предлагаете в наушниках «дороже 50 баксов».
Вы сейчас точно про затычки, а не вкладыши? Даже у недорогих внутриканальных наушников в комплекте часто идут сменные амбушюры разной формы и размеров.
Лицензирование aptX очевидно есть, плюс есть какие-то издержки на программную/аппаратную части. Я же говорю — если технология коммодизируется, она не будет стоить вообще ничего.
Битрейт Audio CD — 44100×16×2 = 1,411,200. Вы будете продолжать сравнивать это с вашими 32,000?
А вы не цепляйтесь к этой модели, она для японского рынка. Я ее назвал как то, чем сам пользуюсь. Ищите европейские модели, например ATH-SR5BT.
Слушайте, ну там 19 страниц наушников.
Мысль ваша понятна и имеет основания. Информацию о поддержке aptX не всегда производители приводят. Но я же дал вам готовую ссылку со списком наушников. На этом же сайте и список телефонов есть. Фильтры не работают, это так. Ну, лично мне пролистать пару десятков страниц было несложно. Не могу назвать это квестом.
aptX — это же фактически про Hi-Fi. Обывателю Hi-Fi не нужен. Производителям бюджетных телефонов нет никакого смысла тратиться на всю цепочку для качественного аудио.
Вот когда Apple снюхается с Нилом Янгом и они загрузят всю крутость 24-bit/192kHz в головы консюмеров, тогда aptX/aptX HD или аналогичный кодек будет в каждых вкладышах.
Впрочем, зачем фантазировать? Можно элементарно пойти в магазин и сравнить.
Не знаю, что и где декларируется, но у качества звука на CD есть совершенно четкая мерка — 16-bit/44.1kHz.
2. Вас научить пользоваться поисковиком? Той же Audio-Technica полно в магазинах, даже в вашем дефолт-сити. Это если нравится переплачивать в полтора-два раза.
3. Я сразу написал, что я не говорю за Xiaomi, а отвечаю на странную реплику про aptX. Какие-то проблемы с aptX в гламурном китайском айфоне — абсолютно не показатель поддержки aptX производителями.
Какое ВДНХ? У меня лично Audio-Technica ATH-AR3BT, которые играют с использованием aptX хоть с компьютера, хоть с телефона. И выбирал я их из большого списка, даже с учетом установленных ограничений.
aptX в Android O на самом деле ничего существенно не изменит, кроме, может быть, большей поддержки производителями наушников. В бюджетных телефонах с паршивыми DAC-ами он попросту не нужен.
Грядущий Android O вообще имеет aptX и aptX HD по умолчанию.
aptX — это уже «CD-качество» (16-bit/44.1kHz)
aptX HD — это 24-bit/48kHz, там битрейт до 576 kbps
EAR/WAR/JAR — это такая смешная модульность. В совокупности с иерархичными загрузчиками классов любой залетевший в нее дятел ведет к краху всего приложения. Начинать какой-то holy war не хочу, ничтоже сумнящиеся могут оценить количество вопросов на SO по [java-ee] + [classcastexception].
PS
У меня нет проблем с закрытием моих реальных потребностей. Это либо OSGi-контейнер, либо EAB/WAB в нормальном Java EE сервере вроде Websphere Liberty. Просто тот кровавый enterprise, в котором живет Java EE, привык следовать стандартам. Отсюда частая невозможность выбирать технологический стэк. OSGi — это не стандарт в мире Java EE и никогда им не будет. Но лично у меня нет сомнений, что JPMS пошагает в Java EE.
Единственный пока положительный результат финализации JPMS — модуляризация JDK. За счет существенного усложнения всей модульной системы, поскольку модульность пришлось впиливать задним числом.
Это при всем том, что аналогичные концепции детально проработаны и реализованы в OSGi с незапамятных времен, а Enterprise OSGi существуют уже лет пять.