Скачать PDF

ГОСТ Р 53556.5-2013. Национальный стандарт Российской Федерации. Звуковое вещание цифровое. Кодирование сигналов звукового вещания с сокращением избыточности для передачи по цифровым каналам связи. Часть III (MPEG-4 audio). Структурированное кодирование звуковых сигналов (SA)

Федеральное агентство по техническому регулированию и метрологии · № ГОСТ Р 53556.5-2013Действующий акт

Актуально на 02.11.2026.

Как цитировать: "ГОСТ Р 53556.5-2013. Национальный стандарт Российской Федерации. Звуковое вещание цифровое. Кодирование сигналов звукового вещания с сокращением избыточности для передачи по цифровым каналам связи. Часть III (MPEG-4 audio). Структурированное кодирование звуковых сигналов (SA)". ГОСТ Р 53556.5-2013. https://bukva.ai/docs/standart-gost-r-53556-5-2013

(утв. и введен в действие Приказом Росстандарта от 22.11.2013 № 1785)

Примечание

Документ введен в действие с 1 сентября 2014 года.

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 22 ноября 2013 г. № 1785

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЗВУКОВОЕ ВЕЩАНИЕ ЦИФРОВОЕ

КОДИРОВАНИЕ СИГНАЛОВ ЗВУКОВОГО ВЕЩАНИЯ С СОКРАЩЕНИЕМ ИЗБЫТОЧНОСТИ ДЛЯ ПЕРЕДАЧИ ПО ЦИФРОВЫМ КАНАЛАМ СВЯЗИ. ЧАСТЬ III (MPEG-4 AUDIO)

СТРУКТУРИРОВАННОЕ КОДИРОВАНИЕ ЗВУКОВЫХ СИГНАЛОВ (SA)

Sound broadcasting digital. Coding of signals of sound broadcasting with reduction of redundancy for transfer on digital communication channels. A part III (MPEG-4 audio). Structured audio (SA)

ISO/IEC 14496-3:2009 (NEQ)

ГОСТ Р 53556.5-2013

ОКС 33.170

Дата введения 1 сентября 2014 года

Предисловие

1 РАЗРАБОТАН Санкт-Петербургским филиалом Центрального научно-исследовательского института связи «Ленинградское отделение» (ФГУП ЛО ЦНИИС)

2 ВНЕСЕН Техническим комитетом по стандартизации № 480 «Связь»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 ноября 2013 г. № 1785

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО/МЭК 14496-3:2009 «Информационные технологии. Кодирование аудиовизуальных объектов. Часть 3. Аудио» (ISO/IEC 14496-3:2009 «Information technology — Coding of audio-visual objects — Part 3: Audio») (NEQ) [1]

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

1 Область применения

1.1 Обзор

1.1.1 Назначение

Комплект инструментальных средств структурированного аудио дает возможность передавать и декодировать синтетические звуковые эффекты и музыку, нормируя несколько различных компонентов. Используя структурированное аудио, может быть создан высококачественный звук при чрезвычайно низкой пропускной способности. Типичная синтетическая музыка для чрезвычайно тонкого выразительного исполнения с использованием многочисленных инструментов может быть кодирована в формате на скоростях передачи в пределах от 0 Кбит/с до 2 или 3 Кбит/с.

MPEG-4 стандартизирует не определенный набор методов синтеза, а метод для описания методов синтеза. Любой современный или будущий метод синтеза звука может быть описан в формате MPEG-4 структурированное аудио.

1.1.2 Введение в главные элементы

В комплекте инструментальных средств структурированного аудио есть пять главных элементов:

1. Язык оркестра структурированного аудио или SAOL. SAOL является языком обработки цифровых сигналов, который позволяет описывать произвольные алгоритмы синтеза и управления как часть потока битов контента. Синтаксис и семантика SAOL стандартизируются нормативным способом.

2. Язык оценки структурированного аудио или SASL. SASL является простым языком оценки и управления, который используется в определенных типах объектов для описания способа, который используют алгоритмы генерации звука описанные в SAOL, для воспроизведения звука.

3. Формат банка сэмплов структурированного аудио, или SASBF. Формат банка сэмплов позволяет передавать банки аудиосэмплов, которые будут использоваться в табличном синтезе, и описание простых алгоритмов обработки, чтобы пользоваться ими.

4. Нормативное описание планировщика. Планировщик является диспетчерским элементом во время выполнения процесса декодирования структурированного аудио. Он отображает структурное управление звуком, определенное в SASL или MIDI, и диспетчеризированные события в реальном времени, используя нормативные алгоритмы генерации звука.

5. Нормативная ссылка на стандарты MIDI, стандартизированные внешне MIDI Manufactures Association. MIDI является альтернативным средством структурного управления, которое может использоваться в сочетании с или вместо SASL, хотя и менее мощное и гибкое чем SASL. Поддержка MIDI в этом стандарте предоставляет важную обратную совместимость с существующим контентом и инструментами авторинга. Поддержка MIDI в этом стандарте состоит из списка распознаваемых сообщений MIDI и нормативной семантики для каждого.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на ГОСТ Р 53556.0-2009 «Звуковое вещание цифровое. Кодирование сигналов звукового вещания с сокращением избыточности для передачи по цифровым каналам связи. Часть III (MPEG-4 audio). Основные положения».

3 Термины и определения

В настоящем стандарте применены термины и сокращения с соответствующими определениями, используемые в ГОСТ Р 53556.0-2009.

4 Символы и сокращения

4.1 Математические операции

Используемые математические операторы, подобны используемым в языке программирования C:

+ дополнение
- вычитание
x или * умножение
/ деление
Exp экспоненциальная функция exp (основание e),
log натуральный логарифм
log 10 десятичный логарифм
abs абсолютное значение
floor (x) наибольшее целое число, меньшее чем или равное x
cell (x) наименьшее целое число, большее чем или равное x
> больше чем
< меньше чем
> = больше чем или равно
<= меньше чем или равно
<> или != не равно

