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

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

Снес я его. Не для средних умов вещица.
По крайнее мере, я руки сломал, настраивая сабж. Все-равно ошибки вылетают.

[_Summit_]

В плеере совмещен минимализм звукового движка (по исполняемому коду, нагрузке на ЦП, длине конвейера), который реализован как отдельный процесс

Отдельный процесс от чего?

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

Честно признаюсь, это кажется очень сомнительным. Как тут пишет народ, на тембры это влиять не может.
Видел. Это ужасно. Люди просто не понимают как работает ЭВМ.

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

Допустим, но причем тут программный код? Комп железо много чего индуцирует, уже только при том, что на него подано питание.

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

Снес я его. Не для средних умов вещица.

А мне наоборот показалось, что все хорошо работает уже из коробки. И настройки понятны.

По крайнее мере, я руки сломал, настраивая сабж. Все-равно ошибки вылетают.

Странно.

[Igor_A]

Отдельный процесс от чего?

Звуковой движок (ap2decoder.exe) - отдельный процесс от процесса декодера/DSP (approxy.exe) и процесса графического интерфейса (APlayer.exe). И он может работать, когда два последних процесса выгружены из памяти.

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

Допустим, но причем тут программный код? Комп железо много чего индуцирует, уже только при том, что на него подано питание.

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

Я предполагаю, что повышенная чувствительность к влиянию именно плееров может быть связана с тем, что их программная активность синфазна, коррелирована с обработкой звукового потока в аппаратной части.
С одним ЦАПом (XMOS USB) мне удавалось получить такие измерения при бит-перфект воспроизведении через ASIO одного и того же тестового файла.
Слева - AIMP 4, справа - аплеер:



То есть, слева такая классическая картина индуцированного джиттера.

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

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

Странно.

да не понимаю чего - то поди. зачем плееру оперировать с отличным от значения установки драйвера АСИО значением буфера? в фубаре, например, настройки АСИО вызывают настройки драйвера. Это логично. Если он уже посылает на вход плеера 32768 сэмла от файла, зачем с ними еще что-то делать? в чем профит?

[Igor_A]

белый человек
Плеер не меняет размер буфера драйвера ASIO (но его можно изменить в ASIO Control Panel, когда драйвер это поддерживает).
Но любой плеер обычно имеет собственный буфер, который больше буфера драйвера, чтобы отдать очередной блок сразу по запросу от драйвера.
Те настройки буферов, которые есть в аплеере, позволяют выбрать между регулируемой по размеру и периодичности предварительной буферизацией данных (режим вывода Standard), безбуферным для плеера декодированием прямо в буфер драйвера (режим Direct Input) и предварительным декодированием всего файла в непрерывный блок в оперативной памяти с дальнейшей передачей драйверу декодированных данных из памяти (режим Full Memory).

[_Summit_]

Звуковой движок (ap2decoder.exe) - отдельный процесс от процесса декодера/DSP (approxy.exe) и процесса графического интерфейса (APlayer.exe). И он может работать, когда два последних процесса выгружены из памяти.

Понятно.

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

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

[Igor_A]

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

Когда я экспериментировал со SpectraLab с 3D режимом визуализации спектра в реальном времени, то один из входных разъемов АЦП был плохо экранирован. И по этому каналу от каждого плеера пролезал свой рисунок помех.

---------- Сообщение добавлено 14:11 ---------- Предыдущее сообщение было 10:55 ----------

Если в буфер ЦАПа пришли одинаковые данные, то он их одинаково и воспроизведет, если ему что-то не помешает. Вот и очень хочется понять, что-же это может быть.

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

[vic57]

Дрожание фронтов тактирующей последовательности, которое может индуцироваться помехами, порождает джиттер.

Именно на этом этапе и начинается "пляска с бубном" с интерфейсами в компе и кабелями снаружи...

[_Summit_]

Но ЦАП воспроизводит не цифры из буфера, а звук.

Разочарую, но звук он тоже не воспроизводит. А выдает некий переменный во времени электрический сигнал, "переменность" которого во времени задается его внутренним тактовым генератором.

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

Никакой роли не играет, если буфер не опустошается.

Дрожание фронтов тактирующей последовательности, которое может индуцироваться помехами, порождает джиттер

Дрожание фронтов - проблемы ЦАПа.

[E.Sokol]

