Summary
- RFC 3190 carried 12-bit nonlinear, 20-bit linear and 24-bit linear audio over RTP, but the hardest boundary was not bit width: DV reserved negative full-scale values as “no valid sample” error codes while the RTP payload formats made every possible value legal audio.
- A bridge could conceal a failed DV read before transmission or alter a legitimate RTP sample before giving it to DV. Either choice made interoperation possible by changing evidence, so the original sentinel, the transmitted sample and the played result had to remain separate records.
One number could not keep both meanings
In a DV recording system, the 12-bit value 800h was not the deepest negative point of a waveform. It was a warning from the medium: no valid audio sample was available for that sample period. The corresponding sentinels were 8000h for 16-bit linear audio and 80000h for 20-bit linear audio. A failure while reading magnetic tape could put one of those values into the stream.
RTP had no such vacancy. RFC 3190 defined DAT12, L20 and L24 as sample payloads in which every possible numeric value was valid. L16 already followed the same rule. The negative full-scale value could be genuine sound data. Giving it an error meaning would remove one legal point from the network representation.
The bridge therefore could not copy bits and preserve semantics in both directions. From DV to RTP, it had to decide what sound, if any, should stand in for a missing tape sample. From RTP to DV, it had to keep a legitimate negative sample from being mistaken for a hardware error. The incompatibility lived in the meaning of the number, not in the ability to carry it.
Concealment repaired the programme and erased the symptom
RFC 3190 said a sender accepting samples from a DV system should apply an error-concealment algorithm. It deliberately did not prescribe the algorithm. A single failed sample and a run of failures might need different treatment. The sender could interpolate, repeat, mute or use another local strategy. It was also permitted to pass the sentinel through as though it were audio, although the document warned that the result was likely to sound undesirable.
That freedom served real-time playback. It did not preserve the source event. Once 8000h had been replaced with an interpolated sample, an RTP receiver could hear a smooth waveform without learning that the tape read failed. Packet capture would faithfully preserve the repair, not the damaged source.
An archive that retained only RTP payloads could therefore be complete at the transport layer and incomplete as a history of the recording. The packet was not corrupt. The audio was not necessarily bit-identical to the tape output. Both statements could be true.
The reverse bridge sacrificed a legal sample
The reverse direction required a different compromise. If an RTP receiver handed a legal negative full-scale value to a DV system unchanged, the DV system could interpret it as an error. RFC 3190 recommended translating the collision to the next smaller negative value: 800h became 801h, and 8000h became 8001h.
For 20-bit audio, the protected range was wider. Values from 80000h through 8000Fh became 80010h. The reason was another compatibility layer: a 16-bit device might play 20-bit material by ignoring the four least-significant bits. Sixteen different 20-bit values would then collapse onto the 16-bit sentinel. The translation moved the whole collision range.
This was controlled distortion. It changed valid source data so that a downstream device would not confuse data with status. The output could be operationally safer and numerically less exact at the same time. No equivalent rule was given for 24-bit audio because the cited DV specification did not include that encoding.
Twelve bits saved bandwidth but did not make a codec verdict
DAT Long Play used a 12-bit nonlinear representation derived from 16-bit linear samples. Sending the material as L16 would have been easy, but RFC 3190 calculated that doing so would consume 33 percent more network bandwidth than necessary. DAT12 kept the compact form.
Samples were signed two's-complement values from -2048 to 2047, packed contiguously from the most-significant bit. When a packet held an odd number of 12-bit samples, the four low bits of the final octet were unused. L20 used the same half-octet condition for odd sample counts; L24 aligned naturally by octets.
Those packing rules established how to recover numbers. They did not prove signal quality, listener preference, source authenticity or successful playback. A valid DAT12 payload could contain a concealed tape error. A perfect bit parser could reproduce the value chosen by the bridge and still know nothing about the value the tape failed to yield.
The channel map was outside the waveform
RTP audio interleaved channels by sampling instant: left sample one, right sample one, left sample two, right sample two. Native DV blocks used a different arrangement. An application extracting audio from DV into DAT12, L20, L24 or L16 therefore had to reshuffle samples into RTP order. If it wanted to retain native bundled DV structure, it belonged in the DV payload format instead.
For one, two or three channels, the AIFF-C convention supplied an implicit order. Four or more DV channels exceeded that convention and needed an out-of-band channel-order parameter. The allowed values were constrained strings such as a left-right-centre-woofer arrangement. Their symbols were concatenated without separators precisely so an implementer could not invent an arbitrary permutation.
The declared order also had to match the declared channel count. Five channels still needed the parameter even though only one five-channel DV order was allowed. Conversely, the parameter had to be omitted for the small implicit layouts so older implementations would remain interoperable.
The RFC drew a social boundary as well as a technical one. Channels intended to be reproduced together could share a stream. Independent channels, such as separate language translations, should use separate RTP sessions. Otherwise every receiver would spend bandwidth on programmes it did not want.
Bright and dull were negotiation failures, not damaged packets
Some source audio had analog preemphasis before quantization. RFC 3190 defined an out-of-band emphasis=50-15 parameter for that condition and required its absence when no preemphasis was applied. The parameter could accompany other payloads, including L16.
An older application might accept the session and ignore the parameter. Packets would still arrive, lengths would still be valid and samples would still decode. Yet reception could sound too bright, or transmission too dull. Transport success and faithful reproduction separated again.
The same pattern ran through the document. DAT12, L20 or L24 named the numeric representation. The sample rate and channel count described the grid. channel-order assigned positions. emphasis explained an analogue transformation. None of them proved delivery, concealment history or audible result.
What the payload registration actually accomplished
RFC 3190 registered three audio media subtypes and a disciplined way to describe them. It let DAT and DV equipment meet RTP without pretending that their native conventions were identical. Its most durable choice was to expose the places where conversion had to occur.
It did not make conversion lossless. The bridge could replace a DV error before packetization, perturb a valid RTP sample before DV output, rearrange native block order, or depend on metadata that an older peer ignored. Interoperability came from specified compromises, not semantic sameness.
The historical lesson is unusually concrete. A bit pattern cannot carry its own jurisdiction. 8000h meant “negative full scale” under one contract and “no sample” under another. The system stayed intelligible only when the boundary named the contract, recorded the conversion and refused to treat the repaired sound as proof that nothing had failed.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
