ISO/IEC DIS 23003-8:2026(en)

ISO/IEC JTC 1/SC 29

Secretariat: JISC

Date: 2025-11-28

Information technology — MPEG audio technologies — Part 8: Biomedical and general waveform signal coding

© ISO/IEC 2026

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.

ISO copyright office

CP 401 • Ch. de Blandonnet 8

CH-1214 Vernier, Geneva

Phone: +41 22 749 01 11

Email: copyright@iso.org

Website: www.iso.org

Published in Switzerland

CONTENTS

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).

ISO draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of publication of this document, ISO [had/had not] received notice of (a) patent(s) which may be required to implement this document. However, implementers are cautioned that this may not represent the latest information, which may be obtained from the patent database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.

This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information, in collaboration with ITU-T (as provisionally named Rec. ITU-T H.BWC, planned Rec. ITU-T T.261).

A list of all parts in the ISO 23003 series can be found on the ISO website.

Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html.

Information technology — MPEG audio technologies — Part 8: Biomedical and general waveform signal coding

This Recommendation | International Standard specifies an interoperable format for efficient compression, transmission, and storage of waveform signals, including biomedical waveform signals such as electrocardiography (ECG), electroencephalography (EEG), electromyography (EMG), and photoplethysmogram (PPG) data, as well as other types of general waveform data. It supports various bit depths, a broad range of sampling rates, and large numbers of channels, as required by a range of biomedical and general signal processing applications. The Specification provides for lossy, near-lossless, and lossless compression, and includes features such as optimized data blocking, indexing for rapid access, independent channel decoding, and metadata support including metadata enabling support of efficient artificial intelligence-based workflows.

The following Recommendations and International Standards contain provisions which, through reference in this text, constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent edition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recommendations.

— None.

— None.

ISO/IEC 10646:2020, Information technology — Universal coded character set (UCS)

IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, DOI 10.17487/RFC3986, January 2005, https://www.rfc-editor.org/info/rfc3986

ISO/IEC 23001‑17:2024, Information technology — MPEG systems technologies, Part 17: Carriage of uncompressed video and images in ISO base media file format

ITU-R Recommendation TF.460-6 (02/2022), Standard-frequency and time-signal emissions

ITU-R Recommendation BS.2088-1 (10/2019), Long-form file format for the international exchange of audio programme materials with metadata

ISO 8601:2019, Date and time — Representations for information interchange

ISO/IEC 23008‑3:2022, Information technology — High efficiency coding and media delivery in heterogeneous environments, Part 3: 3D audio

ISO/IEC 11578:1996, Information technology — Open Systems Interconnection — Remote Procedure Call (RPC), Annex A

NIST FIPS PUB 180-4 (2015), Secure Hash Standard (SHS)

For the purposes of this Recommendation | International Standard, the following definitions apply.

3.1

bin

One bit of a bin string.

3.2

bin string

An intermediate binary representation of values of syntax elements from the binarization of the syntax element.

3.3

binarization

A set of bin strings for all possible values of a syntax element.

3.4

bitstream

A sequence of bits that forms the representation of one or more coded waveform sequences.

3.5

coded waveform sequence (CWS)

A sequence of packets having the same WPS_waveform_parameter_set_id and containing at least one independent frame.

3.6

context variable

A variable specified for the context-based adaptive binary arithmetic decoding process of clause 9.5 of a bin in a manner that depends on the values of previously decoded bins.

3.7

decoder

An embodiment of a decoding process.

3.8

decoding order

The order in which syntax elements are processed by the decoding process.

3.9

decoding process

The process specified in this Specification that reads a bitstream and derives decoded samples from it.

3.10

dependent frame (DF)

A stream packet with stream_packet_type equal to DF_SPT.

3.11

encoder

An embodiment of an encoding process.

3.12

encoding process

A process that accepts waveform data as input and produces a bitstream conforming to this Specification.

3.13

flag

A variable or single-bit syntax element that can take one of the two possible values 0 and 1.

3.14

frame

Either an independent frame or a dependent frame.

3.15

frame sequence

A sequence of frames that starts with an independent frame followed by zero or more dependent frames.

3.16

independent frame (IF)

A stream packet with stream_packet_type equal to IF_SPT.

3.17

stream packet

A string of bytes containing a stream packet header and the syntax structure containing that data.

3.18

stream packet header

A syntax structure specifying the header of a stream packet. It contains a stream_packet_type, a stream_packet_label and a stream_packet_length syntax element that identifies the number of bytes in the syntax structure that follows within the stream packet.

3.19

stream packet stream

A sequence of stream packets.

3.20

syntax element

An element of data represented in the bitstream.

3.21

syntax structure

Zero or more syntax elements that are present together in the bitstream in a specified order.

3.22

transform

A part of the decoding process by which a block of transform coefficients is converted to a block of time-domain values.

3.23

transform block

A block of samples resulting from a transform in the decoding process.

3.24

transform coefficient

A scalar quantity, considered to be in a frequency domain, that is associated with a particular frequency index in a transform in the decoding process.

3.25

transform coefficient level

An integer quantity representing the value associated with a particular frequency index in the decoding process prior to scaling for computation of a transform coefficient value.

For the purposes of this Recommendation | International Standard, the following abbreviations apply.

The term "this Specification" is used to refer to this Recommendation | International Standard.

The word "shall" is used to express mandatory requirements for conformance to this Specification. When used to express a mandatory constraint on the values of syntax elements or the values of variables derived from these syntax elements, it is the responsibility of the encoder to ensure that the constraint is fulfilled.

The word "may" is used to refer to behaviour that is allowed, but not necessarily required.

The word "should" is used to refer to behaviour of an implementation that is encouraged to be followed under anticipated ordinary circumstances, but is not a mandatory requirement for conformance to this Specification.

Content of this Specification that is identified as "informative" does not establish any mandatory requirements for conformance to this Specification and is thus not considered an integral part of this Specification. Informative remarks in the text are, in some cases, set apart and prefixed with the word "note" or "NOTE".

The word "reserved" is used to specify that some values of a particular syntax element are for future use by ITU-T | ISO/IEC and shall not be used in syntax structures conforming to this version of this Specification, but could potentially be used in syntax structures conforming to future versions of this Specification by ITU‑T | ISO/IEC.

The word "unspecified" is used to describe some values of a particular syntax element to indicate that the values have no specified meaning in this Specification and are not expected to have a specified meaning in the future as an integral part of future versions of this Specification.

NOTE – The mathematical operators used in this Specification are similar to those used in the C programming language. However, the results of integer division and arithmetic shift operations are defined more precisely, and additional operations are defined, such as exponentiation and real-valued division. Numbering and counting conventions generally begin from 0, e.g., "the first" is equivalent to the 0-th, "the second" is equivalent to the 1-st.

The following arithmetic operators are defined as follows:

The following logical operators are defined as follows:

When evaluating a logical expression, the value 0 is interpreted as FALSE and any numerical value not equal to 0 is interpreted as TRUE. The result of any logical expression that evaluates as FALSE is the value 0, and the result of any logical expression that evaluates as TRUE is the value 1.

When a relational operator is applied to a syntax element or variable that has been assigned the value "na" (not applicable), the value "na" is treated as a distinct value for the syntax element or variable. The value "na" is considered not to be equal to any other value.

When order of precedence in an expression is not indicated explicitly by use of parentheses, the following rules apply:

— Operations of a higher precedence are evaluated before any operation of a lower precedence.

— Operations of the same precedence are evaluated sequentially from left to right.

Table 5‑1 specifies the precedence of operations from highest to lowest; a higher position in the table indicates a higher precedence.

NOTE – For those operators that are also used in the C programming language, the order of precedence used in this Specification is the same as used in the C programming language.

Table 5‑1 — Operation precedence from highest (at top of table) to lowest (at bottom of table)

The accuracy of all floating-point representations is specified by the following constant parameter:

— FPRNumDigitsVal specifies the number of significant binary digits in the floating-point representation. Given the value of FPRNumDigitsVal, all calculations for the significand of a floating-point representation can be implemented using signed integer arithmetic with N = FPRNumDigitsVal + 2 bits.

Division operations for floating-point representations are specified based on a look-up table. The accuracy of division operations is specified by the following two constant parameters:

— FPRLog2DivTabSize specifies the binary logarithm of the number of elements in the look-up table. The look-up table used for division operations has (1 << FPRLog2DivTabSize) elements.

— FPRNumDigitsDivTab specifies the number of significant binary digits for the values of the division look-up table. Given the value of FPRNumDigitsDivTab, the elements of the look-up table can be represented as unsigned integers with N = FPRNumDigitsDivTab bits or as signed integers with N = FPRNumDigitsDivTab +1 bits.

The division look-up table is referred to as FPRDivTab. It is determined as specified by the following pseudo-code:

where the division represents an integer division with truncation towards zero.

For the following specification, the values FPRNumDigitsVal = 30, FPRLog2DivTabSize = 8, and FPRNumDigitsDivTab = 15 are used. All calculations for the significand of a floating-point representation can be implemented in 32-bit signed integer arithmetic. The look-up table FPRDivTab has 256 elements, and each of these elements can be represented as 16-bit signed integer. The total size required for storing the look-up table is 512 bytes.

A floating point representation is specified as a triple (val, exp, sgn) as follows:

— val is an integer number specifying the significant digits of a floating-point representation, also referred to as the significand. The value of val is represented as signed integer number of at least N = FPRNumDigitsVal + 2 bits. Even though the actual value of val can always be represented by an unsigned integer of FPRNumDigitsVal bits, two additional bits and a signed integer representation is required for intermediate values in calculations with the floating-point representation. With FPRNumDigitsVal = 30, all calculations related to the number val specifying the significand of a floating-point representation can be done using 32-bit signed integers;

