Комментарии 19
С качеством кода поможет заливка на Github, где через Pull Requests вам помогут исправить ваш код.
А чем обусловлен выбор инструмента? Почему бы не переиспользовать что-то более распространённое для этой цели, скажем тот же kaitai struct, там же сразу и парсер нагенерится.
Поверьте, разбираться, хранить миди, аудио и прочие файлы в них гораздо проще.
И, кстати, на чём вы хранили тысячи заготовок?
Подход в целом немного странный. Если прокололи колесо — неужели нужно изучать сопромат резины?..
Я признаю что это спорный подход. Но я не профессиональный музыкант, думаю это простительно. На данный момент, я хочу перейти к более осознанному и организованному процессу, поэтому и занялся тем что описано в статье
Заготовки хранились на карте памяти с периодическим бэкапом на ПК. По размеру они побольше чем миди, но все равно занимают совсем немного места. Опять же, подчеркну — что это только наброски. Когда я дозревал до полноценной записи, конечно я использовал DAW.
А существуют для него редакторы+визуализаторы в виде интегрированной среды? Не в виде веб.
Хорошо всё-таки, что файл никак не упакован и не зашифрован, думаю, даже простейший xor сильно испортил жизнь
Интересный подход сразу шариться в готовых файлах и пытаться что-то оттуда извлечь.
Я бы декомпозировал. Записал бы файл из единственной ноты. Потом из другой ноты. Потом из ноты другой длительности — и т.д., и смотрел бы, что меняется в выходных байтиках.
Когда-то давно я примерно так написал PPD для печати из-под линукса на Ricoh Aficio 450 — перехватывал задания для печати из-под windows с разными параметрами-настройками входных лотков, дуплекса, степлера и т.д. — и делал аналогично под линуксом.
Не так важно, что именно записано в файле; важно, в чём внутреннее отличие от другого файла с заданным визуальным отличием.
Ну а редакторов с поддержкой темплейтов сейчас пруд пруди. Уже 10 лет назад попадался что-то вроде 010 editor, где тоже на встроенном с-подобном языке можно было внятно описать структуру файла
Я бы декомпозировал. Записал бы файл из единственной ноты. Потом из другой ноты. Потом из ноты другой длительности — и т.д., и смотрел бы, что меняется в выходных байтиках.
В продолжении я опишу этот подход. Проблема в том, что данный формат может содержать несколько фрагментов данных, т.е. несколько «песен». Каждая песня состоит из треков. Треки содержат такты. Во всей этой структуре также пришлось разобраться. Кроме непосредственно информации о нажатии нот в блоке данных хранятся метаданные, поэтому прямое сравнение ничего не давало. Даже два пустых трека без нот, но разной длительности будут значительно отличаться.
Реверс-инжиниринг бинарного формата на примере файлов Korg .SNG