Вопрос о сравнительных преимуществах принципиально различных методов беспроводной передачи аудиоданных с помощью Bluetooth или Wi-Fi. Начнём с того, что максимальная скорость передачи данных Bluetooh 5.0 составляет 1 Мб/с. Этого достаточно для передачи звука в CD-качестве при использовании сжатия данных без потерь (lossless) до 700 Кб/с. Но для передачи звука с качеством Hi-Res 96 кГц/24 бит необходима скорость уже около 4,5 Мб/с, а с учётом lossless-сжатия — более 2 Мб/с. Это вдвое превышает возможности Bluetooth. Казалось бы, исходя из этих простых соображений, вывод о целесообразности применения Wi-Fi для беспроводной передачи звука Hi-Res напрашивается однозначно. Но на практике дело обстоит не так просто [79]. Во-первых, в диапазоне 2,4 ГГц имеется не более 14 каналов передачи данных. С учётом того, что ширина канала составляет 22 МГц, это означает, что пересекаются сразу четыре соседних канала (два снизу от рабочей частоты и два сверху).
В диапазоне 5 ГГц число каналов увеличивается до 50, но непересекаю-щихся всего 24. Bluetooth, работая в том же частотном диапазоне 2,4 ГГц, имеет 79 непересекающихся каналов шириной 1 МГц. Далее, благодаря применению технологии AFH (Adaptive Frequency Hopping), Bluetooth непрерывно отслеживает и, при необходимости, динамически переключает каналы с целью обеспечения устойчивости связи. В Wi-Fi смена канала при установленном соединении приводит к обрыву связи. Принцип формирования и передачи пакетов данных в рассматриваемых стандартах также различен. В случае пересечения каналов Wi-Fi передача пакетов в них организуется последовательно, и время задержки, обусловленное необходимостью ожидания свободного "окна", на практике может достигать 200 мс, что является достаточно критичным для передачи звука. Следует также учесть, что для передачи аудиоданных и доступа в сеть устройства как такового используется один адаптер, следовательно, данные разного рода обрабатываются поочерёдно, что приводит к снижению скорости их передачи и общему ухудшению стабильности связи. Всё это чревато не только проявлением джиттера, но и банальным прерыванием звучания. И в завершение — среднее энергопотребление адаптеров Bluetooth и Wi-Fi в режимах ожидания и работы различается на порядок не в пользу последнего.
Решающим фактором в вопросе выбора технологии беспроводной передачи аудиоданных на текущий момент является появление кодеков LDAC [80] и LHDC [81], разработанных специально для Bluetooth. Более того, только эти два кодека имеют официальные сертификаты Hi-Res Audio Wireless от Японского Аудио-сообщества (Japan Audio Society), выданные в 2019 г.
Актуальная версия LDAC обеспечивает передачу звука с параметрами 96 кГц/24 бит при скорости передачи до 990 Кб/с. Использование алгоритмов гибридного сжатия, основанных на методе MDCT (Modified discrete cosine transform), позволяет "уместить" поток данных с разрешением Hi-Res в полосу канала Bluetooth. Этот кодек свободно поддерживается ОС Android, начиная с версии 8.0. Кодек LHDC обеспечивает аналогичные параметры при скорости потока до 900 Кб/с. Он поддерживается ОС Android, начиная с версии 10.0.
Таким образом, применение беспроводной технологии Wi-Fi для передачи звука высокой чёткости (как, впрочем, и изображения) в реальных городских условиях может быть рекомендовано только при невысокой загруженности каналов передачи данных. В равной степени это касается распространённой системы передачи медиаданных Wi-Fi Direct. Для предварительной оценки обстановки в "эфире" и получения исходных данных для настройки оборудования Wi-Fi (в частности, выбора канала) рекомендуется воспользоваться специализированным программным обеспечением, например [82].
Для реализации полноценной поддержки Hi-Res при передаче через Bluetooth в ОС Android рекомендуется вручную выбрать кодек LDAC или LHDC в пункте меню Настройки-* Инструменты для разработчиков-*Сети—> Аудиокодек для передачи через Bluetooth и включить следующий режим в том же разделе Сети-* Аудио-кодек-*1_ОАС-*(1_НОС)-*Оптимизи-ровать качество звука. При этом звук будет постоянно передаваться с максимальным для выбранного кодека битрейтом. Естественно, приёмник Bluetooth тоже должен иметь поддержку выбранного кодека.
В общем случае для передачи звука высокой чёткости более предпочтитель
ным представляется использование технологии UPnP через LAN (проводное соединение). К сожалению, плееров с поддержкой функции выбора UPnP рен-дерера "из коробки" крайне мало. Непревзойдённым в этом смысле является BubleUPnP под ОС Android [83] для работы в беспроводных сетях Wi-Fi. Он распространяется в бесплатной и платных версиях. Внешне этот плеер весьма схож с AIMP; вид его главного окна показан на рис. 41.
Также выбор рендерера непосредственно в пользовательском интерфейсе поддерживают десктопные версии VLC. Функция доступна в пункте меню Play-back-Renderer. В ОС Linux при этом должен быть установлен пакет GUPnP Tools для семейства Debian/Ubuntu [84]:
sudo apt install gupnp-tools или для семейства RedHat/ Fedora: sudo dnf install gupnp-tools.
При этом возможно непосредственное использование утилиты UPnP AV Control Point, входящей в состав этого пакета (рис. 42). Эта утилита имеет функцию воспроизведения содержимого выбранной папки, не имеет никаких функций обработки звука и с учётом крайне лаконичного интерфейса вполне соответствует идеологии Perfect bit.
Наиболее актуальным вариантом обеспечения звука высокой чёткости на ПК по-прежнему следует признать использование файловых хранилищ, локальных либо сетевых с подключением через LAN.
Возвращаясь к рассмотрению Volumio и подобных систем и резюмируя вышесказанное, можно сказать, что такая реализация является чрезвычайно мощной, гибкой и прекрасно подходящей для высококачественного воспроизведения звука. Пожалуй, основным и, возможно, единственным недостатком можно признать абсолютно "узкую специализацию", т. е. принципиальную невозможность использовать одноплатный компьютер, работающий под управлением этой ОС, для решения другого круга задач, не связанных с функциями медиацентра. Конечно, никто не мешает создать и иметь под рукой набор загрузочных SD-карт с ОС для различного функционального назначения, однако при этом будет исключена возможность одновременного выполнения нескольких функций, например, программирования в среде NodeJS с использованием GPIO и работы медиасервера.
Поэтому следует признать актуальность и преимущество решения следующей задачи — собственной реализации медиасервера на основе одноплатного компьютера под управлением ОС Linux общего назначения. Далее будет подробно рассмотрена последовательность "ручного" создания медиа-сервера на платформе Orange Pi РС/ОС Armbian/Music Player Daemon (MPD).
За основу реализации возьмём ОС, настроенную согласно инструкциям, изложенным выше. Будем полагать, что ОС установлена, и подсистема ALSA настроена на использование всех желаемых типов звуковых карт с необходимыми параметрами. Следующим шагом следует установить собственно MPD. Делается это простой командой sudo apt install mpd. В процессе выполнения команды будет также установлен пакет свободных библиотек FFmpeg [85], который, в том числе, предоставляет набор кодеков и определяет возможности работы системы с различными форматами и контейнерами медиафайлов. После установки необходимо убедиться в наличии демона mpd в системе, сконфигурировать его и перевести в разрешённое и активное состояние.
Для работы с <ж демонами (сервисами или службами) в ОС Linux предусмотрен ряд спе-с циальных утилит.
Прежде всего, это утилита systemctl, которая может быть запущена с командами status, start, restart, stop, enable, disable и др. и указанием имени демона в качестве параметра. Назначение команд очевидно. Например, в нашем случае можно воспользоваться командой systemctl status mpd, которая предоставит развёрнутые сведения о текущем состоянии демона mpd.
ВАЖНО! Управление демоном mpd выполняется от имени текущего пользователя, без использования префикса sudo.
Запустить его можно сразу после установки командой systemctl start mpd, однако запуск будет сопровождаться ошибками, так как не проведена начальная конфигурация. Параметры конфигурации могут храниться в файлах -/.mpdconf, ~/.mpd/mpd.conf и /etc/mpd.conf. Система пытается считать их в указанной последовательности. Первые два файла предназначены для хранения пользовательских настроек, третий — для глобальных. Для обеспечения нормальной работы в большинстве случаев достаточно наличия только одного файла глобальных настроек /etc/mpd.conf. Конфигурация осуществляется путём его редактирования. Исходный файл mpd.conf снабжён достаточно подробными комментариями, поэтому далее приведён список только основных параметров, которые необходимо привести в актуальное состояние (в порядке следования по секциям файла mpd.conf) в соответствии с полной инструкцией на MPD [86] и кратким руководством [87]:
— music_directory /media/Music (секция Files and directories) — верхний уровень директории для размещения аудиофайлов. Если директория не указана или недоступна, будут обраба
тываться только источники через сокеты (по протоколу file://) и потоки;
— user opi (секция General music daemon options) — имя пользователя, под которым запускается сервис. Указывается при необходимости смены пользователя при запуске сервиса. По умолчанию используется имя текущего пользователя;
— bind_to _address 127.0.0.1 — важный параметр, который определяет, каким сетевым адресам и каким методом будет предоставлен доступ к управлению сервисом. Возможны варианты с указанием явных сетевых адресов или сокетов Unix (/run/mpd/socket). По умолчанию действует значение any (любой). В нашем случае указан локальный IP-адрес (localhost);
— port 6600 — порт TCP, который будет прослушиваться на предмет обращения к сервису (указано значение по умолчанию);
— restore_paused по — этот параметр указывает, будет ли MPD запускаться в режиме продолжения воспроизведения (значение — по) или в режиме паузы (значение — yes);
— auto_update yes — разрешение функции обновления базы данных автоматически после изменения файлов в m usi c_d i rectory;
— auto_update 3 — глубина сканирования директорий при автоматическом обновлении. Значение 0 ограничивает процесс только верхним уровнем. По умолчанию ограничение отсутствует;
— follow_outside_symlinks yes — определяет, будет ли MPD следовать по ссылкам на внешние хранилища из директории music_directory;
— follow inside symlinks yes — то же, внутри music_directory. По умолчанию значения обоих параметров — yes.
Особый интерес представляет секция Audio Output, в которой размещаются блоки параметров, определяющие типы и настройки используемых аудиоустройств. Исключительно удобной особенностью механизма воспроизведения MPD является то, что обращение к устройствам и их подключение производятся в соответствии с заданной в этой секции последовательностью блоков, независимо от номера устройства в системе. Таким образом удобно разместить, например, блоки параметров звуковых карт в следующем порядке: USB; I2S; HDMI и т. д., что позволит переключаться на следующее устройство в случае отсутствия текущего в системе. В качестве типа выхода может быть указан, в том числе, встроенный (sndio), SPDIF, поток Ogg Vorbis или встроенный стриминг-сервер http, файл в формате Ogg или MP3 и другие, включая null ("заглушку"). Возможно одновременное воспроизведение через несколько устройств разного типа. На момент инициализации MPD все перечисленные устройства должны существовать и должны быть физически подключены. Примеры блоков для типов устройств: USB; rS; HDMI, сконфигурированных для работы в подсистеме ALSA, показаны в табл. 2.
Содержимое параметров device (при необходимости mixer_device, mixer_control, mixer index) должно соответствовать системным значениям, определённым предварительно с помощью команды aplay -/. Для отключения неиспользуемого устройства достаточно полностью закомментировать соответствующий ему блок с помощью символов #.
Блоки описания устройств могут содержать также дополнительные параметры, такие как bitrate и format, в явном виде указывающие соответствующие параметры потока. Например, format 44100:16:2 установит параметры 44,1 кГц/16 бит/2 канала. Любой из параметров может быть заменён символом * с целью сохранения исходного значения. Совместно с указанием вывода в аудиофайл это можно использовать для перекодирования. По умолчанию сохраняются исходные параметры.
Следующая секция нормализации громкости (Normalization automatic volume adjustments) содержит параметры:
— replaygain off, album, track или auto — режим выравнивания громкости в соответствии с тегами метаданных ReplayGain [88]. Следует иметь в виду, что эта технология предназначена именно для выравнивания среднего уровня мощности звука и отличается от функции нормализации по пиковым значениям;
— replaygain_ргеатр О — уровень предусиления в режиме ReplayGain;
— replaygain_missing_preamp "О" — уровень предусиления для файлов, не имеющих тега ReplayGain;
— volume_normalization "по" — включение нормализации громкости. По умолчанию все функции выравнивания громкости отключены.
По завершении основных настроек необходимо выполнить команду разрешения автозапуска демона MPD
sudo systemctl enable mpd.service.
И сразу проверим результат с помощью команды sudo systemctl is-enabled mpd.service. После этого можно произвести перезагрузку, а можно запустить сервис вручную командой sudo systemctl start mpd.service. Текущее состояние сервиса в любой момент проверяется ранее упомянутой командой sudo systemctl status mpd.service. Вывод команды является непрерывным, для его прерывания следует воспользоваться стандартными комбинациями клавиш (Ctrl+C) или (Ctrl+Z). При необходимости полный список сервисов с указанием их статуса можно вывести с помощью команды sudo systemctl listunit-files. Вывод списка можно отфильтровать по нужному критерию стандартным способом с помощью суффикса grep: например,
sudo systemctl list-unit-files | grep enabled
выведет список всех разрешённых демонов. Пример нормального статуса демона MPD показан на рис. 43.
Все сообщения о работе mpd.service выводятся в консоль и в лог-файл (отчёт), адрес которого указан в mpd. conf (по умолчанию /var/log/mpd/ mpd. log). При возникновении ошибок следует проанализировать эти сообщения. Настройки вывода в лог-файл задаются в mpd.conf с помощью параметра log Jevel со значениями notice (напоминание), info (информационный), verbose (подробный), warning (предупреждение) и error (ошибки).
В случае наличия в системе съёмного USB-на-копителя удобно осуществлять автоматическое его монтирование непосредственно в каталог music_ directory, указанный в файле конфигурации mpd. conf. Для автоматического монтирования при загрузке ОС требуется отредактировать файл /etc/fstab [89], добавив в его конец следующую строку:
/dev/sdb1 /media auto defaults, nosuid, no fail 0 0.
При этом имя логического диска носителя должно соответствовать реальному имени в конкретной системе. Монтирование дисков можно осуществлять также по их уникальным идентификаторам UUID, что может оказаться удобнее при наличии нескольких носителей и/или их случайной перестановке в USB-портах, например
UUID=6e1f1d2e-e82b-441f-9af7-83а80с467е56 /media auto defaults, nosuid, notail 0 0.
Символы шестнадцатиричного кода в UUID должны быть представлены в нижнем регистре.
Параметры всех системных дисков, включая имена и идентификаторы UUID, можно определить с помощью стандартной команды sudo fdisk -I или sudo blkid.
В вышеприведённом примере, при наличии в корневом каталоге съёмного диска папки Music, её содержимое будет примонтировано в ректорию /media/Music, что соответствует настройкам в mpd.conf.
Опции монтирования:
— auto — автоматический выбор ти- оо-о па файловой системы;
— defaults — предписывает исполь- "g z зование стандартного набора парамет- J g ров монтирования, последующие опции “ g могут дополнять и переопределять g ф стандартные;
— nosuid — монтирование без под- Е. | держки SUID-битов;
— nofail — безостановочная за- S ■? грузка системы в случае ошибки мон- о. тирования указанной файловой систе- ц о мы.
Предпоследний символ (0/1) в строке параметров показывает, должен ли создаваться dump для примонтирован-ной файловой системы.
Последний символ (0/1/2) в строке параметров показывает, будет ли и в каком порядке проводиться проверка §
этой файловой системы средствами fsck при загрузке. z
Подробно опции монтирования описаны в [90].
Аналогичным образом можно монтировать сетевые диски, например — # NFS
Server:/share /media/nfs nfs defaults, noexec, nosuid, nofail О 0
— # Server — Samba server (IP или имя, если указано в файле hosts)
— # share— имя директории общего доступа
— # Samba
//server/share /media/samba cifs credentials=/etc/samba/credentials, uid= 1000, gid= 100, no fail 0 0
— # Server — сервер Samba (IP или имя, если указано в файле hosts)
— # share — имя директории общего доступа
— # credentials — ссылка на файл авторизации, содержащий данные в виде двух строк:
— # username=user
— # password=password
— # создателем этого файла должен быть root, права доступа устанавливаются 400 (sudo chown root.root /etc/samba/credentials && sudo chmod 400 /etc/samba/credentials).
Для сетевых дисков последний параметр всегда равен 0 (проверка средствами fsck не проводится).
Следующим шагом подготовки ОС является установка и настройка сервиса upmpdcli [91], который является DLNA/UPnP/OpenHome-шлюзом к MPD и соответственно включает медиарен-дерер для удалённой трансляции аудиоданных на МК.
Сначала подключаем дополнительный репозитарий
sudo add-apt-repository ppa:jean-francois-dockes/upnpp 1.
Затем устанавливаем сервис upmpdcli sudo apt-get install -у upmpdcli.
После установки демон upmpdcli становится автоматически активным и, как правило, не требует проведения каких-либо дополнительных настроек.
Рекомендуется проверить его состояние с помощью команд sudo systemctl is-enabled upmpdcli и sudo systemctl status upmpdcli. Результат вывода второй команды для корректно работающего сервиса показан на рис. 44, а внешний вид главного окна BubbleUPnP с доступными настройками рендерера UPnP — на рис. 45. Смена рендерера доступна прямо в процессе воспроизведения.
При желании можно изменить имя рендерера в параметре avfriendlyname файла конфигурации /etc/upmpdcli.conf.
В последнюю очередь установим веб-клиент AMPD [92], который обеспечит выполнение функций мониторинга и управления MPD посредством веб-интерфейса. Этот веб-клиент основан на Java и требует для работы наличия в системе среды исполнения Oracle Java Runtime Environment (JRE) не ниже 11-й версии. Поэтому предварительно устанавливаем комплекс программного обеспечения OpenJDK 11 с помощью команды sudo apt install openjdk-11 -jdk.
Далее скачиваем последнюю актуальную версию со страницы релизов проекта AMPD [93]. На момент написания статьи последняя стабильная версия — ampd-1.6.7. Установки AMPD не требует, единственный исполняемый файл является готовым приложением JAR и имеет соответствующее расширение. Его удобно разместить непосредственно в домашней директории текущего пользователя и установить права доступа 755. Запуск AMPD при этом осуществляется командой java -jar /home/user/ampd-1.6.7.jar, где user — имя текущего пользователя.
Чтобы обеспечить запуск приложения Linux в качестве демона, требуется создать соответствующий файл описания в директории /etc/systemd/system и зарегистрировать его в системе как сервис. Создадим в указанной директории файл с именем ampd.service, правами 644 и содержимым, приведённым в табл. 3.
Путь к исполняемому файлу в секции Service должен быть абсолютным и соответствовать его расположению. Для регистрации демона после созда-
[Unit] Таблица 3
Description=AMPD Run Service
After=multi-user.target
[Service]
Type=ldle
ExecStart=java -jar /home/user/ampd-1,6.7.jar
[Install]
WantedBy=multi-user.target
ния или изменения файла описания следует выполнить команду sudo systemctl daemon-reload. Затем активируем его с помощью уже известной нам команды sudo systemctl enable ampd.service и проверяем состояние: sudo systemctl status ampd.service.
Результат вывода команды проверки статуса AMPD показан на рис. 46. Этот вывод является непрерывным. Обращение к веб-серверу в локальной сети осуществляется с помощью любого интер-нет-браузера по IP-адресу медиасервера с обязательным указанием после него номера порта 8080. IP-адрес МК для подключения к веб-серверу или по протоколу SSH можно узнать в административной панели роутера локальной сети или просто подключить монитор к МК и войти в консоль. Внешний вид главной страницы интерфейса AMPD показан на рис. 47. При нажатии на кнопку Settings будет доступна страница настроек с закладками Frontend, Backend и Admin. Настройки раздела Frontend могут быть изменены через интерфейс и сохраняются в браузере клиента. Настройки раздела Backend указываются в файле настроек application, properties, который при необходимости размещается в одной директории с исполняемым файлом и считывается при запуске программы. Файл application.properties с настройками по умолчанию можно скачать в домашнюю директорию текущего пользователя командой:
wget
https://raw.githubusercontent.com/ rainOr/ampd/master/src/main/ resources/application. properties-O -/application, properties.
В разделе Admin доступны функции обновления БД (Update) и сканирования источников (Rescan), которые рекомендуется запускать после изменения содержимого директории music_ directory MPD или директории, монтируемой к этой точке. Следует учесть, что обновление БД занимает некоторое время, при этом МК выключать не рекомендуется, а для получения представления о ходе этого процесса нужно обновлять страницу настроек в браузере, так как динамически изменение данных на странице не отображается. По завершении обновления БД изменятся сведения о его дате и времени Last update time.
Перейдём к описанию процесса физического подключения внешнего I2S DAC к интерфейсному разъёму GPIO МК Orange Pi PC. Соответствие выводов интерфейса GPIO сигналам I2S приведено в табл. 4.
Случается, что после включения медиасервера вместо нормального звучания может быть слышен белый или модулированный шум, напоминающий звук с аудиовыхода SPDIF. Это объясняется сбоем в последовательности загрузки сервисов. Для устранения этого достаточно перезапустить демон MPD командой sudo systemctl restart mpd.service. Если вы намерены использовать доступ через UPnP, то рекомендуется подобным образом перезапустить и демона upmpdcli. Иногда в таких случаях достаточно просто остановить и снова запустить воспроизведение нажатием соответствующих клавиш в интерфейсе AMPD.
Питание Raspberry Pi, Orange Pi и аналогичных МК удобно и недорого осуществлять от "быстрого" зарядного устройства (ЗУ) для смартфона. При отсутствии обмена данными между потребителем и ЗУ на выходе последнего присутствует только постоянное напряжение +5 В, а номинальный ток нагрузки современного ЗУ (1...3А и более) вполне обеспечивает потребности микрокомпьютера.
В дополнение к теме высококачественных источников звука отметим нестандартный метод цифроаналогового преобразования, вернее, результирующей обработки, "шлифовки" выходного сигнала DAC — создание промежуточной записи на магнитной ленте. Суть данного метода состоит в том, что сигнал, например, с выхода DSD DAC, записывается с помощью высококачественного аналогового магнитофона. В ходе магнитной записи, по самой физике процесса, все высокочастотные артефакты преобразования практически полностью подавляются, поскольку, в первом приближении, на ленту не может быть записан сигнал, половина длины волны которого меньше ширины рабочего зазора магнитной головки. На ленте практически оказывается первая аналоговая копия оригинальной записи, которая и предназначается для прослушивания. Этот метод можно назвать двухстадийным электромагнитным цифроаналоговым преобразованием. Следует помнить, что неизбежным следствием его применения является ухудшение интегрального показателя THD+N до типично "аналоговых" значений. Осуществление "физической" фильтрации продуктов преобразования вовсе не уменьшает требования к параметрам ФНЧ на выходе DAC. При неудовлетворительной первичной фильтрации, вследствие взаимодействия артефактов преобразования с ВЧ-сиг-налом подмагничивания, возможно появление комбинационных частот в звуковом диапазоне. Эти же артефакты могут оказывать влияние на величину тока подмагничивания и нарушать линейность процесса записи. Кроме того, отдельной общей проблемой магнитных лент является спад АЧХ и перегрузочной способности на высших частотах звукового диапазона. Однако вспомним, что применение систем шумоподавления Dolby S [94] позволяет получить динамический диапазон не менее 85 дБ при скорости движения ленты 4,76 см/с. Вторая проблема в значительной степени решается введением систем адаптивного подмагничивания Dolby НХ Pro, СДП, САДП [95—98] и/или использованием высоких скоростей записи (не ниже 19,05 см/с). К чисто механическим особенностям магнитной записи следует отнести, главным образом, проявление детонации, близкой к цифровому джиттеру.
Говоря о ленточных магнитофонах, ради исторической справедливости необходимо упомянуть стандарты цифровой магнитной записи R-DAT и S-DAT, несостоявшихся "убийц" CD [99]. Рассматривать их в основной части статьи несколько неуместно в силу их малой актуальности в настоящее время, однако полного забвения они явно не достойны. Форматы DAT исключительно мощные и обладавшие на момент их создания (1987 г.) большими возможностями и потенциалом. Так, в стандартном режиме DAT предусматривал запись методом РСМ с разрешением 16 бит при частоте дискретизации 48 кГц, что обеспечивало качество "без потерь" несколько выше, чем CD-DA. Запись в R-DAT велась на магнитную ленту шириной 3,81 мм с металлопорошковым рабочим слоем с помощью вращающихся магнитных головок по наклонно-строчному принципу с азимутальным наклоном. Для коррекции ошибок применялось помехоустойчивое кодирование с помощью двойного кода Рида-Соломона, а также интерполяция нескорректированных ошибок. По краям ленты располагались служебные дорожки для записи служебных данных, в частности таймкода, что давало возможность синхронизировать магнитофоны R-DAT с другим профессиональным оборудованием. При перемотке лента не отводилась от блока головок, что позволяло осуществлять быстрый автоматический поиск фрагментов с обработкой данных специального субкода. В версии формата S-DAT запись производилась на параллельные дорожки, расположенные по ширине ленты, с применением неподвижной "сэндвич"-го-ловки. Качественные параметры обоих методов записи DAT были идентичны. R-DAT заметно выигрывал в длительности, однако достигалось это ценой повышения сложности ЛПМ. К сожалению, появление DAT совпало с периодом широчайшей экспансии компакт-кассет и началом эпохи CD.
В общем-то DAT были призваны положить конец их триумфальному шествию, и как минимум составить достойную конкуренцию на массовом рынке. Но как раз интересам массового пользователя более всего отвечали кассетные магнитофоны, сочетавшие в себе доступность, мобильность, удобство и хорошее качество звучания. Аудиофилов в те времена ещё было не так много, а ценители высококачественного звука ориентировались на вполне ещё распространённые катушечные магнитофоны и уже прочно занявшие свою нишу CD. Тем не менее, DAT были по достоинству оценены профессионалами в сфере звукозаписи, так как, помимо высочайшего качества, предоставляли возможности непосредственной работы со звуковым материалом, аналогично привычным студийным магнитофонам. Но решающим фактором в несостоявшейся борьбе форматов магнитной и оптической цифровой звукозаписи стало стремительное распространение персональных компьютеров и, как следствие, резкий всплеск интереса к CD, как удобному и универсальному носителю информации. Сопутствующее быстрое развитие ПО и цифровых форматов хранения и передачи данных и способов их обработки обеспечило новыми инструментами профессиональную часть аудитории. Так объективно сложившиеся обстоятельства затормозили, а затем окончательно остановили развитие DAT.
В завершение приведём некоторые соображения по поводу субъективной комплексной оценки звукового тракта. У автора имеются всего два абсолютно субъективных,совершенно чётких критерия оценки качества звучания, применяемых в случае безусловного предварительного соответствия объективно измеряемых параметров устройств ряду очевидных требований, таких как ширина диапазона эффективно воспроизводимых частот, величина и спектр КНИ и др. Первым критерием, служащим для оценки точности и глубины формирования звуковой панорамы (или, как теперь модно говорить, "стены" звука), является чёткая пространственная локализация трёх виолончелей в композициях группы Apocaliptica, исполняющих свои музыкальные произведения преимущественно в жанре "симфонический металл". Вторым критерием, определяющим детальность и слитность воспроизведения (а также ряд сопутствующих субъективных параметров, например "прозрачность"), является возможность выделить на слух из мелодически-шумового хаоса композиций Darkspace (жанр "эмбиент-блэк-метал") фрагменты овердрайв-соло-гитары, характерные для группы Children Of Bodom, играющей в жанрах "мелодик-дэт-ме-тал" и "пауэр-метал”. Учитывая высокий относительный уровень жёсткости перечисленных музыкальных стилей в отношении АЧХ и ФЧХ и насыщенность их шумовыми составляющими, результат прослушивания можно с высокой степенью достоверности распространить на более "спокойные" стили. В эти критерии предсказуемо не вписываются композиции экстремальных стилей типа "грайнд-кор" (группа Napalm Death), однако и их прослушивание становится более комфортным, если это понятие вообще применимо к подобным стилям.
Здесь уместно позволить небольшое лирическое, но важное отступление на тему жёстких музыкальных стилей. "Металл для тех, кому надоел хард-рок. Дэт-метал для тех, кому надоел металл. Грайндкор для тех, кому надоела ... музыка".
Исходя из этого, можно считать, что перед нами заведомо хороший УМЗЧ и звуковой тракт, в целом, если мы в композиции стиля грайндкор услышим мелодию, в частности, если это композиция You Suffer ("Страдание") группы Napalm Death, занесённая в Книгу рекордов Гиннеса как самое короткое музыкальное произведение из когда-либо написанных, длительностью всего 1,316 с [99]. И это не шутка, а вполне рабочий метод субъективной оценки качества, который не менее, если не более, информативен, чем классический поиск нюансов звучания акустической гитары в Private Investigations Dire Straits или овердрайва в Child in Time Deep Purple.
Ещё одно отступление, напрямую касающееся феномена "лампового" звучания. На взгляд автора, наиболее полно данный феномен проявляется именно при прослушивании соло-партий овердрайв гитар. И это имеет достаточно простое объяснение, изначально "фирменное" звучание электрогитар, очевидно, было рассчитано на то, что в
ламповом УМЗЧ на стороне слушателя звук получит дополнительные искажения, которые и требовались для завершения формирования характерного тембра. Даже неискушённому слушателю сразу заметна разница в звучании классической овердрайв гитары на полупроводниковом и ламповом УМЗЧ. Во втором случае звук приобретает законченную виолончельную окраску, чем "ламповый" овердрайв и отличается от "транзисторного" шумоподобного эффекта дисторшн.
ЛИТЕРАТУРА
79. Почему мы не используем Wi-Fi для беспроводной передачи звука. — URL: https://www.iguides.ru/main/other/ pochemu_my_ne_ispolzuem_wi_fi_dlya_ peredachi_besprovodnogo_zvuka/ (10.12.23).
80. LDAC (codec). — URL: https://en. Wikipedia.org/wiki/LDAC_(codec) (10.12.23).
81. LHDC (codec). — URL: https://en.
Wikipedia.org/wiki/LHDC_(codec) (10.12.23).
82. WiFi Analyzer. — URL: https://play. google.com/store/apps/details?id=abdelra hman.wifianalyzerpro (10.12.23).
83. BubbleUPnP for DLNA/Chromecast. — URL: https://play.google.com/store/apps/ details?id = com.bubblesoft. android, bubbleupnp (10.12.23).
84. GNOME/gupnp-tools. — URL: https:// github.com/GNOME/gupnp-tools (10.12.23).
85. FFmpeg. — URL: https://ffmpeg.org/ (10.12.23).
86. Music Player Daemon documentation. User’s Manual. — URL: https://mpd. readthedocs. io/en/stable/user.html (10.12.23).
87. Ubuntu manuals. — URL: https:// manpages.ubuntu.com/manpages/trusty/ man5/mpd.conf.5.html (10.12.23).
88. ReplayGain. — URL: https://wiki. hydrogenaud.io/index.php?title=Replaygain (10.12.23).
89. Fstab. Introduction to fstab. — URL: https://help.ubuntu.com/community/Fstab (10.12.23).
90. Ubuntu Manpages, mount — mount a filesystem. — URL: https://manpages.ubuntu. com/manpages/mantic/en/man8/mount.8. html (10.12.23).
91. An UPnP front-end to MPD, the Music Player Daemon. — URL: https://github.com/ triplem/upmpdcli (10.12.23).
92. A web-based MPD client. — URL: https://github.com/rainOr/ampd (10.12.23).
93. rainOr/ampd Releases. — URL: https:// github.com/rainOr/ampd/releases (10.12.23).
94. Системы шумопонижения Dolby. — URL: https://ru.wikipedia.org/wiki/CMCTeMbi_ шумопонижения 0о1Ьу (10.12.23).
95. Основы электроакустики. Система динамического подмагничивания Dolby НХ Pro. — URL: https://audioakustika.ru/podmag
(10.12.23).
96. Сухов Н. Динамическое подмагничивание. — Радио, 1983, № 5, с. 36—40.
97. Сухов Н. СДП-2. - Радио, 1987, № 1, с. 39-42; № 2, с. 34-37.
98. Сухов Н. Адаптивное динамическое подмагничивание. Радиоежегодник-91. — М., Патриот, 1991, с. 7-30, ISSN 0235-5132.
99. Digital Audio Таре. — URL: https:// ru.wikipedia.org/wiki/Digital_Audio_Tape (10.12.23).