4.2 Методы описания

4.2.1 Синтаксис потока битов

Синтаксис потока битов структурированного аудио описывается, используя SDL MPEG-4 Sintactic Description Language.

4.2.2 Синтаксис SAOL

Текстовый синтаксис SAOL описывается, используя нотацию расширенного формата Backus-Naur (BNF). BNF является описанием для контекстно-свободных грамматик языков программирования.

Грамматики BNF составляются из терминов, также называемых маркерами (символами). Термины представляют синтаксические элементы языка, такие как ключевые слова и пунктуацию. Правила описывают комбинирование этих элементов в структурные группы.

Правила подстановки, которые отображают продукты в последовательностях других продуктов и терминов, представляются символом — >.

Также описаны правила подстановки, использующие дополнительные элементы, с использованием символов []. Использование этой нотации не увеличивает возможности описания синтаксиса, но делает определенные конструкции более простыми.

Грамматика (начиная с символа seqhead) описывает, в дополнение к установленному выше, все строки, начинающиеся с символа 'c' и с последующей последовательностью 'a's и 'b's.

Маркер NULL может использоваться, чтобы указать, что последовательность никаких символов (пустая строка) является допустимой перезаписью для определенного продукта.

Другие символы, такие как ellipsis (...), будут использоваться тогда, когда их значение будет ясным из контекста.

4.2.3 Синтаксис SASL

Синтаксис SASL определяется, используя расширенные грамматики BNF.

5 Синтаксис потока битов и семантика

5.1 Введение в синтаксис потока битов

Этот подпункт описывает формат потока битов, определяющий поток битов структурированного аудио MPEG-4.

Каждая группа классов записывается с нормативной семантикой, которая определяет значение данных, представленных этими классами.

5.2 Синтаксис потока битов

/******************************
Symbol table definitions
******************************/
Class symbol {
unsigned int (16) sym;
}		//no more than 65535 symbols/orch + score
Class sym_name {//one name in a symbol table
unsigned int (4) length;//names up to 15 chars long
unsigned int (8) name [length];
}
class symtable {//a whole symbol table
unsigned int (16) length;//no more than 65535 symbols/orch+score
sym_name name [length];
}

Поток битов может содержать таблицу символов. Таблица символов позволяет текстовому коду SAOL и SASL быть восстановленным из маркированного представления потока битов. Включение или исключение таблицы символов не влияют на процесс декодирования.

Если таблица символов включена, то все или некоторые из символов в оркестре и таблице должны быть ассоциированы с текстовым именем следующим образом: каждый символ (символ является только целым числом) должен быть связан со строкой символов, соединенной с этим символом в объекте sym_name. С данным символом должно быть ассоциировано не более одного имени, иначе поток битов недопустим. Допустимо для таблицы символов быть неполной и содержать имена, ассоциированные с некоторыми, но не всеми, символами, используемые в оркестре и таблице. Присутствие строки нулевой длины в записи таблицы символов указывает, что имя для этого символа не включается в таблицу символов.

Реализации SAOL и SASL, которые требуют текстового ввода, а не маркируемого ввода, допустимы в декодере совместимости. Тогда декодер может демаркировать поток битов прежде, чем он будет обработан. В этом случае любые символы без ассоциированных имен предполагаются ассоциированными с именем по умолчанию формы _sym_x, где x является значением символа. Имена этой формы с этой целью резервируются в SAOL, и таким образом гарантируется, что имена не будут приходить в противоречие с именами символа, определенными с помощью таблицы символов.

/*********************************
orchestra file definitions
**********************************/
class orch_token}
int done;		// a token in an orchestra
unsigned int (8) token;
switch (token) {		// see standard token table, Annex A
case 0xF0://a symbol
symbol sym;
break;		// the symbol name
case 0xF1:// a constant value
float (32) val;
break;		// the floating-point value
case 0xF2:// a constant int value
unsigned int (32) val;
break;		// the integer value
case 0xF3:
int (8) length;		// a string constant
unsigned int (8) str [length];
break;		// strings no more than 255 chars
case 0xF4;
int (8) val;
break;
case 0xFF://end of oech
done = 1;
break;
}
}
class orc_file {
unsigned int (16) length;
orch_token data [length];
}		// a whole orch file

Файл оркестра (планировки) является строкой маркеров. Маркеры представляют собой синтаксические элементы, такие как зарезервированные слова, базовые имена кода операции и знаки препинания. Кроме того, есть пять специальных маркеров. Маркер 0xF0 является маркером символа. Когда он встречается, следующие 16 битов в потоке битов должны быть номером символа. Маркер 0xF1 является маркером значения. Когда он встречается, следующие 32 бита в потоке битов должны быть значением с плавающей точкой. Этот маркер должен использоваться для всех символьных констант в пределах программы SAOL за исключением тех, с которыми встречаются в специальных целочисленных контекстах. Маркер 0xF2 является целочисленным маркером. Когда он встречается, следующие 32 бита в потоке битов должны быть целочисленным значением без знака. Маркер 0xF3 является строковым маркером. Когда он встречается, следующие несколько битов в потоке битов должны представлять строку символов (этот маркер в настоящий момент не используется). Маркер 0xF4 является маркером байта. Когда он встречается, следующие 8 битов в потоке битов должны быть целочисленным значением без знака. Маркер 0xFF является маркером конца оркестра; этот маркер не имеет никакой синтаксической функции в оркестре SAOL, но показывает конец раздела файла оркестра потока битов.

Не каждой последовательности маркеров разрешено выступать как файл оркестра. Полная последовательность маркеров оркестра должна соответствовать производству <оркестра>.

