Но по мнению многих, в том числе Vit_S здесь ранее, все плееры выдают совершенно идентичный цифровой поток. Он утверждает, что он это проверял, хотя насчет описанного им эксперимента у меня есть некие сомнения, что он имел имел место в реальности, но я спорить с ним не стал. Портит только Windows, если не через asio. Вот собственно это мнение я и собирался опровергнуть, что какие-либо дополнительные фононы информации передаются прямо в мозг через торсионные поля. Раз разный звук - разный цифровой поток. Но доказать это не очень просто.
Вы правы, я эту программу еще не тестил. Перепутал с другой. Надо будет найти, навскидку откуда скачать не высвечивается.
Keep it simple;) Отправить на цап поток DoP и проконтролировать соответствующую индикацию: если кажет DSD, значит с потоком всё в порядке, а если сваливается в PCM - повод искать виновника. Вроде ничего сложного.
Нет! В этом случае плеер сделает из DSD поток псевдо-PCM разрядностью 16 бит, 176 кГц, и к каждому отсчету просто прилепит константу в старшие 8 бит, чтобы поток DoP опознался. Были ли изменения в исходном DSD или нет, на процесс опознания это никак не повлияет. При этом DSD сложная штука, я в DSD на слух не сравнивал.
Сначала берется исходный файл DSD, затем вручную конвертируется в контейнер DoP и уже полученный wav проигрывается плеером под видом обычного PCM. Любое вмешательство приведет к искажению маркеров и сбою декодирования в приемнике. Online-преобразование, разумеется, не подходит)) Кстати, разрядность контейнера не 16, а 24 бит.
Первый удобоваримый результат действительно получен с помощью этой программы.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 мс. Возможно, это как то связано.
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, при этом они такие, на грани восприятия, то ли есть, то ли показалось. Но проверить эту гипотезу - надо очень глубоко в тему копать.
Марат в ветке по джиттеру указывал, что алгоритм действий зависит от реализации прошивки принимающей стороны, т.к. в аудио задействована асинхронная модификация изохронного режима usb. Если по какой-то причине произошло опустошение буфера или вдруг пришел битый пакет (хотя такое случается крайне редко) - запрос на повторную отправку отсутствует и с этим надо что-то делать - либо mute, либо повторять последний успешно полученный. Скорее всего, возможен и третий вариант - интерполировать, но в каких именно приемниках он реализонан, мне неизвестно.
Это все я знаю, я немножко про другое. На самом деле еще при работе в асинхронном режиме после получения каждого фрейма приемник посылает передатчику сигнал прерывания, и он начинает передачу заново, для синхронизации клоков приема и передачи. Думаю, что буфер современных контроллеров USB спокойно вмещает целый фрейм, это копейки памяти, а задержка начала воспроизведения критична только если изображение воспроизводится через одно устройство, а звук через другое. Я тоже думал на тему того, что делает контроллер, когда получает битый пакет. У меня иногда происходят запинки звука, редко, но бывает, думаю, что просто пакет пропускается, и все. Если не целый субкадр. Мой прошлый цап, DacMagic 100, который я продал, реагировал сурово: смаргивал светодиодами индикации частоты и запинался наверное на секунду, или больше, скорее всего, делал прерывание и запрашивал начало передачи, после чего, подстраивал частоту по новой. Интерполяция… в видео по сети встречается в виде квадратов на экране, и то не всегда, при передаче по USB потока по моему никогда.
У меня другое предположение. Например, из-за разного по равномерности заполнения в буферы asio может происходить так, что в одном случае реализации передачи информация в кадрах и пакетах передается равномерно, с одинаковым наполнением кадра, в другом - то больше, то меньше. В один момент заполнены все пакеты, в другом почти ничего или пустой кадр. Вот такая неравномерность и может вызывать какие-то нежелательные эффекты в приемнике. То приемный буфер переполнен информацией, то почти пуст. Может, еще что-то типа того происходит. Такие волны, если они происходят, теоретически могут вызывать эффекты типа формирования цифрового шума в приемнике. Но информация в итоге в байтах доходит вся без искажений.
У меня было предположение, что происходят эффекты уже при формировании сигналов для микросхемы ЦАПа по шине. Типа нарушения синхронизации. Сомнительно выглядит, но по другому я на настоящий момент объяснить найденное субъективное различие в звуке не могу. В торсионные поля я не верю, в самообман в данном случае тоже, потому что когда я уловил различия, я находился в состоянии полной и беспрекословной уверенности, что звук через asio должен быть строго одинаковый. И был немало удивлен найденным различием, хотя оно и еле уловимое. В данном случае раскритиковать любое объяснение этого различия с технической точки зрения будет намного проще, чем найти его.
Тем не менее запинки происходят иногда, трудно сказать уже почему. Скорее всего, причина их еще в компьютере, он не успевает сформировать данные, хотя я потратил очень много усилий, чтобы это исключить. Но видимо, под виндой добиться полного отсутствия подобных проблем на таком капризном плеере, как JRiver, невозможно.
Трудно в данном случае сказать, какого характера это нарушение. По моему, что-то сложное. Я про подобное читал, что-то нечеловекопонятное, но полного описания пока не нашел. Поэтому воздержусь от дальнейших предположений.