— exp is an integer number representing the exponent;

— sgn is a bit representing the sign, where negative numbers have sgn = 1 and positive numbers have sgn = 0.

With x being a floating point representation, the elements of the triple (val, exp, sgn) specifying x are also referred to as x.val, x.exp, and x.sgn, respectively.

The floating-point value fx that is specified by a floating-point representation x is given by:

NOTE – As shown in this equation, when x.val is equal to 0, the value represented is 0, regardless of the values of x.exp and x.sgn.

In the following x, y, and z denote floating-point representations and a denotes an integer. The following functions and arithmetic operators are specified:

— Conversion of an integer to a floating-point representation:

The floating-point representation x is derived by invoking the process for converting an integer to a floating-point representation as specified in clause 5.11.3.1 with a as input and the output is assigned to x.

— Conversion of a floating-point representation to an integer:

The integer a is derived by invoking the process for converting a floating-point representation to an integer as specified in clause 5.11.3.2 with a as input and the output is assigned to a.

— Bit-shift to the left:

The floating-point representation y is derived by invoking the process for shifting a floating-point representation to the left as specified in clause 5.11.3.3 with x and a as inputs and the output is assigned to y.

— Bit-shift to the right:

The floating-point representation y is derived by invoking the process for shifting a floating-point representation to the right as specified in clause 5.11.3.4 with x and a as inputs and the output is assigned to y.

— Negation:

The floating-point representation y is derived by invoking the process for negating a floating-point representation as specified in clause 5.11.3.5 with x as input and the output is assigned to y.

— Addition:

The floating-point representation z is derived by invoking the process for adding two floating-point representations as specified in clause 5.11.3.6 with x and y as inputs and the output is assigned to z.

— Subtraction:

The floating-point representation z is derived by invoking the process for subtracting two floating-point representations as specified in clause 5.11.3.7 with x and y as inputs and the output is assigned to z.

— Multiplication:

The floating-point representation z is derived by invoking the process for multiplying two floating-point representations as specified in clause 5.11.3.8 with x and y as inputs and the output is assigned to z.

— Reciprocal:

The floating-point representation y is derived by invoking the process for deriving the reciprocal of a floating-point representation as specified in clause 5.11.3.9 with x as input and the output is assigned to y.

— Division:

The floating-point representation z is derived by invoking the process for dividing two floating-point representations as specified in clause 5.11.3.10 with x and y as inputs and the output is assigned to z.

The operator precedence for floating-point representations is the same as specified in clause 5.10.

Process for converting an integer to a floating-point representation

Input to this process is a signed or unsigned integer value a.

Output of this process is a floating-point representation x = ( x.val, x.exp, x.sgn ) specifying the integer a.

The output value y is initialized with y.val = 0, y.exp = 0, and y.sgn = 0.

When a is not equal to 0, the output value y is modified as specified by the following pseudo-code:

Process for converting a floating-point representation to an integer

Input to this process is a floating-point representation x = ( x.val, x.exp, x.sgn ).

Output of this process is an integer a specifying the floating-point representation x rounded to an integer value.

The value of a is initially set to 0.

When x.val is not equal to 0, the value of a is modified as specified by the following pseudo-code:

Process for shifting a floating-point representation to the left

Inputs to this process are:

— a floating-point representation x = ( x.val, x.exp, x.sgn ), and

— a non-negative integer number a representing a bit shift to the left.

Output of this process is a floating-point representation y = ( y.val, y.exp, y.sgn ) specifying the result of the bit shift.

The floating-point representation y is determined as specified by the following pseudo-code:

Process for shifting a floating-point representation to the right

Inputs to this process are:

— a floating-point representation x = ( x.val, x.exp, x.sgn ), and

— a non-negative integer number a representing a bit shift to the right.

Output of this process is a floating-point representation y = ( y.val, y.exp, y.sgn ) specifying the result of the bit shift.

The floating-point representation y is determined as specified by the following pseudo-code:

Process for negating a floating-point representation

Input to this process is a floating-point representation x = ( x.val, x.exp, x.sgn ).

Output of this process is a floating-point representation y = ( y.val, y.exp, y.sgn ) specifying the result of the negation of x.

The floating-point representation y is determined as specified by the following pseudo-code:

Process for adding two floating-point representations

Input to this process are:

— a floating-point representation x = ( x.val, x.exp, x.sgn ) specifying the first summand;

— a floating-point representation y = ( y.val, y.exp, y.sgn ) specifying the second summand.

Output of this process is a floating-point representation z = ( z.val, z.exp, z.sgn ) specifying the result of the addition of x and y.

If x.val is equal to 0, z is set equal to y, i.e., z.val = y.val, z.exp = y.exp, and z.sgn = y.sgn.

Otherwise, if y.val is equal to 0, z is set equal to x, i.e., z.val = x.val, z.exp = x.exp, and z.sgn = x.sgn.

Otherwise ( x.val is not equal to 0 and y.val is not equal to 0 ), the value of z is first initialized with z.val = 0, z.exp = 0, and z.sgn = 0 and then updated as specified by the following pseudo-code:

Process for subtracting two floating-point representations

Input to this process are:

— a floating-point representation x = ( x.val, x.exp, x.sgn ) specifying the minuend;

— a floating-point representation y = ( y.val, y.exp, y.sgn ) specifying the subtrahend.

Output of this process is a floating-point representation z = ( z.val, z.exp, z.sgn ) specifying the result of subtracting y from of x.

The floating point representation yn is derived by invoking the process for negating a floating-point representation as specified in clause 5.11.3.5 with y as input and the output is assigned to yn.

The floating point representation z is derived by invoking the process for adding two floating-point representation as specified in clause 5.11.3.6 with x and yn as inputs and the output is assigned to z.

Process for multiplying two floating-point representations

Input to this process are:

— a floating-point representation x = ( x.val, x.exp, x.sgn ) specifying the multiplier;

— a floating-point representation y = ( y.val, y.exp, y.sgn ) specifying the multiplicand.

Output of this process is a floating-point representation z = ( z.val, z.exp, z.sgn ) specifying the result of the multiplication of x and y.

If x.val is equal to 0 or y.val is equal to 0, z is set equal to zero, i.e., z.val = 0.

Otherwise ( x.val is not equal to 0 and y.val is not equal to 0 ), the floating-point representation z is derived as specified by the following pseudo-code:

Process for deriving the reciprocal of a floating-point representation

Input to this process is a floating-point representation x = ( x.val, x.exp, x.sgn ) with x.val being not equal to 0.

Output of this process is a floating-point representation y = ( y.val, y.exp, y.sgn ) specifying the reciprocal of x.

The floating-point representation y is derived as specified by the following pseudo-code:

Process for dividing two floating-point representations

Input to this process are:

— a floating-point representation x = ( x.val, x.exp, x.sgn ) specifying the dividend;

— a floating-point representation y = ( y.val, y.exp, y.sgn ), with y.val being not equal to 0, specifying the divisor.

Output of this process is a floating-point representation z = ( z.val, z.exp, z.sgn ) specifying the result of the division of x and y.

The floating point representation yr is derived by invoking the process for deriving the reciprocal of a floating-point representation as specified in clause 5.11.3.9 with y as input and the output is assigned to yr.

The floating point representation z is derived by invoking the process for multiplying two floating-point representations as specified in clause 5.11.3.10 with x and yr as inputs and the output is assigned to z.

Derivation process for a sub vector

Inputs to this process are:

— an N-dimensional vector vec of floating-point representations, with N > 1;

— an index r.

Output of this process is an (N − 1)-dimensional vector subVec that is obtained by deleting the r-th element from the vector vec.

The (N − 1)-dimensional vector subVec is obtained as specified by the following peudo-code:

Derivation process for a sub-matrix

Inputs to this process are:

— an NxN matrix mat of floating-point representations, with N > 1;

— a row index r; and

— a column index c.

Output of this process is an ( N − 1 ) × ( N − 1 ) matrix subMat that is obtained by deleting the r-th row and the c-th column from the matrix mat.

The ( N − 1 ) × ( N − 1 ) matrix subMat is obtained as specified by the following pseudo-code:

Derivation process for the determinant of a matrix

Inputs to this process is an NxN matrix mat of floating-point representations, with N > 0.

Output of this process is a floating-point representation det that specifies the determinant of the matrix mat.

If N is equal to 1, the determinant det is set equal to det = x[ 0 ][ 0 ].

Otherwise ( N is greater than 1 ), the determinant det is derived as specified by the following recursive process:

— The determinant is set equal to det = FPNum( 0 ).

— For k proceeding over the range from 0 to N − 1, inclusive, the following applies:

— The ( N − 1 ) × ( N − 1 ) sub-matrix subMat is derived by invoking the derivation process for a sub-matrix as specified in clause 5.11.4.2 with mat, the row index k, and the column index 0 as inputs and the output is assigned to the sub-matrix subMat.

— The determinant subDet of the ( N − 1 ) × ( N − 1 ) sub-matrix subMat is derived by invoking the derivation process for the determinant of a matrix as specified in this clause with subMat as input and the output is assigned to subDet.

— Depending on k, the determinant det is updated as specified by the following pseudo-code:

Process for solving a linear equation system with floating-point matrices and vectors

Inputs to this process are:

— an NxN matrix mat of floating-point representations, with N > 0;

— a N-dimensional vector vec of floating-point representations;

— an unsigned integer bshift specifying the precision of the output.

Output of this process is an N-dimensional vector res of integer values.