/*********************************
score file definitions
***********************************/
class instr_event {
bit(1) has_label;
if (has_label)
symbol label;		// a note-on event
symbol iname_sym;// the instrument name
float(32) dur;
unsigned int(8) num_pf;		// note duration
float(32) pf[num_pf};// all the pfields (no more than 255) }
class control_event
bit(1) has_label;
if (has_label)
symbol label;		// a control event
symbol varsym;// the controller name
float(32) value
}
class table_event {		// the new value
symbol tname;// the name of the table
bit(1) destroy;
if (!destroy) {		// a table destructor
token tgen;
bit(1) refers_to_sample;
if (refers_to_sample)		// a core wavetable generator
symbol table_sym;// the name of the sample
unsigned int(16) num_pf;// the number of pfields
if (tgen = = 0x7D) {
float(32) size;
symbol ft[num_pf — 1]; }
else {
float (32) pf[num_pf]; }		// concat
// when coding sample generator, leave a blank array slot
// for «which» parameter, to maintain alignment for «skip» parameter
}
}
class end_event {
// fixed at nothing
}
class tempo_event { // a tempo event
float(32) tempo;
}
class score_line {
bit(1) has_time;
if (has_time) {
bit (1) use_if_late;
float(32) time;// the event time
}
bit (1) high_priority;
bit(3) type;
switch (type) {
case 0b000 : instr_event inst; break;
case 0b001 : control_event control; break;
case 0b010 : table_event table; break;
case 0b100 : end_event end; break;
case 0b101 : tempo_event tempo; break;
}
}
class score_file {
unsigned int(20) num_lines; // a whole score file
score_line lines[num_lines];
}

Файл отсчета является рядом строк информации об отсчете, предоставленной в заголовке информации о потоке. События, которые известны перед началом передачи потока битов в реальном времени, могут быть включены в заголовок так, чтобы они сразу были доступны декодеру, что может помочь эффективному вычислению в определенных реализациях. Каждая линия должна быть одним из пяти событий. У каждого типа событий есть свои импликации в процессе декодирования и планирования. Инструмент событий определяет время старта, инструмент символа имени, продолжительность, и любые другие параметры звука, проигрываемого на инструменте SAOL. Событие управления определяет параметр управления, который передают инструменту или инструментам, уже генерирующим звук. Таблица событий динамически создает или уничтожает глобальную звуковую таблицу в оркестре. Событие конца показывает конец работы оркестра. Событие темпа динамически изменяет темп воспроизведения оркестром.

Файл отсчета не должен быть представлен в порядке увеличения времен событий. События должны быть «сортированы» планировщиком по мере их обработки. В файле отсчета у каждой линии отсчета должна быть отметка времени.

Бит high_priority указывает, что событие отсчета является высокоприоритетным событием. Бит use_if_late указывает, если бит has_time устанавливается, то событие отсчета должно использоваться, прибывает ли оно вовремя или нет.

/
MIDI definitions
**/
class midi_event {
unsigned int(24) length
unsigned int(8) data[length];
}
class midi_file {
unsigned int(32) length;
unsigned int(8) data[length];
}

Участки MIDI позволяют включать информацию отсчета MIDI в заголовке потока битов и поток битов. Класс событий MIDI содержит единственную инструкцию MIDI. Класс файла MIDI содержит массив байтов, соответствующих MIDIFile стандартного формата 0 или формата 1. Каждая последовательность данных может иметь место в любом случае. Допустимые синтаксисы событий MIDI и MIDIFiles помещают в нормативные границы на синтаксически допустимых потоках битов структурированного аудио MPEG-4. Участки данных могут быть длиной до 224-1 и 232-1 байтов. Более длинные сообщения должны быть разбиты на несколько элементов потока битов.

/**********************************
sample data
************************************/
class sample {
/* note that 'sample' can be used for any big chunk of data
that needs to get into a wavetable */
symbol sample_name_sym;
unsigned int(24) length;
bit(1) has_srate;
if (has_srate)		// length in samples
unsigned int(17) srate;
bit(1) has_loop;
if (has_loop) {		// sampling rate (needs to go to 96 KHz)
unsigned int(24) loopstart;
unsigned int(24) loopend; }
bit(1) has_base;		// loop points in samples
if (has_base)
bit(1) float_sample;
if (float_sample) {		// base freq in Hz
float(32) float_sample_data[length];
}
else {		// data as floats ..
int(16) sample_data[length]; // ... or as ints
}
}

Участок выборки включает блок данных, который будет включен в звуковую таблицу в оркестре SAOL. Каждая выборка состоит из имени, длины блока данных, и четырех дополнительных параметров: частота дискретизации, точки начала цикла и конца цикла, и основная частота. Доступ к данным в выборке обеспечивается через генератор звуковой таблицы выборки.

Данные выборки могут быть представлены как 32-разрядные значения с плавающей точкой, тогда они должны масштабироваться между -1 и 1 или как 16-разрядные целочисленные значения, тогда они должны масштабироваться между -32768 и 32767. В случае, когда данные выборки представляются как целочисленные значения, после включения в звуковую таблицу, они должны повторно масштабироваться к плавающей точке.

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

/************************
sample bank data
*************************/
class sbf {
int(32)length;
int(8)
}		data[length];

Участок данных непрозрачен относительно транспортировки системами MPEG-4. Это должно соответствовать спецификации формата — то есть, это должен быть участок данных RIFF, начинающий «RIFF...».

/
bitstream formats
/
class StructuredAudioSpecificConfig { // the bitstream header
bit more_data = 1;
while (more_data) { // shall have at least one chunk
bit(3) chunk_type;
switch (chunk_type) {
case 0b000 : orc_file orc; break;
case 0b001 : score_file score; break;
case 0b010 : midi_file SMF; break;
case 0b011 : sample samp; break;
case 0b100 : sbf sample_bank; break;
case 0b101 : symtable sym; break;
}
bit(1) more_data;
}
}

