(15-01-2017 16:49)slyhach писал(а):  интересует именно соответствие каждого нолика и единицы в разных файлах. Не произошла ли подмена каких-то нулей на единицы, или наоборот?

Сравнивать "нолики и единички" можно только при условии передачи цифра-цифра, без двойного D/D-A/D преобразования и прохождения по аналоговому тракту - в этом случае, "нолики и единички" никогда полностью не совпадут даже с одним и тем-же кабелем.

(15-01-2017 15:51)Kir9790 писал(а):  Уже определили, что именно покупать планируете?

да

(15-01-2017 17:07)rotla писал(а):  Сравнивать "нолики и единички" можно только при условии передачи цифра-цифра, без двойного D/D-A/D преобразования и прохождения по аналоговому тракту - в этом случае, "нолики и единички" никогда полностью не совпадут даже с одним и тем-же кабелем.

В том, что полного совпадения не будет - думаю никто не сомневается. Речь о другом. Проанализировать спектры одного и того же музыкального трека на предмет отличий, и выразить их количественно (раз ушам веры нет) (напр. % ошибок, дисперсия. коэф. вариации - хз чем там спектры измеряют). И можно делать сколько угодно прогонов как с одними и теми же кабелями, так и с разными - результаты в табличку, где всё будет видно.
Например:
- один и тот же кабель - разница в сравнении друг с другом 0,5% (+-0,06).
- хороший аудиофильский кабель - разница с "принтерным" - 2,2% (+- 0,4)
и т.д.

И тогда можно делать выводы, что, например, да - с одним и тем же кабелем звучит по-разному, но разница эта небольшая (0,5%). А вот разница между принтерным и аудиофильским кабелем - гораздо больше (более чем в 4 раза)....

Хотя идея эта не нова и уже высказывалась.

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

А как "перегнать WAV-файл с компьютера на компьютер по USB"?
Просто соединить? Так с одной стороны не лiзе.

Цитата:Просто соединить? Так с одной стороны не лiзе.

Смазать, и с разбегу ...
А если серьезно, то обычный USB кабель наверно никак, хоть это и нонсенс какой-то.
Только специальными:
_http://www.ghisler.com/cables/
_http://www.flint-inc.ru/tchelp/html/usb_cable_connection.html
_http://droidov.com/kak-podklyuchit-kompyuter-k-kompyuteru-cherez-usb-wi-fi-setevoy-kabel
_http://cit.odessa.ua/stati/soedinenie_dvuh_kompyuterov_po_usb.html

(15-01-2017 19:22)slyhach писал(а):  Насколько я понимаю, что при перегоне качественного WAV файла с компьютера на компьютер ....

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

Нормальные устройства работают в асинхронном режиме, зачем изохронный режим ??
Да и фиг с ним, с USB этим ....

Асинхронный режим - подмножество изохронного режима.

(15-01-2017 22:35)slyhach писал(а):  Смазать, и с разбегу ...

Сползает

Цитата:А если серьезно, то обычный USB кабель наверно никак, хоть это и нонсенс какой-то.
Только специальными:

А если серьезно, то эта проверка ничего не даст, т.к. USB будет работать совершенно в другом режиме.

Можно судить по реальной* скорости копирования,допустим с внешнего винта.
Предварительно отключив всё лишнее.

*реальной так как система иногда выдаёт(показывает) желаемое за действительное.

(12-01-2017 13:44)Eugene Balakin писал(а):  Можно пойти методом исключения - экспериментально подтвердить или опровергнуть битперфектность изохронного асинхронного ЮСБ аудио, но мне влом подключать СПДИФ выход к Эдель, я его не использую. Интерфейс встроен в ЦАП, ЦАП с внешним БП - короче - разбирать это все - не хочу.
А так - воспроизводить через Эдель, писать через СПДИФ вход 0404ЮСБ, сравнить файлы - делов-то. До 24/96.
Может можно завернуть петлю по СПДИФ в самой 0404ЮСБ? Нужно подумать. Если битперфектность в таком эксперименте подтвердится, то сразу и для ЮСБ и для СПДИФ.
Какая программа может одновременно проигрывать и записывать? КТо подскажет?

Нам интересен режим передачи аудиоданных без проверки и повторной отправки пакетов. Ни у кого ж нет претензий к витой паре интернет, который идет х.з. знает где(электрические щитки...) и длиной километры.

(16-01-2017 02:14)dmitriy28 писал(а):  Можно судить по реальной* скорости копирования,допустим с внешнего винта.

Совершенно не показательно - это балк-режим, MSD, а не изохрон UAC.

(16-01-2017 07:47)urfinjuss66 писал(а):  Нам интересен режим передачи аудиоданных без проверки и повторной отправки пакетов. Ни у кого ж нет претензий к витой паре интернет, который идет х.з. знает где(электрические щитки...) и длиной километры.

Не будем говорить про то, что битперфетность - это прямо указанный параметр в официальных спецификациях производителей чипсетов и интерфейсов ЮСБ аудио. А официальные спеки публиковать - это уж точно не на аудио форумах фантазировать...
Поговорим про другое.
Зачем сравнивать совершенно , принципиально несравнимые вещи?
Передачу данных на расстояния в тысячи/сотни км (не ограничено) с единицами метров (до 5). Не нужно сравнивать систему, надежность передачи данных которой рассчитана на устойчивость при глобальном ядерном ударе, с подключением периферийных устройств на метровых расстояниях, надежность которого (в сравнении с надежностью связи в усл. глобального ядерного конфликта) вообще пофиг. Это я про Пентагон, АРПАНЕТ и Интернет - ее прямого наследника (с его протоколами).
Такая себе отличная иллюстрация известного философского закона про переход количества в качество.
Не нужно прикручивать протоколы с квитированием туда, где они наверняка совсем не нужны.
Вот смотрите - АйПи пакеты продвигаются в Интернет, адрес назначения один. Но пути могут быть разными, расстояния разными, устройства - разными, технологии по ходу продвижения - разными. По ходу продвижения пакета меняются его заголовки, он может инкапсулироваться в разные протоколы, ожидать в разного рода буферах и - ГЛАВНОЕ - он может отбрасываться - штатно. Т.е предполагается, что на том или ином этапе пакет может быть дропнут. Не дождался своей очереди в буфере, потому, что продвигался более приоритетный трафик, например. Буфер переполнился. До побачення, пакет.
То же самое с кадрами на 2-м уровне. Все же слышали про так называемое качество обслуживание в эзернет сетях? Там теги всякие, очереди. Причем коммутаторы могут по-ходу продвижения кадров эти теги менять, т.е. кадр постоянно претерпевает какие-то изменения. И, конечно, при определенных условиях, и тоже штатно, может отбрасываться. Это не неисправность. Это так эта машинерия работает. Для чего? - например - чтобы вы могли АйПиТВ пользоваться комфортно. Причем это все работает вплоть до домашнего роутера. Иногда проприетарные алгоритмы.
Т.е. продвижение данных в Интернет, посредством стека АйПи протоколов, предполагает, что они могут теряться. В штатной ситуации. А значит, нужны и механизмы на уровне протоколов, чтобы можно было данные доставить гарантированно. Там, где то необходимо, конечно.

А теперь - наш случай - ЮСБ. Его скорее нужно с СПДИФ сравнивать.
В СПДИФ, при исправном интерфейсе, потеря данных невозможна, СПДИФ поток и есть данные. Это изохронный синхронный интерфейс. Чтобы он потерял данные из-за внешнего воздействия, наверное нужно построить специальное устройство - индуктор там какой-то.
А если взять балансный вариант передачи - как в АЕС/...
ЮСБ - балансный интерфейс, расстояния - до 5 метров. Ничего такого с его кадрами не происходит при передаче, никакой обработки. Сравните с Интернетовской (как одна из технологий в рамках - Эзернетовской) машинерией со кучей всяких обработок по-ходу и штатной возможностью дропанья пакетов/кадров!
Как бы не было как с интерполяций в СДДА - она типа есть, но на практике применяется чрезвычайно редко- кадры могут теряться, но раз в 100 часов прослушивания.
Зачем в таком случае протокол с квитированием и повторная передача кадра?
Я тут пытаюсь поставить эксперимент, но без фанатизма. Поставил Кэйк Валк - но это целая студия - программа сложная, спешить разбираться не буду. А с наскоку - фигвам - не выходит. Может кто-то посоветует программу по-проще, чтобы записывала с СПДИФ входа?

(16-01-2017 12:40)rotla писал(а):  Совершенно не показательно - это балк-режим, MSD, а не изохрон UAC.

Протокол протоколом,скорость копирования будет зависеть от кол-ва ошибок
какие то выводы делать будет можно .

(15-01-2017 12:58)bbest писал(а):  Ой, тишина в ветке. Как это всех сразу отпустило :-).

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

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

(16-01-2017 02:14)dmitriy28 писал(а):  Можно судить по реальной* скорости копирования,допустим с внешнего винта.
Предварительно отключив всё лишнее.

*реальной так как система иногда выдаёт(показывает) желаемое за действительное.

Так-то оно так, при ошибках (потере пакетов) будет повторная передача данных и, как следствие, - снижение скорости. То есть по скорости копирования (причём именно в bulk-режиме, где есть переотправка пакетов) можно как-то судить о кол-ве потерянных пакетов, и сделать вывод о качестве ЮСБ-кабеля.

Несколько лет назад вроде бы на оверклокерсах проводили такой эксперимент... но что-то там в итоге вышло всё неоднозначно. (Пытался найти ссылку - пока не смог, поэтому пишу по памяти). То ли разница между повторностями (одним и тем же кабелем) вышла сравнимой с разницей между разными кабелями, то ли ещё что-то... Много критики было, очень многое нужно учесть при этом:
- чтоб скорость накопителей не стала "узким" местом (то есть скорость "упиралась" лишь в кабель);
- чтоб копировалось в одно и то же место жёсткого диска по возможности с наименьшей фрагментацией (для этого желательно форматировать накопитель после каждого раза);
- исключить влияние кеша жёстких дисков;
- точно измерить время копирования (чтоб определить среднюю скорость) и очень важно определить максимальную и минимальную реальную скорость копирования;
- выбрать файлы какого размера копировать (много мелких или наоборот - один крупный).
и т.д.
Кроме того там измерялась скорость разных, но "принтерных" кабелей.

То есть вопросов масса (и, как следствие, возможностей оспорить результат), результат измерений выйдет весьма "косвенный" и результат в итоге выйдет уж очень сомнительный.

Может кто осилит с переводом... _http://marlene-d.blogspot.ru/2012_01_01_archive.html

(16-01-2017 15:01)urfinjuss66 писал(а):  Может кто осилит с переводом... _http://marlene-d.blogspot.ru/2012_01_01_archive.html

Осилил, перевод следующий - "покупайте!"

Вот, если интересно, Гугл справляется - Перевод

(16-01-2017 15:01)urfinjuss66 писал(а):  Может кто осилит с переводом... _http://marlene-d.blogspot.ru/2012_01_01_archive.html

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

Кстати очень интересный факт: Audioquest Forest USB проиграл по показателям программы RMAA "обычному" ЮСБ-кабелю!
Автор пишет:
Удивлены? Да, я тоже. Я не знаю, может быть кабель был неисправен. Но я знаю, что после того как я увидел эти результаты, я протестировал его у себя с Sansa Clip+ и внешним HDD - не было ошибок или падения скорости (из-за повторного чтения испорченных данных) во время передачи данных.

То есть программа ещё раз подтверждает вывод, сделанный "ушами":

(13-01-2017 14:32)serapion1984 писал(а):  Форест (Forest) и Чинамон копипаст от принтера (даже местами резче и хуже).