IgorA

@xeon.ix, спасибо за проделанную работу. Но если бы Вы заглядывали в сам плеер, то обратили бы внимание, что плагины использующие модули библиотеки BASS, обозначены соответствующим образом непосредственно в списке плагинов. И что с плагином out_ds.dll авторства Peter Pawlowski в плеере совпадает только имя плагина, так как он с нуля написан для плеера. Авторы Maxim V.Anisiutkin, Otachan, David Hammerton, Matthew T. Ashland, Josh Coalson, Steve Monks, Alpha-II Productions указаны в инфопанелях соответствующих модулей. Также указан Gildas Bazin в панели "О декодере" DTS плагина и использованная библиотека LibAiff 5.0 в соответствующей панели AIFF плагина. DLL файл библиотеки TAK Томаса Бекера использован без модификации и содержит информацию об авторе. Но суть даже не в этом, а в том, что плеер изначально не претендует на какую-либо оригинальность в декодировании различных форматов файлов и изначально подразумевает использование для этих целей готовых библиотек других разработчиков, полным списком которых, действительно, следует дополнить сопроводительные материалы. Специфика этого плеера в организации вывода декодированного звука (модулях вывода) и его настройках, которые, действительно, имеют авторскую реализацию. Пытались ли Вы об этом задуматься и способны ли Вы это понять?

@Evgen1, насчет вопросов "почему" у меня нет ответа даже на простой вопрос с предыдущей страницы - почему и как влияние плееров просачивается даже через асинхронный USB в ЦАПы с собственным питанием. Свое гипотетическое предположение я выше сегодня высказал - что конкретный "узор", паттерн цифровых шумов порождает как реакцию свой паттерн акустических резонансов в нашем восприятии, который и создает для нас тот или иной характер звука. И если причина такова, то аспект неконтролируемых и непредсказуемых блужданий звука в разных условиях воспроизведения может играть существенную роль. Собственно, с учетом этого я и постарался реализовать максимального размера многомерную матрицу возможных вариантов в настройках плеера.

@Evgen1, И я ведь именно по Вашей, а не своей инициативе развернуто ответил на вопрос, где минимализм, а где - Direct Input. Что вовсе не препятствует Direct Input замечательно играть. Теперь похоже, что я в этом почему-то виноват. Отсутствие файловых операций при работе Full Memory легко проверяется и программами мониторинга, такими как ProcessExplorer.

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

@Evgen1, разве истина не дороже? При старте плеер ничего не записывает на свой диск, а извлечение флешки в произвольный момент опасно только при незавершенной записи.

А Вы попробуйте запустить плеер на воспроизведение с флешки и вынуть ее после старта.

Хорошо, пусть меняется, но насчет размещения воспроизводимых аудиоданных в ОЗУ я выше все пояснил.

В процессе воспроизведения обращений к этой папке не происходит.

Они изначально в том ОЗУ, длинный путь из которого до драйвера я описал выше. А плеер грузит их в то ОЗУ, из которого готовый результат в процессе воспроизведения одним коротким движением отдается драйверу.

Так плеер в ОЗУ вообще всегда, даже когда играет стандартный режим с жесткого диска.

@Evgen1, когда работает Full Memory в ASIO EXTRAS x64 из всего кода плеера периодически выполняется лишь несколько машинных команд, содержание которых сводится к пересылке очередного блока семплов из буфера в памяти в буфер драйвера. Плюс сопутствующая модификация текущих адресов и проверка достижения конца. Это теоретически достижимый предел минимализма. Плеер фактически вынесен за рамки происходящего. Работает по сути только драйвер ASIO. В режиме Direct Input, даже при использовании рамдиска, в воспроизведении еще участвует процесс approxy64.exe, который получает запросы на порции данных от ap2decoder.exe, и передает эти запросы загруженному входному плагину воспроизводимого формата, например, in_flac.dll. Этот плагин вызывает функцию чтения данных из файла, при выполнении которой происходит обращение к драйверу диска и считывание блока данных с диска. Полученные данные декодируются декодером формата и возвращаются через approxy64.exe в ap2decoder.exe. Там, если их разрядность отличается от требуемой драйвером ASIO (чаще всего 32 бита), происходит конвертация разрядности этих данных, и только после этого они попадают в тот буфер драйвера, к пересылке в который из оперативной памяти сводится вся работа Full Memory. Чувствуете разницу?

@8street, стандартный режим по мере увеличения буфера предзагрузки приближается по режиму работы к Full Memory, так как и там, и там, короткие по длительности подкачки данных с диска чередуются с длительным воспроизведением из буфера к памяти. Слабые переходные щелчки в старой архитектуре SACD плагина фактически непобедимы, в том, числе и при PCM выводе. Однако вернуться к старому режиму работы Full Memory с SACD очень просто - достаточно скопировать файл in_sacd.dll из папки 32-разрядной версии плеера в папку 64-разрядной версии. Эти два варианта отличает только интерпретация SACD диска как непрерывного или потрекового.