The determinant detMat of the matrix mat is determined by invoking the derivation process for the determinant of a matrix as specified in clause 5.11.4.3 with mat as input and the output is assigned to detMat.

If detMat.val is equal to 0, the value of res[ 0 ] is set equal to res[ 0 ] = 0.

Otherwise ( detMat.val is not zero ), the value of res[ 0 ] is derived as follows:

— The NxN matrix matX of floating-point representations is derived as specifified by the following pseudo-code:

— The determinant detX of the matrix matX is determined by invoking the derivation process for the determinant of a matrix as specified in clause 5.11.4.3 with matX as input and the output is assigned to detX.

— The value of res[ 0 ] is derived by:

When N is greater than 1, the values res[ k ] with k being in the range of 1 to N − 1, inclusive, are determined by the following recursive process:

— The ( N − 1 ) × ( N − 1 ) sub-matrix subMat is determined by invoking the derivation process for a sub-matrix as specified in clause 5.11.4.2 with mat, the row index 0, and the column index 0 as inputs and the output is assigned to the sub-matrix subMat.

— The ( N − 1 )-dimensional sub-vector subVec is determined by invoking the derivation process for a sub-vector as specified in clause 5.11.4.1 with vec and the index 0 as inputs and the output is assigned to the sub-vector subVec.

— The ( N − 1 )-dimensional sub-vector subVec is modified as specified by the following pseudo-code:

— The process for solving a linear equation system with floating-point matrices and vectors as specified in this clause is invoked with the ( N − 1 ) × ( N − 1 ) matrix subMat, the ( N − 1 )-dimensional vector subVec, and the integer number bshift as input and the output is assigned to the ( N − 1 )-dimensional integer vector subRes.

— The values res[ k ] with k being in the range of 1 to N − 1, inclusive, are determined by:

Process for solving a linear equation system in integer arithmetic

Inputs to this process are:

— an NxN matrix mat of integer values, with N > 0;

— a N-dimensional vector vec of integer values;

— an unsigned integer bshift specifying the precision of the output.

Output of this process is an N-dimensional vector res of integer values.

The NxN matrix fprMat of floating-point representations is derived as specified by the following pseudo-code:

The N-dimensional vector fprVec of floating-point representations is derived as specified by the following pseudo-code:

The N-dimensional output vector res is derived by invoking the process for solving a linear equation system with floating-point matrices and vectors as specified in clause 5.11.4.4 with fprMat, fprVec, and bshift as inputs and the output is assigned to res.

Syntax elements in the bitstream are represented in bold type. Each syntax element is described by its name (all lower case letters with underscore characters), and one descriptor for its method of coded representation. The decoding process behaves according to the value of the syntax element and to the values of previously decoded syntax elements. When a value of a syntax element is used in the syntax tables or the text, it appears in regular (i.e., not bold) type.

In some cases the syntax tables and semantics use the values of other variables derived from the values of syntax elements. Such variables appear in the syntax tables, or text, named by a mixture of lower case and upper case letter and without any underscore characters. Variables starting with an upper case letter are derived for the decoding of the current syntax structure and all depending syntax structures. Variables starting with an upper case letter could, in some cases, be used in the decoding process for later syntax structures without mentioning the originating syntax structure of the variable. Variables starting with a lower case letter are only used within the clause in which they are derived.

In some cases, "mnemonic" names for syntax element values or variable values are used interchangeably with their numerical values. Sometimes "mnemonic" names are used without any associated numerical values. The association of values and names is specified in the text. The names are constructed from one or more groups of letters separated by an underscore character. Each group starts with an upper case letter and could contain more upper case letters.

NOTE – The syntax is described in a manner that closely follows the C-language syntactic constructs.

Functions that specify properties of the current position in the bitstream are referred to as syntax functions. These functions are specified in clause 7.2 and assume the existence of a bitstream pointer with an indication of the position of the next bit to be read by the decoding process from the bitstream. Syntax functions are described by their names, which are constructed as syntax element names and end with left and right round parentheses including zero or more variable names (for definition) or values (for usage), separated by commas (if more than one variable).

Functions that are not syntax functions (including mathematical functions specified in clause 5.8) are described by their names, which start with an upper case letter, contain a mixture of lower and upper case letters without any underscore character, and end with left and right parentheses including zero or more variable names (for definition) or values (for usage) separated by commas (if more than one variable).

A one-dimensional array is referred to as a list. A two-dimensional array is referred to as a matrix. Arrays can either be syntax elements or variables. Subscripts or square parentheses are used for the indexing of arrays. In reference to a visual depiction of a matrix, the first subscript is used as a row (vertical) index and the second subscript is used as a column (horizontal) index. The indexing order is reversed when using square parentheses rather than subscripts for indexing. Thus, an element of a matrix s at horizontal position x and vertical position y could be denoted either as s[ x ][ y ] or as s_yx. A single column of a matrix could be referred to as a list and denoted by omission of the row index. Thus, the column of a matrix s at horizontal position x could be referred to as the list s[ x ].

A specification of values of the entries in rows and columns of an array could be denoted by { {...} {...} }, where each inner pair of brackets specifies the values of the elements within a row in increasing column order and the rows are ordered in increasing row order. Thus, setting a matrix s equal to { { 1 6 } { 4 9 }} specifies that s[ 0 ][ 0 ] is set equal to 1, s[ 1 ][ 0 ] is set equal to 6, s[ 0 ][ 1 ] is set equal to 4, and s[ 1 ][ 1 ] is set equal to 9.

Binary notation is indicated by enclosing the string of bit values by single quote marks. For example, '01000001' represents an eight-bit string having only its second and its last bits (counted from the most to the least significant bit) equal to 1.

Hexadecimal notation, indicated by prefixing the hexadecimal number by "0x", is used in some cases instead of binary notation when the number of bits is an integer multiple of 4. For example, 0x41 represents an eight-bit string having only its second and its last bits (counted from the most to the least significant bit) equal to 1.

Numerical values not enclosed in single quotes and not prefixed by "0x" are decimal values.

A value equal to 0 represents a FALSE condition in a test statement. The value TRUE is represented by any value different from zero.

In the text, a statement of logical operations as would be described mathematically in the following form:

is typically described in the following manner:

Each "If ... Otherwise, if ... Otherwise, ..." statement in the text is introduced with "... as follows" or "... the following applies" immediately followed by "If ... ". The last condition of the "If ... Otherwise, if ... Otherwise, ..." is always an "Otherwise, ...". Interleaved "If ... Otherwise, if ... Otherwise, ..." statements can be identified by matching "... as follows" or "... the following applies" with the ending "Otherwise, ...".

In the text, a statement of logical operations as would be described mathematically in the following form:

is typically described in the following manner:

In the text, a statement of logical operations as would be described mathematically in the following form:

is typically described in the following manner:

Processes are used to describe the decoding of syntax elements. A process has a separate specification and invoking. All syntax elements and upper case variables that pertain to the current syntax structure and depending syntax structures are available in the process specification and invoking. A process specification might also have a lower case variable explicitly specified as input. Each process specification has explicitly specified an output. The output is a variable that can either be an upper case variable or a lower case variable.

When invoking a process, the assignment of variables is specified as follows:

— If the variables at the invoking and the process specification do not have the same name, the variables are explicitly assigned to lower case input or output variables of the process specification.

— Otherwise (the variables at the invoking and the process specification have the same name), assignment is implied.

In the specification of a process, a specific coding block is sometimes referred to by the variable name having a value equal to the address of the specific coding block.

The syntax tables specify a superset of the syntax of all allowed bitstreams. Additional constraints on the syntax might be specified, either directly or indirectly, in other clauses.

NOTE – An actual decoder is expected to implement some means for identifying entry points into the bitstream and some means to identify and handle non-conforming bitstreams. The methods for identifying and handling errors and other such situations are not specified in this Specification.

The following table lists examples of the syntax specification format. When syntax_element appears, it specifies that a syntax element is parsed from the bitstream and the bitstream pointer is advanced to the next position beyond the syntax element in the bitstream parsing process.

The functions presented in this clause are used in the specification of the syntax. These functions are expressed in terms of the value of a bitstream pointer that indicates the position of the next bit to be read by the decoding process from the bitstream.

byte_aligned( ) is specified as follows:

— If the current position in the bitstream is a byte-aligned position, i.e., the current position is an integer multiple of 8 bits from the position of the first bit in the bitstream, the return value of byte_aligned( ) is equal to TRUE.

— Otherwise, the return value of byte_aligned( ) is equal to FALSE.

read_bits( n ) reads the next n bits from the bitstream and advances the bitstream pointer by n bit positions. When n is equal to 0, read_bits( n ) is specified to return a value equal to 0 and to not advance the bitstream pointer.

The following descriptors specify the parsing process of each syntax element:

— ae(ctxSet): context-adaptive arithmetic entropy-coded syntax element. The variable ctxSet is a non-negative integer used for deriving the context variables for parsing. The parsing process for this descriptor is specified in clause 9.5.

NOTE The variable ctxSet adds another dimension to the set of context variables. For example, many syntax elements use disjoint sets of context variables depending on the channel index.

— aep(): equal probable arithmetic entropy-coded syntax element. The syntax element does not use context variables for parsing. The parsing process for this descriptor is specified in clause 9.5.

— aet(): arithmetic entropy-coded termination syntax element. The syntax element does not use context variables for parsing. The parsing process for this descriptor is specified in clause 9.5.

— b(8): byte having any pattern of bit string (8 bits). The parsing process for this descriptor is specified by the return value of the function read_bits( 8 ).

— f(n): fixed-pattern bit string using n bits written (from left to right) with the left bit first. The parsing process for this descriptor is specified by the return value of the function read_bits( n ).

