Today we are picking up where we left off yesterday (See inSync – 05/11/04) in our discussion of “pro” versus “consumer” forms of digital transfer and why the data they transmit may not be compatible. In order to get the full context and background of the discussion we recommend you read yesterday’s tip before proceeding.
It’s important to remember that IEC958 (including AES3, S/PDIF, etc.) is a serial protocol – all of the data is transmitted bit by bit, serially. Each “sample” (or frame) of audio data transmitted consists of two subframes: one for the left channel and one for the right. Each subframe is made up of 32 bits of data – or you could say it is a 32 bit word. These 32 bits break down as follows:
- Bits 1-4: The first four bits are used for synchronization data (sometimes referred to as a preamble). This is not sync like time code – this sync data tells the receiving device where each channel’s data begins (remember, it’s a serial transmission) as well as some other stuff we’ll talk about below).
- Bits 5-8: Technically these bits are for “Aux Data,” but when transmitting 24 bit digital audio they get used for the four least significant bits (LSB) of audio data. If the digital audio data is 20 bits or less they can be used for other things, but usually aren’t.
- Bits 9- 28: Digital audio data, transmitted LSB first, MSB last.
- Bit 29: Validity – tells whether audio data is fit for conversion.
- Bit 30: User Data – some machines let the user encode small amounts of data in the transmission, such as date, reel number, etc.
- Bit 31: Channel Status Data – See below.
- Bit 32: Parity Bit – The first layer of error correction/detection.
For the most part this is all pretty straight forward, however, bits 30 and 31 have some interesting properties. While only one bit of data is transmitted per sample (each channel has its own unique User and Channel Status Bits) they are each accumulated over a period of 192 samples (or frames) and used to construct a data block that is 24 bytes of 8 bit data (do the math – that’s 192 total bits of data). These 192 frame blocks are separated and denoted by unique preamble data (bits 1-4 above). Each time a certain configuration of bits is seen in positions 1-4 the receiving machine knows to begin accumulating Channel Status and User Bit data again.
It is the data contained within the 24 Bytes of the accumulated Channel Status data (bit 31 above) that we are interested in. The Channel Status bit carries all kinds of information that is used to further specify the nature of the digital audio data being transmitted. This includes things like sample rate, emphasis, bit depth (thus defining how bits 5-8 above are used), SCMS info, CRC error correction data, and a whole bunch of other minutiae.
The very first bit of this data (also he first bit of the first byte) is known as the ‘PRO’ bit. It determines the definitions of many of the bits to follow. The key point to understand here is that some of the data mentioned in the paragraph just above this one will be different depending upon the status of this bit (one or zero). If this bit is a one, then it defines the data as a ‘PRO’ transmission. It configures the following 7 bits like so:
- Bit 2: Audio bit – defines whether the data is standard audio data or some other type.
- Bits 3-5: Emphasis – Tells whether emphasis is enabled, and if so, what type.
- Bit 6: Lock – whether the data is locked to the source’s sample frequency.
- Bits 7 & 8: Fs – Information about the sample frequency.
This is just the first byte of data that gets constructed from the 192 bits of Channel Status data. We’ll not go through the rest of it – you can assume a lot of it is similar types of information.
Now…if that ‘PRO’ bit is set to a zero, the meanings of some of the subsequent bits are changed. Let’s look at bits 2 though 8 of the first byte of data in a “consumer” transmission (remember, the first bit is the ‘PRO’ bit itself) and compare it to the structure just above:
- Bit 2: Audio Bit – same as before.
- Bit 3: Copy Bit – This is the first bit of the infamous SCMS copy protection code. (The other bits of SCMS are part of Byte #2).
- Bits 4-6: Emphasis – Pretty much like bits 3-5 in ‘PRO’ mode, but they have some different specific designations.
- Bits 7 & 8: Mode – Defines the meaning of some following Bytes, which we’re not going to get in to.
Okay, by now you have enough information to begin to see the problem yesterday’s inSync reader is having. In the broad definition of IEC958 there are two fundamentally (though subtly) different configurations of data. In the portion we’ve laid out above you can see that one of the SCMS bits in the consumer format overlaps with the emphasis data in the ‘PRO’ configuration.
Now, as goofy as this sounds at face value they are actually implemented in such a way that a true conflict shouldn’t happen (though there are some rare conditions where emphasis can erroneously be indicated). There are, however, other changes throughout the following bytes of data. In ‘consumer’ mode a lot of the following data is not used (or is mapped intelligently) so under most normal circumstances a conflict is not likely to occur. That said, the two different formats of data are ‘technically’ not compatible with one another. They are two different formats that just happen to be able to co-exist most of the time.
Many professional audio devices are capable of recognizing the status of the pro bit and configuring themselves accordingly, or will allow the user to manually change a setting to determine how the data is used (or transmitted). Many other machines may simply ignore it. Many consumer devices will ignore it as well, but some, if unable to reconfigure themselves, will simply refuse to recognize the ‘pro’ data. It would be very unusual for a consumer designated device to give the user access to this setting manually as that, by definition, is a feature reserved for pro devices. It is also possible for a pro machine to refuse to recognize consumer configured data, and to have no way to be reconfigured, though in practice that would be quite rare.
Okay, now that we understand this, what can we do about it? Unfortunately the answer is relatively little. The first thing to do if you run into a situation where this is a problem is call the manufacturers of the two devices and see if there is any way to effect a change to either one of them (in software or firmware) that will enable them to become compatible. If that proves to be a dead end about all you can do is swap out one of the devices for something that will be compatible. A third solution is to purchase a device that is capable of either reconfiguring the data, or at least changing the status of the ‘pro’ bit so that the receiving device can be “tricked” in to thinking it is getting the right kind of data. This actually works pretty well, but the relatively few devices that do this can be somewhat expensive. Your Sweetwater Sales Engineer can help you through this if you think you are having a similar problem.
One added caveat or potential layer of confusion. These ‘standards’ are all in flux to some degree. Things do change from time to time, though usually not in ways that have much consequence to end users. We also have to remember that a standard is not much more than a voluntary statement of common industry practices. A given manufacturer’s compliance with these standards is, A) voluntary, and B) subject to their interpretation of the standard itself. And there is room for subtle differences in the interpretation of some parts.