Consider this simple audio interface. It’s got 2 inputs, and you can record 2 input signals
simultaneously. You’d want full control over the 2 signals, and you’d want to apply
effects on one of them without affecting the other. So you don’t want the 2 signals to
be mixed and summed up together before going into the analog to digital converter. The
only way to do this, is for each input pathway to be made up of a fully fleshed out analog
to digital converter. Now consider this multitrack recorder. You’ve got 8 inputs, and you can
record a drum kit or a choir. Again, to separate the signals, you need 8 different ADCs. As
we saw in the earlier videos, ADCs are fairly complex circuits with very specialized components.
So every new input drives the cost up for the device. Right, but if you look at how
the multiple channels of signals are transmitted to a computer, they are usually via USB, Firewire
or Thunderbolt, and they are all serial communication channels. USB even has serial in its name.
Now the question is, how do we take this set of digital signals that are generated, and
transmit them along a single serial channel. We make use of multiplexing. A multiplexer
is a component used to combine two or more signals for serial transmission. Several multiplexing
techniques are around, but for digital signals, Time Division Multiplexing is the predominant
one. It’s quite simple really. Think about it as a component, where several inputs come
in, and one output goes out. Each input signal gets through for a limited duration of time,
before it’s the turn of the next signal. It’s a simple round robin mechanism, where
a snippet of each signal gets through and the whole process loops back around at the
end. As long as the time duration is constant, we get equal length snippets of each input
signal in the output. In the simplest case, where there are 2 input signals, the snippets
are arranged alternatively. This is called interleaving, and is common in all digital
media that’s multi-dimensional. The duration is important. A lot of the time, the length
of the snippet is as long as the sample word length, just enough to represent exactly one
sample of audio. In more cases than not, they’re the length of a group of samples, sometimes
called a frame. Going the other way now, audio devices can playback multiple channels of
audio at the same time. 2 channels in stereo, 5+1 channels in most surround sound systems,
8 channels in octophonic recordings. Whatever the channel count maybe, the digital output
signal would have all the channels interleaved in it. Before going into Digital to analog
converters, the signal is demultiplexed. This component would split the signal into its
constituent parts and reassemble them into independent channels. Even during storage,
the digital signal is stored interleaved. The simple reason for interleaving and not
storing a channel in its entirety one after another is that seeking becomes more efficient.
A reader pointer would not have to go back and forth to fetch samples. An interleaved
signal would have all the channel’s samples for a particular moment available in the same
general area in physical storage.
Ever wondered how a scratchy CD can be played back, and still get almost seamless output,
without any glitches or dropouts? If you look at the scale of the problem, it’s even more
astonishing. The average width of a human hair is around 70um. In comparison, the width
of the pits that are etched into the surface of the CD are around 1 um. So a single scratch
could potentially wipe out hundreds to thousands of bits of data. Sometimes, the destruction
is so massive, that parts of the original information is irrecoverably lost, and these
sections would result in unexpected glitches or dropouts in the audio. But most of the
time, the damaged information can be recovered back and corrected even, to get back the original
information exactly, or in a form that’s similar at least. How do we do this? We can
add some redundancy. The most brutish way to go about this would be replicate the entire
information set. If you have 3 exact copies of the audio data, you can make a comparison
bit by bit. If one of them doesn't match the other two, we can probabilistically rely on
the two that did match to be correct. If 2 of the bits were erroneous or if none of them
matched, then tough luck, the data is ambiguous, and there might not be a way to retrieve it.
Naturally you might be thinking, having a redundancy of 3 copies is overkill. And you’d
be right. It’s a waste of space and we’d be using up ⅔ of the storage capacity of
the medium for redundancy. Engineers have found clevers ways of adding redundancy, by
surgically putting error correction bits in strategic parts of audio frame data. With
this approach, you can essentially detect errors and even correct them, all the while
minimizing the storage required for redundancy.
The cornerstone for error detection or correction is redundancy. Without this, there is no way
to detect errors. Take a look at this sentence. How long did it take you to detect that there
were errors in it , and correct all of them to form a meaningful sentence? Not long I
presume. It’s estimated that the written english language is about 50% redundant. There
are a lot of identifiable features, like the first and last letters of the words, the number
of characters that a word is made of and the consonants that appear. I could scramble the
first word completely, and you could still make out the sentence based on the context
of usage. But taken on it’s own, it can’t really be corrected. The original meaning
is lost. There are a couple of points we can take away from this example. Redundancy is
not always obvious and easy to recognize, there are subtle ways to detect and correct
errors, and a lot of these algorithms rely on complicated mathematics to achieve this.
The second point, which is probably the most important, is that you can’t correct every
error. You can introduce a certain level of resilience to errors into the system, but
beyond a certain threshold, you just don’t have the redundancy to correct large errors.
I’m not going to delve into the specifics of the algorithms used for detecting and correcting
errors. They can get very technical very soon. The reason I’m not going to focus on it
is because we as audio engineers or programmers don’t deal with this directly. Error correction
is mainly built into storage media that could degrade over time. It’s also added into
digital signals during transmission. But on a computer, when you write to a file, or interact
with audio at the byte level, we never have to deal with error correction. The files that
are written to disk don’t contain error correction redundancies. That’s handled
by the operating system where it does it’s own storage and memory management. But if
you are curious to know more, definitely go check them out, it’s very interesting how
they approach the problem. I’ll give you a list of topics that you could search for.
For error detection, the simplest way is to make use of parity bits. Other methods used
are checksums and cyclic redundancy checks. For error correction, coding schemes are used
to introduce redundancy bits surgically into the data frames, based on some pre-calculated
conditions. These include Hamming codes, Convolution codes and Reed Solomon codes. You can check
out this excellent video on error correction and Hamming codes by 3blue1brown where he
wonderfully illustrates the technicalities of the process.
In the previous video on encoding, I’d brought up this diagram. It’s a high level workflow
diagram for getting a signal in the analog domain, into a fully functional, transmissible
digital signal. It took a while for us to get here, and a lot has been done and said.
The topics that I talk about barely scratch the surface. The details are mind numbingly
more intricate. But that’s for you to explore. If something catches your eye, don’t hesitate
to get your hands dirty. Never know where it might take you. In the next video in the
series, we’ll finally take this digital signal into the realm of computers. We’ll
see how we can save and handle audio as files.