— i(n): signed integer using n bits. When n is "v" in the syntax table, the number of bits varies in a manner dependent on the value of other syntax elements. The parsing process for this descriptor is specified by the return value of the function read_bits( n ) interpreted as a two's complement integer representation with most significant bit written first.

— se(v): signed integer 0-th order Exp-Golomb-coded syntax element with the left bit first. The parsing process for this descriptor is specified in clause 9.3 with the order k equal to 0.

— st(v): null-terminated string encoded as universal coded character set (UCS) transmission format-8 (UTF-8) characters as specified in ISO/IEC 10646. The parsing process is specified as follows: st(v) reads and returns a series of bytes from the bitstream, beginning at the current position and continuing up to but not including the next byte that is equal to 0x00, and advances the bitstream pointer by ( stringLength + 1 ) * 8 bit positions, where stringLength is equal to the number of bytes returned.

NOTE The st(v) syntax descriptor does not require that the current bit position in the bitstream is a byte-aligned position.

— u(n): unsigned integer using n bits. When n is "v" in the syntax table, the number of bits varies in a manner dependent on the value of other syntax elements. The parsing process for this descriptor is specified by the return value of the function read_bits( n ) interpreted as a binary representation of an unsigned integer with most significant bit written first.

— ue(v): unsigned integer 0-th order Exp-Golomb-coded syntax element with the left bit first. The parsing process for this descriptor is specified in clause 9.3 with the order k equal to 0.

— ev(k,n,m): unsigned integer coded using escaped values. The parsing process for this descriptor is specified in clause 9.2.

— utr(c): unsigned integer un-truncated Rice (UTR)-coded syntax element. The parsing process for this descriptor is specified in clause 9.4 with “c” denoting the cRiceParam parameter.

General stream packet unit syntax

Stream packet header syntax

Waveform parameter set syntax

Channel group parameter set syntax

Independent frame syntax

Dependent frame syntax

Annotation channel syntax

Timestamp syntax

Segment payload syntax

Segment payload metadata syntax

Segment payload metadata coded sizes syntax

Feature set syntax

Config set syntax

Config extension data syntax

Synchronization structure syntax

User identifier syntax

Stream identifier syntax

Universally unique identifier syntax

Authentication start syntax

Authentication signature syntax

CRC 16 syntax

CRC 32 syntax

Global CRC 16 syntax

Global CRC 32 syntax

Auxiliary metadata syntax

Trailing bits syntax

Byte alignment syntax

General frame data syntax

Predictive transform coding block syntax

Prediction trafo block data syntax

Cross-channel prediction data syntax

Block matching prediction data syntax

Sample pred mode syntax

Linear predictive filtering data syntax

Quant res sample data syntax

LMS data syntax

Mean value trafo block syntax

General stream packet semantics

syntax_structure_byte[ i ] is the i-th byte of the syntax structure contained in the stream packet.

Stream packet header semantics

stream_packet_type specifies the stream packet type, i.e., the type of syntax structure contained in the stream packet as specified in Table 7‑1.

Stream packets that have stream_packet_type in the range of UNSPEC_20 to UNSPEC_517, inclusive, for which semantics are not specified, shall not affect the decoding process specified in this Specification.

Table 7‑1 — Stream packet types

stream_packet_label specifies a sub-stream indication. For values of 1 and higher, this element provides an indication of which packets in a stream belong together (so called sub-streams). In addition, packets with stream_packet_label set to a value of 0 apply to all sub-streams. A sub-stream is referring to a single CWS consisting of stream packets referencing to a particular wps_waveform_parameter_set_id of a WPS packet. Stream packets in a CWS shall have the same non-zero stream_packet_label as the one specified by the WPS packet or zero (apply to all sub-streams). In a multiplexed bitstream, stream_packet_label is used to facilitate sub-stream identification.

stream_packet_length indicates the length of the stream_packet_payload in bytes. It specifies the number of syntax structure bytes in the stream packet.

Waveform parameter set semantics

A WPS shall be available to the decoding process prior to it being referenced by either of the following:

— a channel group parameter set with cgps_waveform_parameter_set_id equal to the value of wps_waveform_parameter_set_id in the WPS,

— a timestamp structure with ts_waveform_parameter_set_id equal to the value of wps_waveform_parameter_set_id in the WPS,

— a feature set with ft_waveform_parameter_set_id equal to the value of wps_waveform_parameter_set_id in the WPS,

— an annotation channel with ac_waveform_parameter_set_id equal to the value of wps_waveform_parameter_set_id in the WPS.

All WPS stream packets with a particular value of wps_waveform_parameter_set_id in a CWS shall have the same content.

wps_waveform_parameter_set_id provides an identifier for the WPS for reference by other syntax elements.

wps_num_channels_in_next_group_minus1 plus 1 specifies the number of channels in the next channel group in the sequence of channel groups.

wps_num_channel_group_repetitions specifies the number of channel groups that follow the previous channel group. Each of these channel groups has the same number of channels as the previous channel group.

wps_more_channel_groups_present_flag equal to 1 specifies that more channel groups are specified on the WPS.

wps_channel_reordering_flag equal to 1 specifies that syntax elements for reordering the channels in the decoded waveform sequence is present.

wps_num_channel_swaps_minus1 plus 1 specifies the number of channel swaps to be carried out in order to perform channel reordering on the decoded waveform sequence.

wps_swap_frst_idx[ i ] specifies the first channel of channel pair i to be swpped.

wps_swap_scnd_idx_min_frst_idx_min1[ i ] plus 1 plus wps_swap_frst_idx[ i ] specifies the second channel of channel pair i to be swapped.

wps_num_annotation_channels specifies the number of annotation channels present in the bitstream.

Channel group parameter set semantics

A CGPS shall be available to the decoding process prior to it being referenced by either of the following:

— an independent frame with if_channel_group_parameter_set_id equal to the value of cgps_channel_group_parameter_set_id in the CGPS,

— a dependent frame with df_channel_group_parameter_set_id equal to the value of cgps_channel_group_parameter_set_id in the CGPS,

— a segment metadata with sm_channel_group_parameter_set_id equal to the value of cgps_channel_group_parameter_set_id in the CGPS,

All CGPS stream packets with a particular value of cgps_channel_group_parameter_set_id in a coded channel group segment shall have the same content.

cgps_channel_group_parameter_set_id provides an identifier for the CGPS for reference by other syntax elements.

cgps_waveform_parameter_set_id specifies the value of wps_waveform_parameter_set_id for the WPS in use.

cgps_length_signal_mode_flag equal to 1 specifies that a syntax element if_indep_num_samples_per_channel_minus1 is present.

cgps_frame_length_shift specifies an offset for deriving the variable Log2FrameLength as follows:

cgps_max_min_block_size specifies an index for deriving variable Log2MaxBlockSize as follows:

The value of cgps_max_min_block_size shall be in the range of 0 to 62, inclusive.

The array LutBlockSizeMaxLog2[ ] is specified as follows:

{

4, 5, 5, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 8, 8, 9,

9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 11, 11, 11, 11,

11, 11, 11, 11, 12, 12, 12, 12, 12, 12, 12, 12, 12, 13, 13, 13,

13, 13, 13, 13, 13, 13, 14, 14, 14, 14, 14, 14, 14, 14, 14

}

The array LutBlockSizeMinLog2[ ] is specified as follows:

{

4, 4, 5, 4, 5, 6, 4, 5, 6, 7, 4, 5, 6, 7, 8, 4,

5, 6, 7, 8, 9, 4, 5, 6, 7, 8, 9, 10, 4, 5, 6, 7,

8, 9, 10, 11, 4, 5, 6, 7, 8, 9, 10, 11, 12, 5, 6, 7,

8, 9, 10, 11, 12, 13, 6, 7, 8, 9, 10, 11, 12, 13, 14

}

The variable MaxSplitDepth is derived as follows:

cgps_deblocking_mode equal to 0 specifies that the deblocking process is not invoked. Otherwise, it specifies the strength of the applied deblocking process.

cgps_max_bit_depth specifies an index for deriving the variable BitDepthMax as follows:

The value of cgps_max_bit_depth shall be in the range of 0 to 6, inclusive.

The array LutBitDepthMax[ ] is specified as follows:

{4, 8, 12, 16, 20, 24, 28}

cgps_allow_cross_channel_pred_flag equal to 1 specifies that the cross-channel prediction mode is allowed.

cgps_cc_pred_filtering_mode specifies the allowed filtering options that may be applied to the cross-channel prediction signal as follows:

— If cgps_cc_pred_filtering_mode is equal to 0, no filtering may be applied to the cross-channel prediction signal.

— Otherwise, if cgps_cc_pred_filtering_mode is equal to 1, a half-sample position filtering of the cross-channel prediction signal is allowed.

— Otherwise (cgps_cc_pred_filtering_mode is equal to 2), a half-sample position filtering and a full-sample position filtering of the cross-channel prediction signal are allowed.

The value of cgps_cc_pred_filtering_mode shall lie in the range from 0 to 2, inclusive.

cgps_allow_cc_pred_mult_hyp_flag equal to 1 specifies that cross-channel prediction with two input channels is allowed.

cgps_allow_block_matching_pred_flag equal to 1 specifies that the block matching prediction mode is allowed.

cgps_bm_pred_filtering_mode specifies the allowed filtering options that may be applied to the block matching prediction signal as follows:

— If cgps_bm_pred_filtering_mode is equal to 0, no filtering may be applied to the block matching prediction.

— Otherwise, if cgps_bm_pred_filtering_mode is equal to 1, a half-sample position filtering of the block matching prediction signal is allowed.

