text: MIDI ( — «цифровой интерфейс музыкальных инструментов») — стандарт цифровой звукозаписи на формат обмена данными (интерфейс) между электронными музыкальными инструментами. Интерфейс позволяет единообразно кодировать в цифровой форме такие данные как нажатие клавиш, настройку громкости и других акустических параметров, выбор тембра, темпа, тональности и др., с точной привязкой во времени. В системе кодировок присутствует множество свободных команд, которые производители, программисты и пользователи могут использовать по своему усмотрению. Поэтому интерфейс MIDI позволяет, помимо исполнения музыки, синхронизировать управление другим оборудованием, например, осветительным, пиротехническим и т. п. Последовательность MIDI-команд может быть записана на любой цифровой носитель в виде файла, передана по любым каналам связи. Воспроизводящее устройство или программа называется синтезатором (секвенсором) MIDI и фактически является автоматическим музыкальным инструментом. История К концу 1970-х годов получили распространение музыкальные синтезаторы. Они представляли собой наборы генераторов звуковых частот, управляемых напряжением. Нажатие клавиши на клавиатуре синтезатора включало генератор, частота которого задавалась напряжением от регулятора тональности данной клавиши. Количество отдельных генераторов определяло количество тонов синтезатора, которые могут звучать одновременно. Конкретные модели синтезаторов могли иметь особенности звучания и характерные специальные эффекты. Реализовать управление всей гаммой потенциальных возможностей синтеза звука в рамках одного аналогового устройства было невозможно. Рабочее место музыканта того времени могло состоять из нескольких разнородных синтезаторов; работать с таким "зоопарком" было сложно. В начале 80-х годов необходимость увеличения гибкости управления разнородными синтезаторами стала очевидной, а развитие электроники подсказало путь решения проблемы: цифровое программное управление. Компании-производители синтезаторов удачно смогли договориться о разработке и поддержке единого стандарта на интерфейс управления синтезаторами, который и появился в 1982 году. Идеология стандарта подразумевала разделение органов управления и аппаратуры синтеза звука. Интерфейс MIDI фактически стал средством передачи положения клавиш и регуляторов от музыкальной клавиатуры к аппаратуре синтеза звука. Теперь музыкант мог с одной клавиатуры управлять несколькими синтезаторами разных типов и фирм-изготовителей. Более того, цифровой формат передачи позволил дополнить аппаратуру секвенсорами — устройствами, запоминающими наигранную мелодию. Теперь музыкант мог записывать композиции или их части, микшировать без потери качества звука и использования сложных студийных магнитофонов того времени. Стандарт быстро завоевал популярность. Постепенно дополняясь новыми возможностями, он не потерял актуальности и в наше время. Стандарт на аппаратуру и программное обеспечение Физический уровень интерфейса представляет собой токовую петлю (что обеспечивает гальваническую развязку и безопасность при соединении устройств между собой). Передатчик активный, 5 мА, наличие тока обозначает 0, нет тока — 1. Разъём 5-штырьковый DIN 41524. Приёмопередатчик асинхронный, скорость 31250 бод/с, формат 8-N-1. Устройства соединяются кабелями. Выход данных ведущего устройства (разъём MIDI OUT) соединяется со входом ведомого устройства (разъёмом MIDI IN). Данные по кабелю передаются только в одном направлении, от ведущего устройства к ведомому (например, от музыкальной клавиатуры к синтезатору). Для двусторонней передачи данных требуется второй кабель. Большая часть MIDI-устройств не копируют сообщения с входного на выходной разъём. Существует третий тип разъёма (MIDI THRU), на котором дублируется поток данных со входа. Этот тип разъёма позволяет соединить в цепочку произвольное количество синтезаторов. Однако такой тип разъёма есть не у всех синтезаторов. Кроме того, MIDI-устройства могут объединяться с помощью устройств MIDI thru box (хабов), которые ретранслируют входной сигнал на несколько выходов. Стандарт описывает аппаратный интерфейс, который позволяет соединять электронные музыкальные инструменты и компьютеры различных производителей, описывает протоколы связи для передачи данных от одного устройства к другому. MIDI-устройства могут взаимодействовать с программными приложениями, используя коммуникационный протокол MIDI. Используя соответствующий программный MIDI-секвенсор, внешние MIDI-устройства могут посылать информацию на синтезатор звуковой карты. MIDI базируется на пакетах данных, каждый из которых соответствует MIDI-событию (), от нажатия клавиши до простой паузы, эти события разделяются по каналам. Сложная среда MIDI может включать различную аппаратуру, причём каждая часть системы будет отвечать за события на соответствующем канале. Альтернативным вариантом может быть одиночный синтезатор, который сам может управлять всеми каналами. Формат музыкальных файлов В отличие от других форматов это не оцифрованный звук, а наборы команд (проигрываемые ноты, ссылки на проигрываемые инструменты, значения изменяемых параметров звука), которые могут воспроизводиться по-разному в зависимости от устройства воспроизведения. Удобство формата MIDI как формата представления данных позволяет реализовывать устройства, производящие автоматическую аранжировку по заданным аккордам, а также приложения 3D-визуализации звука. Кроме того, такие файлы, как правило, имеют на несколько порядков меньший размер, чем оцифрованный звук сравнимого качества. Стандартный MIDI-файл (SMF — Standard MIDI File) — это специально разработанный формат файлов, предназначенный для хранения данных, записываемых и/или исполняемых секвенсором, секвенсор может быть как программой для компьютера, так и аппаратно выполненным модулем. В этом формате хранятся стандартные MIDI-сообщения (то есть статус-байты и соответствующие им байты данных), а также временные метки или маркеры для каждого сообщения (то есть последовательности байтов, указывающие, какое количество условных единиц времени (импульсов, тиков) необходимо подождать перед тем, как исполнить следующее событие MIDI). Этот формат позволяет сохранять информацию о темпе, временном разрешении, выраженном в количестве тиков на одну четвертную длительность (или во временных единицах, приходящихся на одну секунду, в формате SMPTE), обозначения размера, информацию о музыкальных ключах, а также хранить названия треков и паттернов. Формат предусматривает возможность сохранения в одном файле нескольких паттернов и треков таким образом, что программы-приложения могут выбирать из всего набора хранимой информации ту, которая будет понятна данному приложению. Как правило, трек представляет собой аналог музыкальной партии, например партии трубы. Аналогом паттерна может служить весь набор партий, взятых вместе, например совокупность партий трубы, ударных, фортепиано и т. д., которые используются в данном произведении или его части и исполняются одновременно. При разработке формата предусмотрели возможность для любого секвенсора читать и записывать файл таким образом, чтобы, с одной стороны, не потерялись его данные, а с другой стороны, чтобы формат был достаточно гибким, приложения могли сохранять в файлах свою специфическую информацию, понятную только им, но не понятную другим программам-приложениям, причём при загрузке файлов MIDI непонятная другим программам-приложениям информация не приводит к недоразумениям, а просто игнорируется. В этом смысле формат файлов MIDI можно сравнить с форматами текстовой информации. Различные программы-секвенсоры способны читать MIDI-файлы, подобно тому, как различные текстовые редакторы читают ASCII-файлы, которые могут содержать вспомогательную информацию, понятную лишь данному редактору. Но в отличие от ASCII-файлов MIDI-файлы содержат цифровую информацию, и к тому же эта информация сохранена в виде записей, то есть групп байтов, которые содержат свой заголовок, состоящий из идентификатора записи и длины записи. Эти записи могут форматироваться, загружаться, игнорироваться и т. д. независимо друг от друга. Для осуществления работы с записями программы-приложения используют дополнительную информацию, записываемую в MIDI-файл. Например, возможно, программа «захочет» сохранить флаг, указывающий на то, что пользователь установил включённым звук метронома. Программа может вставить этот флаг в MIDI-файл таким образом, что другая программа-приложение сможет пропустить этот флаг без внимания. В будущем, возможно, существующий формат MIDI будет расширен и появятся новые типы записей. Новые программы для работы с MIDI-файлами будут распознавать и новые типы записей. Однако старые MIDI-файлы могут быть воспроизведены в своём исходном виде. Формат MIDI задуман таким образом, что с его расширениями будут совместимы более ранние его версии. Что такое запись? Данные всегда хранятся в виде записей. В одном MIDI-файле могут сосуществовать несколько различных записей. Каждая запись может иметь свой собственный размер, то есть количество байтов в различных записях может быть различно. Данные, хранящиеся в одной записи, связаны друг с другом определённым образом. Запись — это по своей сути набор взаимосвязанных байтов. Каждая запись начинается с указания её идентификатора, который состоит из четырёх букв, то есть из четырёх ASCII-байтов. Этот идентификатор указывает, какой тип записи представлен в содержащихся в записи байтах данных. Последующие за идентификатором четыре байта (каждый из которых состоит из 8 бит) образуют 32-битное значение, указывающее длину (или размер) данной записи. Все записи должны начинаться с этих двух полей: идентификатора записи и размера записи. Эти два поля, занимающие всего 8 байт, образуют заголовок записи. Длина записи не учитывает 8 байт заголовка. Байты длины просто указывают количество байтов в записи, которые следуют за заголовком. Приведём пример заголовка (здесь байты представлены в шестнадцатеричном виде): 4D 54 68 64 00 00 00 06 Отметим, что первые четыре байта заголовка образуют MThd (то есть первыми четырьмя байтами заголовка являются ASCII значения букв 'M', 'T', 'h', и 'd'). Последующие 4 байта говорят нам, что в записи будет ещё 6 байтов, следующих за заголовком. После этих шести байтов должен следовать следующий заголовок записи или же конец MIDI-файла. Фактически все MIDI-файлы начинаются с заголовка MThd и именно этот факт является указанием на то, что мы имеем дело со стандартным MIDI-файлом). Запись MThd Запись MThd имеет длину 6 байт и следует за идентификатором MThd и 32 битным числом (00 00 00 06). Рассмотрим подробно эти 6 байтов, следующих за 8-байтным заголовком в MThd записи. Первые два байта данных содержат информацию о формате или типе MIDI-файла. Существует три различных типа (формата) MIDI-файлов: Тип 0 означает, что файл содержит MIDI-данные, записанные на одном треке, который, вероятно, объединяет в себе все 16 MIDI-каналов. Если ваш секвенсор сохраняет MIDI-данные в одном единственном блоке памяти, из которого он их воспроизводит, то такой секвенсор будет читать и записывать MIDI-данные именно в этот тип MIDI-файлов. Файл типа 1 подразумевает, что в нём содержатся несколько (но, возможно, и всего один) одновременно воспроизводимых треков, каждый, вероятно, представляет свой собственный MIDI-канал. Все треки начинают воспроизводиться в один и тот же нулевой момент времени. Все треки, взятые вместе, образуют паттерн. Если ваш секвенсор разделяет в памяти различные MIDI-треки и хранит их в различных блоках и воспроизводит различные треки одновременно, то такой секвенсор будет читать и писать файлы типа 1. Файлы типа 2 содержат один или несколько независимых треков, каждый такой трек образует свой собственный паттерн. Если ваш секвенсор разделяет MIDI-данные на несколько блоков в памяти, но воспроизводит лишь один-единственный блок в данное время, но не воспроизводит их одновременно, когда каждый блок памяти содержит отдельную пьесу или её кусок, то этот секвенсор будет читать и записывать MIDI-файлы второго типа. Следующие два байта определяют количество треков, хранимых в файле, эти два байта обозначаются NumTracks. Естественно, что для файлов типа 0 значение NumTracks всегда равно 1. Для двух оставшихся типов возможны другие значения. Оставшиеся два байта указывают величину временного разрешения, то есть количество временных импульсов (временных тиков), приходящихся на одну четвертную длительность, что в виде аббревиатуры английских слов обозначается как PPQN. Например, если ваш секвенвер использует 96 ppqn, то соответствующее поле в заголовке записи будет иметь шестнадцатеричное значение 00 60. Напротив, если первый байт рассматриваемого поля заголовка отрицателен, то соответствующий формат использует стандарт SMPTE вместо стандарта PPQT. В этом случае первый байт поля временного разрешения принимает значения −24, −25, −29 или −30, что соответствует четырём стандартным типам в стандарте SMPTE. Второй байт (положительная величина) указывает величину разрешения во фрейме. Стандартные величины разрешения фрейма представляют собой 4 (временной код MIDI), 8, 10, 80 (SMPTE) или 100. Задавая значения фреймов −25 и величину внутрифреймового разрешения 40, можно установить значение временного разрешения длительностью в миллисекунду. Ниже приводится пример целой записи типа MThd, включая её заголовок: 4D 54 68 64 MThd идентификатор 00 00 00 06 Длина записи MThd всегда равна 6 байтам 00 01 Формат данного MIDI-файла 1 00 02 В данном файле содержится 2 записи типа MTrk 00 60 The Pulses Per Quarter Note is 96. Запись MTrk За записью MThd следует MTrk запись. Это единственный тип записи, отличающийся от MThd записи, который определён для MIDI-файлов в настоящее время. Если по какой-либо причине в файле содержится идентификатор какой-либо записи другого типа, то, вероятно, эта запись создана для какой-либо другой программы, и эта запись должна быть проигнорирована в соответствии с указанной в её заголовке длиной данной записи. MTrk запись содержит в себе MIDI-данные и байты временных меток, а также необязательную информацию. Эти данные относятся к одному треку. Очевидно, что количество MTrk записей в файле должно совпадать со значением NumTracks, указанном в записи MThd. Заголовок записи MTrk начинается с идентификатора записи, который представляет собой четыре ASCII-байта 'M', 'T', 'r', 'k', за которым следует значение длины записи, то есть число, равное количеству байтов в данной записи. Для различных треков значения длин MTrk записей могут быть различны. (Например, трек, содержащий партию скрипки из Концерта Баха, по всей видимости будет содержать больше данных, чем трек, содержащий басовую партию, в которой на один такт приходится лишь две ноты.) Величины переменной длины — Временные метки событий Трек в MIDI-файле аналогичен треку в MIDI-секвенсоре. Трек секвенсора содержит последовательность событий. Например, первым событием может быть взятие ноты «до» первой октавы. Вторым событием может быть взятие ноты «ми» терцией выше. Эти два события могут произойти в одно и то же время. Третьим событием может быть снятие ноты «до». Это событие может произойти несколькими долями позже после первого события (то есть звук «до» будет снят спустя несколько долей после того, как он был взят). Для каждого события указывается его время, именно в этот момент времени событие происходит. Все события организованы в пределах одной записи в памяти секвенсора в порядке их появления во времени. В MIDI-файле время события указывается перед байтами данных, которые описывают само событие. Иными словами, временна́я метка события предшествует описанию события. Например, если первое событие происходит спустя 4 временных интервала (временной интервал устанавливается в MThd записи) после начала воспроизведения, то соответствующее ему значение «дельта» — значение промежутка времени — устанавливается равным 04. Если следующее событие происходит одновременно с этим первым событием, то значение его времени дельта равно 00. Таким образом, время дельта — это длительность, выраженная в элементарных временных интервалах, между данным событием и ему предшествующим событием. Поскольку предполагается, что все треки начинают воспроизводиться с момента времени равного 0, то время дельта первого события становится равным 0. Значения времен дельта хранятся в виде последовательностей байтов, которые носят название величин переменной длины. Лишь младшие 7 бит каждого байта являются значимыми для определения дельта времени. В зависимости от величины времени дельта, количество байтов может быть различным. Старший бит последнего байта в последовательности равен 0. Если время дельта находится в пределах от 0 до 127, то оно может быть выражено одним единственным байтом. Самое большое время дельта устанавливается в размере 0FFFFFFF, для записи такого времени потребуется величина переменной длины размером 4 байта. Так могут выглядеть величины переменной длины для разных значений времен дельта (время дельта выражено в виде 32-битного значения): Время дельта Соответствующая величина переменной длины 00000000 00 00000040 40 0000007F 7F 00000080 81 00 00002000 C0 00 00003FFF FF 7F 00004000 81 80 00 00100000 C0 80 00 001FFFFF FF FF 7F 00200000 81 80 80 00 08000000 C0 80 80 00 0FFFFFFF FF FF FF 7F Отметим, что использование значений переменной длины, то есть разбиение большой величины на последовательность байтов, не ограничивается случаем с временами дельта. Значения переменный длины используются в MIDI-файлах и в других случаях. События Первые байты (от 1 до 4) записи MTrk задают значение времени дельта для первого события в формате величины переменной длины. Следующий за этой величиной байт данных представляет собой первый байт события MIDI. Этот байт носит название байта статуса события или байта текущего MIDI-статуса. Для MIDI-событий он представляет собой статус байт данного события. Например, если этот байт равен 0x90, то данное событие — это событие Взять Ноту на MIDI-канале 0. Или, если этот байт равен 0x23, то необходимо обратиться к статус-байту предыдущего события. Очевидно, что первое MIDI-событие в MTrk записи обязательно должно содержать в себе статус-байт. После статус-байта следуют один или два байта данных, в зависимости от типа события. Особый случай представляют собой сообщения SYSEX, имеющие статус-байт, равный F0. События SYSEX могут иметь любую длину. После статус байта F0 следует последовательность значений переменной длины. Можно получить 32-битовое значение, которое равно количеству следующих далее байтов, образующих SYSEX-событие. Эта длина не включает в себя статус байт (F0). Рассмотрим в качестве примера следующее SYSEX-событие MIDI: F0 7F 7F 04 01 7F 7F F7 В MIDI-файле такое событие будет сохранено в виде следующей последовательности байтов (исключая время дельта, предшествующее событию): F0 07 7F 7F 04 01 7F 7F F7 Статус-байт FF зарезервирован для использования в качестве статуса события, не являющегося MIDI-событием. За байтом FF следует другой байт, указывающий какой тип не-MIDI события описывается в данном событии. Это своеобразный второй статус-байт. За этим байтом следует величина переменной длины, которая показывает, какое количество байтов содержится в данном событии. то есть задаёт длину события. Длина не включает в себя начальный статус байт FF, байт типа события, байты длины события. Это особое сообщение, не принадлежащее протоколу MIDI, носит название мета-события. Ниже описаны некоторые мета-события. Если не указано обратное, в записи MTrk может быть размещено более одного мета-события, причём одно и то же мета-событие может быть размещено в одной записи более одного раза. Как и все MIDI-события, мета-события имеют дельта времена (временные метки). Таким образом, мы можем произвольно смешивать MIDI-события и мета-события. Номер последовательности (записи) FF 00 02 ss ss Это необязательное мета-событие должно находиться в самом начале MTrk записи перед первой ненулевой временной меткой или перед первым событием. Это мета-событие устанавливает номер последовательности (номер записи) Два байта данных ss ss соответствуют данным в MIDI-сообщении MIDI Cue. В MIDI-файлах второго типа эти числа определяют номера каждого паттерна (или MTrk записи) таким образом, что последовательность пьес, содержащихся в файле, может быть управляема при помощи сообщения MIDI Cue. Если байты ss ss опущены (длина данного мета-сообщения равна 0 вместо 2), то номера MTrk записей устанавливаются в порядке того, как они записаны в файле (первая MTrk соответствует первому треку и т. д.) Файлы нулевого и первого типов, которые содержат единственный паттерн, могут содержать мета-сообщение номера последовательности только в первой MTrk записи. Несколько файлов первого типа, содержащих различные номера последовательностей, могут рассматриваться как коллекции независимых пьес. Можно использовать только одно мета-сообщение номера последовательности для каждой MTrk записи в файле формата 2. Можно использовать только одно мета-сообщение номера последовательности в файле формата 0 или формата 1, и это мета-сообщение должно находиться в первой MTrk записи. Текст FF 01 len text Это мета-событие содержит любой объём текста любого назначения. Значение len содержит длину текстового сообщения в байтах. Наиболее удобно помещать такие мета-сообщения в начале MTrk записи. Несмотря на то, что записываемый текст может быть использован в любых целях, необходимо иметь в виду, что предусмотрены также и иные текстовые мета-сообщения, которые специально предназначены для указания инструментов оркестра, слов песен, названий треков и другие. Данное мета-событие главным образом предназначено для добавления комментариев к MIDI-файлу, предполагается, что при загрузке файлов эти комментарии будут проигнорированы. Отметим, что величина len представляется в виде значения переменной длины. Мета-событие Copyright FF 02 len text Текстовое мета-событие copyright наиболее удобно помещать в начале MTrk записи Отметим, что величина len представляется в виде значения переменной длины. Имя последовательности/Имя трека FF 03 len text Текстовое мета-событие, содержащее название MIDI-последовательности или трека. Удобно располагать это мета-событие в начале MTrk записи. Отметим, что величина len представляется в виде значения переменной длины. Инструмент FF 04 len text Текстовое мета-событие, содержащее название инструмента, исполняющего данный трек. Название инструмента может отличаться от названия самого трека. Например, название трека может быть, скажем, «Ария Ленского», а название инструмента может указывать на голос и содержать значение «Тенор». Наиболее удобно располагать одно или несколько мета-событий подобного типа в самом начале MTrk записи, поскольку эти события несут вспомогательную информацию, которая информирует пользователя о том, какой инструмент исполняет данный трек, а также сообщают другие полезные данные. Обычно реальные параметры, задающие тип инструмента, исполняющего трек, хранятся в файле в виде MIDI-событий типа MIDI Program Change, а описанные здесь мета-события позволяют снабдить пользователя удобно читаемыми описаниями, соответствующими сделанным в MTrk записях конфигурациям. Отметим, что величина len представляется в виде значения переменной длины. Слова FF 05 len text Текстовое мета-событие, содержащее слова вокального произведения, приходящиеся на ту или иную музыкальную долю. Одно мета-событие «Слова» должно содержать один единственный слог текста. Отметим, что величина len представляется в виде значения переменной длины. Маркер FF 06 len text Текстовое мета-событие Маркер устанавливается на определённой музыкальной доле. Это событие может использоваться для организации петель и может обозначать начальную и конечную точку петли. Отметим, что величина len представляется в виде значения переменной длины. Точка входа Cue Point FF 07 len text Текстовое мета-событие «точка входа» может использоваться для обозначения точки входа внешнего потока данных, например точки начала воспроизведения файла с цифровым звуком. Текстовое значение данного мета-события может содержать имя WAV файла, содержащего цифровой звук. Отметим, что величина len представляется в виде значения переменной длины. Канал MIDI FF 20 01 cc Это необязательное мета-событие обычно располагается в начале MTrk сообщения перед первой ненулевой временной меткой и перед первым мета-событием, исключая мета-событие номера последовательности. Мета-событие «канал MIDI» устанавливает значение MIDI-канала с которым будут связаны все последующие мета-события и события SYSEX. Байт данных cc — это номер MIDI-канала, величине 0 соответствует первый канал. Спецификация MIDI не предусматривает указание номера канала для SYSEX событий и мета-событий. Если создаётся файл типа 0, то все SYSEX события и мета-события находятся на одном треке и затруднительно распределить эти события между соответствующими канальными (голосовыми) сообщениями (например, если вы хотите обозначить партию канала 1 как «Флейта соло», а партию канала 2 как «Труба соло», то вам придётся использовать два мета-события «Имя трека» для введения этих названий, но поскольку оба этих трека расположены на одном канале, то перед первым мета-сообщением имени трека необходимо поместить мета-сообщение «канал MIDI», в котором указать номер соответствующего канала, а перед вторым мета-сообщением имени трека поместить мета-сообщение канала MIDI с указанием номера второго канала. На одном MIDI-треке можно использовать более одного мета-сообщения «канал MIDI», если события этого трека нужно распределить между несколькими каналами MIDI. Порт MIDI FF 21 01 pp Это необязательное событие, которое как правило располагается в начале записи MTrk перед первым ненулевым временем дельта и перед первым MIDI-событием, которое определяет, с каким MIDI-портом (или устройством) связаны события данного MTrk сообщения. Байт данных pp — это номер порта, нулевому значению pp соответствует первое MIDI-устройство в системе. Спецификация MIDI предусматривает лишь 16 каналов на один входной или выходной порт (устройство, разъём, инструмент — терминология может быть различной) MIDI. Номер MIDI-канала каждого события MIDI содержится в статус байте события, где он занимает четыре младших бита. Таким образом, номер канала всегда представляет собой число в пределах от 0 до 15. Иногда система позволяет осуществлять работу более чем с 16 каналами MIDI, возникает необходимость преодолеть ограничения, накладываемые малым количеством каналов MIDI, и расширить возможности обмена MIDI-данными, сделать обмен информацией со внешними MIDI-устройствами более эффективным, то есть позволить музыканту работать более чем с 16 каналами. Некоторые секвенсоры также позволяют осуществлять работу более чем с 16 MIDI-каналами на входе и выходе одновременно. К сожалению, протокол MIDI не предусматривает возможность использования более чем 16 MIDI-каналов в рамках статус байта в событии MIDI. Поэтому необходим дополнительный метод, который позволяет различать события, которые соответствуют первому каналу на первом MIDI-порте от событий, соответствующих, скажем, первому каналу на втором MIDI-порте. Описываемое мета-событие позволяет секвенсору определить, на какой MIDI-порт посылать события данного MTrk сообщения. Допускается располагать более одного мета-события «Порт MIDI» в пределах одного MIDI-трека, если требуется изменить значение MIDI-порта в определённый момент времени. Темп FF 51 03 tt tt tt Это событие указывает на изменение темпа. 3 байта данных tt tt tt определяют темп в микросекундах в четвертной ноте. Другими словами, значение темпа (мкс) говорит вам, сколько времени должна звучать каждая из «четвертных нот». Если tt tt tt = 07 А1 20, то каждая четвертная нота должна иметь длительность 07 А1 20 (или 500 000) микросекунд. Как правило, музыканты выражают темп как «сумму четвертных нот в каждую минуту (то есть период времени)». Это полностью противоположно тому, как формат MIDI выражает его. Чтобы преобразовать темп в MIDI формат (BPM — ударов в минуту): BPM = 60000000 / (tt tt tt). Например, темп 120 BPM = 07 А1 20 микросекунд за четвертную ноту. ПРИМЕЧАНИЕ: Если темп не определён, по умолчанию предполагается значение 120 BPM. SMPTE Offset FF 54 05 hr mn se fr ff Назначает время начала (часы, минуты, секунды, кадры, подкадры) MIDI-дорожки согласно стандарту SMPTE. Time Signature (размер) FF 58 04 nn dd cc bb Музыкальный размер задаётся четырьмя байтами. • nn и dd — соответственно числитель и знаменатель в нотной записи. Знаменатель вычисляется как двойка в степени dd. (dd = 2: 1/4; dd = 3: 1/8 и т. д.) • cc expresses the number of MIDI clocks in a metronome click. • bb expresses the number of notated 32nd notes in a MIDI quarter note (24 MIDI clocks). This event allows a program to relate what MIDI thinks of as a quarter, to something entirely different. For example, 6/8 time with a metronome click every 3 eighth notes and 24 clocks per quarter note would be the following event: FF 58 04 06 03 18 08 NOTE: • If no Time Signature is defined, the default value 4/4 is assumed. • Time Signature can only be redefined at measure beginnings. Key Signature (тональность) FF 59 02 sf mi • sf = −7 для 7 бемолей, −1 для 1 бемоля и т. д., 0 для до-мажора или натурального ля-минора, 1 для 1 диеза и т. д. • mi = 0 для мажора, 1 для минора. Конец трека FF 2F 00 Это событие является обязательным. Оно обязано быть последним событием каждой MTrk записи. Оно представляет собой явное обозначение конца MTrk записи. Допускается использование единственного мета-события «Конец трека» для каждой MTrk записи. Улучшение звучания синтезатора MIDI Файлы MIDI являются набором команд для синтезатора (секвенсора), установленного на компьютере, но не несут в себе готовых для воспроизведения аудиоданных в отличие от трекерных модулей. Часто звучание установленного по умолчанию на Windows «Программного синтезатора» не устраивает пользователя (из-за качества семплов в его банке звуков). Для улучшения звука можно выбрать банк со звуками лучшего качества, или же синтезатор с отличным от волнового способом создания звука. Преобразование в MIDI Для преобразования музыкальных записей в команды MIDI существуют различные программы. В качестве исходных могут использоваться как WAV-файлы, так и файлы формата MP3, дорожки Audio CD, а также непосредственно поступающий с микрофона звук без записи его в файл. Некоторые программы умеют распознавать полифоническую музыку, то есть содержащую много голосов. Для улучшения качества распознавания в некоторых программах можно использовать встроенный нотный редактор. MIDI-культура Black MIDI — жанр абстрактной музыки, основная идея которого, сделать мелодию, которую невозможно повторить на классических музыкальных инструментах. Есть различные цели при написании музыки — cделать максимально большой файл, повторить вокал на пианино или же сделать сложный узор аудиодорожками . См. также MIDI-клавиатура MIDI-контроллер MIDI-port (Gameport) MIDI-редактор Нотный редактор Black MIDI General MIDI CV/GATE Список аудиоформатов файлов Ссылки Наиболее полная спецификация MIDI на русском (8 статей) Описание стандартов MIDI Описание интерфейса MIDI Технические спецификации MIDI Примечания Последовательные шины Изобретения Японии


source: wikipedia

text: MP3, mp3 (от MPEG-1 Audio Layer III или MPEG-2 Audio Layer III) — аудиоформат, разработанный командой MPEG. Формат был лицензируемым, но 23 апреля 2017 года срок действия всех патентов истёк и лицензионные сборы прекращены. MP3 является одним из самых распространённых и популярных форматов цифрового кодирования звуковой информации. Он широко используется в файлообменных сетях для оценочного скачивания музыкальных произведений. Формат может проигрываться практически во всех популярных операционных системах, на большинстве портативных аудиоплееров, а также поддерживается всеми современными моделями музыкальных центров и DVD-плееров. В формате MP3 используется алгоритм сжатия с потерями, разработанный для существенного уменьшения размера данных, необходимых для воспроизведения записи и обеспечения качества воспроизведения звука, близкого к оригинальному (по мнению большинства слушателей), но с ощутимыми потерями качества при прослушивании на качественной звуковой системе. Принцип сжатия заключается в снижении точности некоторых частей звукового потока, что практически неразличимо для слуха на повсеместно распространённой аппаратуре низкой точности воспроизведения звука (например, доминирующее большинство портативных устройств, звуковых карт, музыкальных центров, автомагнитол и прочей не специальной аппаратуры), а также для людей старшего возраста, в связи с естественными возрастными изменениями слухового аппарата, однако в большинстве случаев чётко различимо на аудиотехнике высокой точности воспроизведения. Данный метод называют перцепционным кодированием. При этом на первом этапе строится диаграмма звука в виде последовательности коротких промежутков времени, затем на ней удаляется информация, не различимая человеческим ухом, а оставшаяся информация сохраняется в компактном виде. Данный подход похож на метод сжатия, используемый при сжатии картинок в формат JPEG. При создании MP3 со средним битрейтом 128 кбит/с в результате получается файл, размер которого примерно равен 1/11 от оригинального файла с CD-Audio (само по себе несжатое аудио формата CD-Audio имеет битрейт 1411,2 кбит/с). MP3-файлы могут создаваться с высоким или низким битрейтом, что влияет на качество файла-результата. История MP3 разработан рабочей группой Института Фраунгофера () под руководством Карлхайнца Бранденбурга и университета Эрланген-Нюрнберг в сотрудничестве с AT&T Bell Labs и Thomson (Джонсон, Штолл, Деери и др.). Основой разработки MP3 послужил экспериментальный кодек ASPEC (Adaptive Spectral Perceptual Entropy Coding). Почти полный стандарт появился в открытом доступе 6 декабря 1991 года. При разработке алгоритма тесты проводились на вполне конкретных популярных композициях. Основной стала песня Сюзанны Веги «Tom’s Diner». Отсюда возникла шутка, что «MP3 был создан исключительно ради комфортного прослушивания любимой песни Бранденбурга», а Вегу стали называть «мамой MP3». Первым кодировщиком в формат MP3 стала программа L3Enc, выпущенная летом 1994 года, а в сентябре 1995 года Институт Фраунгофера выпустил первый программный MP3-плеер — Winplay3. С 1996 года началось нелегальное распространение музыкальных MP3 файлов в интернете. Первой композицией загруженной в сеть 10 августа 1996 года риппером под ником NetFrack, стала песня «Until it Sleeps» с альбома «Load» группы Metallica. 23 апреля 2017 года истекли последние патенты на формат и были прекращены сборы лицензионных отчислений с производителей программного обеспечения и встраиваемых решений. О прекращении лицензирования формата сообщил Институт Фраунгофера на своём официальном сайте. И, хотя формат mp3 всё ещё весьма популярен среди пользователей, большинство радиостанций и телеканалов перешли на использование современных кодеков, обеспечивающих лучшее сжатие и меньшую потерю качества звука. Описание формата Как и формат JPEG, MP3 использует спектральные отсечения, согласно психоакустической модели. Звуковой сигнал разбивается на равные по продолжительности отрезки, каждый из которых после обработки упаковывается в свой фрейм (кадр). Разложение в спектр требует непрерывности входного сигнала, в связи с этим для расчётов используется также предыдущий и следующий фрейм. В звуковом сигнале есть гармоники с меньшей амплитудой и гармоники, лежащие вблизи более интенсивных — такие гармоники отсекаются, так как среднестатистическое человеческое ухо не всегда сможет определить присутствие либо отсутствие таких гармоник. Такая особенность слуха называется эффектом маскировки. Также возможна замена двух и более близлежащих пиков одним усреднённым (что, как правило, и приводит к искажению звука). Критерий отсечения определяется требованием к выходному потоку. Поскольку весь спектр актуален, высокочастотные гармоники не отсекаются, как в JPEG, а только выборочно удаляются, чтобы уменьшить поток информации за счёт разрежения спектра. После спектральной «зачистки» применяются математические методы сжатия и упаковка во фреймы. Каждый фрейм может иметь несколько контейнеров, что позволяет хранить информацию о нескольких потоках (левый и правый канал либо центральный канал и разница каналов). Степень сжатия можно варьировать, в том числе в пределах одного фрейма. Интервал возможных значений битрейта составляет 8—320 кбит/c. MP3 и «качество Audio-CD» В прошлом было распространено мнение, что запись с битрейтом 128 кбит/c подходит для музыкальных произведений, предназначенных для прослушивания большинством людей, обеспечивая качество звучания Audio-CD. В действительности всё намного сложнее. Во-первых, качество полученного MP3 зависит не только от битрейта, но и от кодирующей программы (кодека) (стандарт не устанавливает алгоритм кодирования, только описывает способ представления). Во-вторых, помимо превалирующего режима CBR (Constant Bitrate — постоянный битрейт) (в котором, проще говоря, каждая секунда аудио кодируется одинаковым числом бит) существуют режимы ABR (Average Bitrate — усреднённый битрейт) и VBR (Variable Bitrate — переменный битрейт). В-третьих, граница 128 кбит/c является условной, так как она была выбрана в эпоху становления формата, когда качество воспроизведения большинства цифровых звуковых систем, как правило, было ниже, чем в настоящее время. Грубо говоря, утверждение о «качестве Audio-CD» при 128 кбит/c соответствует границе относительно комфортного прослушивания музыки, ниже которой возникает сильная деградация звука у всех программ кодирования в формат MP3. На 2008 год наиболее часто встречаются MP3-файлы с битрейтом 192 кбит/c, что может косвенно говорить о том, что большинство считает этот битрейт достаточным. Реально воспринимаемое «качество» зависит от исходного аудиофайла, слушателя и его аудиосистемы. Некоторые меломаны предпочитают сжимать музыку с «максимальным качеством» — 320 кбит/c, либо даже переходить на кодеки без потерь, например, FLAC. Также среди меломанов/аудиофилов бытует мнение, что некоторые семплы (фрагменты аудиозаписи) не поддаются качественному сжатию с потерями: на всех возможных битрейтах не составляет особого труда отличить сжатое аудио от оригинала. Однако есть и серьёзные возражения: Совершенно очевидно, что (возьмём с запасом) битрейта 256 kbps в подавляющем большинстве случаев должно быть более чем достаточно для комфортного восприятия музыки с CDA-источника (44 kHz/16 bit/stereo). Это очевидно не только из моего доморощенного теста, но и по анализу профессиональных слепых тестов (например, германского издания «c’t», июнь 2000 г.): даже в них экспертам не всегда удаётся «угадать» сжатый до 256 kbps звук, причём тестирование проходит в специально подготовленных помещениях и на дорогом оборудовании, а эксперт знает, что надо «слушать», чтобы почувствовать сжатие. Режимы кодирования и опции Существует три версии MP3 формата для различных нужд: MPEG-1, MPEG-2 и MPEG-2.5. Отличаются они возможными диапазонами битрейта и частоты дискретизации: 32—320 кбит/c при частотах дискретизации 32000 Гц, 44100 Гц и 48000 Гц для MPEG-1 Layer 3; 16—160 кбит/c при частотах дискретизации 16000 Гц, 22050 Гц и 24000 Гц для MPEG-2 Layer 3; 8—160 кбит/c при частотах дискретизации 8000 Гц и 11025 Гц для MPEG-2.5 Layer 3. Режимы управления кодированием звуковых каналов Так как формат MP3 поддерживает двухканальное кодирование (стерео), существует 4 режима: Стерео — двухканальное кодирование, при котором каналы исходного стереосигнала кодируются независимо друг от друга, но распределение бит между каналами в общем битрейте может варьироваться в зависимости от сложности сигнала в каждом канале. Моно — одноканальное кодирование. Если закодировать двухканальный материал этим способом, различия между каналами будут полностью стёрты, так как два канала смешиваются в один, он кодируется и он же воспроизводится в обоих каналах стереосистемы. Единственным плюсом данного режима может являться только выходное качество по сравнению с режимом Стерео при одинаковом битрейте, так как на один канал приходится вдвое большее количество бит, чем в режиме Стерео. Двухканальное стерео () — два независимых канала, например, звуковое сопровождение на разных языках. Битрейт делится на два канала. Например, если заданный битрейт 192 кбит/c, то для каждого канала он будет равен только 96 кбит/c. Объединённое стерео () — способы двухканального кодирования, позволяющие увеличить коэффициент сжатия файла. Первый способ Mid / Side Stereo, когда левый и правый каналы преобразуются в их сумму (L+R) и разность (L−R). Для большинства звуковых файлов насыщенность канала с разностью (L−R) получается намного меньше канала с суммой (L+R). Поэтому объединённое стерео позволяет либо сэкономить на битрейте канала разности (L−R), либо улучшить качество на том же битрейте, поскольку на канал суммы (L+R) отводится бо́льшая часть битрейта. Бытует мнение, что данный режим не подходит для звукового стереоматериала, в котором в двух каналах воспроизводится субъективно абсолютно различный материал, так как он стирает различия между каналами. Но современные кодеки используют различные режимы в разных фреймах (включая чистое стерео) в зависимости от исходного сигнала. Второй способ Intensity Stereo опирается на свойство человеческого слуха различать положение звуков в пространстве не во всём спектре частот, игнорируя положение очень низких и очень высоких. Таким образом, кодирование звуков сверхнизкой и сверхвысокой частоты в режиме моно повышает эффективность сжатия данных. CBR CBR расшифровывается как Constant Bit Rate, то есть постоянный битрейт, который задаётся пользователем и не изменяется при кодировании произведения. Таким образом, каждой секунде произведения соответствует одинаковое количество закодированных бит данных (даже при кодировании тишины). CBR может быть полезен для потоков мультимедиа-данных по ограниченному каналу; в таком случае кодирование использует все возможности канала данных. Для хранения данный режим кодирования не является оптимальным, так как он не может выделить достаточно места для сложных отрезков исходного произведения, при этом бесполезно тратя место на простых отрезках. Повышенные битрейты (выше 256 кбит/c) могут решить данную проблему, выделив больше места для данных, но зато и пропорционально увеличивая размер файла. VBR VBR расшифровывается как Variable Bit Rate, то есть изменяющийся битрейт или переменный битрейт, который динамически изменяется программой-кодером при кодировании в зависимости от насыщенности кодируемого аудиоматериала и установленного пользователем качества кодирования (например, тишина закодируется с минимальным битрейтом). Этот метод MP3-кодирования является самым прогрессивным и до сих пор развивается и улучшается, так как аудиоматериал разной насыщенности может быть закодирован с определённым качеством, которое обычно выше, чем при установке среднего значения в методе CBR. Плюс к тому, размер файла уменьшается за счёт фрагментов, не требующих высокого битрейта. Минусом данного метода кодирования является сложность предсказания размера выходного файла. Но этот недостаток VBR-кодирования незначителен в сравнении с его достоинствами. Также минусом является то, что VBR считает «незначительной» звуковой информацией более тихие фрагменты, таким образом получается, что если слушать очень громко, то эти фрагменты будут некачественными, в то время как CBR делает с одинаковым битрейтом и тихие, и громкие фрагменты. Формат VBR постоянно улучшается, благодаря постоянному совершенствованию математической модели кодеков, в частности, после выхода обновлённой версии свободного MP3-кодека LAME (версия 3.99.3), кодирование с переменным битрейтом, по заявлению разработчиков, качественно лучше CBR и тем более ABR. Однако формат CBR 320 кбит/c всё ещё позиционируется как гарантирующий максимальное качество (например он используется в пресете «--preset insane»). ABR ABR расшифровывается как Average Bit Rate, то есть усреднённый битрейт, который является гибридом VBR и CBR: битрейт в кбит/c задаётся пользователем, а программа варьирует его, постоянно подгоняя под заданный битрейт. Таким образом, кодек будет с осторожностью использовать максимально и минимально возможные значения битрейта, так как рискует не вписаться в заданный пользователем битрейт. Это является явным минусом данного метода, так как сказывается на качестве выходного файла, которое будет немного лучше, чем при использовании CBR, но хуже, чем при использовании VBR. С другой стороны, этот метод позволяет наиболее гибко задавать битрейт (может быть любым числом между 8 и 320, против исключительно кратных 16 чисел метода CBR) и вычислять размер выходного файла. Кодеки Типы программ, необходимые для преобразования форматов файлов. Наиболее распространённые кодеки MP3. mp3PRO-codec (использует частотное преобразование SBR). LAME-codec. Fraunhofer-codec. Структура файла MP3-файл состоит из нескольких фрагментов (фреймов) MP3, которые, в свою очередь, состоят из заголовка и блока данных. Такая последовательность фрагментов называется элементарным потоком. Фрагменты не являются независимыми элементами («резервуар байт»), и поэтому не могут быть извлечены произвольно. Блок данных MP3-файла содержит сжатую аудиоинформацию в виде частот и амплитуд. На приведённой диаграмме показано, что заголовок MP3 состоит из маркера, который служит для нахождения верного MP3-фрагмента. За ним следует бит, показывающий, что используется стандарт MPEG, и два бита, показывающие использование layer 3; другими словами, это определяет MPEG-1 Audio Layer 3 или MP3. Последующие значения могут варьироваться в зависимости от типа MP3-файла. Стандарт ISO/IEC 11172-3 определяет диапазон значений для каждой секции заголовка, вместе с общей его спецификацией. Большинство MP3-файлов в настоящий момент содержат ID3-метаданные, которые предшествуют или следуют за MP3-фрагментом; они также отображены на диаграмме. Теги Теги (от — ярлык, метка, бирка) — метки в границах MP3-файла (в начале и/или в конце). В них может быть записана информация об авторстве, альбоме, годе выпуска, обложка альбома и текст песни и прочая информация о треке. В более поздних версиях тегов возможно хранение прочих данных о звуковой записи. Существуют различные версии тегов (см.: ID3). Недостатки Технические недостатки. Количество каналов звука ограничено двумя, в отличие от AAC и Vorbis. Также имеется жёсткое ограничение возможной частоты дискретизации: отсутствует возможность задать произвольную частоту дискретизации. Максимальная частота дискретизации для MP3 — 48 кГц в то время как для Vorbis максимальная частота — 192 кГц, и для AAC — 96 кГц. В MP3 возможно сохранить только в следующих частотах дискретизации: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100 и 48000 Гц. Юридические ограничения. Патентом на MP3 владеет компания Alcatel-Lucent, которая требовала лицензирования некоторых способов использования формата (срок действия связанных с MP3 патентов истёк 23 апреля 2017). В США изобретения, публично раскрытые более года, не могут быть запатентованы; однако для патентов, оформленных до 8 июня 1995 года (почти полный стандарт появился в открытом доступе 6 декабря 1991), существовала возможность увеличить их сроки действия. Известные патенты, касающиеся расшифровки MP3, прекратили действие в США к декабрю 2012; по другим данным, если учитывать только патенты, заявка на которые была подана до декабря 1992 года, этого не произошло в сентябре 2015 года. В 2017 году все патенты, касающиеся данного формата, окончили действие, так как не были продлены правообладателями. См. также LAME AAC Vorbis Opus Сжатие аудиоданных Цифровые звуковые форматы Список аудиоформатов файлов Как музыка стала свободной Примечания Ссылки Статья о заголовке фрейма MPEG Developement and Implementation of an MPEG1 Layer III Decoder on x86 and TMS320C6711 platforms — Презентация Power Point с описанием структуры файла Developement and Implementation of an MPEG1 Layer III Decoder on x86 and TMS320C6711 platforms — Презентация Power Point с описанием процесса декодирования Audio Coding (TU Ilmenau) — учебный курс профессоров Карлхайнца Бранденбурга и Геральда Шуллера. Аудиокодеки Форматы аудиофайлов MPEG


text: NTP ( — протокол сетевого времени) — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной . Протокол был разработан , профессором Делавэрского университета, в 1985 году. Версия на 2015 год — NTPv4. NTP, основанный на алгоритме Марзулло, использует для своей работы протокол UDP и учитывает время передачи. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи. В версии 4 способен достигать точности 10 мс (1/100 с) при работе через Интернет, и до 0,2 мс (1/5000 с) и лучше внутри локальных сетей. Наиболее широкое применение протокол NTP находит для синхронизации серверов точного времени. Для достижения максимальной точности предпочтительна постоянная работа программного обеспечения NTP в режиме системной службы. В семействе операционных систем Microsoft Windows — это служба W32Time, в UNIX-подобных системах — демон Ntpd или chronyd. Более простая реализация этого алгоритма известна как SNTP — простой протокол сетевого времени. Используется во встраиваемых системах и устройствах, не требующих высокой точности, а также в пользовательских программах точного времени. Структура пакета Структура пакета описана в RFC 5905. Пакет состоит из целого числа 32-битных слов. Данные в заголовке будут отличаться для различных режимов работы. Например, клиент в поля часовой слой, идентификатор источника, начальное время и время приёма должен записать нули. Заголовок Индикатор коррекции Длина — 2 бита, от . Целое число, показывающее предупреждение о секунде координации. {| class="wikitable" ! Значение ! Описание |- | 0 | Нет предупреждения |- | 1 | Последняя минута дня содержит 61 секунду |- | 2 | Последняя минута дня содержит 59 секунд |- | 3 | Неизвестно (время не синхронизировано) |} Номер версии Длина — 3 бита, от . Целое число, представляющее версию протокола. Режим Длина — 3 бита, от . Целое число, представляющее режим. Значения представлены в таблице ниже. {| class="wikitable" ! Значение ! Описание |- | 0 | Зарезервировано |- | 1 | Симметричный активный режим |- | 2 | Симметричный пассивный режим |- | 3 | Клиент |- | 4 | Сервер |- | 5 | Широковещательный режим |- | 6 | Контрольное сообщение NTP |- | 7 | Зарезервировано для частного использования |} Часовой слой Длина — 8 бит, от . Целое число, представляющее часовой слой. {| class="wikitable" ! Значение ! Описание |- | 0 | Не определено или недопустим |- | 1 | Первичный сервер |- | 2-15 | Вторичный сервер, использующий NTP |- | 16 | Не синхронизировано |- | 17-255 | Зарезервировано |} Интервал опроса Длина — 8 бит, от . Целое число со знаком, представляющее максимальный интервал между последовательными сообщениями. Значение равно двоичному логарифму секунд. Предлагаемые по умолчанию пределы на минимальные и максимальные опросы — 6 и 10, соответственно. Точность Длина — 8 бит, от . Целое число со знаком, представляющее точность системных часов. Значение равно двоичному логарифму секунд. Например, значению −18 будет соответствовать точность около 1 мкс. Задержка Длина — 32 бита, от . Общее время распространения сигнала в обе стороны в коротком формате NTP. Дисперсия Длина — 32 бита, от . Общая дисперсия для источника времени в коротком формате NTP. Идентификатор источника Длина — 32 бита, от . Код источника синхронизации. Зависит от значения в поле Часовой слой. Для слоя 0 — это четыре ASCII символа, называемые «kiss code», используются для отладки и мониторинга. Смотри ниже Для слоя 1 — это четыре октета ASCII символов, дополненные слева нулями, назначенные для опорного времени. В таблице ниже представлен список, поддерживаемый IANA. {| class="wikitable" ! ID ! Источник |- | GOES | Геостационарный спутник системы экологического мониторинга и наблюдения |- | GPS | Система глобального позиционирования |- | GAL | Система местоопределения «Галилео» |- | PPS | |- | IRIG | , США |- | WWVB | , Колорадо, США |- | DCF | Низкочастотный радиопередатчик, 77.5 кГц, DCF77, Майнфлинген, ФРГ |- | HBG | , Швейцария |- | MSF | , Великобритания |- | JJY | Низкочастотный радиопередатчик, 40 кГц, Фукусима, 60 кГц, Сага, Япония |- | LORC | Среднечастотный радиопередатчик, 100 кГц, радионавигация, |- | TDF | , Франция |- | CHU | , Канада |- | WWV | , США |- | WWVH | , США |- | NIST | Телефонный модем Национального института стандартов и технологий США |- | ACTS | Телефонный модем Национального института стандартов и технологий США |- | USNO | Телефонный модем Национальной обсерватории США |- | PTB | Телефонный модем |} Для слоя 2 и выше — это идентификатор сервера и может быть использован для фиксирования временных петель. Если используется IPv4, то идентификатор представляет собой четыре октета IP адреса. Если используется IPv6, то это первые четыре октета MD5 хэша адреса. При использовании IPv6 адресов для сервера с NTPv4 и клиента с NTPv3 идентификатор может принимать случайное значение, из-за чего временные петли могут быть не зафиксированы. Время обновления Длина — 64 бита, от . Время, когда система последний раз устанавливала или корректировала время. Формат NTP. Начальное время Длина — 64 бита, от . Время клиента, когда запрос отправляется серверу. Формат NTP. Время приёма Длина — 64 бита, от . Время сервера, когда запрос приходит от клиента. Формат NTP. Время отправки Длина — 64 бита, от . Время сервера, когда запрос отправляется клиенту. Формат NTP. NTP-сообщение «Kiss-o'-Death» Для слоя 0, который считается неопределённым или недопустимым, поле Идентификатор источника может использоваться для доставки сообщений, которые выполняют роль данных о состоянии системы и управления доступом. Такие сообщения называются «Kiss-o'-Death» (KoD), а доставляемые ими ASCII-данные называются «kiss codes» (коды «помощи»). Перечень принятых в настоящее время кодов «помощи» представлен в таблице ниже. Получатели KoD-сообщений обязаны их проверить и выполнить следующие действия: При получении кодовых комбинаций DENY и RSTR клиент обязан разорвать виртуальные соединения с данным сервером времени и прекратить передачу сообщений этому серверу. При получении кодовой комбинации RATE клиент обязан незамедлительно снизить свой интервал опроса этого сервера и продолжать его уменьшать каждый раз при получении этой кодовой комбинации. При получении кодовой комбинации начинающейся с ASCII-символа Х, предназначенной для проведения экспериментальных исследований и последующих усовершенствований, она должна быть проигнорирована, если она не распознаётся. Все другие кодовые комбинации и KoD-сообщения, не определённые данным протоколом, уничтожаются после их поверки. Часовые слои NTP использует иерархическую сеть, где каждый уровень имеет свой номер, называемый слой (). Слой 1 — первичные серверы, непосредственно синхронизирующиеся с национальными службами времени через спутник, радио или телефонный модем. Слой 2 — вторичные серверы, синхронизируются с первичными серверами, и т. д. Как правило, клиенты и серверы NTP с относительно небольшим числом клиентов не синхронизируется с первичными серверами. Существует несколько сотен общественных вторичных серверов, работающих на более высоких слоях. Они являются предпочтительным выбором. Формат времени Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 232 секунд, с теоретической точностью 2−32 секунды. Поскольку шкала времени в NTP повторяется каждые 232 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать 70 лет (с учётом високосных лет), чтобы корректно совместить время с Windows или Unix-системами. См. также Служба точного времени Дисперсия Аллана OpenNTPD Синхронизация часов Протокол точного времени Заметки Примечания Литература Миллс, Дэвид Л. Сличение времени в компьютерных сетях. Протокол сетевого времени на Земле и в космосе. — Киев : Wircom, 2011. — С. 464. — ISBN 978-966-97191-0-2. Другие версии RFC: RFC 778, RFC 891, RFC 956, RFC 958, RFC 1305, RFC 2030, RFC 4330 Ссылки Протоколы прикладного уровня Интернет-протоколы Часы


text: Napster (New artist program) — файлообменная пиринговая сеть, созданная Шоном Фэннингом (при участии Шона Паркера и Джордана Риттера) и действовавшая в период с июня 1999 год по июль 2001 года, когда он посещал Северо-Восточный университет в Бостоне. Названием сервиса стал псевдоним Шона. Napster был первым широко используемым p2p (peer-to-peer) файлообменным сервисом и оказал сильное влияние на людей, использующих Интернет. Сервис позволял легко обмениваться музыкальными файлами с другими людьми, что привело к обвинениям в нарушении авторских прав со стороны музыкальной отрасли. Несмотря на то, что сервис был остановлен по решению суда, он привёл к появлению децентрализованных peer-to-peer сетей, контролировать которые гораздо сложнее. В настоящий момент торговая марка и логотип сервиса используются платным сервисом . Истоки Шон Фаннинг в компании с двумя своими онлайн-друзьями — Джорданом Риттером из Бостона и Шоном Паркером из Вирджинии — запустил первую версию Napster в июне 1999. Фаннинг хотел найти более лёгкий способ обмениваться музыкой в формате MP3, чем посредством IRC или Lycos. После рассмотрения всех аспектов деятельности компании Джоном Фанингом, дядей Шона, последний получил 30 % акций компании. Остальное отошло к его дяде. Napster являлась peer-to-peer сетью, хотя и использовала централизованное управление для получения списка подключённых компьютеров и их списка предоставляемых файлов, так как обмен файлами происходил непосредственно без участия центрального сервера. Такой принцип работы очень похож на протокол IRC. Хотя и существовали сети, облегчающие обмен файлами (напр., IRC, , USENET), Napster специализировалась исключительно на музыке в формате MP3 и предоставляла удобный интерфейс. Результатом стала система, чья популярность генерировала огромный выбор музыки для скачивания. Хотя музыкальная индустрия провозгласила обмен музыкой посредством p2p-сетей воровством, многие пользователи Napster считали такие закачки оправданными по многим причинам. Многие считали, что к середине 90-х качество новых альбомов снизилось к уровню, когда типичный альбом содержал только одну-две хорошие песни и «музыкальный наполнитель» — песни-пустышки. Поэтому они были благодарны Napster за возможность скачать несколько песен без необходимости платить за весь альбом. Также Napster предоставлял прекрасную возможность меломанам обмениваться песнями, которые сложно найти — старыми записями и песнями с концертов, бутлегами. Также у пользователей появилась возможность скачать музыку, которую они приобрели до популяризации компакт-дисков (например, на виниловых пластинках, кассетах), в оцифрованном виде. Закрытие Причиной закрытия Napster стало появление в 2000 г. демоверсии песни «I Disappear» группы Metallica за несколько дней до её официального выхода. Это не понравилось участникам группы, в особенности барабанщику Ларсу Ульриху, по чьей инициативе и был составлен иск против компании. Музыканты затеяли судебную тяжбу с Napster, заодно учинив иск университетам Южной Калифорнии, Йеля и Индианы за то, что их руководство не воспрепятствовало бесплатному распространению. В итоге, в 2001 году Metallica и Napster пришли к некоторому соглашению. После предложения о покупке за 2,43 млн долларов контрольного пакета акций, сделанного компанией развлечений для взрослых Private Media Group, бренд и логотипы были приобретены на аукционе банкротов компанией , которая использовала их для преобразования музыкального интернет-сервиса в платный сервис Napster 2.0. Napster сегодня В сентябре 2008 года музыкальный сервис Napster[en] был выкуплен американской компанией Rhapsody[en] и в настоящее время является онлайн-магазином музыки. См. также Gnutella Snocap — компания, основанная Шоном Фаннингом и другими работниками Napster. Пузырь доткомов Примечания Ссылки Napster, Inc. Website Музыка для всех, даром // TJournal Файлообменные сети


text: OS/2 — операционная система фирмы IBM, в определённый период времени разрабатывавшаяся с участием Microsoft. История системы 1 августа 1984 года IBM объявила о выпуске нового поколения персональных компьютеров — IBM PC/AT — и приступила к разработке новой операционной системы для этих машин. Новая ОС должна была преодолеть ограничение DOS на 640 Кб памяти для прикладных программ и реализовать поддержку режима многозадачности. Параллельно с разработкой Windows корпорация Microsoft вместе с IBM включилась в активную работу по созданию системы, получившей наименование OS/2. Однако в начале 1990-х годов пути двух гигантов IT-индустрии разошлись. Microsoft независимо от IBM начинает разработку Windows 3.0. IBM, независимо от Microsoft, разворачивает работу над облегчённой версией OS/2, которая требовала бы меньше ресурсов, чем OS/2 1.2. Версии OS/2 v0.99 — бета-версия. Предназначена для отладочных целей, поставлялась почти без драйверов. Цель создания — конкуренция на рынке многозадачных оболочек для DOS, основным конкурентом считалась DESQview. Включает поддержку кооперативной многозадачности. Текстовый интерфейс, переключение экранов. OS/2 v1.0 (декабрь 1987 года) — первая официальная версия. Первая ОС с режимом многозадачности, использующим аппаратные средства процессоров 80286 и 80386 (защищённый режим). По-прежнему текстовый интерфейс. Взаимодействие с пользователем осуществляется только одной из запущенных программ, остальные выполняются в фоновом режиме. Максимально поддерживаемый объём дисков — 32 Мб. Нет поддержки мыши. Все версии OS/2 1.х разработаны для процессора 80286, но могут функционировать и на системах с процессором 80386. OS/2 v1.10SE (Standard Edition) (октябрь 1988 года) Дебют Presentation Manager (PM), реализующего функции графического интерфейса пользователя. Поддерживаются диски с файловой системой FAT16 объёмом до двух гигабайт. OS/2 v1.10EE (Extended Edition) (начало 1989 года) По сравнению со стандартной версией эта версия была дополнена программами Database Manager (администратор баз данных) и Communications Manager (администратор связи с мэйнфреймами IBM). OS/2 v1.20 (ноябрь 1989 года) Включает улучшенный Presentation Manager, а версия EE — также новую файловую систему HPFS (High Performance File System), более эффективную, быструю и надёжную, чем FAT. Также добавлен интерпретатор языка программирования REXX. В 1989 году было начато создание сразу двух новых версий OS/2: OS/2 v2.00 OS/2 v3, которую предназначали для серверов сетей и которая должна была строиться по принципу микроядра и быть переносимой между компьютерами с различными архитектурами. Позже разработка этой ОС была продолжена в Microsoft под названием Windows NT. OS/2 v1.30 (1991 год) Увеличена скорость работы и надёжность по сравнению с предшествующими версиями. В комплект входит много новых драйверов устройств (однако меньше, чем в Windows). Интерпретатор REXX появился и в версии SE, добавлено кеширование записи на HPFS, поддержка видеорежима 1024×768 и шрифтов Adobe Type I. OS/2 v2.00 (весна 1992 года) Эта версия 32-разрядная (за исключением видеоподсистемы), продвигалась IBM под слоганом «лучшая DOS, чем MS-DOS, и лучшая Windows, чем Windows». Использование виртуальных DOS-машин (VDM) позволяет запускать сразу несколько DOS- и Windows-задач. Для запуска программ Windows используется Win-OS/2, основанная на лицензированной IBM Windows 3.1. Использование виртуальных машин позволило изолировать Windows и DOS-задачи, в результате чего сбои в программах не препятствовали продолжению выполнения других программ. Реализованы также такие механизмы межпрограммного взаимодействия, как динамический обмен данных (Dynamic Data Exchange) и буфер обмена. Минимально необходимым для работы этой версии системы является процессор 80386, ядром системы используется его защищённый режим. DOS-приложения используют режим виртуального 8086. Для работы требуется объём оперативной памяти 8 мегабайт. Также в эту версию включена оболочка рабочего стола Workplace Shell, предоставляющая функции объектно-ориентированного графического интерфейса пользователя. OS/2 v2.10 (май 1993 года) Ускорена загрузка, добавлена поддержка шрифтов TrueType в Win-OS/2, а также функции поддержки мультимедиа (Multimedia Presentation Manager, MMPM/2). Графическая подсистема стала 32-битной. Поддерживаются системы PCMCIA и APM BIOS, необходимые для портативных компьютеров; однако качество реализации драйверов невысокое. В конце 1993 года была также выпущена более дешёвая версия OS/2 2.11, устанавливающаяся поверх Windows 3.1. Warp 3 (октябрь 1994 года) и её бета-версия OS/2 v2.99 (начало 1994 года) Первоначально эта версия вышла под названием «OS/2 Warp for Windows» и устанавливалась как и OS/2 2.11 поверх Windows 3.1. Позже была выпущена версия, включающая Win-OS/2. Минимальные требования включают процессор 80386 и 4 мегабайта оперативной памяти. В комплект поставки включены дополнительные драйверы устройств. Улучшена поддержка печати, мультимедиа и PCMCIA, Workplace Shell. Появился новый элемент интерфейса — LaunchPad (панель для быстрого запуска программ). Также доступны сервисы Интернет и TCP/IP. Warp 3 включает комплект доступа в Интернет (Internet Access Kit, IAK), в состав которого входит, помимо системного ПО, браузер Web Explorer, хотя большинство пользователей использовали Netscape. Доступна также поддержка FTP и электронной почты (но предназначенная для этого программа Ultimail Lite неудобна и работает с малой скоростью). В комплект поставки входил компакт-диск BonusPak, на котором представлен офисный пакет IBM Works, включающий электронные таблицы, текстовый процессор, СУБД, генератор отчётов и программу построения диаграмм. Также в Bonus Pak включена программа для приёма/отправки факсов и некоторое другое ПО. В том же году в IBM принято стратегическое решение о концентрации усилий по разработке не на x86-совместимых компьютерах, а на PowerPC, в число разработчиков которого входила сама IBM. Была создана концепция «Workplace OS», а также версия OS/2 для PowerPC. Warp Connect (1995 год) Включает сетевой инструментарий Warp Connect Peer для взаимодействия с LAN Server 4.0, позволяющий разделять между компьютерами, входящими в сеть, файлы, принтеры и модемы. В начале 1996 года был выпущен Warp Server, объединивший OS/2 Warp, LAN Server 4.0 (с добавлениями и исправлениями) и SystemView for OS/2. Этот комплект предназначен для создания файл-серверов и серверов печати. Представлены также службы удалённого доступа и резервного копирования. Warp Server поддерживает симметричную мультипроцессорность (SMP). Warp 4 (Мерлин) (сентябрь 1996 года) Переработан интерфейс Workplace Shell, добавлена поддержка выполнения программ на языке программирования Java, функции голосовой навигации и голосового ввода информации VoiceType Navigation and Dictation. Сетевые средства Warp 4 позволяли ей работать с большим количеством сетей: LAN Server, Windows, Novell Netware, PCLAN, IPX-SPX, LANtastic и т. д. Поддерживались протоколы TCP/IP, SNA, NetBIOS. Также в состав этой версии ОС включены служба удалённого доступа LAN Distance, служба управления системой TME10 Netfinity с поддержкой Desktop Management Interface, сервис для мобильных пользователей Mobile Office Services. Недостатками OS/2 в этот период являются малое количество программ сторонних разработчиков, особенно ориентированных на домашнего пользователя, в том числе игр. Причиной этого была политика IBM, не предпринимавшей особых усилий для того, чтобы побудить разработчиков создавать программы для OS/2. Aurora (Аврора) — полуофициальное название серверной ветви OS/2 4.5x, выпущенной следом за Warp 4 (Мерлин). Первоначально имела название OS/2 Warp Server for e-Business (OS/2 WSeB) и была выпущена в апреле 1999 года (версия Warp 4.5). Иногда её неправильно называют Warp 5. Добавлена поддержка журналируемой файловой системы JFS, поддерживается до 64 процессоров, обновлены практически все компоненты системы. Были выпущены также два пакета обновлений Aurora Convenience Pack: ACP1 (версия Warp 4.51) и ACP2 (версия Warp 4.52). В 2003 году вышел последний третий сервис-пак — ACP3 4.53, но компания IBM более не выпускала дистрибутивы со встроенным данным сервис-паком. eComStation Соревнование с Windows После того, как IBM и Microsoft разошлись в разные стороны, Microsoft сконцентрировалась на создании Windows NT, а сама OS/2 продолжала разрабатываться в фирме IBM, которая всё же не уделяла этой операционной системе должного внимания. 21 мая 1990 года вышла Windows 3.0. За первый месяц её копий было продано больше, чем копий OS/2 за целых три года. Microsoft занимает доминирующее положение на рынке ОС для платформы IBM PC. В 1991 году Microsoft прекратила участие в разработке OS/2, разрабатываемая аппаратно-независимая ОС переименована из «OS/2, Version 3» в «Windows NT». Версию OS/2 Warp 3 всерьёз рассматривали как достойного конкурента Windows, но версия 4 уже не претендовала на это из-за рекламной деятельности Microsoft. 26 октября 1996 года вышла следующая версия — OS/2 Warp 4.0 (Мерлин). В 1999 году появляется OS/2 Warp Server for e-business (кодовое название «Аврора», версия системы — 4.5). Интересен также тот факт, что в процессе совместной работы специалисты Microsoft создавали для Windows существенно более удобный конечному пользователю код, относительно такового для OS/2 v1.10SE и OS/2 v1.20. Таков, в частности, весь код ядра и интерфейсов, относящийся к драйверам устройств. Пример процедуры установки принтера в ранних версиях OS/2: установить драйверы устройства; установить очередь принтера; создать объект принтера; сопоставить драйвер устройства с объектом принтера; сопоставить очередь печати с объектом принтера; настроить COM-порт для принтера, подключаемого к одному порту; при помощи команды SPOOL переназначить принтер на желаемый порт; определить опциональные параметры настройки принтера. Microsoft, официально отказавшись от поддержки OS/2, продолжала внимательно следить за развитием этой операционной системы. Многие детали интерфейса OS/2 IBM и Microsoft перешли в новую ОС Microsoft — Windows 95. Прекращение поддержки OS/2 приобрела некоторую популярность в среде корпоративных клиентов и сетевиков. В России OS/2 не получила широкого распространения. Особой популярностью в качестве домашней операционной системы OS/2 никогда не пользовалась, оставаясь в тени Windows, и, позднее, Windows NT. Тем не менее усилия как самой IBM, так и множества корпоративных и независимых разработчиков программного обеспечения не прошли даром — OS/2 являлась стабильной системой с предсказуемым поведением и хорошим набором системных и прикладных программ. При этом OS/2 представляла собой самостоятельную линию развития операционных систем, в своё время отличаясь от Windows NT существенно меньшими требованиями к аппаратным средствам, а от Linux — лучшей поддержкой программ для DOS и Win16. Поддержка пользователей осуществлялась до 31 декабря 2001 года. После этого срока поддержка осуществляется только для тех пользователей, которые заключили дополнительный договор на обслуживание. Области применения OS/2 ОС для компьютеров ранних моделей/банкоматов На компьютере с процессором 80486 с 4—8 мегабайтами памяти можно работать в OS/2 Warp 3, что достаточно для запуска клиента сети и нескольких программ под DOS. OS/2 традиционно используется в банковской сфере; иногда — в банкоматах, в файрволах для OS/390. На постсоветском пространстве основные области использования OS/2 сводятся к следующему: Сервер «Aurora» (OS/2 WSeB 4.5x) популярна в качестве файлового сервера из-за производительности, надёжности и набора возможностей. Используется, например, в качестве сервера приложений и контроллера домена, а также позволяет использовать разнообразные интернет-сервисы вроде серверов HTTP, FTP, SMTP/POP3, файрвола, прокси-сервера, сервера точного времени и т. п. Рабочее место в лаборатории OS/2 встречалась в 1990-х годах в институтских лабораториях — там, где много управляющих программ для «экзотических» платформ типа Windows 2.x или GeoWorks, где от системы требуется хорошая многозадачность. Обработка больших (для своего времени) объёмов данных OS/2 надёжно обрабатывает многомегабайтные потоки информации (хорошей иллюстрацией является статья Феликса Гербека об использовании OS/2 для обработки данных с метеоспутников). Это было одной из причин популярности OS/2 в Фидонете, где крупные узлы ежедневно обрабатывали десятки и сотни мегабайт почты: OS/2 позволяла, единожды настроив сервер с нужным набором компонентов и даже без графического интерфейса, не беспокоиться о стабильности его работы. Разработка ПО OS/2 была популярна в конце 1990-х годов для разработки программ на Java. Также разрабатывалась серия продуктов IBM VisualAge (C++, Java и SmallTalk). Некоторые особенности системы Файловая система В OS/2 реализован механизм подключаемых файловых систем (Installable File System, IFS). Это означает, что для работы с той или иной файловой системой нужно просто загрузить соответствующий драйвер. Штатная «высокопроизводительная файловая система» (HPFS — High Performance File System) поддерживает разделы диска до 64 гигабайт (это ограничение драйвера, сама файловая система поддерживает до двух терабайт) и позволяет использовать имена файлов длиной до 255 символов. HPFS экономно расходует дисковое пространство (размер кластера составляет 512 байт), крайне мало подвержена фрагментации и отличается стабильностью. В последних версиях OS/2 имеется менеджер логических томов (LVM), позволяющий объединять несколько физических разделов (в том числе находящихся на разных дисках) в единый том, и включена поддержка более быстрой журналируемой файловой системы JFS, поддерживающей тома больших объёмов (до двух терабайт). Помимо входящих в поставку IFS для FAT, HPFS, JFS, ISO9660 (CDFS) и UDF существуют также монтируемые файловые системы сторонних производителей для VFAT, FAT32, EXT2, NTFS, HFS, AEFS и др. Графический интерфейс пользователя В OS/2 в качестве штатного интерфейса используется Workplace Shell (WPS). В отличие от Microsoft Windows, где графические и текстовые программы используют две разные кодировки («кодировка DOS» и «кодировка Windows»), в OS/2 везде используется кодировка DOS (для русской локализации — CP866). Исключение составляют приложения Windows, запускаемые под OS/2. Поддержка Юникода, однако, в «родных» приложениях OS/2 практически отсутствует — в частности, в именах файлов, хотя файловая система JFS хранит их в Unicode (ср.: FAT32 в Windows). Командная строка GUI в OS/2 можно не загружать, получая при этом работоспособную систему в режиме командной строки. Штатная оболочка может быть заменена на более продвинутый аналог (4os2 или портированные из юниксов sh, bash и т. п.). Это позволяет получить работоспособную систему на одной-двух дискетах. REXX REXX — язык для написания скриптов. Это язык с весьма несложным синтаксисом, разработанный в IBM. Версия REXX для OS/2 позволяет писать как консольные, так и графические приложения, выполнять команды OS/2, а также обращаться к API OS/2. Помимо этого, многие программы имеют REXX-API, позволяющее создавать скрипты для управления работой этих программ (ср.: Visual Basic for Applications в Windows и Bash и т. п. в Linux). TCP/IP OS/2 имеет UNIX-подобный стек TCP/IP (последние версии являются полностью BSD4.4-совместимыми), с привычными для пользователей UNIX-подобных систем утилитами и демонами, такими как arp, ifconfig, netstat, ppp, telnetd, sendmail и т. д. Стек TCP/IP в OS/2 содержит клиент SOCKS и портированный из AIX файрвол. Приложения DOS, Win16 и Win32 OS/2 способна выполнять приложения DOS и Win16. К примеру, OS/2 позволяет загружать с дискеты или её образа на диске произвольную версию DOS или передавать в использование программе 736 Кб основной памяти. Для особо «капризных» программ существуют различные параметры настройки, контролирующие практически все аспекты работы сессии DOS. Приложения Windows могут быть запущены как в полноэкранной сессии Win-OS/2 (ничем не отличается от Windows 3.1), так и поверх рабочего стола OS/2. В Win-OS/2 можно работать с программами, требующими для работы Win32s extender (Photoshop 3.0x, MS Internet Explorer/Win16). Некоторое время развивался проект Odin, позволяющий запускать приложения современных версий Windows либо конвертировать их в родные OS/2-приложения. Последний выпуск Odin был сделан 17 февраля 2013 года. Java По тестам VolanoMark 2.1.2, IBM JDK 1.1.7 for OS/2 в своё время являлась наиболее продуктивной Java-машиной на платформе x86. Java-машина для OS/2 бесплатна и поставляется вместе с системой. Программы UNIX Для облегчения портирования Unix/Linux-программ, а также разработки родных приложений в Unix-подобном стиле, используется набор библиотек emx, распространяемый в соответствии с лицензией GNU GPL. Если Unix-программа не завязана на конкретные особенности реализации ядра (часто бывает с приложениями для Linux), то в большинстве случаев её можно скомпилировать под OS/2. Впрочем, если программа рассчитана на POSIX-совместимость, её компиляция под OS/2 может оказаться проблематичной. Существуют также несколько реализаций X Window System для OS/2, наиболее распространённой из которых является XFree86-OS/2. Работа в сети В комплект поставки OS/2 Warp Connect и OS/2 Warp 4 (Merlin) входят клиенты сетей Novell NetWare, Microsoft Network и NFS. OpenGL В OS/2 Warp 4.0 и выше внедрена программная реализация OpenGL. Универсальный видеодрайвер Scitechsoft SNAP реализует «software optimized» поддержку OpenGL. Драйверы Драйверы к различной аппаратуре предоставлялись на официальном сайте IBM, но в связи с прекращением поддержки ныне удалены. Дальнейшее развитие 1 ноября 2005 года сообщество энтузиастов OS/2 направило в IBM петицию с просьбой открыть исходные коды этой операционной системы. Несмотря на то, что петицию подписали 11 613 человек, IBM её проигнорировала. В ноябре 2007 года сообщество направило повторную петицию, которую подписали 3744 человека. 16 января 2008 года IBM ответила отказом, мотивируя своё решение техническими, юридическими, а также бизнес-причинами. IBM до сих пор получает отчисления с продаж OS/2, распространяемой как eComStation. В рамках проекта Core/2 существуют два действующих направления по развитию OS/2: OS/4 — создание современного ядра методом реверс-инжиниринга и полного переписывания кода на основе существующих ядер. osFree — создание всей операционной системы «с нуля» на основе современных микроядерных технологий и активного использования наработок открытого ПО. В ноябре 2015 года компанией Arca Noae было заключено лицензионное соглашение с IBM на выпуск и продажу нового дистрибутива для современного аппаратного обеспечения на кодовой базе OS/2, получившее кодовое имя Blue Lion. Позднее этот проект вышел на коммерческий рынок под названием ArcaOS и рассматривается как полноценная замена старым версиям OS/2 4.5. Примечания Ссылки Сайт разработчика последних версий OS/2 — eComStation Сайт неофициальной поддержки eComStation Сайт разработчика русской версии eComStation OS/2 FAQ — сборник часто задаваемых вопросов и ответов на них Russian Underground/2 — сайт пользователей OS/2 Hobbes — крупнейший файловый архив с софтом для OS/2 Литература Шашков М. Забытая OS/2: Вехи пути // Comprice.ru


text: Vorbis — свободный формат сжатия звука с потерями, официально появившийся летом 2002 года. По функциональности и качеству аналогичен таким кодекам, как AAC, AC3 и VQF, превосходящим MP3. Психоакустическая модель, используемая в Vorbis, по принципам действия близка к MP3 и подобным, однако математическая обработка и практическая реализация этой модели существенно отличаются, что позволило авторам объявить свой формат совершенно независимым от всех предшественников. Контейнер Для хранения аудиоданных в формате Vorbis чаще всего применяется медиаконтейнер Ogg, такой файл обычно имеет расширение .ogg и называется двойным именем «Ogg/Vorbis» или «Ogg Vorbis». Однако «Ogg Vorbis» называют и сам кодек без контейнера, так как он является частью проекта Ogg. Применение На 2013 год распространён существенно меньше, чем MP3. Используется в компьютерных играх, для подкастов. Vorbis идеален для применения в качестве звуковых дорожек фильмов, так как не изменяет их длину при переменном битрейте, что позволяет сохранять синхронность с видеодорожкой, и применим для многоканального звука (например, 6-канальный звук). Используется для звуковой дорожки файлов в формате WebM вместе с видеокодеком VP8 (с VP9 в формат добавили поддержку нового свободного кодека Opus). Метаданные Формат изначально разрабатывался с возможностью потокового вещания. Это даёт формату достаточно полезный побочный эффект — в одном файле можно хранить несколько композиций с собственными метками. При загрузке такого файла в плеер должны отобразиться все композиции, будто их загрузили из нескольких различных файлов. Формат имеет гибкую систему меток. Заголовок меток легко расширяется и позволяет включать тексты любой длины и сложности (например, текст песни), перемежающиеся изображениями (например, фотографиями обложек альбомов). Текстовые метки хранятся в UTF-8, что позволяет писать на нескольких языках одновременно и исключает возможные проблемы с кодировками. Битрейт Ogg Vorbis по умолчанию использует переменный битрейт, при этом значения последнего не ограничены какими-то жёсткими значениями, и он может варьироваться даже на 1 kbps. При этом стоит заметить, что форматом жёстко не ограничен максимальный битрейт, и при максимальных настройках кодирования он может варьировать от 500 до 1000 кбит/с. Такой же гибкостью обладает частота дискретизации — пользователям предоставляется любой выбор в пределах от 2 до 192 кГц. Цель разработки Vorbis был разработан сообществом «Xiph.Org» для того, чтобы заменить все платные запатентованные аудиоформаты. Несмотря на то, что это самый молодой формат из всех конкурентов MP3, Ogg Vorbis имеет полную поддержку на всех популярных платформах (Microsoft Windows, Linux, Apple Mac OS, Android, PocketPC, Palm, Symbian, DOS, FreeBSD, BeOS и др.), а также большое количество аппаратных реализаций. Проект Ogg Vorbis является частью мультимедиапроекта Ogg, в который также входят свободные кодировщики: Speex — для сжатия голоса; FLAC — для сжатия звука без потерь; Theora — для сжатия видео. Для хранения звука в Vorbis используется формат‐контейнер Ogg. Преимущества Vorbis Отсутствие патентных ограничений. До 255 каналов. «Sample accurate» — звуковые данные не будут иметь смещений, дополнительных или потерянных семплов относительно друг друга. «Streamable» — поддержка поточного воспроизведения. Эффективные алгоритмы переменного битрейта. Частота дискретизации до 192 кГц. Разрядность до 32 бит. Гибкий Joint stereo. Гибкая психоакустическая модель. Метки хранятся в Юникоде, а не в национальной кодировке. Большая степень компрессии по сравнению с MP3 при равном качестве (размер файла меньше) Реализации Благодаря открытой модели разработки и распространения существуют несколько вариантов программных кодеров и декодеров Vorbis. Официальные программы и библиотеки Официальная реализация от разработчиков стандартов Ogg и Vorbis, фонда Xiph.Org, распространяется под лицензиями типа BSD и GNU LGPL. Официальной программой-кодировщиком является свободная oggdropXPd, существующая в разных вариантах исполнения: используются библиотеки libVorbis или aoTuVb, и оптимизация под разные процессоры. Последняя версия libVorbis 1.3.7 выпущена 6 июля 2020 года. aoTuV Версия от японского разработчика Aoyumi. Благодаря улучшенной психоакустической модели достигается значительно более высокое качество звука, при этом aoTuV не нарушает совместимости с официальным стандартом. Хотя Aoyumi не является официальным разработчиком кодека Vorbis, его заслуги оказались настолько высоки, что в официальные библиотеки версии 1.1.0 от 22 сентября 2004 года был добавлен разработанный им код (beta 2). Последняя версия — Beta 6.03 от 25 апреля 2011 года. Однако, код aoTuV использовался в официальных и сторонних реализациях последующих версий кодера. Lancer Японский разработчик Nyaochi работает над увеличением скорости кодирования в формат Vorbis. Его версия, называемая Lancer, основывается на актуальных версиях aoTuV. Благодаря оптимизациям кода под современные процессоры достигается существенное увеличение скорости кодирования и декодирования (на десятки процентов, в некоторых условиях в несколько раз). Качество при этом страдает весьма незначительно. Его последняя разработка датирована 10 ноября 2006 года. Код Nyaochi также использовался в сторонних реализациях последующих версий кодировщика. Tremor Реализация декодера Ogg Vorbis с использованием чисел с фиксированной запятой, созданная для платформ, которые не поддерживают числа с плавающей запятой. Будущее кодека Разработчик проекта Ogg фонд Xiph.Org Foundation рекомендует использовать вместо Vorbis новый royalty-free кодек Opus. Примечания См. также MP3 AAC Opus Список аудиоформатов файлов Ссылки Русский сайт Ogg Vorbis Официальный сайт Сайт разработчиков Wiki проект Опрос касательно популярности кодеков Xiph.Org Свободные аудиокодеки