yecora - SoundEX - Клуб любителей хорошего звука Перейти к публикации

yecora

Members
  • Публикаций

    76
  • Зарегистрирован

  • Посещение

  • Дней в лидерах

    1

Последний раз yecora выиграл 3 июля 2013

Публикации yecora были самыми популярными!

Репутация

25 Neutral

Информация

  • Город
    Москва
  • Аудиосистема
    Дистрибьютор - www.mms.ru

    Написать мне можно в [email protected]

    Текущая система (меняю составляющие много и часто, так что скорее это то, что есть под рукой):

    Стриминг: iPad mini 2015/iPhone Xs/Macbook Pro 2008 (Core2Duo 2,4/4Gb/HDD) + Roon + Tidal Hi-Fi + Google Music

    CD: Musical Fidelity M6CD-DAC / PS Audio Lambda CD Drive/ C.E.C. TL-51

    DAC: Weiss DAC1 Mk2 / PS Audio Ultralink Two / California Audio Labs Alpha

    Лента: Studer A80 / C37 / A807

    Кассетная дека: Nakamichi Dragon / Kenwood KX-1100HX / Tascam 122 mkII / Akai GX-9

    Интегральник: Primare I15 Prisma / Cyrus One HD / NAD 304 / Yamaha A-1000 / Thorens TRA3000VT

    Мощник: PS Audio 200cx

    Спикеры: Dynaudio Contour S1.4 / KEF Reference 205.2 / KEF LS50 / KEF LSX / Apogee Centaurus Slant 6