— Otherwise (cgps_bm_pred_filtering_mode is equal to 2), a half-sample position filtering and a full-sample position filtering of the block matching prediction signal are allowed.

The value of cgps_bm_pred_filtering_mode shall lie in the range from 0 to 2, inclusive.

cgps_allow_bm_pred_mult_hyp_flag equal to 1 specifies that block matching prediction with two hypothesis is allowed.

cgps_allow_bm_offset_pred_prev_ch_flag equal to 1 specifies that offsets for the block matching prediction can be predicted from offsets for the block matching prediction of the previous channel.

cgps_allow_lpf_flag equal to 1 specifies that linear predictive filtering is allowed.

cgps_allow_sample_pred_fixed_weights_flag equal to 1 specifies that sample wise prediction with fixed weights is allowed.

cgps_lpf_allow_prev_ch_flag equal to 1 specifies that linear predictive filtering using input samples from a given number of previous channels is allowed.

cgps_allow_transform_skip equal to 1 specifies that a sample wise prediction is allowed

cgps_residual_quant_mode specifies the quantization mode.

cgps_ch_indep_interval_idx specifies the variable DepChMask = ( 2 << cps_ch_indep_interval_idx ) − 1. For the decoding process of clause 8, the channels can be grouped into consecutive groups of channels, each consisting of at most DepChMask +1 many channels, such that each group of channels can be processed independently from each other group of channels.

cgps_max_abs_delta_qp_idx determines the value of the variable MaxAbsDeltaQP = ( 1  <<  cgps_max_abs_delta_qp_idx ) − 1.

cgps_qp specifies the initial quantization parameter.

cgps_allow_verbatim_coding_flag equal to 1 specifies that fixed length binarization and fixed length coding is applied to the sample values if no prediction and no DCT are used on a given block. When cgps_allow_verbatim_coding_flag is not present, it is inferred to be zero.

cgps_allow_zero_lsb_flag equal to 1 specifies that a coding mode that transmis the number of zero least-significant bits per block is enabled.

cgps_ctx_init_flag equal to 1 indicates that if_ctx_init_mode is present.

cgps_allow_lms_flag equal to 1 specifies that LMS prediction is enabled.

cgps_lms_split_flag equal to 1 specifies that a resetting of the LMS prediction at the middle of the spectrum is enabled.

cgps_lms_ar_order_over_four specifies the LMS predictor order in the direction of the current channel, divided by four. As the LMS can operate on mulitple block lengths, the cgps_lms_order parameter is scaled relative to a block length of 2048. The variable LMSOrder is derived as follows:

}cgps_allow_cc_lms_flag equal to one specifies that LMS in the direction of previously decoded channels is enabled.

cgps_max_order_cc_lms_minus_one plus 1specifies the maximal lms order in the direction of previously decoded channels.

Dependent on the maximum allowed blocksize the variable LMSMaxCCOrder is derived as follows:

Independent frame semantics

if_channel_group_parameter_set_id specifies the value of cgps_channel_group_parameter_set_id for the CGPS in use.

if_channel_group_id identifies the channel group to which the current independent frame belongs. This channel group corresponds to the active channel group to be used when parsing syntax elements of the current independent frame. The length of this syntax element is Ceil( Log2( NumChannelGroups ) ) bits. When if_channel_group_id is not present, it is inferred to be equal to 0.

if_mean_per_channel specifies the coded data sample mean per channel.

if_indep_num_samples_per_channel_minus1 plus 1 specifies the number of samples per channel present in the current frame sequence.

if_ctx_init_mode indicates which parameters are used for context initialization.

Dependent frame semantics

It is a requirement of bitstream conformance that a DF unit only occurs in the bitstream if at least one IF occured before whose syntax element if_channel_group_parameter_set_id is equal to the value of df_channel_group_parameter_set_id of the current DF.

df_channel_group_id identifies the channel group to which the current independent frame belongs. This channel group corresponds to the active channel group to be used when parsing syntax elements of the current dependent frame. The length of this syntax element is Ceil( Log2( NumChannelGroups ) ) bits. When df_channel_group_id is not present, it is inferred to be equal to 0.

Annotation channel semantics

ac_waveform_parameter_set_id specifies the value of wps_waveform_parameter_set_id for the WPS in use.

ac_annotation_channel_id specifies the annotation channel index.

ac_num_annotation_bytes_div2_minus1 is used to determine the number of syntax elements am_annotaion_bytes present in the current AC as 2 * ( ac_num_annotation_bytes_div2_minus1 + 1).

Timestamp semantics

The timestamp shall be used for the following cases:

— Indicating the timing information related to the generation of a (first) sample of the signals (acquisition/recording time)

— Indicating the timing information related to the generation of coded data (encoding time)

— Indicating the true signal length or period triggered by an event (e.g., in the presence of discontinuity triggered by an encoder event due to sensor interruption, displacement or restart)

— Enabling signal alignment across multiple channels, sub-streams and signal types, e.g., compensating a clock drift between two input or decoded signals, each having a waveform acquisition timestamp.

Upon receiving the timing data, timestamp insertion into the bitstream can occur in both the encoder (signal input) and bitstream input sides.

ts_waveform_parameter_set_id specifies the value of wps_waveform_parameter_set_id for the WPS in use.

ts_channel_group_id identifies the channel group to which the current timestamp belongs. The length of this syntax element is Ceil( Log2( NumChannelGroups ) ) bits. When ts_channel_group_id is not present, it is inferred to be equal to 0.

ts_type indicates the timestamp use case as specified in Table 7‑2.

Table 7‑2 — Values of ts_type

ts_time_idx_flag equal to 1 indicates the usage of a timestamp identifier specified by ts_time_idx.

ts_time_idx indicates the unique index of the timestamp packet related to feature set.

ts_time_type indicates the time type as specified in Table 7‑3.

Table 7‑3 — Values of ts_time_type

ts_offset_type_flag equal to 0 specifies the unit of ts_time_offset in milliseconds. ts_offset_type_flag equal to 1 specifies the unit as the exact sample index. In this case, the resulting floating-point time resolution in seconds is calculated using the underlying signal sampling frequency, i.e., Ts = ts_time_offset ÷ SampFreq in seconds, where SampFreq denotes the sampling frequency.

ts_time_long is counted in seconds and the count starts on January 1st, 2025 at 00:00:00 UTC.

ts_time_offset specifies an offset of time, added to ts_time_long or ts_time_short or ts_time_uxt, respectively, in units signalled by ts_offset_type_flag.

ts_time_short in seconds elapsed since the last “ts_time_type  = =  TIME_LONG”-update.

ts_time_uxt specifies that time is in units of seconds or fractions thereof, such that the zero value corresponds to 00:00:00 UTC on 1 January 1970.

ts_time_tai specfies the time measurement of an International Atomic Time (TAI) clock and shall be used according to the syntax and semantics TAI_timestamp as specified in ISO/IEC 23001-17.

ts_status_bits shall be used according to the syntax and semantics synchronization_state, timestamp_generation_failure and timestamp_is_modified as specified ISO/IEC 23001-17. Each syntax element is a 1-bit element arranged sequentially from left-most bit to the right-most bit.

ts_time_utc specifies the UTC timing information as defined in ITU-R Recommendation TF.460-6 and the format shall follow ISO 8601, e.g.,. yyyy-mm-ddThh:mm:ss[.xxx]Z, e.g., 1970-01-01T00:00:00.000Z.

ts_time_world_flag equal to 1 indicates the timing information based on the dates of the Gregorian calendar and times based on a 24-hour clock; otherwise this indicates the timing information based on ts_time_long_relative and ts_time_offset_relative.

ts_time_long_relative is counted in seconds and the count starts from the very first sample of the waveform.

ts_time_offset_relative specifies an offset of time, added to ts_time_long_relative, in unit signalled by ts_offset_type_flag.

The time shall be set in a way that ( ts_time_long + ts_time_offset ) or ( ts_time_short + ts_time_offset ) or ( ts_time_uxt + ts_time_offset ) or ( ts_time_long_relative + ts_time_offset_relative ) indicates the time. If ts_offset_type_flag is equal to 0, the indicated timing information is, e.g., Ts = ( 1000 * ts_time_long + ts_time_offset ) in milliseconds. The uniquely associated sample index shall be obtained by ( Floor( 0.5 + Ts * SampFreq ÷ 1000 ) ), where SampFreq denotes the sampling frequency. If ts_offset_type_flag is equal to 1, the indicated timing information Ts is, e.g., ( ts_time_long + ts_time_offset ÷ SampFreq ) in seconds.

The time referring to the waveform indicates when the sample of following IF_SPT or DF_SPT with the same stream_packet_label has been recorded. The value stream_packet_label equal to to 0 indicates a timing information applied to all sub-streams.

Segment payload semantics

A segment is defined at a channel group level, refering to one of the channel groups specified by the WPS. Based on the desired configuration, a segment in a particular channel group may refer to the whole waveform, any waveform partition resulting from the whole waveform partitioning, or any arbitrary waveform excerpt. The definition also applies to the corresponding coded bitstream. Such a representation is mainly intended to facilitate random access interval and for archiving use case.

The following configuration applies:

— A single whole segment of a waveform or bitstream refers to a segment covering the whole waveform or the corresponding coded bitstream.

— A segment is also defined as a single or multiple of random access intervals. A random access interval consists of a single or multiple of frame sequences. A frame sequence is a sequence of one IF_SPT followed by zero or more DF_SPT frames. A bitstream may contain only IF_SPT frames or may also contain DF_SPT frames.