Конфигурация декодера потока битов содержит всю информацию, чтобы сконфигурировать и запустить структурированный аудиодекодер. Она содержит последовательность одного или более участков, где каждый участок является одним из следующих типов: файл оркестра, файл отсчета, файл midi, данные выборки, банк выборки, или таблица символов. Многие участки каждого из этих типов могут появляться в потоке битов (за исключением midi_file) со следующей семантикой:

1. orc_file: многочисленные файлы оркестра должны быть объединены. Если больше чем один глобальный блок появляется в объединенном оркестре, то это синтаксическая ошибка.

2. score_file: многочисленные файлы отсчета должны быть сортированы совместно по временам событий и объединены.

3. midi_file: только один элемент midi_file может появиться в потоке битов структурированного аудио.

4. sample: к samples может получить доступ в оркестр.

5. sbf: все многочисленные банки выборок доступны для процесса синтеза. Поведение не определено, если присутствует определенная комбинация MIDI и номер банка MIDI используется не один раз, либо в единственном банке выборок, либо в множественных банках выборок.

6. symtable: множественные таблицы символов, каждая из которых дает имена символам в оркестре. Имена N0 в первой таблице символов в потоке битов применяются к символам 0.. N0-1; имена N1 во второй таблице символов к символам N0.. N0+N1-1; и так далее.

class SA_access_unit {
bit(1) more_data = 1;
while (more_data) {
bit(2) event_type;
switch (event_type) {		// the streaming data
case 0b00 : score_line score_ev; break;
case 0b01 : midi_event midi_ev; break;
case 0b10 : sample samp; break;
}
bit(1) more_data;
}
}

Блок доступа структурированного аудио содержит управляющую информацию потоковой передачи в режиме реального времени, которая будет обеспечена для выполнения процесса декодирования структурированного аудио. Он может содержать такое количество команд управления, какое требуется и разрешено допустимой пропускной способностью. Он не должен содержать новые инструментальные определения. Конфигурация оркестра фиксируется при запуске декодера. Он может содержать линии отсчета, события MIDI и новые данные выборки. Когда обеспечивается часть блока доступа, линия отсчета не обязана содержать метку времени. Когда has_time очищается в классе score_line, событие диспетчеризируется немедленно. Линии отсчета без меток времени не являются реагирующими к изменениям темпа оркестра.

6 Типы объектов

Есть четыре типа объектов, стандартизированных для структурированного аудио. Каждый из этих типов соответствует определенному набору эксплуатационных характеристик. Объектным типом по умолчанию является объектный тип 4. Когда ссылка дается на формат структурированного аудио MPEG-4 независимо от объектного типа, это нужно понимать как то, что ссылка сделана на объектный тип 4.

Терминалы, реализующие профили систем MPEG-4, содержащие узел AudioFX, должны также обеспечивать поддержку для объектного типа 3 или 4 структурированного аудио.

1. MIDI only. В этом объектном типе в заголовке информации о потоке должен появиться только участок midi_file, и только событие midi_event должно иметь место в данных потока битов. В этом объектном типе используются отображения вставки General MIDI. Этот объектный тип используется, чтобы задействовать обратную совместимость с существующим контентом MIDI и устройствами рендеринга. Нормативное и независимое от реализации качество звука не может быть обеспечено в этом объектном типе.

2. Wavetable syntesis. В этом объектном типе только файл midi_file и участки sbf должны появиться в заголовке информации о потоке, и только событие midi_event должно иметь место в данных потока битов. Этот объектный тип используется, чтобы описать контент музыки и звуковых эффектов в ситуациях, в которых не требуются полная гибкость и функциональность SAOL, включая 3-D аудио.

3. Алгоритмический синтез и AudioFX. В этом объектном типе участки sbf и midi_file не должны появляться в заголовке информации о потоке. Этот объектный тип используется, чтобы описать алгоритмический синтез и обеспечить обработку звуковых эффектов в узле AudioFX, когда использование формата банка выборок SASBF не требуется.

4. Основной синтетический. Могут появиться все элементы потока битов и элементы потоковой информации.

7 Процесс декодирования

7.1 Введение

Этот подпункт описывает алгоритмический структурированный процесс декодирования аудио, в котором поток битов соответствующий, объектному типу 3 или 4 преобразовывается в звук.

7.2 Заголовок конфигурации декодера

При создании элементарного потока структурированного аудио создается декодер структурированного аудио и для этого декодера обеспечивается объект потока битов класса SA_decoder_config, как информация о конфигурации. В это время декодер должен инициализировать планировщика времени выполнения, и затем разобрать заголовок конфигурации декодера на его составные части и использовать их следующим образом:

Файл оркестра: Файл оркестра должен быть проверен на синтаксическое соответствие грамматике SAOL и семантике уровня. Безотносительно предварительной обработки (то есть, компиляция, выделение статического хранения и т.д.) должна быть сделана подготовка к времени выполнения оркестра.

Файл отсчета: Каждое событие в файле отсчета должно быть зарегистрировано в планировщике. «Зарегистрироваться» означает сообщать планировщику о присутствии определенного параметризованного события в определенное будущее время, и о соответствующих действиях планировщика.

Файл MIDI: Каждое событие в файле MIDI должно быть преобразовано в соответствующее событие, и эти события зарегистрированы в планировщике.

Банк выборок: Данные должны храниться в банке выборок, и должны выполняться безотносительно предварительной обработки, необходимой чтобы подготовиться к использованию банка для синтеза.

Данные выборки: Данные в выборке должны храниться, и должны выполняться безотносительно предварительной обработки, необходимой чтобы подготовить данные из генератора звуковой таблицы SAOL. Если данные выборки представлены как 16-разрядные целые числа в потоке битов, то в это время они должны быть преобразованы в формат с плавающей точкой.

