Г.726

Г.726

40, 32, 24, 16 кбит/с Адаптивная дифференциальная импульсно-кодовая модуляция (ADPCM)
Статус	Действующий
Год начался	1990
Последняя версия	(05/06) Май 2006
Организация	МСЭ-Т
Базовые стандарты	Г.721
Домен	сжатие звука
Лицензия	В свободном доступе
Веб-сайт	https://www.itu.int/rec/T-REC-G.726

G.726 — это стандарт речевого кодека ITU-T ADPCM, охватывающий передачу голоса со скоростью 16, 24, 32 и 40  кбит /с. Он был введен для замены как G.721, который охватывал ADPCM со скоростью 32 кбит/с, так и G.723 , который описывал ADPCM для 24 и 40 кбит/с. G.726 также ввел новую скорость 16 кбит/с. Четыре скорости передачи данных , связанные с G.726, часто обозначаются размером бит выборки , которые составляют 2, 3, 4 и 5 бит соответственно. Соответствующий широкополосный кодек, основанный на той же технологии, — G.722 .

Наиболее часто используемый режим — 32 кбит/с, что удваивает полезную емкость сети, используя половину скорости G.711 . Он в основном используется на международных соединительных линиях в телефонной сети и является стандартным кодеком, используемым в беспроводных телефонных системах DECT . Основное применение каналов 24 и 16 кбит/с — для перегрузки каналов, передающих голос в цифровом цепочечном мультипликационном оборудовании (DCME). Основное применение каналов 40 кбит/с — для передачи сигналов модема данных в DCME, особенно для модемов, работающих со скоростью более 4800 бит/с.

G.721 был представлен в 1984 году, а G.723 — в 1988 году. В 1990 году они были объединены в G.726.

G.727 был представлен в то же время, что и G.726, и включает те же скорости передачи данных, но оптимизирован для среды оборудования пакетной мультиплексной передачи (PCME). Это достигается путем внедрения 2-битного квантователя в 3-битный квантователь и того же для более высоких режимов. Это позволяет отбрасывать наименее значимый бит из потока бит без неблагоприятного воздействия на речевой сигнал.

• Частота дискретизации 8 кГц
• Доступны скорости передачи данных 16 кбит/с, 24 кбит/с, 32 кбит/с, 40 кбит/с
• Генерирует поток битов , поэтому длина кадра определяется временем пакетирования (обычно 80 выборок для  размера кадра 10 мс )
• Типичная алгоритмическая задержка составляет 0,125 мс, без задержки на просмотр вперед.
• G.726 — это волновой речевой кодер, использующий адаптивную дифференциальную импульсно-кодовую модуляцию ( ADPCM ).
• Тестирование PSQM в идеальных условиях дает средний балл 4,30 для G.726 (32 кбит/с) по сравнению с 4,45 для G.711 ( μ-закон ) ^{[ необходима цитата ]}
• Тестирование PSQM в условиях сетевой нагрузки дает средний балл 3,79 для G.726 (32 кбит/с) по сравнению с 4,13 для G.711 (μ-закон)
• Кодек G.726 со скоростью 40 кбит/с может передавать сигналы модема со скоростью 12000 бит/с и более медленные, тогда как кодек G.726 со скоростью 32 кбит/с может передавать сигналы модема со скоростью 2400 бит/с и более медленные, а также 4800 бит/с с некоторым ухудшением, чем кодеки чистого канала.

Поскольку порядок байтов для протоколов данных в контексте Интернета обычно определялся как big endian и назывался просто сетевым порядком байтов , как указано (среди прочего) в устаревшем RFC 1700, устаревший RFC 1890 также не определял явно порядок байтов предшественника G.726, G.721, в RTP. Вместо этого в устаревшем RFC 1890 использование big endian термином сетевой порядок байтов было снова указано для всех упомянутых кодеков:

«Для многооктетных кодировок октеты передаются в сетевом порядке байтов (т.е. сначала старший октет)».
— IETF, устаревший RFC 1890, раздел 4.2

Тип полезной нагрузки для G.721 был определен устаревшим RFC 1890 как 2 , таким образом a=rtpmap:2 G721/8000. В черновиках для более новой версии этого RFC он был повторно использован для G.726, т.е. a=rtpmap:2 G726-32/8000.

В отличие от этого ITU явно определил порядок байтов в своих рекомендациях относительно G.726 или соответственно ADPCM, но двумя разными способами. В рекомендации X.420 указано, что он должен быть little endian, в соответствии с рекомендацией I.366.2 Annex E он должен быть big endian. Это привело к противоречивым решениям в различных реализациях, поскольку некоторые производители выбрали little endian, а другие big endian. Следствием этого стало то, что эти реализации были несовместимы, поскольку декодирование с использованием неправильного порядка байтов приводит к сильно искаженному аудиосигналу. Поэтому нечеткое определение было исправлено в RFC 3551, который заменяет RFC 1890. Раздел 4.5.4 в RFC 3551 определяет классические типы MIME G726-16, 24, 32 и 40 как little endian и вводит новые типы MIME для big endian, которые являются AAL2-G726-16, 24, 32 и 40. Тип полезной нагрузки был изменен на динамический, чтобы избежать путаницы. Вместо типа полезной нагрузки 2 должна использоваться динамическая полезная нагрузка в диапазоне от 96 до 127:

«Обратите внимание, что направление «little-endian», в котором образцы упаковываются в октеты в форматах полезной нагрузки G726-16, -24, -32 и -40, указанных здесь, соответствует Рекомендации ITU-T X.420, но является противоположностью тому, что указано в Рекомендации ITU-T I.366.2 Приложение E для транспорта ATM AAL2. Второй набор форматов полезной нагрузки RTP, соответствующих пакетированию I.366.2 Приложение E и идентифицированных подтипами MIME AAL2-G726-16, -24, -32 и -40, будет указан в отдельном документе».
— IETF, RFC 3551, раздел 4.5.4

«Тип полезной нагрузки 2 был назначен G721 в RFC 1890 и его эквивалентному преемнику G726-32 в черновых версиях этой спецификации, но его использование теперь устарело, и этот статический тип полезной нагрузки отмечен как зарезервированный из-за конфликтующего использования для форматов полезной нагрузки G726-32 и AAL2-G726-32 (см. раздел 4.5.4)»
— IETF, RFC 3551, раздел 6

Более новые реализации соответствуют RFC 3551 и четко различают G726-xx (little endian) и AAL2-G726-xx (big endian). Например, телефон Gigaset C610 IP DECT генерирует следующий код в своем SIP INVITE:

a=rtpmap:96 G726-32/8000→ динамическая полезная нагрузка типа 96 и G.726 в соответствии с X.420, таким образом, прямой порядок байтов, как определено в RFC 3551
a=rtpmap:97 AAL2-G726-32/8000→ динамическая полезная нагрузка типа 97 и G.726 в соответствии с I.366.2 Annex E, таким образом, прямой порядок байтов, как определено в RFC 3551
a=rtpmap:2 G726-32/8000→ статическая полезная нагрузка типа 2 и G.726 с непредсказуемым порядком байтов, как G.721 в соответствии с устаревшим RFC 1890

• Список кодеков
• Сравнение форматов кодирования звука

• Страница ITU-T G.726
• Программные средства ITU-T G.191 для кодирования речи и звука, включая код C G.726
• RFC 3551 — Профиль RTP для аудио- и видеоконференций с минимальным управлением, G726-40, G726-32, G726-24 и G726-16