Patent Description:
More specifically, but not exclusively, the present disclosure relates a method and device for efficiently distributing the bit-budget in a codec.

One of the best techniques for encoding sound at low bit rates is the Code-Excited Linear Prediction (CELP) coding. In CELP coding, the sound signal is sampled and the sampled sound signal is processed in successive blocks of L samples usually called frames, where L is a predetermined number corresponding typically to <NUM>. The main principle behind CELP is called "Analysis-by-Synthesis" where possible decoder outputs are synthesized during the encoding process and then compared to the original sound signal. This search minimizes a mean-squared error between the input sound signal and the synthesized sound signal in a perceptually weighted domain.

In CELP-based coding, the sound signal is typically synthesized by filtering an excitation through an all-pole digital filter <NUM>/A(z), often called synthesis filter. Filter A(z) is estimated by means of Linear Prediction (LP) and represents short-term correlations between sound signal samples. The LP filter coefficients are usually calculated once per frame. In CELP codecs, the frame is further divided into several (usually two (<NUM>) to five (<NUM>)) sub-frames to encode the excitation that is typically composed of two portions searched sequentially. Their respective gains may then be jointly quantized. In the following description, the number of sub-frames is denoted as N and the index of a particular sub-frame is denoted as n where n = <NUM>,.

The first portion of the excitation is usually selected from an adaptive codebook. The adaptive codebook excitation portion exploits the quasi periodicity (or long-term correlations) of voiced speech signal by searching in the past excitation the segment most similar to the segment being currently encoded. The adaptive codebook excitation portion is described by an adaptive codebook index, i.e. a delay parameter corresponding to a pitch period, and an appropriate adaptive codebook gain, both sent to the decoder or stored to reconstruct the same excitation as in the encoder.

The second portion of the excitation is usually an innovation signal selected from an innovation codebook. The innovation signal models the evolution (difference) between the previous speech segment and the currently encoded segment. The second portion of the excitation is described by an index of a codevector selected from the innovation codebook, and by an innovation codebook gain (this is also referred to as fixed codebook index and fixed codebook gain).

In order to improve the coding efficiency, recent codecs such as, for example, G. <NUM> as described in Reference [<NUM>] and EVS as described in Reference [<NUM>], are based on classification of the input sound signal. Based on the signal characteristics, basic CELP coding is expanded into several different coding modes. Consequently, the classification needs to be transmitted to the decoder or stored as a signaling information. Another signaling information that is usually efficient to transmit is, for example, an audio bandwidth information.

Thus, in a CELP codec, so-called CELP "core module" parts may include:.

Most recent CELP codecs are based on a constant bit rate (CBR) principle. In CBR codecs a bit-budget to encode a given frame is constant during the encoding, regardless of the sound signal content or network characteristics. In order to obtain the best possible quality at a given constant bit rate, the bit-budget is carefully distributed among the different coding parts. In practice, the bit-budget per coding part at a given bit rate is usually fixed and stored in codec ROM tables. However, when the number of bit rates supported by a codec increases, the length of the ROM tables proportionally increases and the search within these tables becomes less efficient.

The problem of large ROM tables is even more significant in complex codecs where the bit-budget allocated to the CELP core module might fluctuate even at codec constant bit rate. For example, in a complex multi-module codec where the bit-budget at a constant bit rate is allocated between different modules based on, for example, a number of input audio channels, network feedback, audio bandwidth, input signal characteristics, etc., the codec total bit-budget is distributed among the CELP core module and other different modules. Examples of such other different modules may comprise, but are not limited to, a bandwidth extension (BWE), a stereo module, a frame error concealment (FEC) module etc. which are collectively referred to in the present description as "supplementary codec modules". It is usually advantageous to keep the allocated bit-budget per supplementary module variable based on signal characteristics or network feedback. Also, the supplementary codec modules can be adaptively switched on and off. This variability usually does not cause problems for encoding supplementary modules as the number of parameters in these modules is usually small. However, the fluctuating bit-budget allocated to supplementary codec modules results in a fluctuating bit-budget allocated to the relatively complex CELP core module.

In practice, the bit-budget allocated to the CELP core module at a given bit rate is usually obtained by reducing the codec total bit-budget with the bit-budget allocated to all active supplementary codec modules which may include a codec signaling bit-budget. Consequently, the bit-budget allocated to the CELP core module can fluctuate between a relatively large minimum and maximum bit rate span with a granularity as small as <NUM> bit (i.e. <NUM> kbps at a frame length of <NUM>).

Dedicating ROM table entries for all possible CELP core module bit rates is obviously inefficient. Therefore, there is a need for a more efficient and flexible distribution of the bit-budget among the different modules with fine bit rate granularity based on a limited number of intermediate bit rates.

