Формати файлів AIFF і AIFF-C

Фірма Apple запозичила формат IFF фірми Electronic Arts (див наступну главу) для використання на платформі Macintosh і внесла деякі зміни B результаті зявився формат, названий Audio Interchange File Format (AIFF, формат файлів для обміну аудіо) Оригінальний AIFF не підтримував стислі аудіодані, тому був розроблений ще один варіантAudio  Interchange  FiIe Format  Extensionfor  Compression  (AIFF-C або AIFC, формат файлів для обміну аудіо з підтримкою компресії) Файли AIFF і AIFF-C майже ідентичні, тому все, що говориться про AIFF, в рівній мірі відноситься і до AIFF-C Відмінності я розгляну особливо

Структура файлу AIFF така ж, як і у файлу RIFF (див попередню главу) Однак файли AIFF зберігають багатобайтові значення у формі MSB і використовують інші назви блоків

Файли AIFF складаються з єдиного зовнішнього блоку FORM Тип цієї форми AIFF або AIFC B її складу можуть входити деякі або навіть всі блоки, перераховані в табл 181 Найважливішими є блоки COMM і SSND, представлені у всіх файлах AIFF і AIFF-C, і блок FVER, що зустрічається у всіх файлах AIFF-C

Таблиця 181 Блоки AIFF

Тип блоку Опис

FVER Версія файлу AIFF-C

COMM Інформація про формат зберігання звуку

SSND Звукові дані

MARK Маркер

COMT Коментар INST Інструмент MIDI Дані MIDI

AESD Інформація про запис

APPL Блок, вміст якого відноситься до додатка

NAME Імя

AUTH Автор

(С) Інформація про авторські права

ANNO Анотація

Так як AIFF і AIFF-C майже ідентичні, цікаво, чому взагалі існує AIFF-C B файлах AIFF, як і в більшості варіантів IFF, передбачається, що процедура читання ігнорує будь дані, які не може розпізнати B Зокрема, якщо ви додаєте нові типи блоків або нову інформацію в кінець області існуючого типу, ці дані будуть ігноруватися старими процедурами читання Оригінальний формат AIFF не визначає метод стиснення Щоб додати його, довелося б додавати новий тип блоків або розширити існуючий тип COMM (в блоках цього типу міститься інформація про звуковому форматі) B будь-якому випадку старі процедури читання ігнорували б цю інформацію і намагалися б програти дані, не використовуючи відповідний декомпрессор

Щоб обійти дану проблему, інженери Apple були змушені визначити новий контейнерний тип FORM / AIFC Так як цей тип відмінний від інших, старі програвачі не зможуть знайти і коректно програти файл Нові програвачі, які розпізнають обидва контейнерних типу, можуть подивитися код типу компресії, доданий в область COMM, і, як наслідок, працювати з двома контейнерними типами майже однаково

Інженери, які розробили AIFF-C, врахували свою колишню помилку, вони додали в специфікацію блок FVER Цей блок містить код, заснований на даті створення відповідної специфікації

Якщо процедура читання файлу не розпізнає даний код, їй не слід програвати файл, так як для цього треба розуміти нові дані Зміни в коді FVER повинні бути незначними за сім років з моменту появи AIFF-C необхідності в його модифікації взагалі не виникало

Джерело: Кінтцель Т Керівництво програміста по роботі зі звуком = A Programmers Guide to Sound: Пер з англ М: ДМК Пресс, 2000 432 с, іл (Серія «Для програмістів»)

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*