Что такое “теги” аудио-файлов?

Давайте в продолжении темы о безлузных кодеках поговорим о не менее интересной теме — теме тегов. Что это такое? Зачем они нужны? Чем можно редактировать теги? Нужно-ли редактировать теги? Попробуем ответить на эти вопросы и не только…

Кстати, a почему у меня на телефоне вместо русских букв в плеере "кракозябры"? А вы знаете сколько типов "кракозябр" бывают и как их отличить? Смотрите в конце статьи....

А начнем как повелось с терминологии:

«Тег или Тэг (от англ. tag — ярлык, метка, бирка) — метки в границах аудио-файла (в начале и/или в конце). В них может быть записана информация об авторстве, альбоме, годе выпуска и прочая информация о треке. В более поздних версиях тегов возможно хранение обложек альбомов и тексты песни».

«Метаданные — это информация об используемых данных. Или проще информация об информации. Пример: Имя автора правки в тексте».

«Файл — поименованная совокупность информации записанная на физический носитель (диск, флеш и т.д.)».

«Файловый контейнер — файл в котором заключено содержимое нескольких разных типов».

«Replay Gain — (ReplayGain, Replaygain, выравнивание громкости) — стандарт представления информации, позволяющей аудиоплеерам, использующим её, воспроизводить файлы в медиа-библиотеке с однородной громкостью».

Часть — I: ВВЕДЕНИЕ.

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

Предыстория создания тегов такова. 1996 год, год когда только начали появляться на PC длинные имена файлов, год Win95, DOSовских игрушек .... эх!. После создания MP3 формата появилась проблема с хранением данных о музыкальном файле, а в MP3 это никак не предусматривалось. 

В 1996 году некому Эрику Кэмпу пришла идея добавить участок памяти в файл MP3, чтобы решить эту проблему. Стандарт назвали ID3v1, и он быстро стал стандартом хранения метаданных в MP3. Формат выпущен Damaged Cybernetics, подпольной группой, которая занималась взломом консольных игровых сетей. Это и дало начало всем аудио-тегам.

Часть — II: ТИПЫ ПРИМЕНЯЕМЫХ ТЕГОВ
Часть эта получилась длинная, хотя я пытался сократить ее как мог. Тем кому не интересно можно прочитать лишь выводы.

ID3v1

Первая версия ID3-тегов занимала всего 128 байт, начинающихся со строки TAG. Тег помещался в конец файла для поддержания совместимости с ранними проигрывателями. Некоторые из них издавали небольшой шум, когда пытались прочесть тег, но большинство игнорировали его. Современные проигрыватели корректно воспринимают эту информацию.

Поскольку для данных отводилось немного места, в таких тегах можно было хранить только базовые сведения о песне: название, альбом, исполнитель, комментарий, по 30 байт на каждое поле, 4 байта для хранения года и одного байта под жанр, который можно было выбрать из заранее определённого списка из 80 значений (позднее Winamp расширил список своими 68 значениями).

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

код ID3v1 тега:

Чуть позднее в тегах ID3v1 использовалась система Lyrics3. Lyrics3 — это первая попытка внедрить текст песни внутрь MP3 файла, реализованная Петром Стрнадом (Petr Strnad). Текстовый блок помещался между строками LYRICSBEGIN и LYRICSEND в конце файла, перед тегом ID3v1.x (если его не было, то он создавался). Текст был в кодировке ISO-8859-1, максимальная длина 5100 байт, строки разделялись символами CR+LF, была сделана поддержка временны'х меток.

Со временем был выпущен формат Lyrics3 v2.00, который имел больше возможностей (в частности, значительно увеличился размер блока, появились дополнительные поля и возможность вставки изображения). Блок версии 2.00 помещался между строками LYRICSBEGIN и LYRICS200 и имел переменную длину, которая записывалась в последних 6-ти байтах перед конечной строкой LYRICS200.

Идея Lyrics3 не получила широкого распространения ввиду выхода стандарта ID3v2, в котором подобное было организовано более гибко и функционально.

Комментарии и критика:
ID3v1 много критиковали за ряд проблем. Во-первых, поля были слишком небольшими для большинства информации, которой им предстояло хранить. 30 байт не хватало для длинных названий, они урезались.