В плеере совмещен минимализм звукового движка (по исполняемому коду, нагрузке на ЦП, длине конвейера), который реализован как отдельный процесс

Так это же дополнительное звено обработки! Нужно же данные между процессами как-то передавать (через именованный канал или TCP), и они наверняка в процессе передачи портятся ещё больше, ну или как минимум, дополнительные шумы и наводки от этого создаются.

[_Summit_]

Так это же дополнительное звено обработки! Нужно же данные между процессами как-то передавать (через именованный канал или TCP), и они наверняка в процессе передачи портятся ещё больше, ну или как минимум, дополнительные шумы и наводки от этого создаются.

Нет. В этом плане все грамотно сделано. Процесс занимается воспроизведением и слушает канал управления. mpd так-же работает. Где запускать клиент - дело десятое. Можно, в принципе, напрямую сигналы в процесс подавать.

[Igor_A]

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

Никакой роли не играет, если буфер не опустошается.

Если наводки и помехи смещают уровень в реальности наклонного, а не идеального фронта тактового сигнала, это привносит модуляцию моментов записи данных в регистры ЦАПа уже после считывания из буфера. Это и называется джиттером.
Вот, например, статья, где есть раздел Software-induced jitter: Beyond bit-perfect.
Для меня, повторюсь, первичны не теоретические изыскания про природу этих влияний, а неоднократное на протяжении лет удивление от того, что разными плеерами музыка воспроизводится по-разному. Может быть, джиттер - не единственное или не главное объяснение. Но пока - самое естественное.

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

В плеере совмещен минимализм звукового движка (по исполняемому коду, нагрузке на ЦП, длине конвейера), который реализован как отдельный процесс

Так это же дополнительное звено обработки! Нужно же данные между процессами как-то передавать (через именованный канал или TCP), и они наверняка в процессе передачи портятся ещё больше, ну или как минимум, дополнительные шумы и наводки от этого создаются.

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

[_Summit_]

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

С этим никто не спорит. Поэтому схемотехнически разработчики ЦАПов пытаются от этих помех избавится. При чем тут плеер не совсем понятно. Он же далеко до буфера работает.

Вот, например, статья, где есть раздел Software-induced jitter: Beyond bit-perfect.

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

разными плеерами музыка воспроизводится по-разному

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

Может быть, джиттер - не единственное или не главное объяснение. Но пока - самое естественное.

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

[Igor_A]

_Summit_
Но Вы видите разницу между двумя зелеными картинками на предыдущей странице? Условия их воспроизведения отличаются только версией использованного плеера, но оба при этом выводят bit-perfect через ASIO. Реальность bit-perfect при этом доказывается тем, что DoP поток оба воспроизводят без шума. В DoP даже если один бит искажается, это приводит к слышимому шипению. Влияние джиттера на звук не требует нарушения битовой точности. Речь идет лишь о дрожании фронтов цифровых сигналов на десятки-сотни пикосекунд. С точки зрения цифровой синхронизации это ничтожнейшие возмущения, битовую точность никак не затрагивающие.

Что касается возможного механизма косвенного влияния плеера на звук - я ведь выше приводил пример, как несколько миллиметров плохо экранированного провода на входе в АЦП ловили наводки плееров, отображаемые SpectraLab. Полностью аналогично те же наводки может ловить проводник, передающий тактовый сигнал от генератора до входа ЦАПа на плате.

Если Вы никогда не слышали индивидуального влияния плеера на звук - рекомендую послушать широко известный в узких кругах японский Bug Head.
99% слушателей признают, что у него особый звук, но тест на bit-perfect он проходит.

[E.Sokol]

Вы видите разницу между двумя зелеными картинками на предыдущей странице?

1) Почему картинок только одна пара? Это ведь совершенно ни о чём не говорит, т.к. различия могут быть вызваны просто случайным сочетанием шумов.
2) Из этих картинок вовсе не следует, что оба этих плеера выдавали бит-перфект - вы просто предлагаете поверить вам на слово.
3) Чтобы эксперимент был научным, он должен быть повторяемым. Опишите подробно условия его проведения - чтобы все желающие могли его повторить и убедиться лично в корректности предоставленных вами результатов.

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

Если Вы никогда не слышали индивидуального влияния плеера на звук - рекомендую послушать широко известный в узких кругах японский Bug Head.
99% слушателей признают, что у него особый звук, но тест на bit-perfect он проходит.

Bug Head Emperor сделан на движке bass.dll, т.е. его автор программированием звука вообще не занимался - просто сделал оболочку с оригинальным дизайном.

[_Summit_]

Но Вы видите разницу между двумя зелеными картинками на предыдущей странице?

Ya!

Влияние джиттера на звук не требует нарушения битовой точности.

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

Речь идет лишь о дрожании фронтов цифровых сигналов на десятки-сотни пикосекунд.

У нас 2 цифровых потока. 1 поток внутри PC, 2 поток выборки данных из буфера транспорта в МС ЦАПа. В 1 случае с дрожанием сигнала борется (успешно) железо компа. Во втором разработчик ЦАПа. Плеер то тут где?

Что касается возможного механизма косвенного влияния плеера на звук - я ведь выше приводил пример, как несколько миллиметров плохо экранированного провода на входе в АЦП ловили наводки плееров, отображаемые SpectraLab.

Т.е. по вашему ЭМ наводки от работы комп. железа только аудиоплееры могут генерить?

[aganext]

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

[Igor_A]

1) Почему картинок только одна пара? Это ведь совершенно ни о чём не говорит, т.к. различия могут быть вызваны просто случайным сочетанием шумов.
2) Из этих картинок вовсе не следует, что оба этих плеера выдавали бит-перфект - вы просто предлагаете поверить вам на слово.
3) Чтобы эксперимент был научным, он должен быть повторяемым. Опишите подробно условия его проведения - чтобы все желающие могли его повторить и убедиться лично в корректности предоставленных вами результатов.

При измерениях использовались XMOS USB ЦАП с питанием по USB, Windows Server 2008 R2, цифровой тональный тестовый WAV файл 12kHz тон / 384000Hz частота дискретизации, плееры AIMP 4 и Album Player с выводом через ASIO и отключенной обработкой, АЦП E-MU 0204, RMAA Pro. Воспроизводил стационарный компьютер i5/8GB, оцифровывал ноутбук. Делались серии измерений с повторяющимися результатами. foobar2000 я тоже включал в этой конфигурации и у него результат был где-то посередине между AIMP и APlayer.
В других конфигурациях такой разительной разницы измеряемых результатов нет, поскольку динамически индуцируемый джиттер в бытовых условиях трудно зафиксировать. То есть, я не отрицаю, что мне удалось подобрать индивидуальную конфигурацию, особенно чувствительную к влиянию плееров. Но это чувствительность именно к их влиянию, а не к чему-то другому, так как всё остальное не менялось.
В то же время, слышимое влияние плееров является достаточно массово наблюдаемым явлением. И я сам обращал на это явление внимание многократно еще до каких-либо собственных практических или теоретических изысканий в этой сфере.

Bug Head Emperor сделан на движке bass.dll, т.е. его автор программированием звука вообще не занимался - просто сделал оболочку с оригинальным дизайном.

Я видел исходники Bug Head. И пишу выше как раз о том же - что его плеер в общем случае выдает bit-perfect, как и остальные нормальные плееры, но при этом звучит по особому. И есть целое движение поклонников его звучания. Если исключить косвенное влияние плеера на звук за счет своего особого паттерна программной активности или каких-либо иных косвенных факторов, то Вам останется предполагать только массовое помешательство поклонников Bug Head.

---------- Сообщение добавлено 15:33 ---------- Предыдущее сообщение было 15:18 ----------

У нас 2 цифровых потока. 1 поток внутри PC, 2 поток выборки данных из буфера транспорта в МС ЦАПа. В 1 случае с дрожанием сигнала борется (успешно) железо компа. Во втором разработчик ЦАПа. Плеер то тут где?

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

Т.е. по вашему ЭМ наводки от работы комп. железа только аудиоплееры могут генерить?

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

[E.Sokol]

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

Поклонники они дизайна, а не звука. Достаточно исключить визуальную и прочие составляющие (т.е. устроить слепое сравнительное прослушивание) - и всё сразу встанет на свои места.
Ну а массовому умопомешательству есть вполне конкретное название - аудиофилия. Желание чувствовать себя исключительным и быть наделёнными сверх-способностями, недоступным простым смертным.

[Igor_A]

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

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

Дмитрий пишет 2 апреля:

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

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