Не знаю, как это может сказаться технически. При передаче через USB в асинхронном режиме данные передаются пакетами по 1024 байт, с частотой 480 МГц. После приема, данные распаковываются во внутреннем буфере интерфейсного чипа и передаются во внутреннюю шину уже с внутренней частотой, кратной 44.1 или 48 кГц, совершенно не зависящей от исходной частоты в компьютере и в шине USB. Если это изменение настроек BIOS улавливают только на слух, то скорее, всего, не более чем иллюзии. Я знаю одного аудиофила на форуме iXBT, он различает по звуку направление включения SATA кабелей, версию релиза Windows, и даже разрешение экрана монитора. Мне, на мой взгляд, туда еще рано.
1 лайк
Мне нужно проверить JRiver и Foobar одной программой, не зависящей ни от одного из этих плееров ничем.
Не знаю, что вы имеете в виду. В статье этого нет. Более того, она очень критическая к подобным вещам, по моему. Нужно было еще и комментарии к ней читать?
Снимайте сигнал с аналоговых выходов цап. Jtest, как вариант (спуры вокруг частоты 11 кГц как раз являются тем, что отсутствует в исходном тестовом сигнале).
Методологически корректный подход включает две параллельных записи: одна выполняется в цифровом домене и для технически исправного оборудования всегда даёт идентичный результат независимо от применяемых OS и настроек BIOS/UEFI, тогда как вторая - запись сигнала с аналоговых выходов цап.
Для статистической достоверности необходимо 3-5 повторов. Если сравнение файлов из цифрового домена, как правило, проблем не вызывает (инвертируется фаза и сигналы суммируются), то с аналоговым доменом все несколько сложнее. Сравнение можно выполнить либо методом главных компонент (MPCA), либо иерархическим кластерных анализом с построением матрицы смежности (например, по коэффициентам корреляции Пирсона). Если отношение сигнал/шум недостаточно, шум вычитается методом анализа независимых компонент (ICA) как статистически независимый (негауссово распределение). Можно задействовать R или Matlab, это вопрос удобства.
В результате получим либо кучно лежащие точки, отвечающие конкретному кластеру, либо хаотичный разброс.
Повторю вопрос: ASIO Grabber чем не устраивает? Кстати, наблюдается ли воспроизводимость при нескольких последовательных прогонах? Если нет - Хьюстон, у нас проблемы с аппаратной частью.
Это все здорово, но мне интересно было бы узнать не это, что мне делать, а как вы все это объясняете. Если цифровой сигнал на входе микросхемы ЦАП совпадает с исходным, а на аналоговом выходе есть какие-то искажения, очевидно следует, что есть проблемы на этапе цифро-аналогового преобразования.Тут не надо делать 3-5 повторов, чтобы что-то понять. Но это никак не объясняет ситуацию с разным звуком софтовых плееров, если исходить из этой теории, он должен в обоих случаях идентичным образом отличаться от исходного, но не друг от друга. То есть ответ не на тот вопрос, который задан.
Вы невнимательно читаете, видимо. У меня не получилось применить эту программу для Foobar, и результаты, если бы они получились, меня бы не устроили, потому что игра бы шла на поле JRiver, а мне нужен полностью независимый наблюдатель. Вот, буду разбираться с Reaper, но у меня с этим вопросом ничего не подгорает, поэтому - в рабочем порядке, когда время найдется. Не получится, продолжу спокойно искать. Ничего не горит.
Эта тема неоднократно обсуждалась:
Чтобы наводки на аналоговую часть были идентичными должен выполняться идентичный код, что, очевидно, для разных плееров не соблюдается. Операционная система тоже участвует и не всегда строго идентично, поэтому необходимо несколько прогонов.
Разумеется, нельзя запретить человеку пройти свой собственный путь джедая, особенно в вопросе изобретения велосипеда.
ASIO Grabber никак не связан с JRiver. Разработка Игоря Антонова, автора Aplayer.
Но по мнению многих, в том числе Vit_S здесь ранее, все плееры выдают совершенно идентичный цифровой поток. Он утверждает, что он это проверял, хотя насчет описанного им эксперимента у меня есть некие сомнения, что он имел имел место в реальности, но я спорить с ним не стал. Портит только Windows, если не через asio. Вот собственно это мнение я и собирался опровергнуть, что какие-либо дополнительные фононы информации передаются прямо в мозг через торсионные поля. Раз разный звук - разный цифровой поток. Но доказать это не очень просто.
Вы правы, я эту программу еще не тестил. Перепутал с другой. Надо будет найти, навскидку откуда скачать не высвечивается.
Я имел ввиду программный код, исполняемый CPU. Что касается выходного потока данных, ранее уже было указано:
Keep it simple;) Отправить на цап поток DoP и проконтролировать соответствующую индикацию: если кажет DSD, значит с потоком всё в порядке, а если сваливается в PCM - повод искать виновника. Вроде ничего сложного.
Нет! В этом случае плеер сделает из DSD поток псевдо-PCM разрядностью 16 бит, 176 кГц, и к каждому отсчету просто прилепит константу в старшие 8 бит, чтобы поток DoP опознался. Были ли изменения в исходном DSD или нет, на процесс опознания это никак не повлияет. При этом DSD сложная штука, я в DSD на слух не сравнивал.
Спасибо! Буду разбираться.
Сначала берется исходный файл DSD, затем вручную конвертируется в контейнер DoP и уже полученный wav проигрывается плеером под видом обычного PCM. Любое вмешательство приведет к искажению маркеров и сбою декодирования в приемнике. Online-преобразование, разумеется, не подходит)) Кстати, разрядность контейнера не 16, а 24 бит.
1 лайк
И от звучания реального dsd ничего не осталось.
Не представляю, как можно вручную конвертировать. Возможно, конечно, есть такие программы, но я их не встречал.
Я это и имел в виду, 16 бит - dsd, 8 - маркер.
Первый удобоваримый результат действительно получен с помощью этой программы.JRiver выдал полный файл, практически копию исходного. А вот Foobar срывался. При проигрывании wav сформировался файл размером примерно 1/5 исходного, flac - 1/2. Увеличение размера буфера asio привело только к ухудшению результата. Зато JRiver отрезал от начала кусок примерно 64 байта, и дописывалось в конце некоторое количество 00, но это уже возможно сам граббер делал. Foobar хоть и не добегал до финиша, но от начала ничего не отрезал. Возможно, там какие-то метаданные были, и они оказались не важны, не знаю, с первого взгляда не понятно. В итоге пришлось сравнивать так. Полное сравнение не сделал, нужно тогда выравнивать начало и конец, но навскидку, в остальном все одинаково. Что из wav, что из flac. Значит, мое первоначальное предположение не подтвердилось. Зато появилось другое. Раз Foobar такой кривой в плане asio, а JRiver молоток, возможно, причина в этом. То есть что-то портится при работе с буфером asio конкретно моего драйвера ЦАП, что, до конца не понятно. Например, появляется действительно цифровой шум или типа того, какое то паразитное искажение, и так оно доходит до ЦАПа по USB. К слову, первоначально я что-то такое и думал. При этом у JRiver и у Foobar разный способ указания размера выходного буфера: в JRiver - он аппаратный, включается галочкой, в Foobar - по умолчанию 1000 мс. Возможно, это как то связано.
Тсс… не мешаем, у человека пока совсем другая задача, до прослушивания он ещё не дошёл, файлы сравнивает 
1 лайк
VinylStudio, Xrecode3, DSD-to-PCM converter то Yaki-San. У первой крайне неудобный интерфейс, но она единственная, где можно выполнить преобразование в обе стороны. Авторы двух остальных добавили данную функцию по моей просьбе.
Теперь полученный файл повторно прогоняем через связку проигрыватель-граббер и сравниваем. Снова есть изменения или нет?
Вы wav-контейнеры в HEX-редакторе сравниваете? Тогда следует работать с raw, заведомо без метаданных, хотя куда проще суммировать семплы с инвертированным по фазе исходником и проверить - получилась ли цифровая тишина.
Зря ерничаете. Собственно, с прослушивания я начал. Иначе бы меня было не заставить этим заняться, других дел полно.
Респект! Только зачем это…
Да зачем так сложно выеживаться? В hex редакторе отрезал по первой и последней одинаковой сигнатуре, и сравнил с помощью fc. Старо, как валенки, но работает. Все это заняло 5 минут. А так пришлось бы повозиться с огрызком, который Foobar мне наделал.
При повторном прогоне повторил трек, который сделал сделал в первый раз, полностью. Ничего не отчекрыжил. Что ему в исходном не понравилось, загадка. Но он это отрезал у меня упорно несколько раз. Я по hex кодам этого не понял, что это за 64 байта, а в инете по метаданным в wav очень общая информация.
Но вот мое предположение про asio уже так просто не проверить. По моей гипотезе, причина может быть в разном алгоритме работы плееров с asio. Я немного залезал в api asio, там все непросто и не очевидно. Как я понял, можно тупо заказать буфер, туда прямо записать данные последовательно, закрыть, заказать следующий и так далее. И это будет работать. Но в api еще много непонятных вещей, вроде роллбэк функций, которые по тому описанию, что я курил, непонятно, зачем, но наверное, они там не просто так. Скорее всего, есть нюансы, о которых не все заботятся. Поэтому Foobar в этом тесте и вылетает, не дописывая до конца. Возможно при этом, что граббер глюк ловит, звук параллельно идет, не прерывается. Почему - тоже не понятно. На воспроизведении на ЦАП Foobar не затыкается, но похоже все равно что-то делает нет совсем так, как надо. Тут может быть проблема такая, что все в итоге данные доставляются без потерь, поэтому на выходе совпадают, хоть сколько сравнивай, но доставляются как-то неравномерно, что иногда может вызывать проблемы с синхронизацией после перекодировки даже в асинхронном режиме работы usb. То есть, например, один плеер засылает равными порциями, последовательно, другой как-то наваливает и тем вызывает какие-то специфические сложности, о которых я читал иногда вскользь, но которые я совсем не понимаю. Это и может вызвать отличия в звучании плееров, которые я слышал, даже через asio, при этом они такие, на грани восприятия, то ли есть, то ли показалось. Но проверить эту гипотезу - надо очень глубоко в тему копать.