Patent document <CIT> discloses speech signal classification and encoding systems and methods, wherein the signal classification is done in three steps each of them discriminating a specific signal class. Patent document <CIT> discloses a method for low-frequency emphasizing the spectrum of a sound signal transformed in a frequency domain and comprising transform coefficients grouped in a number of blocks, in which a maximum energy for one block is calculated and a position index of the block with maximum energy is determined, a factor is calculated for each block having a position index smaller than the position index of the block with maximum energy, and for each block a gain is determined from the factor and is applied to the transform coefficients of the block. Document <NPL> is a detailed description of the signal processing algorithms of the Enhanced Voice Services. Patent document <CIT> discloses an encoding apparatus for integrally encoding and decoding a speech signal and a audio signal, which includes an input signal analyzer to analyze a characteristic of an input signal; a stereo encoder to down mix the input signal to a mono signal when the input signal is a stereo signal, and to extract stereo sound image information; a frequency band expander to expand a frequency band of the input signal; a sampling rate converter to convert a sampling rate; a speech signal encoder to encode the input signal using a speech encoding module when the input signal is a speech characteristics signal; a audio signal encoder to encode the input signal using a audio encoding module when the input signal is a audio characteristic signal; and a bitstream generator to generate a bitstream. Document "<NPL>discloses high quality monaural superwideband extensions to G. <NUM> and G. <NUM>, standardized as Recommendations ITU-T G. <NUM> Annex D and G. <NUM> Annex B. The superwideband (<NUM>-<NUM>) functionality is achieved using embedded scalable structure that adds extension layers on top of the wideband core codecs. The bit rates are extended to <NUM>/<NUM>/<NUM> and <NUM>/<NUM>/<NUM> kbit/s for G. <NUM> and G. <NUM>, respectively. The main technologies include lower and higher band (<NUM>-<NUM> and <NUM>-<NUM>) enhancements, <NUM>-<NUM> bandwidth extension and transform coding based on algebraic vector quantization.

"<NPL>, describes the adaptive multi-rate (AMR) speech coder under standardization for GSM systems as part of the AMR speech service.

In the following, a decoder or decoding method is disclosed, said disclosure does not form part of the invention but is useful for understanding the claimed encoder/encoding method.

<FIG> is a schematic block diagram of a stereo sound processing and communication system <NUM> depicting a possible context of implementation of the bit-budget allocating method and device as disclosed in the following description. It should be noted that the presented bit-budget allocating method and device are not limited to stereo, but can be used also in multi-channel coding or mono coding.

The stereo sound processing and communication system <NUM> of <FIG> supports transmission of a stereo sound signal across a communication link <NUM>. The communication link <NUM> may comprise, for example, a wire or an optical fiber link. Alternatively, the communication link <NUM> may comprise at least in part a radio frequency link. The radio frequency link often supports multiple, simultaneous communications requiring shared bandwidth resources such as may be found with cellular telephony. Although not shown, the communication link <NUM> may be replaced by a storage device in a single device implementation of the processing and communication system <NUM> that records and stores the encoded stereo sound signal for later playback.

Still referring to <FIG>, for example a pair of microphones <NUM> and <NUM> produces the left <NUM> and right <NUM> channels of an original analog stereo sound signal detected. As indicated in the foregoing description, the sound signal may comprise, in particular but not exclusively, speech and/or audio.

The left <NUM> and right <NUM> channels of the original analog sound signal are supplied to an analog-to-digital (A/D) converter <NUM> for converting them into left <NUM> and right <NUM> channels of an original digital stereo sound signal. The left <NUM> and right <NUM> channels of the original digital stereo sound signal may also be recorded and supplied from a storage device (not shown).

A stereo sound encoder <NUM> encodes the left <NUM> and right <NUM> channels of the digital stereo sound signal thereby producing a set of encoding parameters that are multiplexed under the form of a bit-stream <NUM> delivered to an optional error-correcting encoder <NUM>. The optional error-correcting encoder <NUM>, when present, adds redundancy to the binary representation of the encoding parameters in the bit-stream <NUM> before transmitting the resulting bit-stream <NUM> over the communication link <NUM>.

On the receiver side, an optional error-correcting decoder <NUM> utilizes the above mentioned redundant information in the received digital bit-stream <NUM> to detect and correct errors that may have occurred during transmission over the communication link <NUM>, producing a bit-stream <NUM> with received encoding parameters. A stereo sound decoder <NUM> converts the received encoding parameters in the bit-stream <NUM> for creating synthesized left <NUM> and right <NUM> channels of the digital stereo sound signal. The left <NUM> and right <NUM> channels of the digital stereo sound signal reconstructed in the stereo sound decoder <NUM> are converted to synthesized left <NUM> and right <NUM> channels of the analog stereo sound signal in a digital-to-analog (D/A) converter <NUM>.