A segment payload contains syntax elements mainly consisting of, by default, concatenated headerless frame sequences within a segment (segment payload frames) and/or the segment payload metadata. Forming a segment payload packet from an existing sequence of payload packets in a segment requires the extraction of payload frame sizes from the payload packet headers to obtain the segment_payload_metadata_coded_sizes( ) data, followed by the concatenation of segment payload frames. Generating a segment payload from an input signal also follows the same procedure with the exception that the payload frame sizes are directly obtained from the framewise encoding process. Obtaining the sequence of individual payload packets from the segment payload packets is done by a reverse process of decoding the payload frame sizes to identify individual payload frames, assigning the correct payload packet type (IF_SPT or DF_SPT) to each segment payload frame, followed by generating the corresponding payload packet header. Alternatively, the last step can be substituted by generating the decoded signal.

sp_channel_group_parameter_set_id specifies the value of cgps_channel_group_parameter_set_id for the CGPS in use.

sp_channel_group_id identifies the channel group to which the current segment payload belongs. The length of this syntax element is Ceil( Log2( NumChannelGroups ) ) bits. When sp_channel_group_id is not present, it is inferred to be equal to 0.

sp_num_frames_per_segment_minus_one plus 1, indicates the number of payload frames carried in a segment.

sp_segment_payload_metadata_flag indicates whether segment payload metadata information is present or not.

sp_segment_payload_frames_flag indicates whether segment payload frames information is present or not.

sp_num_sequences_minus_one plus 1, specifies the number frame sequences within a segment.

sp_varying_num_frames_per_sequence_flag indicates whether there is a varying number of frames in each frame sequence in the segment.

sp_num_frames_per_sequence_minus_one plus 1, specifies the number of frames in a frame sequence.

Prior to extraction, a segment of interest is identified by a sub-stream identifier (see stream_packet_label), a channel group identifier and segment portion boundaries or markers (e.g., provided by a user or machine upon inspecting the signal).

Extracting a segment payload shall include the corresponding HLS packets (e.g., WPS, multiple CGPS packets) to ensure that the indicated payload packets are decodable. The payload packets of a segment consist of one or more frame sequences, with the possbility to drop trailing DF_SPT packets. The accompanying HLS packets are of types WPS_SPT, CGPS_SPT, TIMESTAMP_SPT and SEGMENT_SPT. An additional TIMESTAMP packet can be inserted to provide information on the location of an extracted segment within the source bitstream or signal. A segment payload or an extracted segment payload shall be decodable.

Obtaining the exact (input or decoded) signal portion as indicated by a segment shall utilize the segment’s boundary information (i.e., start and length as previously provided by a user or machine).

Segment payload metadata semantics

Segment payload metadata can provide information on the following:

— The presence of features within a segment with the possibility to specify feature markers and annotations

— Distortion measures.

The segment payload metadata packet, when sp_segment_payload_frames_flag = 0, is inserted at the end of each segment.

The distortion measure information can be used, for example, for the following purposes:

— Indicating or classifying the segment’s coding behaviour, i.e., lossless, near lossless (small distortion) or lossy.

— Deriving other distortion measure metrics.

— Enabling assessment of distortion at the decoder side without having access to the original signals. This use case is related to retrieval of lossy coded segments from a dataset by classifying and filtering of the segments in the context of further post-processing such as artificial intelligence-based training.

— Transcoding (encoding of a decoded bitstream) from lossless to lossy or tandem coding (lossy to lossy). According to the first use case of lossless to lossy, the first encoding stage is lossless, therefore during the second stage encoding, the signal from the first stage encoding can be used a a reference, thus enabling computation of the distortion measures. According to the second use case of tandem coding, the first encoding stage is lossy, therefore there is no direct access to the reference signal during the second encoding stage. In this case, estimating the distortion at the second stage involves estimating the distortion measures based on an approximation derived from the distortion measures or quantization parameters from the first encoding stage.

sp_num_features specifies the number of features within a segment.

sp_feature_type specifies the FeatureType, as defined in feat_extract( ) in clause 7.4.2.10, stored in string type value.

sp_feature_segment_marking_flag indicates the presence of feature marking.

sp_feature_segment_start indicates the offset start of a feature marking in units of samples.

sp_feature_segment_length indicates the length of a feature marking in units of samples.

sp_segment_distortion_measures_flag equal to 1 indicates the presence of distortion measures metadata in the segment. This is also indicating the coded data coding mode, a lossless codec shall set this to 0.

sp_distortion_measures_per_channel_flag indicates whether the per-channel distortion measure metadata is present.

sp_num_distortion_measures_per_channel indicates the number of other per-channel distortion measures calculated for the segment.

sp_variance indicates the estimated signal variance measured per channel in decibel units, as specified by the expression Round( 10 * Log10( x ) ), where x denotes the statistical variance of the signal of interest.

