CROSS-REFERENCES TO RELATED APPLICATIONSThis application claims the benefit or priority of and describes the relationships between the following applications: wherein this application is an application for reissue of U.S. Pat. No. 6,070,062, which issued Jun. 13, 2000, and is also a continuation of U.S. patent application Ser. No. 10/170,822, filed Jun. 13, 2002, which is also an application for reissue of U.S. Pat. No. 6,076,062, from U.S. patent application Ser. No. 08/798,198, filed Dec. 9, 1996, which is the National Stage of International Application No. PCT/IB1996/001267, filed Nov. 21, 1996, which claims the priority of foreign application EPO 95203376 filed Dec. 7, 1995.
BACKGROUND OF THE INVENTIONThe invention relates to a method of transferring a non-PCM encoded audio bitstream read from a digital medium, subsequent to parsing thereof, via an IEC 958 protocolled interface to a multi-channel audio reproduction apparatus.
Digital video disc standardizing is proceeding at an accelerated pace. Commercially available MPEG1 decoder circuit SAA2502 is able to decode compressed digital audio received as a continuous bit stream. Present-day MPEG2 technology has standardized 5 channels, to wit: Left, Right, Center, Left Surround, Right Surround, and furthermore a low frequency enhancement (LFE) channel. The MPEG2 bit stream is distributed into frames of 1152 samples for each of the actual channels, and player operation is controllable in a non-uniform manner on a frame-to-frame basis. For example, the number of actual channels may vary, and certain ones or all of them may be outputting silence.
General background to the invention is given by the following earlier documents, all being at least co-assigned to the present assignee and being herein incorporated by reference:
EP Patent 402 973, EP Patent Application 660 540, corresponding U.S. Pat. No. 5,323,396, issued Jun. 21, 1994, which is a continuation of U.S. application Ser. No. 07/532,462, abandoned; U.S. Pat. No. 5,606,618, issued Feb. 25, 1997; U.S. Pat. No. 5,530,655, issued Jun. 25, 1996; U.S. Pat. No. 5,539,829, issued Jul. 23, 1996; U.S. Pat. No. 5,777,992, issued Jul. 7, 1998; and pending U.S. application Ser. No. 08/488,536, describing a MusicamLayer1 encoder and decoder for L and R signals;
EP 678 226, corresponding to U.S. Pat. No. 5,544,247, issued Aug. 6, 1996, describing encoding and decoding of L, R and C channels;
U.S. patent application Ser. Nos. 08/032,915, 08/180,004, 08/427,046, describing the matrixing of bitrate-reduced L, R, C, SL and SR signals.
Now, in a consumer application (SPDIF) of the above specified digital video disc, two subframes are specified that each can simultaneously carry 32 bit data words. This allows to transfer via the IEC 958 bitstream either 2-channel linear PCM audio, or a set of alternating bitstreams, but not those configurations simultaneously. The IEC 958 standard specifies a widely used method for interconnecting digital audio equipment with 2-channel linear PCM audio. A need has been encountered to allow transferring non-PcM encoded audio bitstreams for consumer applications in the same protocolled environment, and in particular pause bursts, in case one or more of the audio channels would represent silence. In particular, the granularity of such pause representation at the receiver side should be sufficiently brief from a perceptive standpoint.
SUMMARY OF THE INVENTIONAccordingly, amongst other things, it is an object of the present invention to extend present protocols to allow transfer of non-PCM encoded audio bitstreams for consumer applications in the same protocolled environment.
This and other objects, features and advantages according to the present invention are provided by a method for decoding a non-PCM encoded audio bit stream, which can be read from a digital medium. Preferably, the method includes the steps, executed for each respective audio channel, of recurrently packaging MPEG audio samples in burst payloads, and packaging the burst payloads as user data in IEC958 format frames, including pause bursts which signal the absence of audio for all associated channels. According to one aspect of the present invention, each pause burst represents such audio absence during a perceptively acceptable time interval only.
According to the state of the art, the above granularity could reach several tens of milliseconds, which the present inventor has found unacceptably long. According to the invention, the granularity is in the millisecond range which is acceptable in all circumstances encountered at present.
These and other objects, features and advantages according to the present invention are proved by a method for receiving a non-PCM encoded audio bitstream emanating from a parsed bitstream read from a digital versatile disc DVD via an IEC 958 protocolled interface for use in a multi-channel reproduction apparatus. Advantageously, the method includes steps for receiving the parsed bitstream as a sequence of frames each accommodating, for each applicable bitstream, a uniform number of data bits, storing each frame in an intermediate frame buffer; detecting presence or absence of data pertaining to a particular output channel. Moreover, in response to the detecting step, executing decoding and outputting decoded information for the particular channel. However, under control of one or more pause bursts received, as representing a sequential multiplicity of absence of the detecting, controlling a soft mute block. It will be appreciated that this feature provides for straightforward decoding of the pause bursts for subsequent representation by a soft mute block.
These and other objects, features and advantages according to the present invention are provided by a device for implementing the method described immediately above, either on the encoding or the decoding side. Further advantageous aspects of the invention are set forth hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGSThese and further aspects and advantages of the invention will be discussed more in detail hereinafter with reference to the disclosure of preferred embodiments, and more in particular with reference to the following drawings, in which:
FIGS. 1-3,4A,4B,4C,4D and5, show various information formats;
FIG. 6, a block diagram of connected DVD player and MC_Box;
FIG. 7, a block diagram of a multi-channel audio decoder;
FIG. 8, a decoding flow chart of a digital signal processor;
FIG. 9, a decoding flow chart of a subband filter DSP;
FIG. 10, a block diagram of an IEC 958 transmitter station;
FIG. 11, a block diagram of an IEC 958 receiver station;
FIG. 12, a flow chart of bit stream transmission.
DESCRIPTION OF THE PREFERRED EMBODIMENTS1. Data Formats
For better detailing the invention, first various applicable information formats are described.FIG. 1 shows the IEC958 format, which according to the upper diagram consists of a concatenation of frames grouped into blocks of 192 frames each. The second diagram shows each frame to consist of two sub-frames. The first frame of a block has subframes labelled B (left) and W (right), further subframes are all labelled M. The third diagram shows the setup of a subframe. As shown, it has four preamble bits, four auxiliary bits, four unused bits, sixteen data bits or bitstream, and four flag bits V, U, C, P. The flag bits indicate the following:
- V indicates no deviation from the standard;
- U indicates user data with ‘0’ default;
- C contains one bit of a channel status word; and
- P is a parity bit relating tobits4 through31.
 A pair of subframes may contain one PCM word from each of left and right channels.
 