The synthesized left <NUM> and right <NUM> channels of the analog stereo sound signal are respectively played back in a pair of loudspeaker units <NUM> and <NUM> (the pair of loudspeaker units <NUM> and <NUM> can obviously be replaced by a headphone). Alternatively, the left <NUM> and right <NUM> channels of the digital stereo sound signal from the stereo sound decoder <NUM> may also be supplied to and recorded in a storage device (not shown).

As a non-limitative example, the bit-budget allocating method and device according to the present disclosure can be implemented in the sound encoder <NUM> and decoder <NUM> of <FIG>. It should be noted that <FIG> can be extended to cover the case of multi-channel and/or scene-based audio and/or independent streams encoding and decoding (e.g. surround and high order ambisonics).

<FIG> is a block diagram illustrating concurrently the bit-budget allocating method <NUM> and device <NUM> according to the present disclosure.

Here, it should be noted that the bit-budget allocating method <NUM> and device <NUM> operate on a frame by frame basis and the following description is related to one of the successive frames of the sound signal being encoded, unless otherwise stated.

In <FIG>, CELP core module encoding whose bit-budget fluctuates from frame to frame as a result of a fluctuating number of bits used for encoding the supplementary codec modules is considered. Also, the distribution of bit-budget among the different CELP core module parts is symmetrically done at the encoder <NUM> and the decoder <NUM> and is based on the bit-budget allocated to encoding of the CELP core module.

The following description presents a non-restrictive example of implementation in an EVS-based codec using the Generic Coding mode. The EVS-based codec is a codec based on the EVS standard as described in Reference [<NUM>], with modifications to permit other CELP-core bit rates or codec improvements. The EVS-based codec in this disclosure is used within a coding framework using supplementary coding modules such as metadata, stereo or multi-channel coding (this is referred to hereinafter as Extended EVS codec). Principles similar to those as described in the present disclosure can be applied to other coding modes (e.g. Voiced Coding, Transition Coding, Inactive Coding,. ) within the EVS-based codec. Moreover, similar principles can be implemented in any other codec different from EVS and using a coding scheme other than CELP.

Referring to <FIG>, a total bit-budget btotal is allocated to the codec for each successive frame of the sound signal. In case of CBR, this codec total bit-budget btotal is constant. It is also possible to use the bit-budget allocating method <NUM> and device <NUM> in variable bit rate codecs wherein the codec total bit-budget btotal could vary from frame to frame (as in the case with the extended EVS codec).

In operations <NUM>, counters <NUM> determine (count) the number of bits (bit-budget) bsupplementary used for encoding the supplementary codec modules and the number of bits (bit-budget) bcodec_signaling (not shown) for transmitting codec signaling to the decoder.

Supplementary codec modules may comprise a stereo module, a Frame-Erasure concealment (FEC) module, a BandWidth Extension (BWE) module, metadata coding module, etc. In the following illustrative embodiment, the supplementary modules comprise a stereo module and a BWE module. Of course, different or additional supplementary codec modules could be used.

A codec may be designed to support encoding of more than one input audio channel. In case of two audio channels, a mono (single channel) codec may be extended by a stereo module to form a stereo codec. The stereo module then forms one of the supplementary codec modules. A stereo codec can be implemented using several different stereo encoding techniques. As non-limitative examples, the use of two stereo encoding techniques that can be efficiently used at low bit rates is discussed hereinafter. Obviously, other stereo encoding techniques can be implemented.

A first stereo encoding technique is called parametric stereo. Parametric stereo encodes two audio channels as a mono signal using a common mono codec plus a certain amount of stereo side information (corresponding to stereo parameters) which represents a stereo image. The two input audio channels are down-mixed into a mono signal, and the stereo parameters are then computed usually in transform domain, for example in the Discrete Fourier Transform (DFT) domain, and are related to so-called binaural or interchannel cues. The binaural cues (See Reference [<NUM>]) comprise Interaural Level Difference (ILD), Interaural Time Difference (ITD) and Interaural Correlation (IC). Depending on the signal characteristics, stereo scene configuration, etc., some or all binaural cues are encoded and transmitted to the decoder. Information about what cues are encoded is sent as signaling information, which is usually part of the stereo side information. A particular binaural cue can be also quantized using different encoding techniques which results in a variable number of bits being used. Then, in addition to the quantized binaural cues, the stereo side information may contain, usually at medium and higher bit rates, a quantized residual signal that results from the down-mixing. The residual signal can be encoded using an entropy encoding technique, e.g. an arithmetic encoder. Consequently, the number of bits used for encoding the residual signal can fluctuate significantly from frame to frame.

