Клуб пользователей iBasso

[ignat-ignatik]

Допишу мысть полнее, раз сунул первые пять копеек. Читал форум по "Безтопливным", мангитным, "вечным" двигателям и генераторам. Тема по специфичнее нашей будет, но ветка более менее продуктивно шла. Всё таки тема колоссальная и люди старались быть собраннее и никто не язвил. Один ученый объяснил что такой двигатель легче сделать не основываясь только на одной какой то специфической энергии силы природы, закона физики, например только магнитной, как многие пытаются делать. Хотя и такие чисто магнитные есть. Удобно делать двигатель совмещая силы природы. Например магнитную, силу энерции, гравитации, механики и т.д. Считаю что в общении также должно быть, совмещать мнение нескольких разных людей думающих в разных неправлениях, в одну интересную идею. Тогда эволюция быстрее пойдёт. Уверен что команда собрав такой двигатель, не раз вздохнёт с облегчением, вспомнив, что в дискуссии не растратили силы на склоки и довели таки дело до ума.

[Vlad168]

"Более слабым" стоит тоже быть поскромнее и не обставлять свои домыслы как квалифициронное экспертное мнение. За язык ведь никто не тянет.

Да здесь, вообще-то форум.
И каждый, извините, высказывает свое мнение - правильное оно или ошибочное - здесь начальников нет !
Если вы не согласны с мнением оппонента - выскажите свое мнение - но вы этого почему-то не делаете.
Я вообще много интересного узнал на форуме от различных людей.

[Lurker]

Да, как бы это не столь существенно, это не экзамен на знание предмета, а форум, где каждый высказывает свое личное вИдение проблемы.

Видите ли, существенны причинно-следственные связи. Зная причины, можно попытаться на них направленно повлиять. Не зная причины, или "зная" неверную причину, повлиять на результат можно лишь случайным образом.

Конкретно в этом примере, исходя из неправильного ответа, сделать ничего нельзя: алгоритм в программе не изменить, процессор не заменить. Исходя из моего ответа, можно заменить аккумулятор Pisen на Samsung, и/или сделать мод по питанию, и получить качественный прирост, в котором разница на слух между wav и flac уменьшится или пропадет. Надеюсь, в таком объяснении понятна принципиальная разница между ответами?

[SergeRX]

Да здесь, вообще-то форум.
И каждый, извините, высказывает свое мнение - правильное оно или ошибочное - здесь начальников нет !

Моя реплика предназначалась ignat-ignatik, который написал

По настоящему великий не тот кто может опустить ближнего или более великого вниз, а тот кто более слабого смог поднять до свого уровня.

В общем я указал на причину некоторого раздражения, которое ignat-ignatik уловил в отдельных постах.

Если вы не согласны с мнением оппонента - выскажите свое мнение - но вы этого почему-то не делаете.

Высказываю в том числе и в том посте. Если вам не нравится, что конкретно по вашему вопросу не отписался (flac vs wav), так вы сами сказали - тут демократия.

[krasil]

Скажите пожалуйста, а процессор живет своей жизнью и сам решает, что и как ему делать? И в догонку: как вы себе представляете алгоритмически игнорирование этих самых участков?

FLAC является потоковым форматом, что достигается разбиением данных на множество блоков, которые могут иметь разный размер, хотя имеющиеся кодеки используют блоки только постоянного размера. Так как каждый блок кодируется отдельно, то изменяя размер блока при кодировании можно добиться различной длины выходного файла т.к. чем меньше размер блока тем их соответственно больше и увеличивается количество служебной информации. Размер блока определяется от 16 до 65535 семплов, что покрывает оптимальные размеры для всех возможных аудиоданных (музыка, речь). При этом каждый блок полностью не зависим от предыдущего.

---------- Добавлено в 16:16 ---------- Предыдущее сообщение было размещено в 16:15 ----------

http://www.tux.in.ua/articles/459
цитата отсюда, форум глючит, не могу писать посты, поделю пост на несколько

---------- Добавлено в 16:19 ---------- Предыдущее сообщение было размещено в 16:16 ----------