Предложение закрепить жанр за ограниченным числом альтернатив также нашло много противников. Многим просто не нравился предложенный список, в котором не отводилось места под такие жанры, как минимализм или барокко. ID3v1 также не хватало интернационализации.

Он утверждал, что все строки должны храниться в ISO 8859-1, но на практике пользователи часто используют национальную кодировку, поэтому нередко им приходилось видеть "кракозябры".

В результате не просуществовав и двух лет формат потихоньку отошел. Его место занял ID3v2.

ID3v2

Новый стандарт ID3v2 был разработан в 1998. Хотя он носит название ID3, он мало похож на первую версию ID3. Теги ID3v2 переменной длины и обычно находятся в начале файла что было сделано для поддержания потокового воспроизведения. Тег состоит из нескольких кадров, каждый из которых содержит какие-либо метаданные.

Например, кадр TIT2 содержит название, а WOAR содержит ссылку на сайт артиста. Кадры могут быть длиной до 16 MB, в то время как весь тег может занимать до 256 MB. Проблемы с кодировками почти устранены благодаря поддержке UTF-16. Текстовые кадры помечаются битом кодировки, хотя "кракозябры" всё ещё возможны, если использовать свою кодировку вместо UTF-16.

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

код ID3v2 тега:

На сегодня известны и используются три версии ID3v2:

ID3v2.2 — первый широко используемый ID3v2. Используется трёх-символьный идентификатор кадра вместо 4х(TT2 для названия вместо TIT2). Этот стандарт считается устаревшим.

ID3v2.3 — расширяет идентификаторы до 4 байтов и добавляет количество кадров. Кадр может содержать много значений, разделённых знаком «/». Это наиболее распространённая версия тегов для файлов Mp3.

ID3v2.4 — это самая поздняя версия, датируемая ноябрём 2000. Она позволяет хранить строки в UTF-8. Для разделения значений используется нулевой байт, поэтому знак «/» можно спокойно использовать в тексте, появилась возможность добавить тег в конец файла, как в первой версии.

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

Например, кадр TIT2 с названием и USLT с текстами песни требуют различных алгоритмов по извлечению данных. С 84 различными кадрами требуются десятки суб-парсеров. Когда дело доходит до Windows Explorer, появляются другие проблемы. Когда в MP3 файле используется тег версии ID3v2.4, Windows Explorer не может прочитать теги, поскольку он поддерживает только версию ID3v2.3.

Хотя ID3 был изобретён для MP3, в этом стандарте можно хранить теги и в отличных от MP3 форматах файлов. На практике, единственный формат, который широко использует ID3v2, это AIFF, где тег хранится внутри RIFF области под именем «ID3».

Комментарии и критика:
ID3v2.Х. несомненно считается прорывом для тегов и на сегодняшний день версия 2.3 наиболее используемая. Версия 2.4 несмотря на добавленную кодировку UTF-8 и унификацию фреймов ничего кардинального не поменяла, а порой даже создает трудности для программистов.

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

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

Официальный сайт ID3, включающий полную спецификацию на английском языке.

Vorbis comment

Формат Ogg Vorbis официально появился в 2002 году усилиями некоммерческой организации Xiph Foundation и при разработке метаданных для него учитывались проблемы связанные с тегами других форматов. Теги для формата Ogg называются "Vorbis comments" или реже "Ogg Comments".
Комментарии Vorbis — это контейнер для метаданных, используемый в форматах аудио-файлов Vorbis (ОGG), FLAC, и Speex.

Тег Vorbis — это список полей в формате ИмяПоля=Данные. Имя поля может состоять из печатаемых ASCII символов, 0x20 (пробел) — 0x7D («}»), исключая 0x3D («=») и 0x7E («~»). Поля не чувствительны к регистру, так что "artist" и "ARTIST" — одно и то же поле.

Количество полей и их длина ограничены величиной 4 294 967 295 (максимальное значение 32-битного целого), но большинство приложений для редактирования тегов налагают более строгие ограничения. Данные кодируются в UTF-8, так что любая строка Unicode может быть использована как значение.