Another stereo encoding technique is a technique operating in time-domain. This stereo encoding technique mixes the two input audio channels into so-called primary channel and secondary channel. For example, following the method described in Reference [<NUM>], time-domain mixing can be based on a mixing factor, which determines respective contributions of the two input audio channels upon production of the primary channel and the secondary channel. The mixing factor is derived from several metrics, e.g. normalized correlations of the input channels with respect to a mono signal or a long-term correlation difference between the two input channels. The primary channel can be encoded by a common mono codec while the secondary channel can be encoded by a lower bit rate codec. The secondary channel encoding may exploit coherence between the primary and secondary channels and might reuse some parameters from the primary channel. Consequently, the number of bits used for encoding the primary channel and the secondary channel can fluctuate significantly from frame to frame based on channel similarities and encoding modes of the respective channels.

Stereo encoding techniques are otherwise known to those of ordinary skill in the art and, therefore, will not be further described in the present specification. Although stereo was described as a way of example of supplementary coding modules, the disclosed method can be used in a 3D audio coding framework including ambisonics (scene-based audio), multichannel (channel-based audio), or objects plus metadata (object-based audio). Supplementary modules may also comprise any of these techniques.

In most of the recent speech codecs, including wideband (WB) or super wideband (SWB) codecs, the input signal is processed in blocks (frames) while employing frequency band-split processing. A lower frequency band is usually encoded using the CELP model and covers frequencies up to a cut-off frequency. Then the higher frequency band is efficiently encoded or estimated separately by a BWE technique in order to cover the rest of the encoded spectrum. The cut-off frequency between the two bands is a design parameter of each codec. For example, in the EVS codec as described in Reference [<NUM>], the cut-off frequency depends upon the operational mode and bit rate of the codec. In particular, the lower frequency band extends up to <NUM> at bit rates of <NUM> - <NUM> kbps or up to <NUM> at bit rates of <NUM> - <NUM> kbps. A BWE then further extends the audio bandwidth for WB (up to <NUM>), SWB (Up to <NUM> or <NUM>), or Full Band (FB, up to <NUM>) encoding.

The idea behind BWE is to exploit the intrinsic correlation between the lower and higher frequency bands and make benefit of the higher perceptual tolerance to encoding distortions in higher frequencies compared to lower frequencies. Consequently, the number of bits used for the higher band BWE encoding is usually very low compared to the lower band CELP encoding, or even zero. For example, in the EVS codec as described in Reference [<NUM>], a BWE where no bit-budget is transmitted (a so-called blind BWE) is used at bit rates of <NUM> - <NUM> kbps while a BWE with some bit-budget (a so-called guided BWE) is used at bit rates of <NUM> - <NUM> kbps. The exact bit-budget of a guided BWE is dependent on the actual codec bit rate.

In the following description guided BWE is considered, which forms one of the supplementary codec modules. The number of bits used for the higher band BWE encoding can fluctuate from frame to frame and is much lower (typically <NUM> - <NUM> kbps) than the number of bits used for the lower band CELP encoding.

Again, BWE is otherwise known to those of ordinary skill in the art and, therefore, will not be further described in the present specification.

The bit-stream, usually at its beginning, contains codec signaling bits. These bits (codec signaling bit-budget) usually represent very high level codec parameters, for example codec configuration or information about the nature of the supplementary codec modules that are encoded. In case of a multi-channel codec, these bits can represent for example a number of encoded (transport) channels and/or codec format (scene based or object based, etc.). In case of stereo encoding, these bits can represent for example the stereo encoding technique being used. Another example of codec parameter that can be sent using codec signaling bits is an audio signal bandwidth.

Again, codec signaling is otherwise known to those of ordinary skill in the art and, therefore, will not be further described in the present specification. Also, a counter (not shown) can be used for counting the number of bits (bit-budget) used for codec signaling.

Referring back to <FIG>, in operation <NUM>, a subtractor <NUM> subtracts the bit-budget bsupplementary for encoding of the supplementary codec modules and the bit-budget bcodec_signaling for transmitting codec signaling, from the codec total bit-budget btotal to obtain a bit-budget bcore of the CELP core module, using the following relation: <MAT>.

As explained above, the number of bits bsupplementary for encoding the supplementary codec modules and the bit-budget bcodec_signaling for transmitting codec signaling to the decoder fluctuates from frame to frame and, therefore, the bit-budget bcore of the CELP core module also fluctuates from frame to frame.

In operation <NUM>, a counter <NUM> counts the number of bits (bit-budget) bsignaling for transmitting to the decoder CELP core module signaling. CELP core module signaling may comprise, for example, audio bandwidth, CELP encoder type, sharpening flag, etc..

