Dark

MpaKus Dominion - блог о кино, музыке и веб-программировании

несколько жизненных трендов

Previous Entry Поделиться Next Entry
Как на самом деле плохо запроектированы вокруг нас вещи, на примере формата MP3
Dark
mpak666
В общем-то всего спроектировать и построить правильно нельзя с первого раза нельзя. Ну вот вообще ничего... Что там говорить о сложных конструкторских решениях двигателей или архитектурных сооружений, взять простейший пример: MP3 файлы, к которым мы уже привыкли как к родным и слушаем уже с десяток лет. MP3 тот самый злейший убийца AUDIO CD!

Нам кажется, что так просто кинул *.mp3 файл себе в плэйер (я не считаю мерзкий тунец плэйером) и тут же вместо 06-pope-burn-in-hell.mp3 становится для вас например: Slayer - Reign in Blood (thrash-metal). То есть "магическим" образом ваш плэйер узнает какая великая группа играет какую песню в каком году и на каком альбоме + даже стиль. Многие уже просекли слово "тэги", да это просто кто-то из цифровавших диск задал описание и теперь они лежат внутри файла. Где-то и как-то внутри, ну вы поняли.

Вот тут и подошли к самому интересному. Я тут немного попилил и думал, что закончу за пару часов одно дельце, но затянулось это на 2 дня с переменным успехом конечно на нормальную работу. Занимался я тем, что пытался восстановить как же внутри mp3 файла хранится эта самая информация, были проблемы что сайт id3.org лежит и пришлось читать его через вебархив.

И тут про "проектирование" формата мне открылись его больные места. Напомню, что еще Билл Гейтсу приписываемые слова при выпуске его MS-DOS звучали: "640 kb хватит всем".
Это как бы фэйл. Но видимо фэйлы никого не учат. Берем лопату в виде hex редактора и копаем в историю mp3 формата.

id3


Вот предумали гении формат сжатия, устроили ему контейнер и назвали mp3 пусть это возможно не исторически верно, но все же.
Решили положить туда информацию внутрь, тэги, это Артиста, Название песни, Альбом, Год, Жанр, Комментарий.
И тут решили, что 128 байт хватит, ну и выделили с конца файла те самые 128 байт, по 30 байт на текстовые а-ля Название, Артиста, Альбом, на Жанр числовой код в 2 байтика и Комментарию еще 30. Туда сюда, вот и 128 байтиков.
И ведь жеж понятно, ну что такое 30 байт? ОК, это 30 букв в стандартной например ASCII кодировке, а и но! Ведь весь мир не анлоязычен, есть море языков от самого распространенного испанского до русского, китайского и прочих. Сразу урезаем до 15 символов при UTF-8 и в худжем случае до 7-8 при UTF-16. 7 - букв (иерогливоф) на название песни вы представляете? Я тоже, считаю это мало, очень мало...

id3v1


Гениальные инженегры ничего более глупого не придумывают как ввести еще один блок, расширяющий предыдущий id3 и называют его id3v1 дают туда 227 байт и засовывают опять от конца файла перед тем блоком, итого fseek где-то -(227+128) выходит. И опять мало!
Да и ладно бы мало, появляется еще одна неучтенная при проектировании проблема - потоки! Да, музыку начинают слушать по сети и как вы пониманиете в нашем случае чтобы узнать какая это песня и кто поет, нам надо дождаться пока весь mp3 файл скачается и тогда можно будет заглянуть ему под "хвост". Это плохо, очень плохо.

id3v2.3 - id3v2.4


И тогда придумывают опять новый формат хранения тэгов внутри бедных mp3 файлов. Теперь это блок неограниченного размера, начинается сначала и подразумевает внутреннюю кодировку с запасом на японцев (UTF-16). Там все просто в общем-то в начале файла 10 байт заголовок, по нему мы определяем это тэговый блок (сигнатура ID3 в самом начале файла скорее всего говорит, что это mp3), дальше типа минорная и мажорная версия по байту, потом общий размер блока. А дальше пошли простые структурки фрэймов или тэгов: 4 байта на идиотские название, например APIC или TIT2 с ходу хрен догадаешься, но это attachment picture и title почему 2 я не знаю. Дальше 4 байта на размер текстового значения (V_SIZE), 2 байта на служебный флаг и 1 байт на указание кодировки текста, а потом уже сам текст размером V_SIZE байт. Все просто в общем-то, но...

