Конвертер SFL-TXT
[ English ]
[ На русском ]
Формат SFL
Формат SFL является производным от формата RIFF, только вместо звука в чанках находятся метки и другая информация. Ниже я кратко изложу, как устроены файлы SFL, которые создает Sound Forge 4.5. Вдруг кому-то понадобится эта информация, а из документальных свидетельств у меня к тому времени останется только исходный код конвертера. Я уже изрядно подзабыл, впрочем, что к чему, так что могу что-то напутать. На всякий случай, я не буду поэтому называть функцию меток вроде "RIFF" или "ltxt", потому что могу ошибиться в терминах, и выйдет конфуз.
В файле могут описываться сущности двух типов: метки и регионы. У меток есть начальная точка и нет длительности, а у регионов есть. Впрочем, с точки зрения формата, метка первична и описывается всегда. А регион описывается как сочетание описания соответствующей метки и размера региона. Поэтому у чистых меток в файле по две записи на каждую, а у регионов - по три.
Длина и положения фрагментов указываются в единицах дискретизации, т.е (1/частота_дискретизации) секунд. Надо, наверное, не наводить тень на плетень и сказать, что они указываются в штуках колебаний, но меня эта формуировка смущает.
Заголовок:
- 4 байта - "RIFF"
- 4 байта - размер остального файла, в байтах
- 4 байте - "SFPL", что это значит, я не знаю, но подозреваю, что не San Francisco Public Library, а Sound Forge что-то что-то.
Заголовок отдела CUE:
- 4 байта - "CUE "
- 4 байта - размер оставшейся части отдела в байтах (удобно вычисляется по формуле 24 * количество_элементов + 4)
- 4 байта - число элементов, в штуках
Для каждого элемента в отделе CUE описывается его начальное положение и id:
- 4 байта - идентификационный номер. Судя по всему, они назначаются последовательно в порядке создания меток.
- 4 байта - начальное положение элемента, в единицах дискретизации
- 4 байта - "data", тип чанка
- 4 байта - всегда 0 - по документам "chunk start"
- 4 байта - всегда 0 - по документам "block start"
- 4 байта - совпадает со вторым полем (начальным положением элемента). Из описания RIFF я вынес, что второе поле называется "порядок воспроизведения", а последнее - "смещение сэмпла". Почему используются оба и что будет, если значения в них не совпадут, я не знаю.
Заголовок контейнера "список":
- 4 байта - "LIST"
- 4 байта - размер оставшейся части списка (следующее поле включается в счёт)
- 4 байта - "adtl"
Для каждого региона (все регионы описываются подряд в начале списка, затем подряд все метки):
- 4 байта - "ltxt"
- 4 байта - размер оставшейся части записи, всегда 20 из-за фиксированной длины полей и их количества
- 4 байта - идентификационный номер
- 4 байта - длина фрагмента, в единицах дискретизации
- 4 байта - "rgn ", идентификатор региона
- 4 байта - всегда 0
- 4 байта - всегда 0, назначение этих двух полей для меня неясно
Для каждой метки (соответственно, для всех элементов, регионы ли они или нет):
- 4 байта - "labl"
- 4 байта - размер записи (длина поля с id и строки в поле с меткой)
- 4 байта - идентификационный номер
- Поле произвольной длины - текст метки. Если поле с текстом метки получается нечётной длины, добавляется 1 пустой байт, который не идёт в счёт размера (могу ошибаться).
Итого:
- Для каждого элемента разметки надо сделать запись в CUE, где описывается положение её начала;
- Если элемент - регион, то сделать запись в контейнере LIST с указанием его длины;
- Сделать запись в контейнере LIST с текстом метки.