Разрешены любые имена тегов, и не существует формата для значения данных. Разрешено так же использовать имена полей более чем однажды. Эта возможность используется для поддержки множественных значений, например два поля artist=... для перечисления имен двух исполнителей одной композиции.

код Vorbis тега:

В комментариях Vorbis не предусмотрено хранение двоичных данных. Это сделано намеренно, комментарии предназначены для использования как часть формата контейнера, такого как Ogg, и любые дополнительные двоичные данные следует кодировать напрямую в контейнер.

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

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

Комментарии и критика:
Плюсами формата являются: гибкая система тега, выстраиваемая самими пользователями и использование кодировки UTF-8. Конечно, есть отрицательные моменты, но разработчики не стоят на месте.

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

Еще один минус привязка данного формата тегов к продукции одного производителя, при этом сейчас он больше продвигается через формат FLAC, а не OGG.

Спецификация формата Ogg Vorbis I, на английском языке

WM metadata

Одновременно с разработкой и продвижением WM формата компания Microsoft разрабатывала свои медиатеги. Поскольку WMA является частью стандарта Windows Media, то и тег создавался единый как для аудио, так и для видео. Метаданные для WM не имеют конкретного названия, компания Microsoft называет их просто: мультимедийные данные, но распространены и такие названия как ASF/WMA-tag или WMA/ASF-comments/metadata.

Структура WM metadata очень напоминает ID3v2tag. Тег разделен на категории, каждая из которых имеет свой заголовок и может варьировать свой объем.

код WM тега:

Названия категорий во многом совпадают с ID3v2, хотя есть и дополнительные, связанные с видео, такие как: продюсер, информации о киностудии, возрастной рейтинг и т.д. Сам тег с потоком аудиоданных при этом запаковывается в контейнер-оболочку ASF (Advanced Systems Format).

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

Расширение файла может быть *.wma или *.asf, причем расширение *.wma используется, только для аудио файлов. WM metadata базируются на XML-Syntax, который может использовать практически любые кодировки ISO/IEC 8859 или Unicode, но для WM metadata используется исключительно Unicode.

Комментарии и критика:
К плюсам WM metadata можно отнести использование Unicode-кодировки и фиксированную структуру тега не создающую проблем при их чтении и редактировании.
К минусам же можно отнести малую распространенность и низкую популярность самого WMA формата.

Спецификация формата WM metadata, на английском языке

MP4 / iTunes metadata

В 1998 году группа экспертов MPEG (Motion Picture Experts Group) представила новый формат MPEG-4, предназначенный для хранения и передачи аудио и видео данных. А MP4 в свою очередь является контейнером для формата MPEG-4.

В качестве стандарта для аудио в формате MPEG-4, компания Apple Computer (теперь просто Apple) в 2002 году предложила стандартизировать формат AAC (Advanced Audio Coding), разработанный группой специалистов, в которую входили представители Fraunhofer (разработчик MP3), Dolby, Sony, AT&T, и Nokia. А в ноябре 2004 Apple заявила о добавлении в свой арсенал еще и формат AAC+.

Логично полагать, что компания Apple, предложившая формат M4A, разработавшая защиту для него и активно использующая его в своих, Mac, iTunes Music Store, iTunes и iPod, позаботилась о разработке тегов для "своего" формата.

М4А так же как и WMA оснащен своими собственным механизмами хранения информации метаданных. Метаданные входят в состав самого контейнера MP4, который сформирован из объектно-ориентированных структур, называемых атомами. Каждый атом идентифицируется тегом и длиной.

Большинство атомов описывают иерархию метаданных, несущих в себе информацию о медиа-данных файла. Это собрание атомов содержится в атоме, называемом "кино-атом". Расположение самих медиа-данных строго не определено.

В файле MP4 они могут содержащемся в одном или более mdat, в медийных информационных атомах или размещаться вне файла MP4 с доступом через URL. Естественно для текстовых полей используется исключительно Unicode (UTF-8). Кроме стандартного набора полей в MP4 metadata так же, как и в WM metadata имеется большой набор специализированных полей для видеоинформации.