Чем 2.3 от 2.4 отличается я не шибко уловил, только, что добавили возможность вкладывать в mp3 файл картинку - это раз (!!!) и лирику песни - это два.

Чем и тут я недоволен в проектировании?
- Может быть конечно это удобно когда скачал один файл mp3, а у тебя внутри и картинка и текст, текст ладно пусть будет. Но картинка?! Вы понимаете, что если у вас альбом лежит в папочке, а там 13 песен, а в каждой песне еще по 500кб. png картинка (а размер не редкость), то ведь это почти на 7 мб. больше пришлось бы качать по модему, трафик. Конечно винты большие, скорости дикие и "ВСЕМ ХВАТИТ", опять же на мой взгляд уж можно было решить проблему лучше, вынести файл в папку или сделать ссылку на мировой ресурс обложек и т.д.
Но не пихать все внутрь файла, похоже кстати на моду на nosql запилить внутрь и засунуть все в одно.
- Ну и второй момент, вы же уже поняли, что теперь внутри 1-го mp3 файла у вас будет лежать целых 3 версии как оформлены тэги! Это 128 байт с конца ID3 + 228 байт перед ними это ID3v1 и еще туева-хуча байт в начале это будет ваш ID3v2.x И все это надо уметь читать, конвертить, проверять и показывать. Потому и например некоторые плэйеры правильно показывают тэги файла, а кидаешь на другой уже нет, один умеет читать одну версию, другой нет.

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

p.s. Всем спасибо, а либу для более или менее работающего варианта получаения ID3 и ID3v2.x я написал, задача была на PHP потому и на PHP она, один простой класс, обязательно ее подчищу и доведу до красоты приемлимой и выложу на http://github.com/mpakus

p.p.s & upd: класс выложил, в целом более или менее сносно и приемлимо работает, брать тут https://github.com/mpakus/mp3meta


  • 1
Я тоже когда возился с задачкой переименования файлов в локальной коллекции (педант-с) по информации в ID3 тегах - долго недоумевал, почему бы с ID3v2 не перестать поддерживать уебанство в виде id3 и id3v1 )

А обложки - ну да, но зато оффлайн плееры отображают, типа круто - слушаешь песню, на обложку любуешься :)

Ну да, тоже думал, что почему бы не держать последнюю версию и просто иметь бесплатный конвертер внутри плэйера или вообще. Т.е. дали mp3шку со старым id3 он тебе в фоне переписал на id3v2.4 и радостно показал тэги уже из нового варианта. И т.д.

Про облоги я тоже думал, пока сам не понимаю, вроде удобно конечно хранить внутри файла, но это жеж как расточительно! По идеи было бы круто иметь некий пиринговый формат, чтобы на фид он был а-ля jar (gem) - обычный зазипованный файл, где отдельно лежит: mp3 - файл потока, tags.yml - вся инфа о трэке, когда и кем записан, ссылка на сайт и т.п., отдельно lyrics.markdown - файл текста, cover.(jpg|png|gif) - файл облоги, и клип video.(avi|mp4|3gp....), present.html + present.js - это презентуха или эффекты на js для создания настроения.. было бы вообще шикарно!

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

Edited at 2013-09-18 19:24 (UTC)

Делали как-то поисковик по mp3-файлам, лежащим в свободном доступе. Вот там я конечно расстроился, когда узнал, что придётся скачать несколько миллионов mp3 полностью, чтобы теги прочитать.

Восхищен проведенной работой)

А я вот чего-то удивлён, что не появились общепризнанные форматы "пачка mp3шек". Ну там чтобы весь альбом одним файликом (с кучей метаданных). Или всю дискографию.

Да-а-а, что-то со стандартами у людей вообще проблема договориться. Ну а так "пачка mp3шек" - это очень похоже на APE если я правильно понимаю.

Я не сомневаюсь, что такие форматы есть. Странно, что нет общепризнанных.

  • 1
?

Log in

No account? Create an account