Передача данных в портативных мультимедиа-плеерах: проприетарные протоколы

В прошлом портативные плееры воспроизводили музыку с распространенных сменных носителей и не нуждались в подключении к чему бы то ни было, кроме наушников

До недавнего времени ПК был для них единственным источником контента. При этом возникала необходимость в механизме сопряжения портативного плеера и компьютера. Задача заключалась в передаче данных в цифровой форме с одного носителя (в ПК) на другой (в плеере) в формате, принятом в компьютерной отрасли.

Контент необходимо перенести с компьютера, в котором он обычно хранится на жестком диске форм-фактора 3.5”, на носители портативных плееров: флэш-память, жесткие диски форм-фактора 1” и 1.8”

Следовательно, нужно задействовать какой-либо компьютерный интерфейс передачи данных.

В любом подобном интерфейсе можно выделить два уровня. Первый – физический, т.е. непосредственно провода, разъемы, микросхемы и т.п. Второй – программный, это, условно говоря, набор инструкций и алгоритмов, согласно которым осуществляется обмен данными на физическом уровне. Этот программный уровень часто называют протоколом. Сегодня мы будем в основном говорить именно о нем. Для пользователя он является «лицом» интерфейса, его возможности и недостатки определяют удобство или сложности в эксплуатации устройства в целом.

Для полноценной эксплуатации протокола необходимо наличие двух программных компонентов. Во-первых, это драйвер, занимающийся непосредственно сопряжением портативного устройства и ПК на программном уровне. Во-вторых, это программное обеспечение, позволяющее пользователю управлять протоколом и использовать его для своих нужд. ПО, строго говоря, не является непосредственной частью протокола. Но без его наличия само существование протокола теряет смысл. Поэтому в рамках данной статьи мы будем рассматривать ПО как неотъемлемую часть рассматриваемых протоколов.

Любой программный протокол использует драйверы и ПО, хотя реализация этих компонентов в каждом конкретном случае может сильно отличаться. Удачность протокола можно условно вычислить по формуле: возможности минус неудобства. Под возможностями понимается спектр доступных функций. Неудобства обычно включают в себя непрозрачность при использовании, неудобство в установке, сложность в освоении, ограниченную совместимость.

По меркам цифровой портативной техники MP3-плееры – уже достаточно немолодой класс устройств. Они появились в то время, когда инфраструктура ПК была совершенно не готова к роли компьютера как мультимедиа-хоста. И на физическом, и на программном уровне в этой области еще не существовало распространенных и стандартизированных решений, они лишь находились в разработке, готовились к выходу на рынок или существовали в штучных количествах. В схожем положении оказались другие родственные классы портативных устройств: мобильные накопители, цифровые камеры, сотовые телефоны, КПК. Все эти разновидности мобильной техники появились примерно в одно и то же время, во второй половине 90-х годов. Своим появлением они вызвали необходимость разработки единых стандартных протоколов сопряжения ПК с портативной техникой.

На физическом уровне все было относительно ясно. Первые портативные устройства были вынуждены использовать COM и LPT – других широкодоступных интерфейсов в то время просто не было.

LPT-разъем до сих пор можно найти на большинстве ПК

Так, именно физический интерфейс LPT использовался родоначальниками MP3-плееров, Saehan MpMan и Diamond Rio. Этот период можно назвать «кустарным», разработчикам приходилось использовать интерфейсы и протоколы, изначально созданные для совершенно иных задач.

Однако мучаться в оковах медленных и неудобных интерфейсов новому поколению портативного аудио пришлось недолго: уже в следующем 1999 году производители представили широкий спектр устройств, использующих новый стандарт: USB, Universal Serial Bus.

Какое-то время наблюдалась видимость борьбы между USB и распространенным главным образом на компьютерах Apple Macintosh протоколом Firewire.

Война Firewire-USB в портативных плеерах: от iPod 1G – только Firewire – до iPod 5G – только USB

Однако основная масса портативного аудио быстро и безболезненно пересела на Universal Serial Bus, закрыв, по крайней мере в рамках проводных решений, вопрос с передачей данных на физическом уровне.

Далеко не так просто сложилось все для программных протоколов. В тот короткий период, когда производители вынужденно использовали COM и LPT, программные протоколы были исключительно их собственной разработки. Никакими другими они быть, собственно, и не могли, т.к. и COM-, и LPT-интерфейсы создавались в свое время, естественно, совсем не для передачи мультимедийных файлов на портативные цифровые проигрыватели. Разрабатывать драйверы и программные оболочки для последних кроме самих разработчиков было некому, а о стандартизации речи и вовсе не шло.

Но и появление USB не решило проблему. Индустрия в первую очередь озаботилась созданием стандартных протоколов для мобильных накопителей, цифровых камер. Ситуация с MP3-плеерами была вообще не ясна: запретят их или нет, а если все же не запретят, то какими особенностями должны обладать протоколы, чтобы форум SDMI дал добро. В подобных условиях разработка программных протоколов по-прежнему лежала на плечах разработчика устройства. Так продолжалось не менее четырех лет, пока, наконец, в плеерах не начали появляться стандартные протоколы передачи данных. Эти годы были временем господства первой разновидности программных протоколов – проприетарных или закрытых.

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

Проприетарный протокол на примере RCA-Thomson Lyra. Используется собственный драйвер (PDP2222.SYS), который необходимо устанавливать отдельно на каждый ПК, к которому планируется подключать плеер