Для "голого" формата ААС теги никогда не разрабатывались, так как в теории присоединение к файлу тега может привести к потере совместимости со стандартом. Но на пракрите ААС успешно используют с ID3tag ранних версий, а в последнее время и версии 2.4, например, компанией Nokia. Кроме того неофициальным тэгом для этого формата является APEv2.

Однако использование ID3 второй версии для ААС все же не рекомендуется. Несмотря на то, что безконтейнерный ААС формат всё реже используется для хранения аудио, компания Nokia предлагает его использовать как один из основных после MP4.

Комментарии и критика:
Компания Apple учла плюсы и минусы, имевшиеся у других форматов, поэтому критических нареканий к MP4 metadata не имеется.

Фактически, это один из самых удобных и сбалансированных форматов тегов. Отрадно так же то, что компанией осуществляется поддержка своего программного обеспечения, а так же MP4/iTunes metadata.

Спецификация формата MP4/iTunes metadata, на английском языке

ATRAC metadata

ATRAC (Adaptive Transform Acoustic Coding) – формат, который практически синхронно с МР3, начал разрабатывать гигант SONY. По существу, это файл MP3, а ATRAC используется как кодек. Можно сказать экзотический формат, поскольку используется только в девайсах от компании SONY / SONY-Ericsson.

Для защиты своего контента компания Sony так же применяет технологию OpenMG DRM, которая является неотъемлемой частью формата.

Метаданными компания Sony стала оснащать свой формат, начиная с версии ATRAC3, но изобретать свой собственный формат для метаданных не стала, а попросту переняла тег ID3v2. ATRAC metadata использует стандартные типы фреймов тега ID3v2, но помимо стандартных типов фреймов, имеются и специальные TXXX и GEOB, содержащие метаданные OpenMG, предназначенные для ограничения нелегального распространение музыки.

Таким образом, народный ID3 tag был поставлен на службу коммерческим технологиям. Думаю нет необходимости описывать причины, по которым данный формат в народе по сегодняшний день не находит широкого применения. Так же практически полностью отсутствует программное обеспечение, поддерживающее данный формат.

Собственно только компания Sony предлагает программу SonicStage, которая позволяет транскодировать такие форматы как MP3, AAC или WMA в формат ATRAC для дальнейшего переноса на разные цифровые устройства SONY.

Но и эта программа находится в поле критики, поскольку при транскодировании форматов происходит перезапись метаданных, содержащиеся в первичном файле в ATRAC metadata и происходит это не всегда гладко. Были нередки случаи, когда происходила потеря метаданных или их искажение. А кроме того, при конвертации снижается качество звука.

Комментарии и критика:
ATRAC metadata имеет все те же недостатки, которыми обладает ID3v2 tag. Сам формат ATRAC малопопулярен и в его распространении принципиально заинтересованы только продавцы музыки, но ни как не пользователи.

Спецификация формата ATRAC metadata, на английском языке

APEv2

APEv2 теги используются для хранения метаданных, таких как название альбома, исполнитель, номер трека в аудио файлах. Изначально первые версии тегов (APEv1) были предназначены для формата Monkey's Audio, но Фрэнк Клемм(Frank Klemm) модифицировал их, добавив заголовок (header), дав этим самым возможность APE тегам располагаться в начале файла, и также реализовав хранение метаданных в формате Unicode.

Впервые этот вариант тегов был использован в аудио-файлах формата Musepack, но в дальнейшем, из-за простоты и гибкости этого варианта, он был адаптирован как основной формат тегов для форматов WavPack и OptimFROG, для Monkey’s Audio (с версии 3.99) и TAK.

Аудиоплеер Foobar2000 позволяет использовать эти теги в файлах MP3, вместо стандартных ID3 тегов, потому что APEv2 теги легче записывать, и они более гибкие в использовании. Тем не менее, из-за того, что APEv2 не были изначально ориентированы на использование в MP3 файлах (в отличие от ID3 тегов), существует ряд проблем.

Например, строка APETAGEX является началом APEv2 тега, а строка TAG — началом ID3v1 тега. Поэтому если TAG в APETAGEX заканчивается там, где ожидается ID3v1 тег, то это значение может быть прочитано неверно. Кроме того, ID3 содержат так называемую «схему рассинхроницазии» («unsynchronization scheme»), которая не позволяет аудиоплеерам проигрывать данные тегов.

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