предполагаю, что при нехватке процессорного времени, семплы или целые блоки игнорируются, что на слух воспринимается как ухудшение качества.
Именно так происходит при просмотре видео на слабом процессоре (снижается частота кадров). Это все видели и знают.

[Lurker]

http://www.tux.in.ua/articles/459
цитата отсюда

Этот "первоисточник" трудно воспринимать всерьез, т.к. он откуда-то передран, причем передран бездумно. Например, по смыслу должны быть ссылки на другие страницы, а ссылок нет. К подобным источникам информации надо относиться осторожно.

На самом деле, единственный правильный источник информации о flac - это сайт разработчиков.

предполагаю, что при нехватке процессорного времени, семплы или целые блоки игнорируются

Такое предположить может только человек, абсолютно незнакомый с программированием. Поверьте - Ваше предположение абсолютно безосновательно. Ну а если не верите - почитайте, пожалуйста, API (в идеале - исходные тексты) декодера flac и убедитесь, что там такого нет. Я - читал.

К сожалению, Ваш первичный пост на эту тему не содержал и намека на то, что Вы не уверены в том, что говорите... А теперь вот получается - это просто предположение, ни на чем конкретном не основанное... не хорошо как-то...

---------- Добавлено в 18:32 ---------- Предыдущее сообщение было размещено в 18:27 ----------

Именно так происходит при просмотре видео на слабом процессоре (снижается частота кадров). Это все видели и знают.

Если Вам интересно, я мог бы объяснить принципиальную разницу между этим Вашим примером и плеером DX50. Объяснить?

[gemzza]

Вот то же хотел спросить про API флака и про исходные алгоритмы кодирования/декодирования. Но меня опередили . В следующий раз, когда будете предполагать, сообщайте об этом остальным, дабы не выглядеть глупо.

[SergeRX]

предполагаю, что при нехватке процессорного времени, семплы или целые блоки игнорируются, что на слух воспринимается как ухудшение качества.

Во, другое дело! К такой формулировке никто не придирется

Такое предположить может только человек, абсолютно незнакомый с программированием.

Да ладно, что уж такого невероятного в предположении?
Кодек кстати необязательно стандартный должен быть, может быть и проприетарный. Хотя вы наверно наверно этот момент прояснили для себя когда прошивку моддили.

[Lurker]

Да ладно, что уж такого невероятного в предположении?

Начнем с простого: первично речь шла о разнице в звучании между wav и flac, и krasil говорил о снижении качества, тогда как отбрасывание блока потока flac приведет к выпадению звука. Потому что flac - беспотерьный формат. С ним нельзя получить на выходе "хуже", можно либо "так же, как оригинал" или "никак".

Теперь посложнее, в общем виде.

Спойлер: 

Современные приложения, воспроизводящие всякую мультимедию, обычно состоят из "оболочки" и набора "фильтров". Оболочка взаимодействует с пользователем и выстраивает фильтры в цепочки для декодирования аудио-видеоинформации. Mango устроен именно так. Так вот, роль фильтра в такой архитектуре - точно выполнить свою часть работы. Если это декодер flac - честно декодировать поданный на вход блок.

Если приложение рассчитано на потоковое вещание (т.е. когда аудиовидеоданные приходят непрерывно в реальном времени), есть необходимость принимать решение об отбрасывании очередного блока. Когда приложение рассчитано на работу с локальными файлами - такой нужны нет. Но в любом случае - такое решение может принимать только оболочка, но не фильтр! А krasil говорил о поведении декодера flac.

Далее, Mango работает не только с "потоковыми" форматами, поэтому потенциальная "потоковость" flac не должна приниматься в рассмотрение, т.к. оболочка должна вести себя одинаково для любых форматов. Mango вообще не предназначено для работы с потоками в реальном времени: плеер читает локальный файл по мере необходимости, т.е. после обработки очередной порции. Никто в спину не дышит и не толкает.

Конкретно по примеру от krasil: если взять любой видеоплеер, который умеет работать с потоковым видео, и завести ему потоковое видео - он будет выбрасывать фреймы при невозможности декодировать в реальном времени. Но если тот же плеер умеет работать с файлами, и ему подать файл с предзаписанным потоком (.ts какой-нибудь) - он будет тормозить, виснуть, но пытаться воспроизвести всё, что читается. Потому что "знает", что в спину никто не толкает.