Таблица символов: Никакое нормативное поведение декодера не связывается с таблицей символов.

Если имеется больше одного файла оркестра в заголовке информации о потоке, различные файлы объединяются посредством сочленения и обрабатываются как один большой файл оркестра. Таким образом, каждый файл оркестра в рамках потока битов ссылается на одно и то же глобальное пространство имен, инструментальное пространство имен и пространство имен кода операции.

7.3 Данные потока битов и создание звука

7.3.1 Отношение с системным уровнем

На каждом шаге, в рамках системной работы, системный уровень может представить декодер структурированного аудио с блоком доступа, содержащим данные, соответствующие классу SA_access_unit. Декодер структурированного аудио отвечает за то, чтобы получить элементы данных AU, проанализировать и понять их как различные элементы данных потока битов структурированного аудио, выполнить продолжающийся оркестр SAOL, произвести одну единицу композиции выхода и передать системному уровню эту единицу композиции.

7.3.2 Элементы данных потока битов

Поскольку блоки доступа получают из системного демультиплексора, они анализируются и используются декодером структурированного аудио различными способами следующим образом:

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

События линии отсчета должны быть зарегистрированы в планировщике, если у них будут отметки времени, или если их нет, то выполняться в следующем k-цикле.

События MIDI должны быть преобразованы в соответствующие события SAOL, и затем зарегистрированы в планировщике, если у них есть отметки времени, или если их нет, то выполняться следующем k-цикле.

7.3.3 Семантика планировщика
7.3.3.1 Назначение планировщика

Планировщик является центральным механизмом управления системы декодирования структурированного аудио. Он отвечает за обработку событий инструментами создания и прекращения, отслеживая то, какие инструментальные создания активны, давая различным инструментам команду выполнить синтез, направляя вывод инструментов на шины, и отправляя шины инструментам эффектов.

7.3.3.2 Инстанцирование инструмента

Инстанцировать (создать) инструмент означает создать пространство данных для его переменных и пространство данных, требующееся для любых кодов операции, вызванных этим инструментом. Когда инструмент инстанцируется, должны выполняться следующие задачи. Должно быть выделено место для любых полей параметра и установлены их значения согласно p-полям выражения или события инстанцирования. Затем должно быть выделено место для любых локально объявленных переменных, и значения этих переменных установлены в 0. Затем в локальное место для хранения должны быть скопированы текущие значения любых импортированных переменных i-rate. Затем должны быть созданы локально объявленные звуковые таблицы и заполнены данными согласно их объявлению.

7.3.3.3 Завершение инструмента

Завершить инстанцирование инструмента означает уничтожить пространство данных для этого экземпляра.

7.3.3.4 Выполнение инструмента

Выполнить инстанцирование инструмента на определенной скорости означает вычислить результаты команд, данных в это инструментальное определение. Когда экземпляр инструмента будет выполнен на определенной скорости, должны выполняться следующие шаги. Во-первых, значения любых глобальных переменных и звуковых таблиц импортированных этим инструментом на этой скорости должны быть скопированы в место для хранения инструмента. Кроме того, во время выполнения на a-скорости экземпляр инструмента, который является целью оператора send, текущее значение стандартного имени input в экземпляре должны быть установлены в текущее значение шины или шин, на которые ссылаются в операторе send. Затем, блок кода для этого инструмента должен выполняться на определенной скорости с учетом пространства данных инстанцирования инструмента. Затем, значения любых глобальных переменных и звуковых таблиц, экспортируемых этим инструментом на этой скорости, должны быть скопированы в глобальное место для хранения. Наконец, при выполнении инстанцирования инструмента на a-скорости значение вывода инструмента должно быть добавлено к шине, на которую направляется инструмент. Если инструмент не является целью выражения send, ссылающегося на специальную шину output_bus, вывод инструмента является выводом оркестра и может быть превращен в звук.

7.3.3.5 Запуск оркестра и конфигурация
7.3.3.5.1 Введение

Задачи определения инструмента и ширины шины, назначения глобальной переменной, выполнение startup, создания глобальной звуковой таблицы, инициализации шины и инструмента send должны быть выполнены в обозначенном ниже порядке.

7.3.3.5.2 Определение ширины выхода инструмента и ширины шины

Ширина выхода каждого инструмента определяется в порядке, определенном глобальными правилами упорядочивания. Ширина каждой шины обеспечивается оператором send или определяется суммой выходных ширин инструментов, направленных к этой шине в route. У любого инструмента, который не получает данных шины согласно правилам упорядочивания, должна быть ширина inchannels равная 1 (эта спецификация необходима, так как выходные ширины могут зависеть от значения inchannels или ширины input).

Примечание: если выходная ширина инструмента зависит от outchannels и ширина шины, куда этот инструмент направляется, не определяется посредством других операторов send/route, оркестр может быть недетерминированным. Программисты должны обратить особое внимание на проверку детерминированного поведения оркестра или использовать определенные ширины шины.

7.3.3.5.3 Варьируемое выделение, выполнение запуска и создание глобальной звуковой таблицы

Для изменений любых глобальных сигналов должно быть выделено место, и их значения установлены в нуль. Если в оркестре будет инструмент, называемый startup, этот инструмент нужно инстанцировать и выполнить в i-rate. После того, как это выполнение закончено, создаются все глобальные звуковые таблицы и заполняются данными согласно их определениям в глобальном блоке оркестра.

7.3.3.5.4 Инициализация шин и инструментов send

После создания глобальной звуковой таблицы создаются и инициализируются шины оркестра. Каждый канал каждой шины устанавливается в значение 0. После того, как шины созданы, все инструменты, которые являются целями операторов send, нужно инстанцировать и выполнить в i-rate, в порядке, определенном глобальными правилами упорядочивания. Глобальное абсолютное время оркестра должно быть установлено в 0.

