> Мне хватило и первого трека :)Чудес не бывает - lossy на 64 кбит таки lossy. Однако, не слыша рядом оригинал или не зная как звучит оригинал - сложно заметить подвох :P.
> Да и это хорошо, для некоторых ситуаций - ты просто не замечаешь,
Я думаю что это нормально чтобы слушать музыку на том же мобильном устройстве например. Где место может быть ограничено, а колонки на ушах могут быть непрактичны.
> Немного лениво. Но хочу еще жене поставить, она музыкант - интересно какие
> проблемы она отметит.
В идеале слепым тестом и на разных кодеках, но это уж как ресурсы позволят.
> Тут еще вопрос на чем и в каких условиях они слушают.
Ну да. Хотя слепые тесты для пузомерок кодеков обычно вроде делают на нормальном оборудовании и opus там прилично смотрелся.
> Ну не в два, но в полтора - возможно. Да и по
> результатам оценок на их сайте примерно так и получается.
ИМХО опусом на 96-128 можно заменить мп3 на 256 и выше, поэтому я его считаю ближе к двукратной разнице.
> Статика (режим самолет) - 20-25 мА. Динамика еще добавляет 15-20 мА в
> зависимости от формата.
Интересно. Нокла около 50-55 на мои обычные уши, с обычной громкостью, трек наобум у которого была версия в mp3 и vorbis. А в самолетном режиме в idle - около 4 ма. Но это не статика. С одной стороны немного клоков тикает, с другой половину блоков и периферии гейтанули по питанию - это некая смесь.
> ИМХО все равно много. Явно плохо оптимизирован - динамика на clip zip
> 3-5 мА и это с его древним cpu.
У него все-таки этот ваш хардварный блок и система менее разлапистая.
> Естественно, сравнивал на практически не подвижных фрагментах.
Видео все-таки для движущихся картинок. Кодек имеет полное право использовать эффект temporal masking для экономии битрейта. А то что это затрагивает стопкадры - видео все-таки не для публикации фотографий и скриншотов.
> Меня в основном интересует q21-24 (для x264) - не вижу смысла очень
> сильно занижать битрейт. Хочется сохранить достаточно приличное видео, ведь смотреть я
> его буду и через 20 лет. Так что хочется сохранить детали.
А q - квантизатор? Я не кодирую с постоянным квантизатором. Зачем мне пустой экран с той же квантизацией как интенсивная сцена? Это субоптимально по bit allocation, насколько я понимаю. Поэтому я обычно использую vbr с заданием желаемого среднего (определяющего какой размер файла я хочу), min (часто близкий к 0) и max (который я в принципе готов терпеть в пике). И иногда ручным лимитом на квантизаторы/кейфреймы. Хотя обычно не требуется. Нечто между crf и vbr наверное. При этом кодек может менять квантизаторы как ему удобнее, ограничения битрейта - для вменяемости результата (лимитирование CPU/bandwidth spike и желаемый размер). При этом кодек как я понимаю получит условия близкие к оптимальным и при 2-проходном кодировании без проблем отберет биты там где они не требовались и докинет где требовались, стараясь остаться в пределах желаемого размера в среднем. При этом с одной стороны я понимаю в какой размер (средний битрейт) будет. С другой вроде бы не должно мешать кодеку оптимально кодировать.
> Да, но на средних-больших битрейтах эти блоки превращаются в детали.
А я не фанат больших битрейтов. Зачем мне "как xvid", только еще сильнее грузящий проц? Пойнт психовизуальных махинаций - потерять максимум данных и не заметить это.
> А у vp9 немного мыла остается.
Не замечал особо. А титры и тому подобный мелкий текст, где это хорошо заметно у VP9 так вообще традиционно четче чем в x264 обычно получается. С вашими квантизаторами такое как вообще выглядит? Вроде это довольно высокий квантизатор.
> У меня даже телефон снимает в него в реальном времени, не говоря уж о камере :)
Кодек подпертый реалтаймом не может долго искать оптимальные варианты motion compensation и прочего представления субблоков. Поэтому соотношение битрейт/качество может продуть наверное даже xvid. Поэтому у меня получалось сдуть файлы с камер в РАЗЫ при том что я не могу найти дефекты даже на стопкадрах. А сотни гигз полученные в результате сдувания жирных файлов на глаз заметны хорошо.
> 720p на моей машине (пресет slow) 0.7 realtime, ultrafast - в 3.3 раза быстрее realtime.
Когда я перекодирую видео - я обычно использую 2-проходное кодирование и мне пофиг какой там процент от реалтайма. Для x264 я использую самый медленный пресет - если что-то перекодируется, оно наверное будет храниться долго, поэтому меня интересует оптимизация битрейт/качество прежде всего. Чтобы выглядело симпатично и не занимало терабайты.
> Тоже смотрю в его сторону, но пока не пробовал.
Он тоже медленный в кодировании. Но первые впечатления - по битрейт/качество он уже ощутимо делает VP9, x264 до такого уровня разогнать нереально, x265 - пилят полтора человека, в web он играться наверное не будет. Да и один из goal-ов AV1 - nextgen по сравнению с H.265 :).
> Нет. Перед оцифровкой нужно срезать весь ультразвук, дабы избежать искажений в слышимом
> диапазоне. Для cd audio - 22.5кГц - 20кГц = 2.5 кГц.
Вообще, некоторые "золотые ущи" вроде могут слышать чуть более 20кГц, если мощность достаточна, у 21-22 кГц чтоли. У некоторых болевой порог наступает чуть выше 20кГц, хоть там и крутая кривая.
> вполне приемлемой крутизной, а затем в цифровым фильтром срезать весь ультразвук
> и перевести в 44.1/48кГц.
Только потом зачастую забывают применить этот фильтр, в процессе обработки донавешивают еще артефакты - формат позволяет. А потом - маркетологи же сказали - всем по 24/192, да чтоб в lossless! Ну и вот, отгружают. А как по мне - пусть сразу 100 MSPS запиливают.
> Это решения ценой в 0.5$-5$, где качество звука в прямом смысле как у AC97.
Это большинство чипов для смартов и планшетов, встроенное аудио большинства писюков/лаптопов и проч. Большинство людей слышат через них. И поэтому удобно будет им - они больше всего денег за музыку в онлайне платят и индустрия развернется на них. Да уже в общем то. Хоть как и положено с маркетинговыми приколами, с 24/192 и ультразвуком.
> Любой современный CGU (clock generation unit) без проблем справляется с этой
> задачей, так как имеет гибкую систему делителей и множителей.
Это некий отдельный узкоспециализированный блок. Его элементарно нет в большинстве железяк. Дробные делители и множители для большинства железяк - экзотика. Например я без проблем синтезирую 48кГц или деривативы таймером в STM32 от типовых кварцев. А вот как 44100 или деривативы там получить - я хз. Не то чтобы тамошний DAC нацелен на качественное аудио т.к. 12 битов. Но все-таки.
> В современных SoC куча различной периферии и частоты там очень разные и далеко
> не всегда кратные.
Это конечно зависит от. Но именно дробные множители и делители экзотика. А хомякам все-равно сейчас 24/192/lossless подавай. Маркетолоки сказали что меньше - не круто. И поэтому всем будет FullHD'ец :)
> И много их? 1% или 0.1%?
Учитывая что онлайн продажи перевесили физические носители - годиков через 5 поговорим чего там 0.1% :)
> под него весь конвейер. Они по прежнему выпускают cd, зачем им
> делать второй мастер для online? Им как раз проще выложить 44.1.
Затем что нынче большинство покупок уже совершается онлайн. А сидюки как формат распостранения околели. И хомяки сейчас любят уже 24/192, lossless. Маркетологи сказали что это рулит. Да и продажи флешпамяти надо двигать :)
> Если взять 44.1 и сжать opus - получаешь 48. Но если сделать opusdec - получаешь 44.1
По всем признакам эта проблема самоустраняется силами маркетологов и сторов ;)
> Потому, что все музыка в нем.
Продаваны уже решили что вся музыка должна быть 24/192. Ну как видео - менее 4K - уже не человек^W монитор/телевизор :P. Студии построятся, так же как производители панелей и контента. Денег всем хочется. А обладатели плееров вообще онлайн с своих железок не лазят и поэтому денег с них не получишь.
> На PC да - стандарт. А вот в мобильном сегменте - не факт.
Описание блоков на которые я натыкался обычно гласили про 48кГц или кратные.
> Нет, как я уже сказал, это элементарно делает современный (5-10 лет) CGU.
У большинства систем аудио таки не цель существования системы а всего лишь одна из 100500 фич и вешать каждой фиче по жирному специализированному блоку - накладно слишком. Такое только в спец-SoC для плееров наверное. Может иногда и где-то еще бывает. Но обычно есть целые делители и иногда PLL для умножения. При том PLL - нишевые штуки со своими особенностями.
> и поставит. Раньше на дорогих платах ставили отдельные два кварца и
> переключались между ними - точность выше (кварцы с повышенной точностью) но
> относительно сложно и дорого.
Не знаю про какие платы речь, но большинство планшето-смартовых чипов тактируется от одного кварца с какой-нибудь типовой круглой частотой. Сделать из них 48 или даже 192 кГц можно элементарным счетчиком. А вот 44100...
> Qualcomm MSM7227A
Хм, интересно. Надо попробовать поискать даташит, чтоли.
> Тут ситуация похожа на jpeg и mp3 - даже если есть что
> лучше, особого смысла менять нет и все продолжают использовать.
Вот не надо тут за всех расписываться. У меня часть треков в vorbis, что-то в flac, немного даже в opus. А mp3 я считаю глупым и неэффективным форматом, да еще и с патентами. И поэтому избегаю его при наличии альтернатив. Один из самых плохих lossy форматов.
А с jpeg - на самом деле альтернативы пытаются сделать давно но у них свои проблемы. Кто патентами обложен как собака блохами, у кого либ вменяемых нет, кто просто неоднозначный и сделан наспех, как webp.
> Я это не утверждал. Это как с mmx/sse когда подходит - используем
> и ускоряемся, если не - делаем по-старинке на стандартном наборе команд.
Ну так то да, но мне больше нравятся generic железки не делающие допущения какой там будет алгоритм. Ну разве что совсем generic допущения, как simd всякий.
> Производители SoC с вами не согласны, но это их дело :)
Производители узконишевых специализированных SoC. Которые капля в море полупроводниковой промышленности. В большинстве SoC ничего такого нет. Техас вон тоже думал что их сигнальники встроенные в omap - преимущество. А на них все взяли и забили.
> Я же лично хотел бы "вечный" плеер с зарядом от нажатия клавиш
> при использовании и весом в 20-30г.
Подозреваю что в нажатии клавиш недостаточно энергии. Физику не обманешь: в сами уши улетают какие-то доли ватта, кнопками это напряжненько. Вообще, пока такие уровни энергии проще всего снять или с солнечной батареи или с пельтье, подогреваемого таки приличнее чем температура тела человека. В плеере можно попробовать пристроить какой-нибудь магнитный маятник, наводящий ЭДС в катушке. Накрайняк если тряски от ходьбы не хватит, потряс специально - подзарядил. Жаль что для автономных датчиков не катит - они чаще всего неподвижны. Хотя... хотя мне кажется что я придумал пару прикольных вещиц где номер прокатит.
> Для этого и нужны серьезные оптимизации.
Я не думаю что вы с кнопок снимете достаточно хотя-бы для энергии в уши без превращения плеера в тренажер.
> Пока при таком весе и 20-30 часов не каждый плеер осилит.
Хм, получается что смарт почти столько же играет - за счет более жирной батарейки. Габариты у него конечно не плеерные, но он обычно со мной.
> Нет ;)
Я про ваш смарт ;)