PS Кто будет ставить эксперимент - не забудьте отключить синхронизацию по видеокарте, иначе это и будет "вспинутолкатель".

[vladbrich]

Подскажите, что нужно сделать, чтобы использовать полтинник в качестве внешней звуковой карты на ноутбуке под Windows 7 x64, на последней прошивке Дока. И работает ли вообще эта функция ?

[SergeRX]

Начнем с простого: первично речь шла о разнице в звучании между wav и flac, и krasil говорил о снижении качества, тогда как отбрасывание блока потока flac приведет к выпадению звука. Потому что flac - беспотерьный формат. С ним нельзя получить на выходе "хуже", можно либо "так же, как оригинал" или "никак".

Чисто флейма ради. Выпадение достаточно короткого куска аудиоданных из-за инерции восприятия может вообще на слух сознанием не восприниматься. Хотя возможно при этом общий характер звучания как-то и меняется (не говорю что это так и есть, но допустить можно).

Если приложение рассчитано на потоковое вещание (т.е. когда аудиовидеоданные приходят непрерывно в реальном времени), есть необходимость принимать решение об отбрасывании очередного блока. Когда приложение рассчитано на работу с локальными файлами - такой нужны нет.

Только в том случае если предварительно все данные распаковываются в отдельный буфер и только потом проигрываются.

Но в любом случае - такое решение может принимать только оболочка, но не фильтр!

Согласен.

А krasil говорил о поведении декодера flac.

Он не заострял на этом внимание, просто выдал общую идею. Что если система не справляется происходит некая "оптимизация". Практика правда говорит об обратном, например всякие DSD честно начинают тормозить когда проц не справляется. Но стопроцентной гарантии все же нет.

Mango вообще не предназначено для работы с потоками в реальном времени: плеер читает локальный файл по мере необходимости, т.е. после обработки очередной порции. Никто в спину не дышит и не толкает.

Как то тайминги он все же должен обеспечивать.

Конкретно по примеру от krasil: если взять любой видеоплеер, который умеет работать с потоковым видео, и завести ему потоковое видео - он будет выбрасывать фреймы при невозможности декодировать в реальном времени. Но если тот же плеер умеет работать с файлами, и ему подать файл с предзаписанным потоком (.ts какой-нибудь) - он будет тормозить, виснуть, но пытаться воспроизвести всё, что читается. Потому что "знает", что в спину никто не толкает.

Согласен, с точки зрения логики так намного правильнее, но опять конкретный разработчик конкретного софта по конкретный плеер вполне может решить сделать все по-своему.

[gemzza]

Во, другое дело! К такой формулировке никто не придирется

Раз уж вы такой специалист, скажите пожалуйста, что произойдет при отбрасывании блока в процессе декодирования флака?

Да ладно, что уж такого невероятного в предположении?
Кодек кстати необязательно стандартный должен быть, может быть и проприетарный. Хотя вы наверно наверно этот момент прояснили для себя когда прошивку моддили.

Можете привести пример такого кодека, который бы не использовал библиотеку libFlac, а был бы полностью самописным? А самое главное рассказать, в чем смысл сей задумки?

---------- Добавлено в 21:04 ---------- Предыдущее сообщение было размещено в 21:02 ----------

Раз уж вы такой специалист, скажите пожалуйста, что произойдет при отбрасывании блока в процессе декодирования флака?

Выпадение достаточно короткого куска аудиоданных из-за инерции восприятия может вообще на слух сознанием не восприниматься. Хотя возможно при этом общий характер звучания как-то и меняется (не говорю что это так и есть, но допустить можно).

На этот вопрос можете не отвечать, мне все ясно

[Lurker]

SergeRX, Вы в своем флейме аккуратно пропустили мысль о том, что далеко не все поддерживаемые Mango форматы - потоковые Собсно, потоковых там ровно 0 (ноль), т.к. потенциально потоковые MP3 и flac в потоковом виде имеют совсем иное оформление и ограничения, не соблюдаемые в файловом формате. И я не буду продолжать, ОК?