In operation <NUM>, a subtractor <NUM> subtracts the bit-budget bsignaling for transmitting CELP core module signaling from the CELP core module bit-budget bcore to find a bit-budget b<NUM> for encoding the CELP core module parts, using the following relation: <MAT>.

In operation <NUM>, an intermediate bit rate selector <NUM> comprises a calculator which converts the bit-budget b<NUM> into a CELP core module bit rate by dividing the number of bits b<NUM> by the duration of a frame. The selector <NUM> finds an intermediate bit rate based on the CELP core module bit rate.

A small number of candidate intermediate bit rates is used. In an example of implementation within the EVS-based codec, the following fifteen (<NUM>) bit rates may be considered as candidate intermediate bit rates: <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, <NUM> kbps, and <NUM> kbps. Of course, it is possible to use a number of candidate intermediate bit rates different from fifteen (<NUM>) and also to use candidate intermediate bit rates of different values.

In the same example of implementation, within the EVS-based codec, the found intermediate bit rate is the nearest higher candidate intermediate bit rate to the CELP core module bit rate. For example, for a <NUM> kbps CELP core module bit rate the found intermediate bit rate would be <NUM> kbps when using the candidate intermediate bit rates listed in the previous paragraph.

In another example of implementation, the found intermediate bit rate is the nearest lower candidate intermediate bit rate to the CELP core module bit rate. Using the same example, for a <NUM> kbps CELP core module bit rate the found intermediate bit rate would be <NUM> kbps when using the candidate intermediate bit rates listed in the previous paragraph.

In operation <NUM>, ROM tables <NUM> store, for each candidate intermediate bit rate, respective, pre-determined bit-budgets for encoding first parts of the CELP core module. As a non-limitative example, the CELP core module first parts for which bit-budgets are stored in the ROM tables <NUM> may comprise the LP filter coefficients, the adaptive codebook, the adaptive codebook gain, and the innovation codebook gain. In this implementation, no bit-budget for encoding the innovation codebook is stored in the ROM tables <NUM>.

In other words, when one of the candidate intermediate bit rates is selected by the selector <NUM>, the associated bit-budgets stored in the ROM tables <NUM> are allocated to encoding of the above identified CELP core module first parts (the LP filter coefficients, the adaptive codebook, the adaptive codebook gain, and the innovation codebook gain). However, in the described implementation, no bit-budget for encoding the innovation codebook is stored in the ROM tables <NUM>.

The following Table <NUM> is an example of ROM table <NUM> storing, for each candidate intermediate bit rate, a respective bit-budget (number of bits) bLPC for encoding the LP filter coefficients. The right column identifies the candidate intermediate bit rates while the left column indicates the respective bit-budgets (number of bits) bLPC. For simplicity the bit-budget for encoding the LP filter coefficients is a single value per frame although it could be a sum of several bit-budget values when more than one LP analysis are done in a current frame (for example a mid-frame and an end-frame LP analysis).

The following Table <NUM> is an example of ROM table <NUM> storing, for each candidate intermediate bit rate, respective bit-budgets (number of bits) BACBn for encoding the adaptive codebook. The right column identifies the candidate intermediate bit rates while the left column indicates the respective bit-budgets (number of bits) BACBn. As the adaptive codebook is searched in every sub-frame n, N bit-budget bACBn (one per sub-frame) are obtained for every candidate intermediate bit rate, N representing the number of sub-frames in a frame. It should be noted that the bit-budgets bACBn may be different in different sub-frames. Specifically, Table <NUM> is an example of ROM table <NUM> storing bit-budgets bACBn in the EVS-based codec using the above defined fifteen (<NUM>) candidate intermediate bit rates.

It should be noted that, in the example using the EVS-based codec, four (<NUM>) bit-budgets bACBn per intermediate bit rate are stored at lower bit rates where the frame of <NUM> is composed of four (<NUM>) sub-frames (N=<NUM>) and five (<NUM>) bit-budgets bACBn per intermediate bit rate are stored at higher bit rates where the frame of <NUM> is composed of five (<NUM>) sub-frames (N=<NUM>). Referring to Table <NUM>, for a CELP core module bit rate of <NUM> kbps corresponding to an intermediate bit rate of <NUM> kbps, the bit-budgets bACBn in the individual sub-frames are <NUM>, <NUM>, <NUM>, and <NUM> bits, respectively.

The following Table <NUM> is an example of ROM table <NUM> storing, for each candidate intermediate bit rate, respective bit-budgets (number of bits) bGn for encoding the adaptive codebook gain and the innovation codebook gain. In the example below, the adaptive codebook gain and the innovation codebook gain are quantized using a vector quantizer and thus represented as only one quantization index. The right column identifies the candidate intermediate bit rates while the left column indicates the respective bit-budgets (number of bits) bGn. As can be seen from Table <NUM>, there is one bit-budget bGn for every sub-frame n of a frame. Accordingly, N bit-budgets bGn are stored for every candidate intermediate bit rate, N representing the number of sub-frames in a frame. It should be noted that, depending on the gain quantizer and size of the quantization table being used, the bit-budgets bGn may be different in different sub-frames.

In the same manner, a bit-budget for quantizing other CELP core module first parts (if they are present) can be stored in the ROM tables <NUM> for each candidate intermediate bit rate. An example could be a flag of an adaptive codebook low-pass filtering (one bit per sub-frame). Therefore, a bit-budget associated to all CELP core module parts (first parts) except of the innovation codebook can be stored in the ROM tables <NUM> for each candidate intermediate bit rate while a certain bit-budget b<NUM> still remains available.

In operation <NUM>, a bit-budget allocator <NUM> allocates for encoding the above mentioned CELP core module first parts (the LP filter coefficients, the adaptive codebook, the adaptive and innovation codebook gains, etc.) the bit-budgets stored in the ROM tables <NUM> and associated to the intermediate bit rate selected by the selector <NUM>.

In operation <NUM>, a subtractor <NUM> subtracts from the bit-budget b<NUM> (a) bit-budget bLPC for encoding the LP filter coefficients associated to the candidate intermediate bit rate selected by the selector <NUM>, (b) the sum of the bit-budgets bACBn of the N sub-frames associated to the selected candidate intermediate bit rate, (c) the sum of the bit-budgets bGn for quantizing the adaptive and innovation codebook gains of the N sub-frames associated to the selected candidate intermediate bit rate, and (d) the bit-budget, associated to the selected intermediate bit rate, for encoding other CELP core module first parts (if they are present), to find a remaining bit-budget (number of bits) b<NUM> still available for encoding the innovation codebook (second CELP core module part). For that purpose, the following relation can be used by the subtractor <NUM>: <MAT>.

In operation <NUM>, a FCB bit allocator <NUM> distributes the remaining bit-budget b<NUM> for encoding the innovation codebook (Fixed CodeBook (FCB); second CELP core module part) between the N sub-frames of the current frame. Specifically, the bit-budget b<NUM> is divided into bit-budgets bFCBn allocated to the various sub-frames n. For example, this can be done by an iterative procedure which divides the bit-budget b<NUM> between the N sub-frames as equally as possible.

In other non-limitative implementations, the FCB bit allocator <NUM> can be designed by assuming at least one of the following requirements:.

A glottal-impulse-shape codebook may consist of quantized normalized shapes of truncated glottal impulses placed at specific positions as described in Section <NUM>. <NUM> (Glottal pulse codebook search) of Reference [<NUM>]. The codebook search then comprises selection of the best shape and the best position. For example, glottal impulse shapes can be represented by codevectors containing only one non-zero element corresponding to candidate impulse positions. Once selected, the position codevector is convolved with the impulse response of a shaping filter.

Using the above requirements the FCB bit allocator <NUM> may be designed as follows (expressed in C-code):
<IMG>
<IMG>
<IMG>
<IMG>
where function SWAP() swaps/interchanges the two input values. The function fcb_table() then selects the corresponding line of the FCB (fixed or innovation codebook) configuration table (as defined above) and returns the number of bits needed for encoding the selected FCB (fixed or innovation codebook).

A counter <NUM> determines the sum of the bit-budgets (number of bits) bFCBn allocated to the N various sub-frames for encoding the innovation codebook (Fixed CodeBook (FCB); second CELP core module part).

In operation <NUM>, a subtractor <NUM> determines the number of bits b<NUM> remaining after encoding of the innovation codebook, using the following relation: <MAT>.

Ideally, after encoding of the innovation codebook, the number of remaining bits b<NUM> is equal to zero. However, it may not be possible to achieve this result because the granularity of the innovation codebook index is greater than <NUM> (usually <NUM>-<NUM> bits). Consequently, a small number of bits often remain unemployed after encoding of the innovation codebook.

In operation <NUM>, a bit allocator <NUM> assigns the unemployed bit-budget (number of bits) b<NUM> to increase the bit-budget of one of the CELP core module parts (CELP core module first parts) except of the innovation codebook. For example, the unemployed bit-budget b<NUM> can be used to increase the bit-budget BLPC obtained from the ROM tables <NUM>, using the following relation: <MAT>.

The unemployed bit-budget b<NUM> may also be used to increase the bit-budget of other CELP core module first parts, for example the bit-budgets bACBn or bGn. Also, the unemployed bit-budget b<NUM>, when greater than <NUM> bit, can be redistributed between two or even more CELP core module first parts. Alternatively, the unemployed bit-budget b<NUM> can be used to transmit FEC information (if not already counted in the supplementary codec modules), for example a signal class (See Reference [<NUM>]).

Traditional CELP has limitations of scalability and complexity when it is used at high bit rates. To overcome these limitations, the CELP model can be extended by a special transform-domain codebook as described in References [<NUM>] and [<NUM>]. In contrast to traditional CELP where the excitation is composed from the adaptive and the innovation excitation contributions only, the extended model introduces a third part of the excitation, namely a transform-domain excitation contribution. The additional transform-domain codebook usually comprises a pre-emphasis filter, a time-domain to frequency-domain transformation, a vector quantizer, and a transform-domain gain. In the extended model, a substantial number (at least tens) of bits is assigned to the vector quantizer in every sub-frame.

In high bit rate CELP, bit-budget is allocated to the CELP core module parts using the procedure as described above. Following this procedure, the sum of the bit-budgets bFGBn for encoding the innovation codebook in the N sub-frames should be equal or approach bit-budget b<NUM>. In the high bit rate CELP, the bit-budgets bFCBn are usually modest, and the number of unemployed bits b<NUM> is relatively high and is used to encode the transform-domain codebook parameters.

First, the sum of the bit-budget bTDGn for encoding the transform-domain gain in the N sub-frames and eventually the bit-budget of other transform-domain codebook parameters except the bit-budget for the vector quantizer are subtracted from the unemployed bit-budget b<NUM>, using the following relation: <MAT>.

Then, the remaining bit-budget (number of bits) b<NUM> is allocated to the vector quantizer within the transform-domain codebook and distributed among all sub-frames. The bit-budget (number of bits) by sub-frame of the vector quantizer is denoted as bVQn. Depending on the vector quantizer being used (for example an AVQ quantizer as used in EVS), the quantizer does not consume all of the allocated bit-budget bVQn leaving a small variable number of bits available in each sub-frame. These bits are floating bits employed in the following sub-frame within the same frame. For a better effectiveness of the transform-domain codebook, a slightly higher (larger) bit-budget (number of bits) is allocated to the vector quantizer in the first sub-frame. An example of implementation is given in the following pseudocode:
<IMG>
where <MAT> denotes the largest integer less than or equal to x and N is the number of sub-frames in one frame. Bit-budget (number of bits) b<NUM> is distributed equally between all the sub-frames while the bit-budget for the first sub-frame is eventually slightly increased by up to N-<NUM> bits. Consequently, in high bit rate CELP, there are no remaining bits after this operation.

In many instances, there are more than one alternative for encoding a given CELP core module part. In complex codecs like EVS several different techniques are available for encoding a given CELP core module part and the selection of one technique is usually made on the basis of the CELP core module bit rate (the core module bit rate corresponds to the bit-budget bcore of the CELP core module multiplied by number of frames per second). An example is gain quantization where there are three (<NUM>) different techniques available in the EVS codec as described in Reference [<NUM>], Generic Coding (GC) mode:.

Also, at a constant codec total bit rate btotal, different techniques for encoding and quantizing a given CELP core module part can be switched on a frame by frame basis depending on the CELP core module bit rate. An example is parametric stereo coding mode at <NUM> kbps, in which different gain quantizers (See Reference [<NUM>]) are used in different frames as shown in Table <NUM> below:.

It is also interesting to note that there can be different bit-budget allocations for a given CELP core module bit rate depending on the codec configuration. As an example, encoding of the primary channel in EVS-based TD stereo coding mode works, in a first scenario, at a total codec bit rate of <NUM> kbps and, in a second scenario, at a total codec bit rate of <NUM> kbps. There can happen in both scenarios that the CELP core module bit rate is the same even though the total codec bit rate is different. But a different codec configuration can lead to a different bit-budget distribution.

In the EVS-based stereo framework, the different codec configurations between <NUM> kbps and <NUM> kbps is related to a different CELP core internal sampling rate which is <NUM> at <NUM> kbps and <NUM> at <NUM> kbps, respectively. Thus CELP core module coding with four (<NUM>), respectively five (<NUM>) sub-frames is employed and a corresponding bit-budget distribution is used. Below are shown these differences between the two mentioned total codec bit rates (one value per table cell corresponds to one parameter per frame while more values correspond to parameters per sub-frames).

Accordingly, the above table shows that there can be different bit-budget distributions for the same core bit rate at different codec total bit rates.

When the supplementary codec modules comprises a stereo module and a BWE module, the flow of the encoder process may be as follows:.

The CELP core module bit rate is not directly signaled in the bit-stream but is computed at the decoder based on the bit-budgets of the supplementary codec modules. In the example of implementation comprising stereo and BWE supplementary modules, the following procedure could be followed:.