@BSV, с причинами влияния разных вариаций кода, модулей, режимов на звук пока особой ясности нет. Для получения субъективно предпочитаемого звука, похоже, и минимализм процессинга не панацея. У меня такое ощущение, что здесь влияет возникновение каких-то резонансов в сигнальном процессоре мозга с распределением тех микро-модуляций, которые привносятся в цифровой поток. Иначе трудно объяснить такую сверхчувствительность восприятия к вариациям условий воспроизведения, отличия в которых обычными приборами не измерить. Кстати, Realtek недавно сделал нативный ASIO драйвер. Вроде, хвалят: https://yadi.sk/d/24JGYMFwyTkbk

Требуется, похоже, помощь в подсчете плагинов и их авторов? Пожалуйста: В плеере используется 20 входных плагинов: AC3, AIFF ALAC, APE, CDA, DTS, DVD-A, FFmpeg, FLAC, MP3, MP4, MPC, OGG, OPUS, RAD, SACD, TAK, WAV, WMA, WV. 15 из них написаны автором плеера: AC3, AIFF ALAC, CDA, DTS, FFmpeg, MP3, MP4, MPC, OGG, OPUS, RAD, TAK, WAV, WMA. 3 представляют собой модифицированные декодеры независимых разработчиков, с указанием авторства в панели "О декоде" : FLAC (Josh Coalson), APE (Matthew T. Ashland), WV (Conifer Software). 2 являются плагинами, основанными на коде Максима Анисюткина, использованном по согласованию с автором и с указанием его имени в панели "О декодере": SACD и DVD-A. : В плеере используется пять альтернативных модулей вывода: Стандартный, EXTRAS ASIO, EXTRAS WASAPI, EXTRAS KS, EXTRAS WAVEOUT. Они написаны автором плеера. EXTRAS модули выводят звук самостоятельно. Стандартный модуль вывода использует четыре выходных плагина, из которых один написан автором плеера (DirectSound), а три остальных представляют собой модифицированные плагины независимых разработчиков с указанием авторов в панели "О модуле": ASIO (Otachan), KS (Steve Monks), Alpha-II WaveOut (Alpha-II Productions).

Я понимаю. Да и те же аудиокниги... Но пока так.

@AleXH, для радио ведь это работать не будет, какой смысл тогда . Если серьезно - мне это просто не интересно.

@8street, поскольку слушать в этом случае придется параллельно с загрузкой, у плеера есть два режима воспроизведения, которые уже сейчас решают эту задачу (и с существенно меньшей нагрузкой на процессор) - это "Стандартный" и Direct Input. Переходных помех между треками SACD не будет и в этих режимах тоже.

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

@Инженер механик, есть еще вариант, что 176 сделан из SACD, содержит ультразвуковой шум и, возможно, медленнее распаковывается из-за этого. Тогда в качестве эксперимента на вкладке DSP можно включить ресемплинг 192->176 и посмотреть, создаст ли это проблему при воспроизведении исходника 192. Вообще, при воспроизведении в Direct Input фазовый шум, видимо, будет больше. И то, что этот вариант больше нравится, скорее говорит о том, что борьбу за минимализм можно заканчивать, раз больше процессинга по ходу - это лучше. Наверно звуки от этого немного раздуваются и становятся более весомыми.

@Инженер механик, плеер в обоих режимах - Full Memory и Direct Input, просто пересылает запрашиваемые блоки семплов драйверу, конкретную частоту дискретизации никак не учитывая. При этом 176 должна быть при прочих равных несколько более устойчивой чем 192, так как соответствующие запросы будут приходить несколько реже. Если 176 оказывается менее стабильной, значит, ей сопутствует какой-то дополнительный процессинг, возможно, в драйвере, если явно не включен ресемплер.

@MAMAY, может быть, надо снять флажок "Конвертировать 5.1 в стерео" на вкладке DSP в ap2config? Или отключить VST плагин, работающий в стереорежиме? В работе с DTS ничего не менялось и 6 каналов там выводится.

@David R. Оперативное управление воспроизведением и навигацией равноценны в обоих случаях. Общие настройки доступны в основном плеере. Скачивать "управлялки" не требуется. На стороне IOS это комплектный браузер Safari, а на стороне плеера - программа ap2web.exe из папки web.

Давид, в IOS работают браузеры и содержание раздела V рассказывает, что именно они используются как инструмент дистанционного управления плеером. Вы не обратили на это внимание или браузер в этой роли не приемлем?

Добрый день, Давид! Этому вопросу посвящен целый раздел (V) файла readme_ru.txt, который можно найти в основной папке плеера или загрузить по прямой ссылке со страницы плеера.

@BSV, что касается стабильности, то сам процесс воспроизведения новые плагины не должны в чем-то менять, поэтому отличия в стабильности работы с VST скорее связаны с настройками. Можно взять хорошо работающую, настроенную конфигурацию и прямо там поменять файлы на новые. Я думаю, что будет работать также. Что касается переходов между треками, то они будут правильно отображаться, если открывать папки с использованием новых файлов, а не воспроизводить сохраненные прежней версией плейлисты.