sp_squared_error indicates the estimated average signal squared error measured per channel in decibel units, as specified by the expression Round( 10 * Log10( ), where e_i denotes the signal error introduced by the encoding of the i-th sample in a sequence of n samples.

sp_distortion_measure_type indicates other types of per-channel distortion measure calculated in a segment, e.g., maximum absolute error or maximum amplitude error, including its unit. Some distortion measures can also be derived from sp_variance or sq_squared_error such as the percentage root mean square distortion (PRD), channel-normalized percentage root mean square distortion (CPRD), as defined below.

where denotes the signal error introduced by the encoding of the i-th sample in a sequence of n sample, for the j-th channel out of M channels. denotes the encoding (original) input signal i-th sample of the j-th channel and denotes the mean of the encoding input for the j-th channel defined as

NOTE – The definition of the PRD includes a mean-removal in order to be invariant towards constant signal-shifts.

sp_distortion_measure indicates the per-channel distortion measure value.

sp_distortion_measures_in_cg_flag indicates the measure of distortion per-channel group.

sp_num_distortion_measures_in_cg indicates the number of other per-channel group distortion measures calculated for the segment.

sp_variance_cg indicates the estimated signal variance per-channel group in decibel units, as specified by the expression Round( 10 * Log10( x ) ), where x denotes the statistical variance of the signal of interest in the channel group.

sp_squared_error_cg indicates the estimated signal squared error per-channel group in decibel units.

sp_distortion_measure_type_cg indicates other types of per-channel group distortion measure calculated in a segment, e.g., maximum absolute error or maximum amplitude error, including its unit.

sp_distortion_measure_cg indicates the per-channel group distortion measure value.

Segment payload metadata coded sizes semantics

Segment payload metadata coded sizes is part of the segment payload storing the coded payload frame sizes.

sp_frame_size[ 0 ] indicates the size/length of the first (n equal to 0, IF_SPT) coded data frame in the segment. Subsequent frame sizes (for n greater than 0) are encoded using the un-truncated Rice or Golomb-Rice delta encoding method.

sp_delta_utr_param specifies the parameter that controls the un-truncated Rice or Golomb-Rice delta encoding of subsequent sp_frame_size[ n ]. It uses the fixed-length (FL) binarization process having cMax equal to 15, see clause 9.5.3.7.

sp_abs_delta for a given iteration n, specifies the encoded absolute value of the difference between the n-th and ( n – 1 )-th sp_frame_size values (encoded absolute delta value).

sp_sign_delta specifies the sign of abs_delta. It uses the fixed-length (FL) binarization process having cMax = 1, see clause 9.5.3.7.

Feature set semantics

The feature set syntax structure is used to indicate a portion of the signal that has particular characteristics or is of particular interest, such as for the following purposes:

— Defining, marking, annotating and maintaining a list of feature segments. Any arbitrary waveform excerpt can constitute a feature segment. Feature segments may be disjoint, overlapping or may have a superset/subset relationship.

— Indicating sparsely and ultra-low sampled measurements or metadata. The timestamp of instantaneous measurements or metadata is specified by setting ft_feature_length value to the same value as ft_feature_start, ensuring a single timestamp per measurement. The measurement value is stored in ft_annotation_str, ft_annotation_uri, or ft_annotation_channel_id.

ft_waveform_parameter_set_id specifies the value of wps_waveform_parameter_set_id for the WPS in use.

ft_channel_group_id identifies the channel group to which the current feature set belongs. The length of this syntax element is Ceil( Log2( NumChannelGroups ) ) bits. When ft_channel_group_id is not present, it is inferred to be equal to 0.

ft_num_features the number of features available in the bitstream.

ft_feature_annotation_type specifies the desired feature annotation type as indicated in Table 7‑4.

Table 7‑4 — Values of ft_feature_annotation_type

ft_annotation_str specifies an arbitrary feature type annotation string.

ft_annotation_uri specifies the feature type annotation string as a URI which shall be as specified in IETF Internet Standard 66.

ft_annotation_channel_id indicates the annotation channel index of the specified annotation_channel ID (ac_annotation_channel_id). Together with ft_annotation_channel_wps_id, they shall point to the annotation stored in the annotation_channel_data of the specified annotation_channel.

ft_feature_type_enum indicates a certain type of features of the signal as indicated in the following tables (Table 7‑5, Table 7‑6, or Table 7‑7) for different signal types.

Table 7‑5 — Values of ft_feature_type_enum (for cs_signal_type ST_ECG or ST_PPG)

Table 7‑6 — Values of ft_feature_type_enum (for cs_signal_type ST_EEG)

Table 7‑7 — Values of ft_feature_type_enum (for cs_signal_type ST_EMG)

feat_extract( ) function processes the input syntax elements ft_annotation_str or ft_annotation_uri or ft_annotation_channel_id or ft_feature_type_enum, and returns the FeatureType value. In case ft_feature_type_enum, feat_extract( ) returns FeatureType value as indicated by Feature type values in Table 7‑5, Table 7‑6 and Table 7‑7, depending on cs_signal_type. FeatureType provides a description or annotation to the portion of the signal that has particular characteristics or is of particular interest (feature segment).

ft_feature_marking_present_flag equal to 1 indicates the presence of markers defining feature segment boundaries in the bitstream. The markers, ft_feature_start and feature_length, define a feature segment associated with FeatureType. In the absence of such markers (ft_feature_marking_present_flat equal to 0), the feature segment is refering to the whole signal or bitstream.

ft_feature_start indicates the timestamp index ts_time_idx of the start of a feature marking. Utilizing ts_time_idx requires setting ts_time_idx_flag to 1.

ft_feature_length indicates the timestamp index ts_time_idx denoting the end of a feature marking defining the feature segment length. The segment length indicates the signal portion that has the corresponding portion of payload packets. Utilizing ts_time_idx requires setting ts_time_idx_flag to 1.

ft_num_qualities the number of quality level periods available in the bitstream.

ft_quality_start indicates the timestamp index ts_time_idx of the start of a quality level marking.

ft_quality_length indicates the timestamp index ts_time_idx denoting the end of a quality level marking defining the quality level length.

ft_quality_value indicates the value of the marked quality, as contained in the cs_quality_lut.

Prior to extraction, a feature segment of interest is identified by a sub-stream identifier (see stream_packet_label), a channel group identifier and segment portion boundaries or markers (either from the stored markers in FEATURE set packet in the bitstream or provided by a user or machine upon inspecting the signal).

Extracting a feature segment shall include the corresponding HLS packets (e.g., WPS, multiple CGPS packets) to ensure that the indicated payload packets of the segment are decodable. The payload packets of a segment consist of one or more frame sequences, with the possbility to drop trailing DF_SPT packets. The accompanying HLS packets of an extracted feature segment are of types WPS_SPT, CGPS_SPT, TIMESTAMP_SPT and FEATURE_SPT. An additional TIMESTAMP packet can be inserted to provide information on the location of an extracted segment within the source bitstream or signal. The extracted segment’s HLS packets shall be adjusted such that the number of features, ft_num_features, in FEATURE set packet and the TIMESTAMP packets indicated by ft_feature_start and ft_feature_length, correspond to the feature(s) contained in the extracted segment. A feature segment or an extracted feature segment shall be decodable.

Obtaining the exact (input or decoded) signal portion as indicated by a feature segment shall utilize the feature segment’s boundary information (i.e., start and length derived from FEATURE_SPT).

Config set semantics

The default syntax elements constitute the minimum configuration information. This can be extended by specifying config_extension_data( ).

cs_num_wps_ids specifies the number of WPS packets in the bitstream.

cs_wps_id specifies the value of wps_waveform_parameter_set_id for a particular WPS.

cs_wps_id_label specifies the stream_packet_label value of the WPS indicated by cs_wps_id.

cs_wps_id_label_zero specifies a non-zero value denoting the mapping of stream_packet_label 0 belonging to a subset of wps packets in the bitstream.

cs_num_channel_groups_in_wps indicates the number of channel groups in the indicated WPS.

cs_num_sampling_freqs_in_wps indicates the number of sampling frequencies in the indicated WPS.

cs_sampling_freq specifies the sampling frequency value.

cs_sampling_freq_idx specifies the corresponding index indicating the sampling frequency value. The number of bits required is calculated as Ceil( Log2( cs_num_sampling_freqs_in_wps ) ).

cs_num_signal_types_in_wps indicates the number of signal types in the indicated WPS.

cs_signal_type specifies the signal type value.

cs_signal_num_annotation_channels specifies the number of annotation channels associated with the signal type.

cs_signal_annotation_channel_id specifies the ac_annotation_channel_id in use.

cs_signal_type_idx specifies the corresponding index indicating the signal type value. The number of bits required is calculated as Ceil( Log2( cs_num_signal_types_in_wps ) ).

cs_signal_info_data_flag_in_wps indicates whether signal-specific metadata is included for the channel groups within the WPS

cs_has_range_info indicates whether the digital and analogue ranges are specified for the channel group.

cs_digital_min and cs_digital_max specify the minimum and maximum values that may occur for the signals within the channel group respectively.

cs_analogue_min and cs_analogue_max specify the analogue values to which cs_digital_min and cs_digital_max may be converted to respectively. Linear interpolation shall be used for the intermediate values.

cs_analogue_units specifies the analogue units for the waveforms within the channel group, e.g. ‘mV’.

cs_recording_start_time_flag indicates whether the starting time of the recording is included in a timestamp_struct( ).

cs_config_extension_flag indicates whether config_extension_data( ) is present.

Config extension data semantics

cs_features_in_wps_flag equal to 1 indicates the presence of feature segments in the indicated WPS.

cs_features_in_cg_id_flag equal to 1 indicates the presence of feature segments in a particular channel group within the indicated WPS.

cs_num_features_in_cg_id indicates the number of features present in the indicated channel group.

cs_enable_high_res_quality_metrics_flag specifies whether a feature_set( ) syntax structure may contain quality metrics for the encoding performance of the channels within the channel group.

cs_has_custom_quality_lut_flag specifies whether a custom look-up table is defined to be used with the quality metric.

cs_quality_metric specifies the metric used to asses the quality of the channel encoding, as specified in Table 7‑8. When cs_has_custom_quality_lut_flag is equal to 0, cs_quality_metric is inferred as specified by Table 7‑9.

Table 7‑8 — Values of cs_quality_metric

Table 7‑9 — Default values of cs_quality_metric by cs_signal_type

cs_quality_num_bands specifies the number of bands that shall be used to construct the look up tables for the quality metric.

cs_quality_lut[ i ][ j ] specifies the lower bound for the quality specified by the jth entry into the look up table for the ith channel group. When cs_has_custom_quality_lut_flag is equal to 0, the values of cs_quality_lut[ i ] are inferred as specified by Table 7‑10 to Table 7‑13.

Table 7‑10 — Default cs_quality_lut[ i ][ j ] for cs_quality_metric = = SNR

Table 7‑11 — Default cs_quality_lut[ i ][ j ] for cs_quality_metric = = PSNR

Table 7‑12 — Default cs_quality_LUT[ i ][ j ] for cs_quality_metric = = PRD

Table 7‑13 — Default cs_quality_lut[ i ][ j ] for cs_quality_metric = = MAE

cs_uses_quality_threshold_flag specifies whether a minimum quality threshold is used. If true, all time periods are assumed to have a quality level at or above that given by cs_quality_threshold.

cs_has_custom_quality_threshold_flag specifies whether a minmum quality threshold value is provided in the bitstream.

cs_quality_threshold[ i ][ cg ] specifies the default quality value used for all time periods not indicated by a feature_set( ) quality period. When cs_has_custom_quality_threshold_flag is equal to 0, the values of [ i ][ cg ] are inferred as specified by Table 7‑14.

Table 7‑14 — Default values of cs_quality_threshold[ i ][ cg ]

cs_segment_payload_frames_in_wps equal to 0 indicates the absence of segment payload frames in the bitstream. Equal to 1 indicates that all channel groups have the segment payload frames. Setting it to values greather than 1 indicate the partial presence of segment payload frames. The partial presence in each channel group is indicated by cs_segment_payload_frames_in_cg_id_flag, where equal to 1 indicates the presence and 0 the absence in a channel group.

cs_segment_payload_frames_in_cg_id_flag equal to 1 indicates the presence of a segment payload frames in a channel group.

Synchronization structure semantics

syncword_8bits shall be equal to 0xDD.

User identifier semantics

The UUID specified in the user identifier data, indicates a user identifier and shall have a value specified as a UUID according to the procedures of ISO/IEC 11578, Annex A.

Stream identifier semantics

The UUID specified in the stream identifier data, indicates a stream identifier and shall have a value specified as a UUID according to the procedures of ISO/IEC 11578, Annex A.

Universally unique identifier semantics

uuid_segment_start_flag equal to 1 indicates the start of a UUID segment.

uuid_segment_stop_flag equal to 1 identifies the end of a uuid_segment. If both uuid_segment_start_flag and uuid_segment_stop_flag are equal to 1, the uuid_data-field contains the full UUID.

uuid_reserved_2bits shall be equal to 0 in bitstreams that conform to this version of this Specification. However, decoders that conform to this version of this Specification shall allow other values to be present and shall ignore the value. It is possible that a future version of this Specification will allow other values and specify their meaning.

uuid_segment_length_minus1 plus 1 specifies the length of the partial UUID in bytes.

uuid_data specifies a segment of a UUID or the full UUID.

Authentication start semantics

aust_id contains an identifying number of a verification system that may be applied for verifying that the coded packets represented by the current verification period have been produced by the content provider identified by this packet. It indicates the combination of aust_hash_type, aust_prov_id and aust_key_id to which the related authentication information belongs to. This can be used to enable authentication of one authentication sequence with different authentication configurations.

aust_sequence_id indicates the authentication sequence the related authentication information belongs to.

aust_hash_type indicates the hashing algorithm as specified in Table 7‑15.

Table 7‑15 — Values of aust_hash_type

aust_key_id identifies the authentication key used to calculate the value of the signature (ausig_sig_partial, ausig_sig_complete) as specified in Table 7‑16. The values of this field are implementation dependent and are not defined in the present document. This value shall be set to 0 in case there is no key needed of the underlying hash-function.

Table 7‑16 — Values of aust_key_id

aust_prov_id identifies the provider of the authentication system, as specified in Table 7‑17. In case aust_prov_id equals to 1, there is no provider. This mode can be used to create the message digest only by using the method identified by aust_hash_type.

Table 7‑17 — Values of aust_prov_id

aust_key_source_uri contains a URI with syntax and semantics as specified in IETF Internet Standard 66.

aust_frame_types_present_flag indicates if authentication information for additional packet types is signalled.

aust_inclusion_types_flag indicates the following. If set to 1, all packet types signalled in aust_packet_type[ ] syntax elements shall be included into the calculation of the authentication information. If set to 0, all packet types signalled in aust_packet_type[ ] syntax elements shall be excluded from the calculation of the authentication information.

aust_reserved_7bits shall be equal to 0 in bitstreams that conform to this version of this Specification. However, decoders that conform to this version of this Specification shall allow other values to be present and shall ignore the value. It is possible that a future version of this Specification will allow other values and specify their meaning.

aust_pactype_length_minus1 plus 1 indicates the number of syntax elements aust_packet_type[ ] present.

aust_packet_type[ ] indicates the following. If aust_inclusion_types_flag is equal to 1, all packet types signalled in aust_packet_type[ ] syntax elements are included into the calculation of the authentication information. If aust_inclusion_types_flag is equal to 0, all packet types signalled in aust_packet_type[ ] syntax elements are excluded from the calculation of the authentication information.

aust_multi_stream_flag indicates if authentication information for additional labels is signalled.

aust_inclusion_labels_flag indicates the following. If equal to 1, all sub-streams signalled in aust_add_packet_label[ ] syntax elements are included into the calculation of the authentication information. If equal to 0, all sub-streams signalled in aust_add_packet_label[ ] syntax elements are excluded from the calculation of the authentication information.

aust_label_list_length_minus1 indicates the number of syntax elements aust_add_packet_label[ ] present.

aust_add_packet_label[ ] indicates the following. The value of aust_add_packet_label[ ] indicates that the sub-stream with this packet label are included in (aust_inclusion_labels_flag is equal to 1) or excluded from (aust_inclusion_labels_flag is equal to 0) the calculation of the authentication information in addition to the sub-stream with the same stream_packet_label as assigned to the AUTH_START_SPT packet.

stream_packet_label equal to 0 indicates that all sub-streams are included. In this case, aust_inclusion_labels_flag should be set to 0, to signal exclusion of the labels indicated in aust_add_packet_label[ ].

Authentication signature semantics

ausig_id contains an identifying number of a verification system that may be applied for verifying that the coded packets represented by the current verification period have been produced by the content provider indicated by the associated authentication start packet.

ausig_sequence_id indicates the authentication sequence the related authentication information belongs to.

ausig_partial_sig_flag indicates whether a partial or a complete signature is present.

ausig_segment_start_flag indicates whether the first part of new signature is present in ausig_sig_partial.

ausig_segment_stop_flag indicates whether the last part of new signature is present in ausig_sig_partial. If both ausig_segment_start_flag and and ausig_segment_stop_flag are equal to 1, ausig_sig_partial contains a signature which is complete, but shorter than a full signature resulting from the related hashing algorithm. In this case, verification may happen comparing only a subset of the bits resulting from the hashing algorithm.

ausig_segment_length_minus1 indicates the number of bytes for the syntax element ausig_sig_partial.

ausig_sig_partial carries partial protection information.

ausig_length_minus1 indicates the number of bytes for the syntax element ausig_sig_complete.

ausig_sig_complete carries complete protection information.

An authentication verification of protected encoded messages in the received packets shall be conducted to ensure their authenticity.

CRC 16

Shall be used according to the syntax and semantics mhasParity16Data for MHASPacketType PACTYP_CRC16 as specified in ISO/IEC 23008-3:2022.

CRC 32

Shall be used according to the syntax and semantics mhasParity32Data for MHASPacketType PACTYP_CRC16 as specified in ISO/IEC 23008-3:2022.

Global CRC 16

Shall be used according to the syntax and semantics global_CRC_type for MHASPacketType PACTYP_GLOBAL_CRC16 as specified in ISO/IEC 23008-3:2022.

Global CRC 32

Shall be used according to the syntax and semantics global_CRC_type for MHASPacketType PACTYP_GLOBAL_CRC32 as specified in ISO/IEC 23008-3:2022.

Auxiliary metadata semantics

An AM unit shall only occur as the first stream packet in the bitstream.

am_header_crc32 is the CRC calculated over the byte sequence starting with the byte containing the am_reserved_flag until the end of auxiliary_metadata( ).

am_extension_present_flag shall be equal to 0 in bitstreams that conform to this version of this Specification. However, decoders that conform to this version of this Specification shall allow the value 1 to be present and shall ignore the value. It is possible that a future version of this Specification will allow the value 1 and specify its meaning.

am_waveform_type specifies the waveform type according to Table 7‑18.

Table 7‑18 — Name association to am_waveform_type and type description

am_length_signal_mode equal to 1 indicates that syntax element am_stream_num_samples_per_ch is present in the bitstream.

am_allow_reconfig_flag

am_copyright_flag

am_original_flag

am_private_flag

am_stream_max_sampling_rate_minus1 plus 1 specifies the maximum sampling rate present in the bitstream.

am_stream_max_num_channels_minus1 plus 1 specifies the maximum number of channels in the bitstream.

am_stream_num_samples_per_ch specifies the number of samples per channel present in the bitstream.

am_metadata_reserved_flag shall be equal to 0 in bitstreams that conform to this version of this Specification. However, decoders that conform to this version of this Specification shall allow the value 1 to be present and shall ignore the value. It is possible that a future version of this Specification will allow the value 1 and specify its meaning..

am_metadata_num_bytes_minus1 plus 1 specifies the number of metadata payload bytes present in the AM.

am_metadata_payload_bytes[ i ] specifies the i-th metadata payload byte. The array am_metadata_payload_bytes is a bitstream according to ITU-R BS.2088-1 (RIFF chunk data bytes starting after cbSize field).

am_signal_type indicates the present signal type as specified in Table 7‑19

Table 7‑19 — Name association to am_signal_type and cs_signal_type type description

Trailing bits semantics

stop_one_bit shall be equal to 1.

alignment_zero_bit shall be equal to 0.

Byte alignment semantics

byte_alignment_bit_equal_to_zero shall be equal to 0.

General frame data semantics

end_of_frame_sequence_flag equal to 1 indicates that that the current frame sequence is terminated. When end_of_frame_sequence_flag is not present, it is inferred to be equal to 0.

block_split_log2 specifies a parameter for calculating Log2BlockSize. When block_split_log2 is not present, it is inferred to be equal to 0.

end_of_truncated_frame_sequence_flag equal to 1 indicates that the current block is the last block of the frame sequence. When end_of_truncated_frame_sequence_flag is not present, it is inferred to be equal to 0.

num_samples_per_channel_to_discard specifies the number of samples per channel to be discarded at the end of the current block. Discarding of samples is only done if end_of_truncated_frame_sequence_flag equals 1. The length of this syntax element is Log2BlockSize bits. The value of num_samples_per_channel_to_discard shall not be equal to 0.

end_of_frame_one_bit equal to 1 indicates the end of a frame. When end_of_frame_one_bit is present, it shall be equal to 1. When end_of_frame_one_bit is not present, it is inferred to be equal to 0.

Predictive transform coding block semantics

Predictive trafo block data semantics

block_matching_or_cross_channel_pred_flag equal to 1 indicates that the predicition is generated by invoking either the block-matching or the linear model prediction mode. When block_matching_or_cross_channel_pred_flag is not present, it is inferred to be 0.

cross_channel_pred_flag equal to 1 indicates that the prediction is generated by invoking the cross-channel prediction mode.

When cross_channel_pred_flag is not present, it is inferred as follows:

— If cgps_allow_cross_channel_pred_flag is equal to 1 and block_matching_or_cross_channel_pred_flag is equal to 1, cross_channel_pred_flag is inferred to be 1.

— Otherwise (cgps_allow_cross_channel_pred_flag is equal to 0 or block_matching_or_cross_channel_pred_flag is equal to 0), the value of cross_channel_pred_flag is inferred to be 0.

block_pred_mode specifies the block prediction mode according to Table 7‑20. When block_pred_mode is not present, it is inferred to be equal to BPM_OFF.

Table 7‑20 — Name association to block_pred_mode and mode description

block_abs_delta_qp specifies the absolute value of the current QP-value-difference associated with the current block of the current channel. When block_abs_delta_qp is not present, it is inferred to be equal to 0.

block_delta_qp_sign_flag specifies the sign of the current QP-value-difference.

When block_delta_qp_sign_flag is not present, it is inferred to be 0.

transform_present_flag equal to 1 indicates that the identity transform is not used on the current block.

transform_dst_flag equal to 1 indicates that the discrete sine transform is used on the current block.

The syntax elements transform_present_flag and transform_dst_flag determine the block-wise transform TransformMode for the current block. The possible values of TransformMode are delineated in Table 7‑21.

Table 7‑21 — Name association to TransformMode and mode description

zlsb_present_flag equal to 1 specifies that zero least significant bits are present. If zlsb_present_flag is not present, it is inferred to be equal to zero.

num_zlsb_minus1 plus 1, specifies the number of zero least significant bits.

Cross-channel prediction data semantics

cc_pred_offset_only_flag equal to 1 indicates that the cross-channel prediction mode is to be applied without a scaling factor.

cc_pred_filter_flag equal to 1 indicates that the output of the cross-channel prediction mode is to be filtered, where the set of filter coefficients is determined by the syntax element cc_pred_filter_idx. When cc_pred_filter_flag is not present, it is inferred to be 0.

cc_pred_filter_idx specifies the index filterIdx to derive the array CCFiltCoeffs as specified in Table 7‑22 for filtering the output of the cross-channel prediction.

Table 7‑22 — Name association to filterIdx