> Я думаю что это нормально чтобы слушать музыку на том же мобильном
> устройстве например. Где место может быть ограничено, а колонки на ушах
> могут быть непрактичны.И для аудио книг - там самые популярные битрейты - mp3/64-128, качество не особо критично, а сами книги более 30 часов бывают.
> В идеале слепым тестом и на разных кодеках, но это уж как
> ресурсы позволят.
Да, хочу проверить на каких битрейтах (для mp3 и opus) определение сжатого трека станет неуверенным.
> ИМХО опусом на 96-128 можно заменить мп3 на 256 и выше, поэтому
> я его считаю ближе к двукратной разнице.
У опус вроде упор оптимизации был на низкие битрейты. Нужно сравнивать.
>> ИМХО все равно много. Явно плохо оптимизирован - динамика на clip zip
>> 3-5 мА и это с его древним cpu.
> У него все-таки этот ваш хардварный блок и система менее разлапистая.
Нет, у clip zip только ARM926EJS, так что декодирование полностью программное.
> Видео все-таки для движущихся картинок. Кодек имеет полное право использовать эффект temporal
> masking для экономии битрейта.
Так он и использует. Просто я не знаю надежной методики, как сравнивать качество на движущихся сценах. При обычном просмотре на моих битрейтах оба кодека ведут себя прилично.
> А то что это затрагивает стопкадры -
> видео все-таки не для публикации фотографий и скриншотов.
Конкретно для меня это важно. Основной материал - home video и 3d/2d анимация. Для home video мне самому иногда интересно рассмотреть детали, 3d/2d анимация будет демонстрироваться студентам в качестве примера, да и неподвижных/малоподвижных кадров там много.
> А q - квантизатор?
Неправильно написал - crf 21-24, то есть постоянное качество.
>> Да, но на средних-больших битрейтах эти блоки превращаются в детали.
> А я не фанат больших битрейтов. Зачем мне "как xvid", только еще
> сильнее грузящий проц?
Не, для xvid нужен еще в двое больший битрейт.
> Не замечал особо. А титры и тому подобный мелкий текст, где это
> хорошо заметно у VP9 так вообще традиционно четче чем в x264
> обычно получается. С вашими квантизаторами такое как вообще выглядит? Вроде это
> довольно высокий квантизатор.
Не знаю. Но при crf=21 2d/3d анимация (там часто текст анимируется) стопкадры выглядят практически идеально.
> Поэтому у меня получалось сдуть файлы с камер
> в РАЗЫ при том что я не могу найти дефекты даже
> на стопкадрах. А сотни гигз полученные в результате сдувания жирных файлов
> на глаз заметны хорошо.
Там задача другая - сохранить максимум деталей. Я бы лично хотел еще больший битрейт, так как стоп кадр все равно уступает хорошему jpeg. А далее редактирование и естественно сжатие с качеством зависящим от задачи.
> Для x264 я использую самый
> медленный пресет - если что-то перекодируется, оно наверное будет храниться долго,
> поэтому меня интересует оптимизация битрейт/качество прежде всего.
Why is placebo a waste of time?
It helps at most ~1% compared to the veryslow preset at the cost of a much higher encoding time. It's diminishing returns: veryslow helps about 3% compared to the slower preset, slower helps about 5% compared to the slow preset, and slow helps about 5-10% compared to the medium preset.
https://trac.ffmpeg.org/wiki/Encode/H.264
На placebo два часа видео (720p) будет жаться примерно двое суток, при выигрыше менее 10%. Электричество дороже обойдется, чем место на винте :)
>> Это решения ценой в 0.5$-5$, где качество звука в прямом смысле как у AC97.
> Это большинство чипов для смартов и планшетов, встроенное аудио большинства писюков/лаптопов
> и проч. Большинство людей слышат через них.
Так им все равно, что 44.1, что 48 или 96 - им качество второстепенно. В лучшем случае они будут слушать через средние затычки, а то и вовсе через динамик смарта/ноутбука.
>> Любой современный CGU (clock generation unit) без проблем справляется с этой
>> задачей, так как имеет гибкую систему делителей и множителей.
> Это некий отдельный узкоспециализированный блок. Его элементарно нет в большинстве железяк.
Как нет? ИМХО не один SoC без него не обходится (возможно называется иначе). Сейчас обычно ставят один кварц и от него тактируют все блоки.
> Дробные делители и множители для большинства железяк - экзотика.
Для SoC - норма.
> Например я
> без проблем синтезирую 48кГц или деривативы таймером в STM32 от типовых
> кварцев. А вот как 44100 или деривативы там получить - я
> хз. Не то чтобы тамошний DAC нацелен на качественное аудио т.к.
> 12 битов. Но все-таки.
Ну STM32 это все же uC и не предназначен для аудио, но даже на нем - "DAC by setting the clock to TIM_Period to 1088 (48Mhz / 1088 = 44117)". Точность не ахти, но для такого случая более чем достаточно.
> А хомякам все-равно сейчас 24/192/lossless подавай.
Не забывайте, что есть и второй стандартный ряд - 44.1/88.2/176.4.
> Маркетолоки сказали что меньше - не
> круто. И поэтому всем будет FullHD'ец :)
Говорить они могут много. А вот реально мало кто использует 96 или 192. Ибо если человеку нужно хорошее аудио - он читает и через 5-10 минут узнает, что 96-192 ничего реально не дают. Если ему все равно - то он и не знает, что такое 24/192.
>> И много их? 1% или 0.1%?
> Учитывая что онлайн продажи перевесили физические носители - годиков через 5 поговорим
> чего там 0.1% :)
HD audio доступно уже лет 15. Пять лет ничего не изменят. Люди не хотят качать альбомы в гигиабайт-два. MP3/320 и flac/16/44.1 стали фактически стандартами. Да и то flac качают только меломаны. Уверен, что и через 5 лет - MP3/320 существенно не сдаст позиций.
> Затем что нынче большинство покупок уже совершается онлайн. А сидюки как формат
> распостранения околели. Да но и dat (откуда те самые 48kHz) околел еще ранее :)
> И хомяки сейчас любят уже 24/192, lossless. Маркетологи сказали
> что это рулит. Да и продажи флешпамяти надо двигать :)
Оглянитесь вокруг: все слушают mp3 и даже не знают что такое 24/192. Я знаю четырех людей, у которых основной источник - коллекция винила, в том числе и современного (у двух из них ламповые усилители). Но не знаю никого, кто собирает 24/192.
>> Потому, что все музыка в нем.
> Продаваны уже решили что вся музыка должна быть 24/192. Ну как видео
> - менее 4K - уже не человек^W монитор/телевизор :P. Студии построятся,
> так же как производители панелей и контента. Денег всем хочется. А
> обладатели плееров вообще онлайн с своих железок не лазят и поэтому
> денег с них не получишь.
Я могу поверить, что opus приживется в online, но не как не 24/192 с их битрейтами.
>> Нет, как я уже сказал, это элементарно делает современный (5-10 лет) CGU.
> У большинства систем аудио таки не цель существования системы а всего лишь
> одна из 100500 фич и вешать каждой фиче по жирному специализированному
> блоку - накладно слишком. Такое только в спец-SoC для плееров наверное.
Нет это единый блок для всего SoC.
> Может иногда и где-то еще бывает. Но обычно есть целые делители
> и иногда PLL для умножения. При том PLL - нишевые штуки
> со своими особенностями.
Для uC - да. Для SoC PLL и CGU - неотъемлемая часть.
>> и поставит. Раньше на дорогих платах ставили отдельные два кварца и
>> переключались между ними - точность выше (кварцы с повышенной точностью) но
>> относительно сложно и дорого.
> Не знаю про какие платы речь,
Типа моих emu-1212m и emu-0204.
> но большинство планшето-смартовых чипов тактируется от
> одного кварца с какой-нибудь типовой круглой частотой.
Так и я о том же. Но на SoC куча железа и не факт, что все частоты будут кратными. Ставить отдельные кварцы не выгодно. Ставят один кварц и CGU. Он тактирует железо как угодно. Да и удобно это - так как можно легко отключать/включать блоки и произвольно менять частоты для оптимальной производительности/энергопотребления.
>> Qualcomm MSM7227A
> Хм, интересно. Надо попробовать поискать даташит, чтоли.
Если в плеер с конечной ценой 15-30$ ставят SoC с GCU, то в смарте без него никак.
> Вот не надо тут за всех расписываться.
Ok, 99.9% пользователей.
> А с jpeg - на самом деле альтернативы пытаются сделать давно но
> у них свои проблемы. Кто патентами обложен как собака блохами, у
> кого либ вменяемых нет, кто просто неоднозначный и сделан наспех, как
> webp.
С jpeg вообще все печально - уже много лет не действуют патенты и можно свободно использовать его с арифметическим кодированием, но все из-за совместимости продолжают использовать обычный jpeg.
> Производители узконишевых специализированных SoC. Которые капля в море полупроводниковой
> промышленности. В большинстве SoC ничего такого нет. Техас вон тоже думал
> что их сигнальники встроенные в omap - преимущество. А на них
> все взяли и забили.
Бывает и так.
>> Я же лично хотел бы "вечный" плеер с зарядом от нажатия клавиш
>> при использовании и весом в 20-30г.
> Подозреваю что в нажатии клавиш недостаточно энергии. Физику не обманешь: в сами
> уши улетают какие-то доли ватта,
Очень не много, в первом приближении их можно вообще не учитывать.
> Вообще, пока такие
> уровни энергии проще всего снять или с солнечной батареи или с
> пельтье, подогреваемого таки приличнее чем температура тела человека. В плеере можно
> попробовать пристроить какой-нибудь магнитный маятник, наводящий ЭДС в катушке. Накрайняк
> если тряски от ходьбы не хватит, потряс специально - подзарядил.
Возможно, это будет и лучше. Или комбинация источников. Но в любом случае нужно работать над потреблением устройства.
>> Пока при таком весе и 20-30 часов не каждый плеер осилит.
> Хм, получается что смарт почти столько же играет - за счет более
> жирной батарейки.
Да. Учитывая сколько может работать обычная звонилка, эффективность смарта и в режиме ожидания/разговора также не велика.
>> Нет ;)
> Я про ваш смарт ;)
Ну тогда - да ;) Но даже на нем есть разница в 5-10%.