код APEv2 тега:

По формату APEv2 теги концептуально ближе тегам Vorbis, чем к ID3 тегам. Так же, как и "Vorbis Comments", они представляют собой неструктурированные пары ключ/значение, но в отличие от них, эти теги хранят список значений для каждого ключа, а не ключ для каждого значения.

Не понятно? Для примера возьмем трек, который содержит данные о двух исполнителях. В «комментариях Vorbis» эти данные будут храниться как два отдельные поля ARTIST, а в теге APEv2 — как одно поле ARTIST, с двумя значениями, разделенными нуль-символом (байтом со значением, равным 0)

Значения APEv2 тегов могут быть помечены как принадлежащие к типу «text», «binary» или «external». То есть можно в тело тега записать нормальную картинку или размещать "линки" выходящие за контейнер.

Комментарии и критика:
Несомненно APEv2 имеет ряд преимуществ, таких как отсутствие ограничений на количество и длину полей, использование Unicode и легкость записи и редактирования. APEv2 используют для различных аудио форматов, поскольку тег обладает хорошей гибкостью.

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

Спецификация APEv2 на английском языке

Часть — III: ПРИМЕНИМОСТЬ ТЕГОВ

Увы не все теги можно применить ко всем файлам, но есть среди них и "универсалы", смотрим картинку:

Часть — IV: ПРОБЛЕМЫ ВЫБОРА

Вот мы и дошли до той части статьи в которой кроме копи/пасты мне нужно пошевелить мозгами.
Итак, что-же выбрать? Мой ответ наверное будет немного обескураживающим — НИЧЕГО из вышеперечисленного!

Как мы выяснили все теги пишутся в разные части файлов, все теги не стандартизованы и не проверены, тегов в одном файле может быть сколь угодно много, на все теги тратится драгоценное время плеера на сканирование, это фигня если индексируются 10 альбомов, а если это диск объемом в 2Тб?

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

Еще есть проблема которая появилась с некоторыми современными плеерами типа AIMP или Foobar — они позволяют "на лету" выставлять рейтинг из 5-ти звездочек. Пишется этот рейтинг опять в наши многострадальные теги, после чего "раздать" файл по сети под той-же раздачей будет невозможно, файл-то изменился и хеш уплыл. И не известно в какой тег, какого формата плеер записал информацию.

На практике бывают и такие курьезные случаи — альбом разделен на треки и в каждом треке по гигантской картинке по размеру совместимой с размером самого трека (типа, здрасте — я обложка). Еще совершенно не понятно зачем писать тег к файлу-образу диска?

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

А это происходит от части потому, что наш плеер читает эти самые теги, каждый раз, разбираясь во всех типах тегов, фильтрует бинарные данные, уровни ReplayGain, годы, исполнителей и так далее и тому подобное. Какой выход?

Выход довольно прост. Давайте подумаем, что обычный меломан хочет знать о своем артисте?
1. Имя исполнителя
2. Название альбома
3. Название треков из альбома
4. Номера треков из альбома
5. Год выпуска альбома или диска
6. Жанр музыки.
7. крик души: "Еще б картинку альбома!"
и еще желательно делать какие-нибудь пометки для себя.
Знаете куда я клоню?

Правильно к началу-начал к файлу CUE !

Часть (последняя) — V: CUE sheet файл для аудио треков или для аудио-имиджа.

Cue sheet, или файл cue, — обычный текстовый файл, содержащие команды, а так же метаданные, которые описывают раскладку треков CD или DVD диска. Файлы cue имеют текстовый формат и расширение .cue.

Впервые файлы cue sheet появились в программе CDRWIN. Теперь они поддерживаются многими приложениями так же они используются для определения подлинности оптических дисков и многими, но не всеми мультимедиа проигрывателями.

Для Audio-CD cue файлы указывают названия и исполнителей альбома и его треков, а также имена одного или более используемых аудиофайлов. Синтаксис cue sheet файлов позволяют использовать как одиночные (потрековые) файлы MP3, WAV, FLAC, APE ..., так и образы диска сжатые или нет.