---------- Добавлено в 20:13 ---------- Предыдущее сообщение было размещено в 20:09 ----------

Можете привести пример такого кодека, который бы не использовал библиотеку libFlac, а был бы полностью самописным?

Вот тут я Вас удивлю: ffmpeg.

Сложно со мной иметь дело, я знаю...

[SergeRX]

Мои знания на тему флака дальше википедии не распространяются, так что допускаю что глупости какие-то пишу.

У меня ощущение, что вы в теме. Если так, то не томите откройте правду. Блоки как то сцеплены или что там?

Можете привести пример такого кодека, который бы не использовал библиотеку libFlac, а был бы полностью самописным? А самое главное рассказать, в чем смысл сей задумки?

Не могу и пытаться искать не буду, но гипотетически может же существовать, стандарт ведь открытый?

В общем если разбираетесь лучше просветите народ, чем троллить.

[gemzza]

Вот тут я Вас удивлю: ffmpeg.

Мельком взглянув на исходники рискну предположить, что там то же все ок ffmpeg - целое кроссплатформенное решение. Скорее всего "самописный флак" делался там только лишь для того, чтоб вписаться в общую концепцию кода ( ну или возможно у программистов руки чесались ). А еще примеры есть?

[SergeRX]

Mango форматы - потоковые Собсно, потоковых там ровно 0 (ноль), т.к. потенциально потоковые MP3 и flac в потоковом виде имеют совсем иное оформление и ограничения, не соблюдаемые в файловом формате. И я не буду продолжать, ОК?

Можно.
Ответьте на такой вопрос. Что технически мешает обработать файловый формат как потоковый?

[Lurker]

Что технически мешает обработать с файловый формат как потоковый?

Работать с потоковым сильно сложнее - лишние, никому не нужные заморочки типа синхронизации на начало фрейма с пропуском мусора, разные параметры (частота дискретизации, битность, даже кодер!) у разных фреймов... У файла считал заголовок, настроил фильтр по параметрам из заголовка - и струячь туда блоки. Собсно, с звуковым файлом, фактически, не нужно и временной синхронизации. Типичный цикл воспроизведения аудиофайла таков:

1. Настроить аудиодрайвер на битность, число каналов, частоту дискретизации.
2. Записать туда очередной декодированный блок, сколько влезло. Что не влезло - оставили на потом.
3. Продолжать 2, пока не закончилось.

Это аудиодрайвер не берет больше, чем он может прокачать с заданными параметрами. Ручная синхронизация нужна только при аудио-видео, когда входной поток демультиплексируется, и его синхронно надо гнать в два устройства - аудио и видео.

Вот список операционных систем, для которых я писал вывод звука:

Спойлер: 

Windows мобильные и десктопные, OS/2, Linux (alsa, pusleaudio), QNX, Android (двумя методами), iOS (нативный и OpenAL), Samsung bada.

[SergeRX]

ОК. Убедили.
Резюме.
Разработчики стремятся все собирать из стандартных компонент на базе стандартной программной архитектуры. Чтобы реализовать тот вариант, который предположил krasil надо все поломать и сделать свое если не с нуля то близко к этому. В результате цена вопроса возрастет на несколько порядков. Ради такой сомнительной фичи никто заморачиваться не будет.

[Vlad168]

Ну, что ж, есть еще один интересный вопрос, на который пока никто не дал внятного объяснения, хотя вопрос этот поднимался в ветке.

Как всем известно, у полтинника есть переключатель уровня громкости (gain) телефонного выхода.
Изменение уровня громкости (по схеме) достигается различными гасящими сопротивлениями от каскада ЦАП к усилительному каскаду: на low - максимальное гасящее сопротивление, на high - таковое отсутствует, mid - соответственно среднее значение гасящего сопротивления.

И при переключении этого переключателя изменяется АЧХ выходного сигнала с телефонного выхода независимо от сопротивления наушников - на low середина провалена, на high - середина выправляется.
Причем это заметил не я один.

Кто-то сможет дать внятное объяснение этому замечательному явлению ?

[krasil]

gemzza, Скажите , Вы не могли бы сделать Рокбокс для DX50 со сменой напряжений, как на Сансе?