What remains is the CELP core bit-budget bcore, which is an input parameter to the bit-budget allocation procedure described in the foregoing description. The same allocation is called for at the CELP encoder (just after preprocessing) and at the CELP decoder (at the beginning of CELP frame decoding).

The following is a C-code excerpt from an extended EVS-based codec for Generic Coding bit-budget allocation, given by way of example only. <IMG>
<IMG>
<IMG>
<IMG>
<IMG>.

<FIG> is a simplified block diagram of an example configuration of hardware components forming the bit-budget allocating device and implementing the bit-budget allocating method.

The bit-budget allocating device may be implemented as a part of a mobile terminal, as a part of a portable media player, or in any similar device. The bit-budget allocating device (identified as <NUM> in <FIG>) comprises an input <NUM>, an output <NUM>, a processor <NUM> and a memory <NUM>.

The input <NUM> is configured to receive for example the codec total bit-budget btotal (<FIG>). The output <NUM> is configured to supply the various allocated bit-budgets. The input <NUM> and the output <NUM> may be implemented in a common module, for example a serial input/output device.

The processor <NUM> is operatively connected to the input <NUM>, to the output <NUM>, and to the memory <NUM>. The processor <NUM> is realized as one or more processors for executing code instructions in support of the functions of the various modules of the bit-budget allocating device of <FIG>.

The memory <NUM> may comprise a non-transient memory for storing code instructions executable by the processor <NUM>, specifically a processor-readable memory comprising non-transitory instructions that, when executed, cause a processor to implement the operations and modules of the bit-budget allocating method and device of <FIG>. The memory <NUM> may also comprise a random access memory or buffer(s) to store intermediate processing data from the various functions performed by the processor <NUM>.

Those of ordinary skill in the art will realize that the description of the bit-budget allocating method and device are illustrative only and are not intended to be in any way limiting. Other embodiments will readily suggest themselves to such persons with ordinary skill in the art having the benefit of the present disclosure. Furthermore, the disclosed bit-budget allocating method and device may be customized to offer valuable solutions to existing needs and problems related to allocation or distribution of bit-budget.

In the interest of clarity, not all of the routine features of the implementations of the bit-budget allocating method and device are shown and described. It will, of course, be appreciated that in the development of any such actual implementation of the bit-budget allocating method and device, numerous implementation-specific decisions may need to be made in order to achieve the developer's specific goals, such as compliance with application-, system-, network-and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the field of sound processing having the benefit of the present disclosure.

In accordance with the present disclosure, the modules, processing operations, and/or data structures described herein may be implemented using various types of operating systems, computing platforms, network devices, computer programs, and/or general purpose machines. In addition, those of ordinary skill in the art will recognize that devices of a less general purpose nature, such as hardwired devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or the like, may also be used. Where a method comprising a series of operations and sub-operations is implemented by a processor, computer or a machine and those operations and sub-operations may be stored as a series of non-transitory code instructions readable by the processor, computer or machine, they may be stored on a tangible and/or non-transient medium.

Claim 1:
A method for encoding a sound signal using a CELP core module and supplementary codec modules of a sound signal encoder comprising (<NUM>):
allocating (<NUM>) to the supplementary codec modules a bit-budget (bsupplementary) fluctuating based on the sound signal;
subtracting (<NUM>), from a total codec bit-budget (btotal), the supplementary codec modules bit-budget (bsupplementary) to determine a fluctuating CELP core module bit-budget (bcore) ;
allocating the CELP core module bit-budget (bcore) to (a) a plurality of first parts, including at least one of LP filter coefficients, a CELP adaptive codebook, a CELP adaptive codebook gain and a CELP innovation codebook gain, and (b) a second part, including a CELP innovation codebook, of the CELP core module, comprising:
storing (<NUM>) bit-budget allocation tables (<NUM>) assigning, for each of a plurality of fixed candidate intermediate bit rates, respective bit-budgets for encoding the first CELP core module parts;
determining (<NUM>) on the basis of the CELP core module bit-budget (bcore) a fluctuating CELP core module bit rate;
selecting (<NUM>) one of the intermediate bit rates based on the determined CELP core module bit rate;
allocating (<NUM>) to the first CELP core module parts and from the CELP core module bit-budget (bcore) the respective bit-budgets assigned by the bit-budget allocation tables (<NUM>) for the selected intermediate bit rate; and
allocating (<NUM>) to the second CELP core module part a bit-budget remaining from the CELP core module bit-budget (bcore) after allocating (<NUM>) to the first CELP core module parts the respective bit-budgets assigned by the bit-budget allocation tables (<NUM>) for the selected intermediate bit rate; and
encoding the audio signal using the supplementary codec modules and the first and second CELP core module parts using the respective allocated bit-budgets.