Файлы cue Позволяют восстановить полную реальную копию диска из lossless файла имиджа с задержками между дорожками, с информацией ISRC и т.д.

Синтаксис прост как автомат Калашникова:

REM
Команда игнорирования строки (комментарий)

REM GENRE ""
Жанр музыки — любой хоть "Шансон Уркаганский"

REM DATE ""
Год или дата в любом формате.

REM DISCID
Идентификатор диска в базе данных "FREEDB" не говорит ни о чем, кроме того, что теги были записаны не ручками, а через сервис freedb.org

REM COMMENT ""
Позволяет добавлять комментарии к файлу (файлам), или треку.

CATALOG ""
Номер диска по каталогу UPC/EAN
UPC (универсальный код товара) — американский стандарт штрих-кода.
EAN (европейский номер товара) — европейский стандарт штрих-кода, предназначенный для кодирования идентификатора товара и производителя. Является надмножеством американского стандарта UPC.
13 цифр.

PERFORMER ""
В начале: Исполнитель или создатель работы в целом. После строки TRACK: Исполнитель или создатель соответствующего трека.

TITLE ""
В начале файла название альбома в целом. После строки TRACK: название соответствующего трека. Команда TITLE пишется до команды TRACK, написанная после автоматически будет отнесена к следующему TRACK.

