From: Mikhail Yakshin <greycat@altlinux.org> To: ALT Linux Sisyphus discussion list <sisyphus@altlinux.ru>, ALT Devel discussion list <devel@altlinux.ru> Subject: [devel] I: Russian and Unicode ID3 tags Date: Wed, 03 Aug 2005 02:38:01 +0400 Message-ID: <42EFF5C9.2080203@altlinux.org> (raw) Приветствую всех! Извиняюсь за кросспост, просто меня уже не такое уж маленькое число людей просило дописать эту статью, и вот я ее выкладываю, надеясь на некий резонанс. Буду рад любым замечаниям, предложениям и вообще помощи. Предисловие =========== Так получилось, что у меня выдалось сколько-то свободного времени и я решил немножко позаниматься всякими около-юникодными делами, начав с того, что поставил себе локаль ru_RU.UTF-8 и решив немножко поразбираться с тем бардаком, который я подспудно подозревал, наличествует в том, что в mp3-файлах называется тэгами ID3. Тогда я даже близко не подозревал о размерах этого самого бардака. Начну издалека. Ogg/Vorbis ========== Есть хороший и замечательный по всех отношениях, но относительно малораспространенный формат Ogg/Vorbis. В нем возможность вставлять метаинформацию в файл сделана ужасно просто, тупо, но зато работает везде и всегда. В начало файла вставляются пары "имя=значение", где список "имен" - well known, т.е. есть те, которые зафиксированы стандартом и их понимают все, а те приложения, которым нужно, могут добавлять свои расширения. Значения всегда являются текстовыми юникодными строчками, закодированные в utf8. Работает железно, за исключением, может быть, самых сильно мозгоповрежденных приложений, принимающих utf8 за usascii, но им ничего не поможет вообще. Разнообразие ID3 ================ С mp3 все, к сожалению, на порядки хуже. Тем, кто придумывал тэги ID3, стоит оторвать все, что только можно, только не поможет уже: стандарт закреплен, плодить и пытаться внедрять новые стандарты сейчас - фактически нереально. Стандарт повествует нам о том, что если только брать современные, не вымершие еще повсеместно варианты тэгов, есть как минимум id3v1 и id3v2 - это знают почти все, даже многие знают, чем они отличаются. На самом деле все хуже. Бывает как минимум id3v1, id3v1.1, id3v2.3 и id3v2.4, которые друг с дружкой не очень совместимы. Дальше - еще хуже. С id3v1.* все понятно - полудохлый стандарт, умеет только фиксированное количество полей небольшой длины и только в 8-битной кодировке, как правило, совпадающей с 8-битной национальной кодовой страницей локальной системы (хотя стандарт декларирует там использование только кодировки iso8859-1). С id3v2.* все хуже: стандарт дает возможность для каждой текстовой строчки определить свою кодировку. В состав кодировок входят, как ни странно, iso8859-1, utf16-be, utf16-le и utf8. Наиболее распространенным вариантом, особенно для русских тэгов, без сомнения, является вариант записи их в 8-битной национальной кодировке системы (для русских - это windows-1251) в тэг формата id3v2.*, указав кодировку iso8859-1. Это формально не соответствует стандарту вообще, но де-факто - это уже давно так. В Windows-системах 8-битная кодировка задается тупо, соответствующей 8-битной кодовой странице (для русского языка - только windows-1251), в почти всех железных плеерах есть некий выбор региона, который, в частности и устанавливает эту кодировку. Анализ бардака с помощью test suite =================================== К сожалению, фришный софт отнюдь не всегда учитывает эти реалии. Да по большому счету - и проверить-то это толком не проверишь - потому как зайдя на http://www.id3.org/ можно увидеть, что у них планируется некий test suite, но он еще в разработке, да и потом, когда будет - он будет за деньги. Поэтому как первый шаг разбирательства в этом бардаке я создал свой test suite. Он представляет собой набор маленьких mp3-файлов с различными тэгами. Файлы называются так: [язык]-[версия ID3]-[кодировка].mp3 [язык] - это "rus" для русских тэгов (использующих символы кириллицы) и "fra" для "псевдофранцузских" тэгов (использующих символы набора latin1, в том числе не только usascii); [версия ID3] - это "1" для 1.x, "23" для 2.3, "24" для 2.4; [кодировка] - это "iso8859-1", "utf16-le", "utf16-be" и "utf8"; Не все комбинации возможны, допустимы или интересны для исследования. Те файлы, что находятся в директории non-standard - нестандартны и их поддержка не обязательна. Как это работает ================ Работает это на самом деле очень просто: вся пачка файлов загружается в исследуемый продукт и смотрится, какие файлы прочитались, какие - нет. Для файлов с русскими тэгами должны появляться легко опознаваемые фразы на русском языке ("Русский трек" - "Русский альбом" - "Русский артист"), для файлов с псевдофранцузскими тэгами должны появляться тэги с обилием символов с диакритическими значками - точечками, кружочками и прочими загогулинами. Для тэгов, записанных в 8-битной кодировке (помеченных как iso8859-1), в случае русских тэгов в продукте должна быть выставлена русская перекодировка, в случае псевдофранцузских - французская или паневропейская. Обращаю внимание на то, что тестируется _чтение_ тэгов из файлов, а никак не возможность записи. Сам test suite можно взять здесь [4K]: http://www.lrn.ru/~greycat/suite.zip Результаты тестирования ======================= То, что выяснилось в результате, можно посмотреть в tab-separated файле-табличке здесь: http://www.lrn.ru/~greycat/compat.txt Результаты неутешительны. Более-менее прилично умеет обращаться с тэгами из протестированного софта только виндовый freeware foobar2000. Он же умеет писать большинство вариантов тэгов и имеет вменяемые переключатели, в каком формате читать и писать. В Unix-системах к нему приближаются eyeD3 на Python и приложения на libtag. И первым, и вторым мешает отсутствие перекодировки 8-битных кодировок не только в де-юре стандартной iso8859-1. Такие популярные плееры, как xmms, winamp2 и Windows Media Player - терпят сокрушительное поражение. Некоторые версии тэгов в файлах приводят даже к полной нечитаемости этих файлов в некоторых из плееров. Выводы ====== Так как наша задача не просто предаваться унынию, а как-то это фиксить и идти дальше, по этому поводу возникают следующие мысли: 1. Необходимо оттестировать как можно больше приложений и железок с целью выяснения наиболее адекватных на данный момент форматов. Пока мне оными представляются: * для русских и чистых usascii тэгов - id3v2.3 или 2.4 в windows-1251, замаскированной под iso8859-1; * для всех остальных тэгов - id3v2.4 в utf16-le; Здесь я был бы рад любой помощи. Если у вас есть какие-то приложения и железки, которые я не охватил - тестируйте и присылайте изменения к моей табличке, пожалуйста. 2. Необходимо создать хотя бы одну полноценно работающую библиотеку. На данный момент у нас есть: * libid3tag - очень древняя штука, толком ничего не умеет; к сожалению, некоторый софт ее до сих пор использует; * id3lib - ужасная поделка, работает только с ID3, не поддерживает ID3v2.4 вообще, заброшена уже несколько лет как; к сожалению, достаточно популярна, например, перспективный для некоторых плеер beep, а также тэггер EasyTag пытаются ее использовать; * taglib - наиболее перспективная с моей точки зрения библиотека, хотя и обладает рядом недостатков и не очень вменяемым апстримом, думаю, можно будет довести ее до ума. В качестве достоинств стоит назвать относительно нормальную объектную модель и большое число приложений уже завязано на нее (в том числе - KDE, amarok и Juk). По сути, от библиотеки нам требуется: 1) Некая глобальная - лучше всего не зависящая от приложений перекодировка 8-битных тэгов, и ID3v1, и ID3v2. В некоторых приложениях, например, amarok, такая перекодировка сделана, но только для ID3v1 тэгов. Предлагаю сделать некий конфиг, вроде ~/.tagrc, откуда библиотека будет получать строчку настройки вроде "8bitencoding = windows-1251" и руководствоваться ею для всех приложений. 2) Вменяемые утилиты командной строки, уважающие установки локали терминала пользователя, корректно выводящие, скажем, и 8-битные, и юникодные тэги и в ru_RU.UTF-8, и в ru_RU.KOI8-R. Сейчас в taglib есть tagreader / tagwriter, которые это делают, но они работают нормально только с usascii тэгами. И все. 3. Необходимо исправить некие переходные границы в районе KDE/Qt/QString, где почему-то происходит преобразование в 8-битную кодировку и всякие умляуты превращаются в русские буквы. Думаю, это мелкая техническая проблема, решаемая относительно просто - здесь хотя бы нет никаких идеологических решений. Баги в Сизиф я повешу скоро, если zerg@ не успеет быстрее это пофиксить. 4. Необходимо просмотреть внимательно список совместимости, получившийся на 1 этапе и вычистить Сизиф от совершенно ненужных приложений, дублирующих друг друга, да при этом еще и не проходящих по test suite. Первые кандидаты на выкидывание - mp3info, id3v2, xmms, kid3, id3editor. Вторые в ряду - beep, easytag, moc, lamip, orpheus - если они кому-то нужны, то их, видимо, стоит достаточно срочно фиксить так, чтобы они поддерживали весь test suite - самым простым будет, видимо, переделка их на работу с "правильной библиотекой" из п.1. Разумеется, крайне желательно пропихнуть этот глобальный переворот в апстрим. Rationale таких жестких мер очень прост: я хочу быть уверен в том, что если я передаю какие-то файлы человеку, который тоже использует Сизиф, но у него не такой плеер, как у меня - он гарантированно увидит мои тэги. Неподдерживание стандартных (как де юре, так и де факто) тэгов - major bug. 5. От приложений, выполняющих кроме работы с тэгами какие-то другие полезные функции, например, mpg123 - стоит отодрать поддержку чтения ID3-тэгов, чтобы не смущать народ. В том же mc сделать чтение ID3-тэгов через вменяемые утилиты командной строки, разработанные в п.1, а не через mpg123. 6. В некоем гипотетическом светлом будущем - свести всю работу с тэгами в одну библиотеку, а все старые и дублирующиеся библиотеки - изъять из Сизифа. Все приложения будут иметь user-friendly дефолты, типа тех, что я указал выше. MusicBrainz =========== Параллельно я собираю новый MusicBrainz-тэггер - Picard, который, разумеется, умеет тоже работать только в стандартных iso8859-1, utf16 и utf8. Он требует неимоверного количества библиотек и работа идет очень медленно, но когда он появится в Сизифе - можно будет полноценно обрабатывать свои коллекции через MusicBrainz. Список литературы ================= 1. http://www.id3.org/develop.html 2. http://id3lib.sourceforge.net/ 3. http://developer.kde.org/~wheeler/taglib.html 4. http://www.musicbrainz.org/ -- WBR, Mikhail Yakshin AKA GreyCat ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]
next reply other threads:[~2005-08-02 22:38 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-08-02 22:38 Mikhail Yakshin [this message] 2005-08-03 7:36 ` [devel] I: Russian and Unicode ID3 tags -- Stop The Madness Mikhail Zabaluev 2005-08-03 8:36 ` Vital Khilko 2005-08-03 8:00 ` [devel] I: Russian and Unicode ID3 tags Kirill A. Shutemov 2005-08-03 8:43 ` Mikhail Yakshin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=42EFF5C9.2080203@altlinux.org \ --to=greycat@altlinux.org \ --cc=devel@altlinux.ru \ --cc=sisyphus@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git