Примечание - Время называют absolute, если оно определяется в секундах. Когда сначала декодируется команда темпа и значение темпа изменяется из его значения по умолчанию, время отсчета и абсолютное время больше не идентичны. Все времена в отсчете следующем за выполнением линии темпа, масштабируются согласно новому темпу и ставятся в очередь в абсолютные времена диспетчеризации и продолжительности.

7.3.3.6 Выполнение декодера во время потоковой передачи

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

1. Если есть событие конца, чье время диспетчеризации ранее или равно текущему абсолютному времени оркестра, или событие конца было получено без метки времени после последнего выполнения этого правила, никакой дальнейший вывод не производится, и на все будущие запросы от системного уровня даются ответы буферами как нуль.

2. Если есть какие-либо инструментальные события, чьи времена диспетчеризации ранее или равна текущему абсолютному времени оркестра, или какие-либо инструментальные события были получены без меток времени после последнего выполнения этого правила, для каждого такого инструментального события создается инстанцирование инструмента, и каждый из этих инстанцирований выполняется в i-rate порядке, предписанном глобальными правилами упорядочивания. Если инструментальное событие определяет продолжительность для инстанцирования инструмента, то инстанцирование инструмента должно быть запланировано для завершения во время, данное суммой текущего абсолютного времени оркестра и указанной продолжительности (масштабируемый к абсолютным единицам измерения времени согласно фактическому темпу, если имеется).

3. Если есть какие-либо активные инстанцирования инструмента, время завершения которых ранее или равно текущему абсолютному времени оркестра, то стандартное имя released должно быть установлено в 1 в пределах каждого экземпляра такого инструментального инстанцирования, и инструмент отмечается для завершения в шаге 12.

4. Если имеются какие-либо события управления, чьи времена диспетчеризации ранее или равны текущему абсолютному времени оркестра, или любые события управления были получены без меток времени после последнего выполнения этого правила, глобальным переменным или инструментальным переменным в пределах инстанцирований инструмента, маркированных каждым таким событием управления, нужно обновить их значения. Подразумевается, что оркестром может быть получено не больше, чем одно изменение управления на переменную за цикл управления. Если множественные изменения управления, которые ссылаются на одну и ту же переменную, получаются в единственном цикле управления, результирующее значение инструмента или глобальной переменной является неуказанным.

5. Если есть какие-либо табличные события, чьи времена диспетчеризации ранее или равны текущему абсолютному времени оркестра, или любые табличные события были получены без меток времени после последнего выполнения этого правила, глобальные звуковые таблицы должны создаваться или уничтожаться, как определено табличным событием.

6. Если имеются какие-либо события MIDI, метка времени которых ранее или равна текущему времени оркестра, или которые были получены без меток времени после последнего выполнения этого правила, они диспетчеризируются согласно их семантике.

7. Если есть какие-либо события темпа, чьи времена диспетчеризации ранее или равны текущему абсолютному времени оркестра, или любые события темпа были получены после последнего выполнения этого правила, то глобальная переменная темпа должна быть установлена в указанное значение, и времена диспетчеризации всех событий, ожидающихся для выполнения, должны масштабироваться к новым временам согласно новому значению темпа. Уже запланированные времена для завершений также масштабируются в их остающейся части, согласно отношению между старым и новым темпом. На существующие времена extend это не влияет, так как они определяются в абсолютном времени и таким образом «вне» отсчета. Значение стандартного имени dur должно быть изменено в каждом активном экземпляре инструмента, чтобы отразить новую продолжительность инструмента.

Если множественные события темпа обрабатываются согласно предыдущему абзацу в том же самом цикле управления, то глобальная переменная темпа должна изменяться только однажды к темпу, обозначенному в событии темпа, полученном последним или с последней меткой времени, а другие события темпа отбрасываются. Если есть множественные события темпа с той же самой меткой времени, или события без метки времени, события с меткой времени должны быть диспетчеризированы в том же самом цикле управления, и результирующее значение глобальной переменной темпа не указывается.

Примечание - Если текущее время оркестра отличается от времени диспетчеризации темпа, чтобы вычислить новые продолжительности, и будущее время диспетчеризации событий должно использоваться прежнее время.

8. Если поле speed узла сцены AudioSource, ответственное за инстанцирование этого декодера, было изменено в последнем k-rate, переменная стандарта темпа должна быть установлена в 60-кратное значение, и события в оркестре должны повторно масштабироваться.

9. Значение каждого канала каждой шины должно быть установлено в 0.

10. Каждый активный экземпляр инструмента должен выполняться однажды в k-rate и n раз в a-rate, где n является числом выборок в период управления. Каждое выполнение в k-rate должно быть выполнено в порядке, данном глобальными правилами упорядочивания, и каждое соответствующее выполнение в a-rate (то есть, первое выполнение a-rate в k-rate, второе выполнение a-rate в k-rate и т.д.) должно быть в порядке, данном глобальными правилами упорядочивания.

Примечания

1 Если инструмент a упорядочен перед инструментом b, то выполнение k-rate a должно быть строго перед выполнением k-rate b и выполнение k-rate a должно быть строго перед первым выполнением a-rate a, и первое выполнение a-rate a должно быть строго перед первым выполнением a-rate b. Однако нет никакого нормативного упорядочивания между вторым выполнением a-rate a и первым выполнением a-rate b или между первым выполнение a-rate a и выполнением k-rate b в пределах определенного цикла оркестра.

2 В соответствии с правилами упорядочивание выполнения, описанное в этом подпункте, может быть перестроено или проигнорировано, когда исходя из исследования оркестра может быть решено, что если так сделать, то не будет оказано никакого влияния на вывод процесса декодирования. «Не имеет никакого влияния» должно быть принято как означающее, что вывод процесса декодирования в перестроенном порядке является повыборочно идентичным выводу процесса декодирования, выполняемого строго согласно правилам в этом подпункте.

3 Выполнения k-rate каждого экземпляра инструмента должны происходить как атомарная работа; то есть выполнение k-rate одного инструмента должно быть завершено прежде, чем начинается следующее. Не допустимо выполнять k-rate параллельно. Это не касается a-rate. Если у двух инструментов нет никакого отношения упорядочивания согласно глобальным правилам упорядочивания их, a-rate могут быть выполнены в любом порядке или параллельно.

11. Если специальная шина output_bus направляется к инструменту, вывод этого инструмента в каждом a-rate является выводом оркестра в этом a-rate. Иначе значение специальной шины output_bus после выполнения каждого инструмента для a-rate является выводом оркестра в этом a-rate. Если значение текущего вывода оркестра будет больше чем 1 или меньше чем -1, оно должно быть установлено в 1 или -1, соответственно.

12. Если инструмент, названный extend с параметром больше, чем количество времени в цикле управления, инструмент не завершается. Все другие инструменты, отмеченные для завершения в шаге 3, завершаются. В случае сообщения MIDI «All Notes Off» инструменты могут не расширять себя, и в это время уничтожаются.

13. Текущее глобальное абсолютное время оркестра продвигается на один период управления.

7.3.3.7 Приоритет событий

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

Если флаг high_priority будет установлен, и если наступит критическое состояние, событие всегда должно выполняться без ухудшения, и никакие инстанцирования, создаваемые на низких приоритетных уровнях, не будут активными. Если флаг high_priority будет убран, то событие должно выполняться без ухудшения, если не наступят никакие критические состояния. Инструментальные события с убранным флагом high_priority могут быть преждевременно завершены, если не доступны ресурсы, чтобы диспетчеризировать событие с установкой флага high_priority.

Примечание - Ухудшение не планируется как дозволенный, нормативный метод, чтобы понизить вычислительную сложность. Соответствующие декодеры должны быть в состоянии декодировать в нормальных условиях потоки битов указанного уровня Profile@Level без ухудшения.

7.3.3.8 Запаздывающие события

В случае ошибки транспортировки или ошибки кодера определенные события могут поступить с метками времени, которые уже прошли. Поле use_if_late в элементе потока битов указывает надлежащее поведение в этом случае. Если это поле очищается, то событие игнорируется, и обработка должна продолжаться, как будто событие никогда не прибывало. Если это поле устанавливается, то событие немедленно диспетчеризуется, как если бы оно было получено без метки времени.

7.4 Соответствие

Относительно всего нормативного языка соответствие нормативному языку измеряется во время вывода оркестра. Любая оптимизация кода SAOL или перестановка последовательности обработки могут быть выполнены, пока их выполнение никак не влияет на вывод оркестра. «Не имеет никакого влияния», в этом смысле означает, что вывод перестроенного или оптимизированного оркестра является повыборочно идентичным выводу исходного оркестра.

8 Синтаксис и семантика SAOL

8.1 Соотношение с синтаксисом потока битов

Описание синтаксиса потока битов определяет представление инструментов и алгоритмов SAOL, которые должны быть предоставлены декодеру в потоке битов. Однако маркируемое описание, как представлено там, не достаточно, чтобы описать синтаксис и семантику языка SAOL. Чтобы обеспечить создание потока битов и обмен надежным способом, полезно иметь стандартное удобочитаемое текстовое представление кода SAOL в дополнение к маркируемому двоичному формату.

Грамматика формата Backus-Naur (BNF) обозначает язык или бесконечный набор программ. Допустимые программы, которые могут быть переданы в потоке битов, ограничиваются этим набором. Любая программа, которая не может быть проанализирована этой грамматикой, не является допустимой программой SAOL — у нее есть синтаксическая ошибка — и поток битов является недопустимым потоком. Хотя поток битов составляется из маркеров, грамматика будет описана с точки зрения лексических элементов. Синтаксические правила, выраженные грамматикой, которые ограничивают набор текстовых программ, также нормативно ограничивают синтаксис потока битов через отношение потока битов и текстового формата в нормативном процессе маркирования.

Этот подпункт таким образом описывает текстовое представление SAOL, которое стандартизируется, но стоит за пределами отношения декодера потока битов.

Приложение В содержит грамматику для текстового языка SAOL, представленного в форматах 'lex' и 'yacc'. Используя эти версии грамматики, синтаксические анализаторы могут быть созданы автоматически, используя инструменты 'lex' и 'yacc'. Эти версии годятся только в информативных целях и используются в создании декодера.

Нормативный язык синтаксиса в этом подпункте обеспечивает границы синтаксически верных программ SAOL и дополнительно, синтаксически верных последовательностей потока битов, которые могут появиться в классе потока битов orchestra. Таким образом есть конструкции, которые допустимы только после чтения грамматики BNF, но отвергаются в нормативном тексте, сопровождающем грамматику. Состояние таких конструкций является состоянием тех, которые лежат за пределами языка, определенного одной только грамматикой.

Процесс декодирования для потоков битов, содержащих синтаксически недопустимые программы SAOL (то есть, программы SAOL, которые не соответствуют грамматике BNF, или содержат синтаксические ошибки или ошибки несоответствия уровня), является необусловленным.

Нормативная в отношении языка семантика в этом подпункте описывает семантические границы поведения декодера структурированного аудио. Определенные конструкции описывают «ошибочные по времени выполнения» ситуации. Поведение декодера при таких обстоятельствах не нормировано, но реализации позволяют корректно восстановиться из таких ситуаций и продолжать декодирование.

8.2 Лексические элементы

8.2.1 Понятия

Текстовый оркестр SAOL содержит знаки препинания, которые синтаксически снимают неоднозначность оркестра, идентификаторы, которые обозначают символы оркестра, числа, которые обозначают постоянные величины, строковые константы, которые в настоящий момент не используются, комментарии, которые допускает внутренняя документация оркестра и пробел, который лексически разделяет различные текстовые элементы. Эти элементы не появляются в потоке битов так, как каждый представляется там маркером.

8.2.2 Идентификаторы

Идентификатор является серией одной или более букв, цифр и подчеркиваний, которая начинается с буквы или подчеркивания. Он обозначает символ оркестра. Идентификаторы являются чувствительными к регистру, что означает, что идентификаторы, которые отличаются регистром только одного или более символов, обозначают различные символы.

Строка символов, эквивалентная одному из зарезервированных слов, перечисленных в 8.9, одному из стандартных имен перечисленных в 8.6.8, имени одного из базовых кодов операции перечисленных в 9.3, или имени одного из базовых генераторов звуковой таблицы, перечисленных в 10, не обозначает символ, а обозначает что зарезервировано слово, стандартное имя, код операции, или генератор звуковой таблицы.

Идентификатор обозначается в грамматике BNF терминальным символом .

8.2.3 Числа

Существуют два вида символьных констант, которые содержат числовые значения в SAOL: целочисленные константы и константы с плавающей точкой.

Целочисленная константа обязана появляться в определенных контекстах, таких как определения массива. Целочисленный маркер является серией одной или более цифр. Строка символов, которая оказывается отрицательным целым числом, должна быть лексически проанализирована как константа с плавающей точкой. Никакая целочисленная константа, больше чем 232 (4294967296), не должна иметь места в оркестре.

В SAOL нет разницы между числами, кодированными с маркером потока битов для целых чисел и кодированными с маркером потока битов для байтов. Последний является только средством сжатия потока битов.

Целочисленная константа обозначается в грамматике BNF терминальным символом .

Константа с плавающей точкой присутствует в выражениях SAOL и обозначает постоянное числовое значение. Маркер с плавающей точкой состоит из основания, дополнительно сопровождаемого экспонентой. Основание является серией одной или более цифр, опционно сопровождаемых десятичной точкой и серией из ни одной или большего количества цифр, или десятичной точкой, сопровождаемой серией из одной или более цифр. Экспонента обозначается буквой e, дополнительно сопровождаемой символом + или -, сопровождаемым серией из одной или более цифр. Так как константа с плавающей точкой появляется в выражении SAOL, где унарный оператор отрицания всегда является доступным, константы с плавающей точкой не должны быть лексически отрицательными. Каждая константа с плавающей точкой в оркестре должна быть представимой 32-разрядным числом с плавающей точкой.

Константа с плавающей точкой обозначается в грамматике BNF терминальным символом .

8.2.4 Строковые константы

Строковые константы не используются в нормативной спецификации SAOL, но описаны здесь, чтобы они могли обрабатываться разработчиками, которые хотят добавлять к своим реализациям функциональность свыше нормативных требований.

Строковая константа обозначает постоянное строковое значение, то есть, последовательность символов. Строковая константа является серией символов, заключенных в двойные кавычки («). Символ двойных кавычек может быть включен в строковую константу, предшествуя ей с символом наклонной влево черты (). Любой другой символ, включая символ разрыва линии (новая линия), должен быть заключен в кавычки.»

8.2.5 Комментарии

Комментарии могут использоваться в текстовом представлении SAOL чтобы внутренне документировать оркестр. Однако они не включаются в поток битов и теряются в последовательности tokenisation/detokenisation (назначения/удаления маркеров).

Комментарий является любой серией символов, начинающихся с двух наклонных черт (//), и завершающихся с новой линией. Во время лексического анализа, всякий раз когда в линии находится элемент //, остальная часть линии игнорируется.

8.2.6 Пробел

Пробел служит для того, чтобы лексически разделить различные элементы текстового оркестра SAOL. Он не имеет никакой синтаксической функции в SAOL, и не представляется в потоке битов, таким образом точный пробел текстового оркестра теряется в последовательности tokenisation/detokenisation. Пробел не требуется в SAOL, кроме случаев когда надо снять неоднозначность маркеров и зарезервированных слов, которые появляются друг за другом (например, отделяет «asig» от объявленного имени переменной).

Пробел является любой серией одного или более пространств, таблицы, и/или символов новой строки.

8.3 Переменные и значения

Каждая сигнальная переменная в рамках оркестра SAOL содержит значение или упорядоченный набор значений для переменных массива, как промежуточное вычисление оркестра. В любом моменте времени значение переменной, выборка в звуковой таблице или единственный элемент переменной массива должны быть представлены 32-разрядным значением с плавающей точкой.

Реализации свободно использовать любое внутреннее представление для переменных значений, пока вычисленные результаты идентичны результатам вычислений, используя 32-разрядные значения с плавающей точкой.

Определенными чувствительным цифровым образом фильтрующими операциями, результаты использования большей точности в вычислении могут быть эквивалентно вредными для вывода оркестра, так же как и результаты использования меньшей точности, поскольку устойчивость фильтра может критически зависеть от ошибки квантования. Этому строго следуют для потоков битов, содержащих код, который генерирует совсем другие результаты, вычисленные с 32-разрядной и 64-разрядной арифметикой.

При выводе оркестра значения, вычисленные оркестром, должны находиться между минимальным значением -1 и максимальным значением 1. Эти значения при выводе оркестра представляют максимум негативно — и положительно оцененных аудиосэмплов, которые могут быть произведены терминалом. Если значения, вычисленные оркестром, падают вне того диапазона, они отсекаются к [-1, 1]. Этот звук представляется циклом управления MPEG-4 системы для использования в составе AudioBIFS.

8.4 Оркестр

         -> 
          ->

Оркестр является набором подпрограмм обработки сигналов и объявлений, которые составляют структурированное описание обработки аудиоданных. Это должно состоять из списка одного или более элементов оркестра.

->

->

->

->