Поля PERFORMER и TITLE могут содержать любой набор символов заключенных в кавычки ("...") кроме самого символа кавычки (").

FILE "имя файла" ДАННЫЕ
Имя файла, содержащего данные. Может быть указано с указанием пути к файлу и обязательно заключено в кавычки. В названии файла или пути к нему не должно содержаться кавычек (")!

За именем файла обязательно должен быть указан тип данных: WAVE, MP3, BINARY, MOTOROLA, AIFF или DATA для форматов сжатия без потерь это поле должно быть WAVE, для файлов кодированных с потерями MP3. BINARY или DATA используются для записи дисков с компьютерными данными.

Для записи CD необходимо,чтобы аудио-файлы были в формате 44.1KHz 16-bit Stereo PCM обычно несжатые WAV, реже AIFF, для использования CUE в качестве плей-листа для медиа-проигрывателей и плееров это абсолютно не критично.

TRACK [номер] [тип данных]
Определяет трек, с указанием номера и типа данных. Последующие строки, такие как INDEX, TITLE и PERFORMER, предоставляют информацию касательно этого трека и могут располагаться в любом порядке.

[номер] — номер трека цифры от 1 до 99 (формат CD не допускает больше 99 треков)
[тип данных] — тип данных может быть следующих типов:

AUDIO — Audio/Music (2352)
CDG — Karaoke CD+G (2448)
MODE1/2048 — CDROM Mode1 Data (cooked)
MODE1/2352 — CDROM Mode1 Data (raw)
MODE2/2336 — CDROM-XA Mode2 Data
MODE2/2352 — CDROM-XA Mode2 Data
CDI/2336 — CDI Mode2 Data
CDI/2352 — CDI Mode2 Data

INDEX ""
Указывает начальную позицию внутри данных, где начинается данный трек, в формате ММ:СС:ФР (минута-секунда-фрейм, например 04:18:63 = 4 минуты, 18 секунд, 63 фрейма).

Максимально допустимое значение для фреймов CDDA составляет 74. Бывает двух видов INDEX 01 — указывает на начало трека и INDEX 00 — указывает "прегап" (обычно двух секундная задержка). В мульти-файловом cue файле обычно используется только INDEX 01 со значением 00:00:00. Первый по счету индекс всегда должен начинаться со значения: 00:00:00

PREGAP ""
Команда указывающая создать перед началом трека зазор в формате ММ:СС:ФР

POSTGAP ""
Команда указывающая создать за треком зазор в формате ММ:СС:ФР

эти две команды POSTGAP и PREGAP должны находится после всех комманд INDEX. Разрешено использование только одной команды POSTGAP или (и) PREGAP на трек.

ISRC ""
Международный стандартный номер аудио/видео записи (International Standard Recording Code) (ISRC), определённый ISO 3901 — международный стандартный код для точного определения уникальной аудио- или видеозаписи.

Поле может быть длинной 12 символов и содержать буквы ABCDE и цифры. В организации ISRC хранятся данные не по альбомам, а по трекам, т.е. команду ISRC можно писать после команды TRACK, но перед INDEX.

SONGWRITER ""
Если расположен в начале cue sheet то обозначает композитора всего диска, возможно использование по трекам, в этом случае команда пишется за треком.

REM REPLAYGAIN_TRACK_GAIN
REM REPLAYGAIN_TRACK_PEAK
Информация ReplayGain.

CDTEXTFILE
Позволяет добавить файл для записи CD-TEXT так CDTEXTFILE <имя файла>

FLAGS
Флаги субкода трека, могут быть четырех видов:

"PRE" — (Pre-emphasis) — самый страшный флаг. Включены пред-искажения, слушать можно только звенит сильно. Для нормального прослушивания есть деконвольверы, но эта тема для отдельной статьи, и встречается этот флаг крайне редко, хотя и "метко".
"DCP" — (Digital Copy Permited) — то есть диск не защищен от записи, копируйте на здоровье! И по идее Михалкову за такие диски с такой меткой платить не надо. Но, на домашних рекордерах в которых встроена система SCMS с используемым флагом можно будет сделать только одну копию.
"4CH" — понятно из названия, в практике я никогда не встречал.
"SCMS" — (Serial Copy Management System) — если есть такое поле диск не оригинальный, а скопированый! Эту систему использовали некоторые домашние рекордеры и редкие компьютерные приводы. Для защиты создания "копии с копии" и копии вообще.

Спецификация CUE Sheet на английском языке

А вот примеры:

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

На просторах жестких дисков встречаются несколько типов файлов cue обычно подписаных:

Non compliant — не предназначен для проигрывания (использования в качестве плей-листа) с помощью плееров (теги прописаны в самих файлах), у него единственная функция использование при записи.

Межтрековые зазоры могут указываться как в виде PREGAP 00:00:50, так и в виде двойных индексов — INDEX 00 + INDEX 01 (во втором случае cue прекрасно читается плеерами, а не только прогами для прожига типа EAC, Burrrn и Plextools Команда PREGAP также не поддерживается Nero и большинством программ для записи образов AudioCD!

Compliant — предназначен для проигрывания (использования в качестве плей-листа) с помощью плееров и находит понимание во всех прогах для прожига дисков.

ИМХО такое деление "от лукавого". Значений INDEX хватает во все времена.

Согласитесь, это то что мы искали! Он удовлетворяет всем нашим требованиям по данным. Файл очень маленький, не требует специальных программ для редактирования, легкий синтаксис, не вписывается внутрь нашего ценного музыкального файла, допускает пакетную обработку текстовыми редакторами, поддерживает UTF-8.... И в отличии от любых тегов позволяет сделать самое главное — при желании восстановить оригинальный диск, жалко, что это не со всеми типами CUE проходит.

Как водится и тут зарылись несколько минусов — не все медиа-железки и телефоны согласны работать с такими файлами, но в предыдущей статье я оговаривался, что для телефонов и МП3 с тегами ID3v2 можно пожать, было-бы из чего.

Что делать если нет cue файла — создать или загрузить из Internet, а вот чем, как и где в другой статье про софт ...

Итак я в своей коллекции (больше 5 Терра Байт) использую файлы CUE в качестве плей-листа. Вы спросите, а почему не MRU или LST, либо другие плeйлисты?

Ответ прост — большая часть файлов образы дисков которые без файла CUE воспроизвести по трекам нельзя, потому не M3U и не LST. Я стандартизировал фонотеку таким образом.

Я запретил Foobar-у грузить все расширения файлов кроме .CUE ! Таким образом получается, что имидж-файлы я воспроизвожу как обычно через cue-файл, а раздельные файлы при помощи cue-плейлиста.

Но это уже другая тема, везде должен быть порядок!
В грядующей статье.... «О "фен-шуе" в цифровой коллекции музыки».

---

Ссылки:
ru.wikipedia.org/
wiki.hydrogenaudio.org/
Как и обещал — наш ответ "кракозябрам" !
Кликабельно: