AleXH

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

@IgorA, я как-то раньше писал о баге особенностях реализации воспроизведения при высокой занятости ЦП. Воспроизводятся потрековые файлы, плейер автоматически после окончания предыдущего трека переходит на новый, начинает его воспроизводить 1-2 сек, потом замолкает на 3-6 сек и затем снова начинает трек с начала. Треки - флэки 24-2-192, FM Asio, 1 ядро, полная предзагрузка, sox 192->48, VST не задействовано.

@Schepke, с помощью программы для составления плейлистов - фубара

Какие там записи в достойном качестве, с нормальным динамическим диапазоном? На какие альбомы обратить внимание в первую очередь?

Игорь, 2103 забыли положить в архив.

Где и всегда: x32 http://albumplayer.ru/APNNNN.zip x64 http://albumplayer.ru/APNNNN_x64.zip , где NNNN номер версии

Никто не запрещает использовать тот ap2decoder (речь о FM), который больше нравится. Кладём в папку с последним АП и наслаждаемся. Нюансы звучания новых версий ap2decoder специально не программируются - их подкладывает ПК с ухмылкой - "Сюрпрайз!".

Именно это я у себя и услышал, когда перенёс ap2decoder из 2101 в 2104 и сравнивал полученный микс с оригинальным 2104, переключаясь между плейерами. Помимо этого есть ещё и приподнятость на НЧ и ВЧ по отношению к 2101. Причём отнести возросшую артикуляцию исключительно за счёт изменения АЧХ не получается - звук весь стал более прорисованным.

Подразумевало, что разница Ильёй не услышана, а надумана, так как в режиме FM Asio процесс aproxy во время воспроизведения не существует, а данные для транспорта ap2decoder все варианты прокси создают одинаковые - это я исследовал и описывал ранее. Поэтому "В FM Asio такого нет и быть не может".

Слух в данном случае имеет отношение к описываемым ощущениям лишь потому, что он тоже "в голове"

В FM Asio такого нет и быть не может - процесс aproxy перед воспроизведением выгружается из памяти.

Если бы не было разницы, то и плейеры все играли бы одинаково. Я не утверждаю, что именно латентность является причиной разницы в звучании, вероятнее всего здесь имеет место простая корреляция, а действительная причина зарыта гораздо глубже. К тому же, учитывая, что ПК агрегат довольно сложный - куча устройств со своими спектрами помех, соединённых общими шинами с арбитрами, то причин может быть несколько. Одна из гипотез классическая - букет помех влияет на восстановление цифры в аналог в мс цапа. Помехи могут попадать в цап как по входу, так и по общей земле, либо через общую электросеть. Вторая гипотеза "изотерическая" - дело в ячейках памяти драйвера, которые "заряжаются" ap2decoder'ом во время записи и заряд перетекает при чтении далее. Это только в теории ячейки памяти и данные - нули/единицы, а в реальности это сложные электрические устройства оперирующие зарядами, а не какими-то мифическими двоичными единицами. На первый взгляд данные в память драйвера пишутся всеми плейерами - так какая разница? - Предполагаю, что дело здесь во времени исполнения кода и квантах времени отводящимися многозадачной ОС на выполнение задачи. При неоптимальном многокомпонентном коде события "размываются" и звук получается "среднестатическим". Если же код мелок и быстр, укладывается в один квант, то в протекании процессов появляется некий устройчивый рисунок - "несущая", которая оказывает влияние на конечный звук.

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

Не думаю. Эффект разности звучания версий транспорта одних и тех же данных кроется в "местных" условиях используемой системы.

Здесь принципиальное значение имеет КАК проводилась цифровая запись. ПО типа VAC может показать лишь наличие явных ошибок в коде вывода плейера и ничего больше. Взял стерео файл 16/44, удалил в правом канале 1-й семпл - оказалось, что разница с оригинальным файлом слышна даже на мультимедиа акустике. А казалось бы - 1 семпл из 44000 на 1 сек. Но характер изменения звука совершенно не похож на разницу между ap2decoder от 2101 и 2104, так что предположение с рассинхроном между каналами неверно.

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

Мысль в том, что АЧХ другое из-за сдвига семплов в каналах друг относительно друга. В результате при сложении правого и левого канала изменяется как сцена, так и АЧХ воспринимаемого образа. Возможно сдвиг это результат "обалдевания" конкретных драйверов от использованного в АП метода работы с ними. Для строгого подтверждения или опровержения надо было бы на 2-х канальном осциллографе с памятью проверить одновременность прихождения импульса сигнала в данных семпла по обоим каналам. Но поскольку такой техники нет, то ... Игорь, возможно ли сделать тестовую версию со сдвигом в семплах правого канала относительно левого? Например по смещению такому-то в ap2decoder изменяем байт 0 на ffh и правый канал опережает левый на 1 семпл, 02h запаздывает на 2 и тд. Вручную нарезать в редакторе сдвинутые на разное количество семплов треки не столь оперативно.

Сделал 2 копии 2104 FM Asio, в одной из них заменил ap2decoder на аналогичный из 2101, в диспетчере установил обоим одинаковый приоритет - средний. ap2decoder из 2101 суб ективно имеет несколько другую АЧХ, по отношению к 2104 чуть опущена середина и чуть подняты низ и верх, на полочной акустике звучит интереснее. Запустил процесс хакер, посмотрел на пути процессов ap2decoder и выяснилось, что всё ровно наоборот - это 2104 имеет поднятые края, а не 2101. Игорь, Послушал внимательнее и обратил внимание на то, что сцена разная - может изменение АЧХ есть результат другого сложения фаз? - Данные на воспроизведение в обоих процессах идентичны - проверил, но что если они попадают в каналы со сдвигом относительно друг друга? Понятно, что такого быть не должно, но вдруг в этом всё и дело в наблюдаемых эффектах разности звучания версий?

Что именно непонятно в: ?

- Неправильно. Побочные эффекты не лично его, а системы ПК-ОС, порождающей их.

Кто сказал, что АЧХ выравнивалась автором? - Это побочный эффект модификации архитектуры ap2decoder.

Аналогично - у меня чем меньшая латентность системы, тем звук более открытый, мелодичный, он обретает большую детализацию, об ёмность и "дальность" полёта.

Это побочный эффект ПК как источника.

Термин "кривые" конечно не политкорректен - правильнее было бы сказать "имеющими особенности в реализации" или ещё тоньше - составляющими меньшую группу. Собственно "кривыми" они были названы исходя из истории доработок ap2decoder. Если оптимизированный, допиленный вариант звучит в некой системе хуже, то...

В 101-й от билда к билду АЧХ изменялась довольно значительно, к 102 она более-менее устоялась, в 103-й была выровнена, 104-я ровную АЧХ наследовала и от билда к билду у меня в 104-й изменений нет. Концептуально в АП меня напрягает лишь одно - шаманство с задержками, говорящее о том, что в консерватории не всё хорошо. С другой стороны, сам ПК как музыкальный инструмент - кошмарен, его архитектура, конечная реализация в "железе", многозадачная ОС, драйвера и пр. привели к тому, что существует корреляция между отзывчивостью (латентностью) системы и свободой звука, открытостью звучания.