Посетители профиля

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

  1. Bowers & WIlkins презентовали новую восьмую серию - версии D3. По фото на сайте понятно мало, но как то противоречиво они выглядят. Что думаете? http://www.bowers-wilkins.com/Speakers/Home_Audio/800_Series_Diamond
  2. Какие временные задержки? Вы о чем? Сервер начинает чтение файла, считывает первичные данные, посылает клиенту. Тот ловит служебную инфу о файле первым же пакетом - имя файла, размер, битрейт, кодек и тп. Потом они договариваются с сервером какими кусками тот будет слать файл, меряют пропускную способность сети и плеер выделяет в памяти буфер на, скажем 10-20 секунд проигрывания. Сервер начинает слать нумерованные и подписанные пакеты, а плеер закачивает в буфер первые 20 секунд файла, после чего начинает воспроизводить (до этого момента потерь нет). И далее догружает по мере необходимости дальнейшее. Всё. Если сеть заткнулась или коллизии пошли - трек замолкает и плеер ждет пока буфер не наполнится опять.
  3. Ох, сподвигаете меня на написание поста, а то и статьи. Видите ли, давайте еще раз, пока идет речь о передаче и хранении данных в пакетном виде, с контрольными суммами и тп и тд, все разговоры об каких то искажениях этих данных в процессе передачи - довольно бесполезная затея. Какие то потери возможны только когда этот контроль отсутствует, когда идет поток битов без проверки (как например PCM по оптике с CD-плеера). Протокол DLNA, на котором работают наверное практически все аудиосервера и плееры, довольно четко регламентирует классы устройств и передачу данных между ними. Так, DMS - digital media storage - передает данные на DMR - digital media renderer - без потерь. Между DMR и DMP (player) - уже идет поток в котором могут быть, опять же теоретически, потери. Но, как правило, DMR и DMP - это одно устройство. Клиент DLNA. А NAS , он же DMS, не причем. Как и вся сетевая инфраструктура. Но иногда DMS может и выполнять рендер, то есть декодинг, вот тогда сетевой плеер получает стрим, в которм могуть ошибки. Лечить это проще правильными девайсами, а не проводами и свитчами. Аналогии не очень люблю, но это примерно как говорить о том, что коробочка для переноса компакт диска влияет на качество его звучания. Коробочка всего лишь не дает ему поцарапаться, потеряться и запачкаться. При условии что коробочка не сломана и диск перед тем как вставить в плеер смотрят на наличие царапин - разницы нет и быть не может.
  4. Не надо путать компакт диск и поток pcm с него и пакетную передачу данных. Файл состоит из набора ноликов и единичек и два файла копируются с сохранностью 100%, иначе он просто не скопируется. А вот с компакта два рипа да, могут быть разными. И это, кстати никакая не тЭория, это самая что ни есть практика и правила передачи данных в IT и компьютерных сетях.
  5. Ух... А вы знаете как работает жесткий диск, неважно какой он, на блинах или твердотельной памяти? Файл, записываемый на хдд, бьется на блоки, соответствующие размеру кластера (определяется типом использованной файловой системы), после чего записывается - причем файл может быть записан в совершенно разные места диска - при его форматировании ранее (давно) разделы логические можно было сделать только при низкоуровнем форматировании или с плясками с бубном, сейчас контроллеру винчестера вообще плевать, он может отдельный раздел логический сделать "на лету", но физически куски этого раздела могуть быть в совершенно разных местах, а при рейде - вообще на разных винчестерах. В процессе бития на блоки - они награждаются контрольной суммой и записываются физически на носитель, а контрольная сумма по каждому блоку, включая контрольную сумму файла, записывается в системный раздел винчестера. При считывании файла, если не совпадает контрольная сумма - то получается ошибка и контроллер дает команду перечитать блок, пока не сумма не совпадет. Если это невозможно, то файл не читается, блок в системном разделе помечается как bad block и более в процессе не участвует. И как тип диска может при таком раскладе влиять на сохранность данных?
  6. Давайте отделять мух от котлет. Все интернет ресурсы, включая, наверняка, этот сайт, хостятся в огромных датацентрах, в которых стойки, набитые серверами с самыми обычными не-SSD винчестерами генерят огромное количество помех. Теперь вопрос - вы часто видели пропадающие буквы на страницах, или, например артефакты на картинках типа .BMP, .JPG, .PNG и прочих? Или может быть записать музыкальный файл в дропбокс влечет за собой его компроментирование? Помехи от сварки влияют на аналоговые цепи, а вся эта цифровая шляпа (за исключением некоторых протоколов) разработана как раз с учетом сохранения данных. Опять же, гораздо больший эффект теоретически даст использование ECC памяти с четностью и raid массива, нежели замена хдд на ssd.
  7. Ну, если вы считаете что это работает - то это ваше дело, просто идея в том, что крутизна фронтов сигналов и прочее - никак не связано с патчкордами, роутерами и прочими представителями низших слоев OSI. Грубо говоря - хоть я и не люблю аналогии - в целом вы можете леть в бизнесклассе, можете в экономе, но самолет ваш прилетит в одно и то же время в аэропорт назначения. В бизнесе лучше кормят, наливают и из самолета можно выйти быстрее, но в целом доставка от ВПП аэропорта вылета до ВПП аэропорта назначения - абсолютно в то же время. Кстати для улучшения передачи данных гораздо полезнее не патчкорды менять, а озаботиться свитчом, который умеет думать и работать с QoS. Ну и отконфигурить его так, чтобы пакеты от сервера до плеера имели наивысший приоритет. Это, я думаю, на несколько порядков более полезно, чем перепаивать лампочки в разьемах RJ-45.
  8. Добью еще парой моментов. ТЕОРЕТИЧЕСКИ, кроме TCP есть протокол UDP, но UDP это в основном IPTV и прочее вещание от одного источника нескольким клиентам/адресам _в реальном времени_, и это работает в основном когда один сервер вещает для кучи клиентов одно и тоже. Вот в UDP пакеты могут теряться и клиент сам "додумывает" контент - поэтому при просмотре всяких КартинТВ и прочих IPTV сервисов картинка может рассыпаться. Если вы смотрите видео на телевизоре которое стримится с наса на WDTV или всякие XBMC - то картинка не рассыпается, но если по каким то причинам затык в передаче данных - они тупо заново буферят и только потом начинают проигрывать с последнего кадра. По поводу потери пакетов - в принципе, если сеть построена нормально, то количество коллизий - то есть "потерянных" и заново запрошенных пакетов крайне невелико. Более того, в любом управляемом свитче или нормальном роутере можно посмотреть статистику по потерянным пакетам - и если их количество велико - то имеет смысл фиксить это не аудиофильскими патч-кордами или линейными блоками питания, а более надежными свитчами и убиранием всяких помех естественного свойства, но никак не заменой NAS.
  9. Слушайте, я почитал тему (не всю) и несколько удивлен. Я немного попытаюсь приземлить всю эту дискуссию и завести ее в более менее логические рамки. Смотрите - для понимания того, как работает передача данных по сети, надо знать такую штуку, как модель OSI. Вот ссылка на wiki . Идея очень простая - качество физического соединения между двумя клиентами сети, в принципе, не играет роли, пока оно есть. Все переходы между слоями OSI возможны только в пределах соседних уровней (вертикальный переход) либо между клиентами одного и того же слоя (горизонтальный переход) и везде данные четко проверяются. Отличие, например от USB Audio в следующем - USB Audio не имеет коррекции данных и поток байтов стримится между двумя точками, если какие то байти теряются, то цап на втором конце может аппроксимировать ближайшие полученные данные и получить то что потеряно между. Передача по Ethernet по протоколу TCP - это передача пакетная, с проверкой целостности каждого пакета и наличия каждого пакета, если пакет потерялся или нет корректной контрольной суммы - то пакет будет запрошен клиентом еще раз. Более того, на жесткий диск процесс записи/чтения также связан с контрольными суммами файлов, то есть файл, даже если он читается постепенно, не может быть прочитан неправильно. Потери могут быть только на стадии инкапсулирования данных в пакеты TCP (сервером) и вытаскивания данных из них (плеером), если звук идет по стриму. Но на стадии инкапсулирования, вполне вероятно, тоже есть проверка, ибо данные после запаковывания в пакет получают ту самую контрольную сумму, которая как раз и является проверкой на этапе расшифровывания. То есть, по факту, только плеер может лажануть. Что скажете? С "ну я же слышу разницу" - я уже ознакомился, все понял, но поверить в это не могу.
  10. Дирак, грубо говоря, это алгоритм, который умеет рассчитатывать фильтры и задержки. Работает он, естественно, в рамках возможностей DAC/DSP железа. И, что немаловажно, микрофона тоже. Ну а как там сделали байпасы и как крутилки громкости - это уже не Дирак
  11. Хотелось бы отметить, что если в коробочке от miniDSP у кого то при off режиме эквализации звук не такой как при исключении коробочки из тракта, то это проблема не Dirac, а miniDSP, ибо Dirac железо сам не делает (в отличие от Триннова)
  12. Сереж, ну сложно сказать что там было в 1962 году, с удовольствием при случае тебя послушаю, ибо тогда компьютеров особо не было, а как оно работало в аналоге вообще не представляю. В моменте такие системы установлены в ХСС, Светлановском зале дома Музыки на Павелецкой и вроде как на второй сцене Мариинского театра.
  13. Насчет реверберации помещения и ее корректировки электронными методами. То что есть некие формулы, описывающие физические характеристики некоего предмета(среды), вовсе не означает что эти характеристики нельзя корректировать внешними факторами. Самый простой пример - есть вода, у нее есть теплоемкость, формула, куча физически измеримых параметров. Но если мы воду в кастрюле поставим на горелку - то она превратится в пар. Грубое сравнение, но тем не менее - время реверберации в помещении МОЖНО менять. Есть такая хитрая штука - система Constellation от одной малоизвестной на этом форуме, но весьма известной в среде профессионалов компании Meyer Sound. Штука дорогая, штука сложная, но суть именно такова - путем установки кучи специальных микрофонов и специальных АС (лучше сказать transducer) - можно менять характеристики помещения. От полностью заглушенного до концертного холла. Лично видел. Охренел чуть более чем полностью. Вот описание - https://www.meyersound.com/products/constellation/
  14. Ценник на Datasat RS-20 довольно большой, факт, но это не только потому что там есть Dirac, но еще и потому что это довольно неплохой 16-канальный процессор )) Насчет емотивы - зная их изделия снаружи и изнутри - я бы не стал обольщаться. Ценник на нее гуманный вполне, но потому что она продается напрямую (не подразумевает наличие дилеров/дистрибьюторов) - то есть получив аппарат в России по почте, все проблемы и ньюансы придется решать самому. По качеству - процессоры Sherbourn, которые делала таже емотива (Jade Design) - процент брака был примерно 20-25%, что запредельно просто. Хорошо что к ним хотя бы иногда платы приходили. По усилителям особых вопросов не было. Но с процами у них беда.
×
×
  • Создать...