According to the present invention, for consumer applications, the channel status word as built from a sequence of C bits has the following meaning: bit bO withvalue 0 indicates consumer PCM audio, bit bi withvalue 1 indicates Non-linear PCM samples,bits8 through15 contain a category code. Furthermore, the MPEG header indicates audio sample rate and sample size in bits.
Now, audio bit streams as read from the DVD disc may contain gaps, that may be due to pauses in the audio, or to a trick mode of the related video source, such as the transition to a freeze picture produced in track mode. Now, during transfer in bursts on theIEC 958, these gaps in the bit stream may remain unused or rather, filled with bursts of the data_type ‘pause’ to be described hereinafter. If the gap occurs inMPEG1 layer1, or inMPEG1layer2 or3 data, or in MPEG2 without extension, or in MPEG2 data with extension audio bitstream, the gap will be filled with a sequence of bursts of data_type ‘pause’. These bursts may have the minimum allowable length therefor, corresponding to 32 sample periods. Preferably, this number is three times as long, so corresponding to 96 sample periods, which is the recurrency of LFE samples.
It is possible on this interface to simultaneously convey multiple multi-channel non_PCM encoded data streams, for example relating to both a main audio service and to an associated audio service. In that case, the burst of the associated service occurs before the burst of the main service to which it is associated.
FIG. 2 describes the burst format attained by unpacking the user information of anIEC 958 block in a standard manner, or rather before the packing of anIEC 958 block. The burst has a fixed repetition time related to the number of audio samples for each channel encoded within that frame. Any unused bit between two bursts is set to zero. Each burst has four sixteen-bit preamble words, with the following meanings: Pa, Pb sync words, Pc burst info to be specified hereinafter, Pd length of payload in bits. Subsequently, the burst contains a payload field and is optionally terminated by stuffing zeroes to attain its pre-specified format. An advantageous, but not mandatory lower bound for the number of stuffing zeroes is 32. The payload also contains the MPEG header. The format of non-PCM encoded Audio bitstreams allows multiplexed conveying of more than one bitstream, wherein a burst can fill the space of stuffed zeroes from other bursts. The sampling frequency must be uniform across the bursts. The field Pc has the following codes:
|  | 
| Pc |  |  | repetition of burst in | 
| Bits | value | content | number of sample periods | 
|  | 
| 0-4 | 0 | Null data | @4096 | 
|  | 1 | AC-3 stream | 1536 | 
|  | 2 | SMPTE time stamp |  | 
|  | 3 | MPEG1 layer 1 data | 384 | 
|  | 4 | MPEG1 layer ⅔ orMPEG 2 | 1152 | 
|  |  | without extension |  | 
|  | 5 | MPEG2 with extension | 1152 | 
|  | 6 | PAUSE | 32 or 96 | 
|  | 7 | ACX data | 1024 | 
|  | 8 | MPEG 2layer 1 low sample rate | 384 | 
|  | 9 | MPEG2 layer ⅔ low rate | 1152 | 
|  | 10-31 | Reserved | 
|  | 
The content of further bits of Pc is irrelevant to the present invention. The provision of the relatively brief ‘pause’ burst allows a low granularity size of ‘soft mute’ intervals controlled thereby. The indication of the various burst type specifications by Pc bit values 3, 4, 5, 8, 9, allows an extremely flexible control policy.
FIG. 3 shows anMPEG1 layer1 base frame that has a length of 384 sample periods (each of L and R). The various aspects of the format have been considered supra. The base frame for the payload of the MPEG1 layer ⅔ or MPEG2 without extension has the same shape, be it with a length of 1152 instead of 384 sample periods. MPEG2 allows transfer of five audio channels in parallel. In certain circumstances, the MPEG2 burst needs an extension that has been shown inFIGS. 4B and 4C.
Now, an MPEG2 frame comprises 1152 samples for each encoded channel. The burst as shown in the uppermost row, is headed by a burst_preamble, followed by the payload, and stuffed with stuffing zero bits. The payload numbers up to 36768=1152×32 bits. Furthermore, there are at least 32 stuffing zeroes and 64 bits for the Pa..Pd header. Bitstreams matching theMPEG layer2 data type are:
- either encoded according toMPEG2 layer2 or3,
- or even encoded according to MPEG2 layer1 ‘superframe’.
 
