Album Player (APlayer)

[Shadovv]

Album Player 2.3 (APlayer) предназначен для составления и прослушивания сборников музыкальных альбомов на жестком диске или на CD/DVD. Плеер воспроизводит основные типы аудиофайлов, для которых существуют plug-in модули в формате программы Winamp (MP3, APE, FLAC, Audio-CD и т.д.). При формировании плейлистов для образов дисков используется информация из .cue файлов.

В программе реализован поддерживаемый некоторыми плагинами режим прямого вывода звукового потока из декодера звукового формата в выходное устройство. Отсутствие промежуточной обработки и микширования обеспечивает наиболее точное воспроизведение звука.

Кто-нибудь использовал этот плеер? Автор утверждает, что данный плеер звучит лучше чем foobar.
Плеер можно взять на официальном сайте: http://vv.uka.ru/aplayer.html

[E.Sokol]

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

[aganext]

E.Sokol,

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

[E.Sokol]

К вопросу о влиянии на звук.
Мне с определенной периодичностью на e-mail приходят письма от пользователей плеера.
Вот, например, 28 марта этого года, написал Александр:

Когда слушал музыку через foobar2000, звучание было далеко от идеала, настолько, что решился на продажу цапа M2Tech Young DSD, но один знакомый порекомендовал попробовать Album player. Я был поражен изменениям, сразу появилось все - трехмерность сцены, детальность(но не резкость), выслкие частоты стали особено прозрачны. Ваш плейер просто вдохнул жизнь в звучание системы.

Не в обиду, но суть письма говорит о том же - в плохом звуке не виноват плохой ЦАП, плохие АС, плохой усилитель, плохая КДП - виноват плохой плеер. Кто не может себе позволить поменять ничего, кроме плеера - меняет плеер и пытается себя убедить, что в нём-то и была проблема.

[LepekhinV]

Вдвоём с товарищем слушали и сравнивали в моей системе Фубар и А-плейер. Слушали на 2-х ЦАПах. Различия есть. Явные. Оба сошлись на том, что А-плейер звучит лучше. Мне всё равно с чем это связано. Слушаю плейер автора темы. Спасибо ему за продукт.
P.S. Система следующая - усилитель Л.Зуева, АС - Серената А.Коваленко ( TL на Пирлесс+купол+Морель на ВЧ). ЦАПы - на PCM63 (от Сергея из Гомеля) с выхлопом Гагарин на LH, второй - на 1955 от Виктора Корсакова. Оба ЦАПа с Чарльстоном на входе.
P.P.S. С компами "на вы", поэтому оба плейера устанавливал и настраивал Алексей energetik .

[_Summit_]

Сами эти помехи действуют синхронно с функционированием ЦАПа и могут влиять, в том числе, на стабильность фронтов тактовых сигналов, поступающих в микросхему ЦАПа.

От куда синхронность?

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

Я так понимаю имелось ввиду декодера?

может быть связана с корреляцией, синфазностью их активности с обработкой звукового потока в аппаратной части

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

Можно предположить влияние от конкретной реализации шины USB и ее режима работы, но никак от высокоуровнего приложения.

Вдвоём с товарищем слушали и сравнивали в моей системе Фубар и А-плейер. Слушали на 2-х ЦАПах. Различия есть.

А от метода открытия файла различия есть? Перетаскиванием мышкой или через меню "опен" на клавиатуре? Еще грят, когда мышью на компе работаешь шумов больше. Я как то давно на старых компах такое слышал. Мышкой водишь, а в колонках "ш-шшшш".

[LepekhinV]

Мышь у меня беспроводная (клавиатура тоже), не шуршит ничего. Комп брал специально под музыку безвентиляторный. Глюков нет. ОС - Вин10.

[onv23]

Если данные переданы в буфер ЦАПа и они совпадают с тем что оправлено, то о какой битовой точности мы говорим?

А кто сказал, что до буфера ЦАПа по линии 480МГц без возможности перепосылки битого доезжает то, что отправлялось ?

[Igor_A]

Сами эти помехи действуют синхронно с функционированием ЦАПа и могут влиять, в том числе, на стабильность фронтов тактовых сигналов, поступающих в микросхему ЦАПа.

От куда синхронность?

Синхронность в том смысле что код плеера выполняется в то же время, когда на ЦАП поступает тактирующая последовательность импульсов.
А некоторая фазовая согласованность программных и аппаратных операций может быть связана с тем, что действия плеера по очередной передаче данных в драйвер синхронизированы через обратный вызов из драйвера с исчерпанием (обычно на половину) аппаратных буферов.
Если Вы придумаете теорию лучше для объяснения программного влияния с сохранением bit-perfect точности передачи - пожалуйста, предлагайте.
Я, повторюсь, и сам не уверен на 100%, что программно индуцированный джиттер - это главное объяснение. Но пока оно самое естественное.

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

Я так понимаю имелось ввиду декодера?

Нагрузку в основном создает декодер, но некоторые плееры занимаются и визуализацией воспроизводимых данных, да и сам трансфер данных может создавать некоторую нагрузку, если при этом, например, float пересчитывается в integer, как в плеерах со стандартным внутренним float представлением данных.

[_Summit_]

А кто сказал, что до буфера ЦАПа по линии 480МГц без возможности перепосылки битого доезжает то, что отправлялось ?

А что, разве не так? А если даже не так, явно не плеер осуществляет флоу контроль USB.

Синхронность в том смысле что код плеера выполняется в то же время, когда на ЦАП поступает тактирующая последовательность импульсов.

Код плеера выполняется раньше, чем выборка данных из буфера. Причем это совершенно разные операции. У плеера и транспорта немного разные задачи.

Если Вы придумаете теорию лучше для объяснения программного влияния с сохранением bit-perfect точности передачи - пожалуйста, предлагайте.

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

Я, повторюсь, и сам не уверен на 100%, что программно индуцированный джиттер - это главное объяснение. Но пока оно самое естественное.

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

Нагрузку в основном создает декодер, но некоторые плееры занимаются и визуализацией воспроизводимых данных, да и сам трансфер данных может создавать некоторую нагрузку, если при этом, например, float пересчитывается в integer, как в плеерах со стандартным внутренним float представлением данных.

Понятно. Я тоже считаю, что лишние операции не к чему. Но их влияние в современных комп. системах сложно адекватно оценить. Слишком уж они ничтожные на фоне всего остального. Той же самой отрисовки пользовательского граф. интфса в 32 битном цвете в режиме 4К.

[EDDiE]

По поводу разности звучания: автор Wave Pcm Upconvert Player http://wpup.html.xdomain.jp/ в своей предыдущей версии 1.2.1.0 перестарался с высокими частотами
В последующей версии он это исправил...
так что даже один и тот же плэйер разных версий может звучать по-разному.

[Igor_A]

Код плеера выполняется раньше, чем выборка данных из буфера.

Выборка данных из последнего аппаратного буфера выполняется равномерно в процессе всего воспроизведения. Естественно, код плеера работает в то же время.

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

В статье, на которую я выше дал ссылку, под Software-induced jitter понимается именно то, о чём пишу выше я - влияние помех и наводок, создаваемых динамической программной нагрузкой на процессор, на фронты тактовых импульсов.

P.S.
На мой взгляд, мы высказались достаточно полно и дальше разговор пойдет по кругу. Можно его закончить.
Для меня программное влияние на звук - несомненная данность, с которой я сталкивался много лет (и в слепом тесте, кстати, тоже проверял).
Кто-то на это никогда не обращал внимания. Не удивительно, что нам друг друга не понять. Первична практика, а не теории.

[_Summit_]

По поводу разности звучания: автор Wave Pcm Upconvert Player http://wpup.html.xdomain.jp/ в своей предыдущей версии 1.2.1.0 перестарался с высокими частотами
В последующей версии он это исправил...
так что даже один и тот же плэйер разных версий может звучать по-разному.

Ну да. Есть даже редакторы звука. Там специально вносятся изменения в данные, что бы получить на выходе что-то другое. А тут не вносятся, а выход разный. Чудеса...

В статье, на которую я выше дал ссылку, под Software-induced jitter понимается именно то, о чём пишу выше я - влияние помех и наводок, создаваемых динамической программной нагрузкой на процессор, на фронты тактовых импульсов.

Я понял. Что речь идет о неком исполняемом коде, который меньше генерирует ЭМ помех, которые передаются от компа в аналоговую часть.

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

Пож.

Для меня программное влияние на звук - несомненная данность, с которой я сталкивался много лет (и в слепом тесте, кстати, тоже проверял).

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

Кто-то на это никогда не обращал внимания. Не удивительно, что нам друг друга не понять. Первична практика, а не теории.

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

[onv23]

А что, разве не так?

Изохронный режим.
Isochronous Transfers: time sensitive information, such as an audio or video stream

• Guaranteed access to USB bandwidth.
• Bounded latency.
• Stream Pipe - Unidirectional
• Error detection via CRC, but no retry or guarantee of delivery.
• Full & high speed modes only

[E.Sokol]

А кто сказал, что до буфера ЦАПа по линии 480МГц без возможности перепосылки битого доезжает то, что отправлялось ?

Если это PCM (а не DSD) поток, то битые пиксели семплы на слух будут звучать как щелчки и никак иначе.

---------- Сообщение добавлено 09:09 ---------- Предыдущее сообщение было 08:30 ----------

Для меня программное влияние на звук - несомненная данность, с которой я сталкивался много лет (и в слепом тесте, кстати, тоже проверял).

Вероятность угадать один из двух вариантов в слепом тесте - 50/50%. Достаточно большая вероятность для того, чтобы сделать правильный выбор с первого раза.

[Igor_A]

Вероятность угадать один из двух вариантов в слепом тесте - 50/50%. Достаточно большая вероятность для того, чтобы сделать правильный выбор с первого раза.

Я два раза по семь раз подряд правильно различал две разных версии модуля вывода ASIO. Воспроизводился звук под управлением тщательно перетасованных на рабочем столе двух идентичных окон плеера. Версия модуля проверялась после принятия решения о его версии, через вызов инфопанели.

[E.Sokol]

Я два раза по семь раз подряд правильно различал две разных версии модуля вывода ASIO. Воспроизводился звук под управлением тщательно перетасованных на рабочем столе двух идентичных окон плеера.

Без обид, но "тщательно перетасованных" - это вообще несерьёзно. Карточные шулеры работают точно по такому же принципу. Но спорить больше не буду - каждый имеет право верить в то, во что хочет.

[белый человек]

Тоже буду продолжать объяснять для себя разницу в звучании софт-вывода разной степенью нагрузки и свистом в аналоговую часть. Так проще жить. Хотя при современном потенциала железа - это несколько смешно.

[Igor_A]

E.Sokol
Видимо, каждый дискутирует на том уровне, на который способен.

---------- Сообщение добавлено 10:54 ---------- Предыдущее сообщение было 10:22 ----------

Первична практика, а не теории.

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

Хорошо, я поясню подробнее. Есть наблюдаемый факт - разные плееры со слышимыми отличиями воспроизводят музыку. Есть первое рациональное объяснение, из которого разумно исходить всем - эти плееры как-то обрабатывают код звукового потока. Но дальнейшие исследования с перехватом этого потока между плеером и драйвером показывают, что данные выдаются одни и те же. Как в этой ситуации может влиять плеер? - Только косвенно. Как исключить такое влияние? Есть универсальный ответ, вне зависимости от деталей механизма косвенного влияния - вообще не влияет ни на что тот, кто не делает вообще ничего. И, соответственно, есть универсальный принцип реализации оптимизированного плеера - не делать по возможности ничего насколько это вообще возможно при условии, что звук будет вообще звучать. То есть, минимизация конвейера, минимизация числа операций с данными. По этому принципу реализован APlayer. Безотносительно к деталям реального теоретического объяснения механизмов этого влияния этот практический принцип работает. Предположим, например, на секунду, что главный источник косвенного влияния плееров - не джиттер, индуцированный наводками на цепи оконечного тактового генератора, а влияние этих помех непосредственно на сигнальный аудио процессор мозга. В обоих случаях решение по минимизации программной активности, сопровождающей воспроизведение - это универсальное решение.

[E.Sokol]

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

Вот только помимо плеера, в операционной системе работает ещё порядка 1000 потоков, между которыми процессор постоянно переключается. Чем нагрузка плеера на процессор и память принципиально отличается от всех остальных задач?

---------- Сообщение добавлено 14:29 ---------- Предыдущее сообщение было 14:17 ----------

Есть наблюдаемый факт - разные плееры со слышимыми отличиями воспроизводят музыку. Есть первое рациональное объяснение, из которого разумно исходить всем - эти плееры как-то обрабатывают код звукового потока.

Наиболее рациональное объяснение - что слышимые отличия это лишь иллюзия, вызванное разным дизайном разных плееров.

[Igor_A]

Вот только помимо плеера, в операционной системе работает ещё порядка 1000 потоков, между которыми процессор постоянно переключается. Чем нагрузка плеера на процессор и память принципиально отличается от всех остальных задач?

У меня на Server 2008 R2 по данным ProcessExplorer активны 5 процессов, в каждом по несколько потоков. Каждый из этих процессов потребляет менее 0.1% ресурсов процессора. Остальные процессы и потоки находятся в состоянии ожидания системных событий и не потребляют ресурсов процессора.
Я уже выше упоминал, что на 3D realtime диаграмме спектра в SpectraLab вклад плееров в спектр помех был хорошо заметен.