Это создает множество неудобств для пользователя. Ни о какой прозрачности речи нет – пользователь сам вынужден вручную устанавливать драйверы и ПО для своего плеера. При этом могут возникать различные сложности, к примеру, если покупатель по ошибке подключит плеер к ПК раньше установки драйверов.

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

О совместимости тоже лучше забыть: драйверы и ПО работали лишь с данной моделью плеера (в лучшем случае – с несколькими моделями от данного производителя), а плеер мог работать только с ПК, на котором установлены данные драйверы и ПО. Возможности программных оболочек поначалу были совсем скудны и ограничивались исключительно копированием аудиофайлов в память плеера. Позже появилось разнообразие в способах копирования контента на плеер: индивидуально по трекам или синхронизацией содержимого памяти плеера с содержимым скомпонованной из аудиофайлов, находящейся на ПК библиотеки. Отдельные программные оболочки поддерживали лишь один из этих способов. Со временем ПО обретало дополнительные возможности, к примеру, копирование любых файлов, а не только поддерживаемых плеером, что давало возможность использования его как накопителя (функция получила прозвище Data Taxi). Однако тот факт, что для данной операции была обязательна установка на ПК драйверов и ПО, серьезно снижал полезность этой функции. О высоких эстетических качествах, безукоризненной работе и хорошей эргономике оболочек речь, как правило, и вовсе не шла. Пользователи тогда были в массе своей людьми суровыми и неизбалованными: копируются файлы на плеер – и ладно.

Через проприетарные системы прошло большинство производителей: iriver, Rio Audio, Creative, Cowon, Mpio и т.д. У каждого из этих производителей в свое время были и свои драйверы, и свое программное обеспечение, у кого-то более, у кого-то менее удачное. В любом случае, сменив плеер на устройство другого производителя, пользователь был вынужден приспосабливаться к новой оболочке с ее логикой и особенностями. Многие производители продолжают и сегодня комплектовать свои устройства этими программами как альтернативой стандартам MSC/UMS или MTP-решениям.

Проприетарные оболочки-менеджеры: Iriver Music Manager, Cowon JetAudio, Mpio Manager, Creative Play Center

Зоопарк всевозможных оболочек не мог устраивать потребителей (с существованием кучи разношерстных драйверов они еще могли смириться). Не устраивал он и производителей, особенно небольших, не имевших ресурсов на разработку качественного программного обеспечения. Поэтому в 1999 – начале 2000-х годов определенную популярность обрело использование оболочек сторонних производителей.

Среди них можно выделить программу MusicMatch Jukebox.

Интерфейс MusicMatch Jukebox

До появления iTunes для Windows PC именно она использовалась здесь для работы с Apple iPod. Работала она и с плеерами других производителей, таких, как RCA-Thomson.

Программы типа MusicMatch Jukebox были первыми ростками стандартизации. Они позволяли использовать плееры разных производителей без установки дополнительного ПО для каждого из них. Решение не было безупречным, это был лишь шаг от разномастных протоколов и оболочек к стандартизированным решениям. В данном случае же был стандартизирован только интерфейс управления протоколом, установка отдельных драйверов для каждого устройства по-прежнему оказывалась необходимой. Сами оболочки не входили в состав операционной системы, их было необходимо устанавливать отдельно, из Интернета или с сопутствующего CD. Их функциональность, стабильность работы и удобство зачастую также вызывали вопросы. Поддерживались далеко не все плееры, что вынуждало производителей комплектовать свои устройства плагинами для популярных программ-менеджеров.

Доступно для скачивания на сайте RCA-Lyra: в первую очередь плагин для MusicMatch Jukebox и только потом собственная оболочка Lyra DJ

Обычно со временем программа «толстела», обрастала ненужными пользователю функциями, рекламой, требовала все больше ресурсов.

Еще одна популярная в прошлом оболочка – RealJukebox

Одновременно росло давление конкурентов: в 2001 году Windows Media Player вошел в стандартную поставку Windows XP, в 2003 году появился iTunes для Windows. Небольшие азиатские компании в 2002-2003 году также нашли хорошую замену этому ПО – открытый протокол MSC/UMS. В результате оболочки типа MusicMatch Jukebox сошли со сцены, чтобы уступить место протоколам нового поколения. Но их наследие не пропало даром: модель «одна оболочка для разных плееров» во многом унаследована системой Microsoft PlaysForSure.

Одна черта проприетарных систем, однако, позволила им прожить на отдельных рынках дольше разумного. Их закрытость создавала препятствия при использовании плеера для свободного переноса данных с ПК на ПК, то есть, по версии RIAA, при использовании его как орудия цифрового пиратства. На проблемных рынках, наподобие американского, компании, не желающие привлекать к себе лишнего внимания, продолжали придерживаться проприетарного подхода даже после распространения универсальных решений.

На сайте iriver непроприетарные прошивки до сих пор отмечаются особо, как UMS или MTP

Тут можно вспомнить, к примеру, iriver или Creative. Плееры iriver вообще выпускались в двух вариантах: для рынка США – работающие через проприетарный протокол, для других – через открытый MSC/UMS. Такая «жизнь после смерти» для закрытых протоколов продолжилась вплоть до выхода в 2004 протокола MTP, который, будучи относительно универсален, устроил и звукозаписывающие компании.

Период 2002-2004 гг. был переходным от «темных веков» закрытых систем к относительной открытости современных протоколов. Сегодня чистые проприетарные протоколы полностью вышли из употребления.