A burst with an Audio frame consists of a synchronized and concatenated Base frame (MPEG1 compatible) and an extension frame.FIG. 4A shows theMPEG2 layer2 base frame, with MPEG1 header, MPEGi Audio field, MC (multichannel) extension part i field, and a field for ancillary data. If extension is necessary, additional format according toFIG. 4B is appended that contains inMPEG2 layer2 Extension frame an Extension header followed by theMC extension part2.FIG. 4C of this shows the formats ofFIGS. 4A and 4B both synchronized and concatenated. Likewise, theFIG. 4D shows the MPEG2 base frame, with extension frame as fractional payload inside the burst repetition time represented by the lower arrow, that in its turn needs a preamble and allows for trailed stuffing zeroes to the frame.
Now, by using units of 32 sample periods per subband filter, synchronization is maintained. In this respect,FIG. 5 shows a burst of data type ‘PAUSE’ inside its burst repetition time indicated by the bottom arrow. The length is 1024 bits=32 IEC frames, increased with the stuffing zeroes. As earlier, the four indications Pa, Pb, Pc, Pd are preappended. The user content is all zero. Another and preferred size of the burst allows for 3×32=96 frames. The burst frame has of course a dummy content; the longer version allows better synchronization to the LFE feature that occurs every 96 frames. Due to the relatively small size of pause bursts, the transition between pause and non-pause has a small granularity size.
2. Hardware Embodiments
FIG. 6 is a block diagram of aninterconnected DVD player30 and anMCBox46. Inplayer30, block20 symbolizes a turn-table and associated read-out and feedback mechanisms, associated control signals being transferred by means ofcontrol path21. Control processing is inmicroprocessor26.Block22 is an MPEG2 program stream decoder and audio parser that separates the massive bitstream received into standard stereo audio and video streams on the one hand to go to audio-video decoder24, and furthermore, multi-channel bitrate reduced audio data onchannel23. Audio-Video decoder24 operates in a standard manner for separating the bit stream into left and right audio channels and video as indicated. In fact, this type of reproduction is conform to the MPEG1 standardization. Relatively low-level consumer applications would do with the system as described thus far.DVD player30 is implemented with a user control interface, such as hard buttons, soft keys, display.
For attaining full functionality of MPEG2, anexternal multichannel MC_box46 has been provided. To this effect, first inplayer30, the MPEG data is configured according to the burst format described with respect to the earlier Figures. Next, this requires anoutput channel33 for data according to thestandardized IEC 958 protocol, and which is used to convey a non-PCM bitstream inclusive of various commands for the MC_box. The channel may be based on galvanic interconnection or optical fibre. Optionally, interconnection is by a uni- orbidirectional channel48, in particular for transmitting commands to the DVD player. The channel may be protocolled according to D2B described in U.S. Pat. No. 4,429,384 to the present assignee. Moreover as shown, aFIFO28 is provided that by way of example accommodates 8 k Bytes as generally required for intermediate storage of MPEG data, abus interface circuit32 of commercially available type TDA1315, and acontrol interface circuit34 of type MSM6307, organized according to the D2B protocol. Alternatively, block32 receives commands from themicroprocessor26 on the data path, rather than on its control path.
Like the DVD player,MC_box46 has aninternal control path41,interface circuit38 of type MSM6307, and control processing inmicroprocessor40. In correspondence toFIFO28, theMC_box46 has a relativelysmall FIFO44. This stores the data of one bitstream while the previous one is decoded locally. The decoding pertains first to the burst level, and next to the sample level. The output fromFIFO44 feedsMC_decoder42 that may output up to seven audio channels as indicated: Left, Right, LFE/C, Left center surround, Right center surround, Left surround and Right surround. As shown, these are grouped on four I2S interfaces, according to a protocol described in U.S. Pat. No. 4,755,817 to the present assignee. AlternativelyFIFO44 plusdecoder42 are combined into a single hardware block and controlled directly by the commands contained in theIEC 958 data. Moreover, the MC Box attaches to thesecondary control channel48 by means ofcircuit38.
FIG. 7 is a block diagram of a multi-channel audio decoder, as contained inblock42 inFIG. 11. First, the decoding proper is executed inblock56 according to the process described with reference toFIG. 8, and implemented with a Motorola DSP processor of the 56000 series architecture. Also, the dematrixing is executed in this processor.Block54 symbolizes a control shell to the processor in question. The output of the first DSP processor is organized in blocks that each contain for eachappropriate channel 3*32=96 subsamples. For such channel at the highest applicable sample frequency of 44.1 kHz, the block length corresponds to an interval of 2 msec, which is considered a sufficiently fine granularity to be practically imperceptible.
Block58 is an intermediate buffer that can hold n blocks as specified supra, optimized as regards to cost versus allowable occurrence of over/underflow; expected value of n is about four.Line70 transmits a stop/go signal toDSP shell54 that functions as source;line68 transmits a request signal from thedata destination block60.
Block60 executes the demultiplexing function with respect to the maximum of seven channels received; it is based on a similar Motorola 56000 DSP processor. In particular, block62 symbolizes the subband filtering, whereasblock64 symbolizes an LFE ups ample filter. Again, the processor shell has been indicated byblock66. During each execution cycle, 32 subchannels per channel are filtered, and unloaded by means of a dual port RAM: the length of a cycle is thus for a sample frequency of 44.1 kHz:32/44, lk=0.725 millisec. The delay length of the RAM for each channel is advantageously equal to 3*32 subsamples. Filtering takes place when 3*32 subsamples have been received, otherwise the subband filter will output all zeroes signalling an audio pause, which thus has a reduced granularity with respect to prior art. The processor will contain a ‘free running’ function, and will continually output audio samples at uniform intervals. Thefirst DSP56 will continually produce audio samples in bursts of 1152 samples per channel, 12 groups of 3*32 samples each for each and every channel. The real-time demand is onsubband filter62. If applicable,decoder56/54 is put on “hold” to avoid an overflow ofbuffer58.
The MC Box does not have a user control interface, but the data received on the IECunidirectional interconnect33 are used for effecting control, inclusive of the soft-mute and concealing feature according to the invention. If required, the D2B interconnect allows for sending control signals in the reverse direction. Themultichannel decoder60 can be controlled bydecoder54, such as by means of an I2C interface as disclosed in U.S. Pat. No. 4,689,740. This will be robust enough to recover from error conditions. However, no status output to a user is deemed necessary. If underflow occurs inbuffer58, the soft mute feature is controlled subsequently.
FIG. 8 shows a decoding flow chart of a processor, in particulardigital signal processor54 inFIG. 7. The received input bitstream is symbolized by74, on which the decoder continually undertakes a synchronizingoperation76. Actual decoding starts inblock78 as soon asDSP54 synchronizes and a next concatenated frame through the synchronizing words Pa, Pb is received. Frame item Pd gives the length of the payload. When synchronized,decoder54 for each frame produces twelve groups of 3*32 sub-samples for each channel.Decoder56 is put on hold when the free area in the sub-sample buffer is not sufficient to store all sub-samples of that group (of 3*32) sub-samples for each channel to avoid buffer overflow.
The hand-shake between the sub-sample buffer anddecoder DSP56 is implemented by a token that indicates the current owner of the block in question; this token is transferred when synchronization has been effected (77,88). In the flowchart, block78 detects either audio data, or a pause. Unless third pause, data type detecting is continued (78). Upon meeting a non-pause, decoding is continued inblock80, and the decoding result is outputted online81, subject to the reception of a blocking token to put the processor on hold viablock82. The handshake is betweenblocks80 and82.Bidirectional connection83 allows reacting to the filling degree ofbuffer58. When the third pause is received (84), block86 prepares zero output blocks for outputting online81 as an alternative to the decoding results fromblock80, to function as ‘soft mute’ information.
FIG. 8 is a decoding flow chart ofsubband DSP filter62 inFIG. 7. Each cycle, the subband DSP receives 32 subsamples per channel at its input; if no subsamples are available, the input will become all zeroes as a soft-mute. The subband filter DSP processes blocks of 32 sub-samples and produces 7 out of 8 signals for the four I2S interfaces shown in the Figure. The eighth signal LFE will be upsampled byblock64. The filter operates according to a continuous process, producing audio at equidistant time intervals. After power-on, all outputs are muted by default; the output registers will contain zeroes until the subband filter is initialised after 512 sample periods.
In the implementation, block50 detects whether thebuffer58 is not empty. If empty, zeroes are output in such a way as to maintain synchronization. If not empty and a token has been passed, the block output is at right, and 32 samples are outputted for each actual channel, plus a single LFE sample. If not empty and no token has been passed, the block output is at left, and 32 zero subband samples are outputted to emulate a pause. Both outputs fromblock50 lead to the input of subb and filter62 and LFE upsample filter64 inFIG. 7.
The token indicates which processor is currently the owner of the block. An owner has read/write access to a block, non-owners can only read, such as read the token. Block ownership is only passed along by the owner of the block, render the actual owner to non-owner. After power-on, all tokens will be handed to the decoder DSP. Absent a token, the subband filter will clear all registers and will filter exclusively zeroes. When synchronizing on the Burst_Preamble, the first token shall be passed to the subband filter DSP after an expected ‘worst case’ decoding time.
FIG. 10 is a block diagram of anIEC 958 transmitter station, of which a central part is the commercially available TDA 1315circuit98 interconnected as shown.Block90 symbolizes the parser of synchronized and concatenated Base and Extension bitstreams (block22 inFIG. 11).Microprocessor92 corresponds tomicroprocessor26 inFIG. 11.Microprocessor92 interacts withinterface circuit98 along a three-wire L3 control bus protocolled according to U.S. Pat. No. 5,434,862 assigned to the present assignee, and connected topins23,24,25 as shown. The data output fromblock90 is protocolled according to the I2S format and connected onpins35,36,37 as shown.Input32 receives a mute control signal fromparser90, pin33 an I2S selection signal and pin38 an I2S output enable signal, these two continuously atlogic 1. Timingcontrol block96 is controlled bymicroprocessor92, and handshakes alonginterconnection93 withparser block90. Also, it handshakes on a sync cycle basis with TDA 1315 onpins39,40. Finally, the circuit outputs serial data according toIEC 958 onpin8, and receives an enable signal onpin9 at a continuously low value.Block100 is an electric to optical converter, allowing a remote position of the MC_Box.
FIG. 11 is a block diagram of anIEC 958 receiver station. Data is received as 16 bit words over optical-to-electric converter102 and transferred toIEC 958input pin6. Standard control pins are ConTRLMODE atpin21,IECSELection pin7, andI2SOoutputENable pin38, all three held at logic ground. Furthermore, there areIECOEoutputenable pin9 andCLIocK SELection pin43, both held at logic high (1). The clock selection allows to select between 384 kHz and 256 kHz. The data output from TDA 1315 is by means of an I2S protocol onpins35,36,37 tomulti-channel decoder108. This produces the four output bit streams as deemed inFIG. 11. Control interconnection between TDA 1315, the microprocessor (item40 inFIG. 11) andmulti-channel decoder108 is protocolled according to the 12S protocol referred supra.
FIG. 12 is a flow chart of bitstream transmission. Inblock120, transmission is started.Channel status bit1 becomes “1” Inblock122IEC 958 “Idle” is detected. If “Idle”, inblock124 it is detected whether NULL data is needed. If “No”, the system reverts to block122. If “Yes”, in block132 a NULL data burst is sent; the latter feature is optional. If inblock122 an Audio bitstream is detected, inblock126 it is detected whether a Gap occurs. If “Gap”, in block120 a PAUSE data burst is sent. Also, the repetition time is set. If inblock126, an Audio data-burst is detected, an audio data burst is sent. Also, the repetition time is set. Both afterblock128 and afterblock130, inblock134 it is detected whether the repetition time has finished. If No, inblock136 “stuffing” is executed, and the system reverts to block134. If inblock134, the repetition time has finished, the system reverts to block126.
PAUSE data-bursts are intended to fill small discontinuities in the bitstream, the gaps which may occur between two data-bursts of a non-PCM encoded audio data type. PAUSE data-bursts convey information of the audio decoder that a gap exists. The PAUSE data-bursts may also indicate the actual length of the audio gap, or that the non-PCM audio data stream has stopped. This information may be used by the audio decoder to minimise (or conceal) the existence of the audio gap, or in the case that the bitstream stops, to trigger a fade-out of the audio. A sequence of PAUSE data-bursts can also assist decoder synchronization prior to the beginning of a non-PCM audio bitstream. It is recommended to send a short sequence of PAUSE data-bursts immediately preceding the transmission of the first audio data-burst.
|  | 
| Data | stuff- | P | stuff- | P | Stuff- | P | stuff- | Data | stuff- | Data | 
| burst | ing |  | ing |  | ing |  | ing | burst | ing | burst | 
| R |  | R |  | R |  | R |  | R |  | R | 
|  | 
In this example, P indicates a PAUSE burst, P+subsequent stuffing represents the repetition time of PAUSE, and the total gap in between the data bursts is three times as long. The length of Data burst+stuffing is the repetition time of the burst. The PAUSE burst is transferred with the same bit stream number as the bit stream number of the audio data stream which contains the gap that the PAUSE data-bursts are filling, or for which synchronization is being assisted.
The PAUSE data-burst contains the burst_preamble and a 32-bit payload. The first 16 bits of the payload contain the audio gap_length parameter. The remaining bis are reserved, and should all be set to ‘0’. The audio gap_length parameter is an optional indication of the actual audio gap length. This is the length, measured in IEC958 frames, between the first bit of Pa of the first PAUSE data-burst and the first bit of Pa of the next Audio data-burst. The detailed use of the PAUSE data-burst depends on the data-type of the Audio data-burst. For example, gaps between AC-3 data bursts are filled with a sequence of very short PAUSE bursts, and the repetition time of PAUSE data-bursts between data-bursts of an MPEG type is related to the algorithm. The gap_length parameter of the first PAUSE data-burst of the sequence may be used to indicate the length of the audio gap which is being bridged by the sequence of PAUSE data-bursts. The PAUSE data-bursts in the sequence which follows the initial PAUSE data-burst do not have a gap_length specified (gap_length=0). A gap may be filled with one single sequence of PAUSE data-bursts with a single indication of audio gap_length. For example, a gap corresponding to an audio gap of 768 samples may be filled with one sequence of PAUSE data-bursts with an indication of gap-length=768 in the initial PAUSE data-burst. Or this gap could be filled with a number of smaller sequences of PAUSE data-bursts, with the initial PAUSE data-burst in each sequence indicating the gap_length bridged by that sequence (E.g. one sequence with a gap-length of 200 samples, followed by a sequence with gap-length of 568, together bridging a gap of 768 sample periods).
The information about the full length of the audio gap in the first PAUSE data-burst will allow the decoder to perform the best concealment. However, if the data source does not have the information about the full audio gap length at the time the gap begins, then it may signal an initial value for gap_length. If the data source then determines that the audio gap will be longer than the initial indication, then another sequence of PAUSE data-bursts may be initiated (following the first sequence by the repetition time) with another gap_length value to signal the decoder that the audio gap is being extended. If the gap is further extended, additional sequences may be initiated.
Audio decoders may use the gap_length information to optimise their concealment of the audio gap. The inclusion of non-zero values of gap_length is optional, data sources are not required to indicate the length of the audio gap.
The data type PAUSE has a sequence of four control words Pa, Pb, Pc, Pd followed by the Payload and the Stuffing.
“Gaps” are discontinuities in a bitstreams, and may be due to switching between bitstreams. The length of the gaps depend on the timing of switching from one to the other bitstream, and may have any value. The length of a gap however, depends on the decoder which must be able to conceal the gaps. Therefore the transmitter shall adjust the length of the gap to a multiple of the repetition time of PAUSE data-bursts. The PAUSE data-burst has its repetition time, which gives the time of transmission of Pa of the next data-burst.
Some AC-3 decoders may be capable of “concealing” audio gaps. The indication of the audio gap length (gap_length) which may be included in the payload of the PAUSE data-burst allows the decoder to know how long an audio gap will need to be concealed, and thus allow the decoder to optimise the concealment process for the actual audio gap length. AC-3 decoders will most easily conceal audio gaps which have a length equal to an integral multiple of 256 samples. Thus audio gaps oflength256, ?68, etc. IC958 frames are preferred, as follows:
|  | 
|  | repetition time of PAUSE data-burst | 
| data-type of Audio data-burst | mandatoty | recommended | 
|  | 
| AC-3data |  | 3 IEC958 frames | 
| MPEG-1Layer 1data | 32 IEC958 frames |  | 
| MPEG-1Layer 2 or 3 data or | 32 IEC958 frames |  | 
| MPEG-2 without extension |  |  | 
| MPEG-2 data withextension | 32 IEC958 frames |  | 
| MPEG-2, layer-1Low sample rate | 64 IEC958 frames |  | 
| MPEG-2, layer-2 or 3Low sample | 64 IEC958 frames |  | 
| rate | 
|  | 
The AC-3 bitstream consists of a sequence of AC-3-frames. The data-type of aAC 3 data-burst is 01 h. An AC-3 frame contains 1536 samples for each encoded channel. The data-burst is headed with a burst_preamble, followed by the burst_payload. The burst-payload of each data-burst of AC-3 data shall contain one complete AC-3-frame. The length of the AC-3-data-burst will depend on the encoded bit rate (which determines the AC-3-frame length). An AC-3 data burst with reference instant R comprises again four control words Pa, Pb, Pc, Pd an AC-3 burst_payload, and stuffing.