Back to the classroom

Join Our Community Subscribe to Paul's Posts

March 23, 2014 by Paul McGowan

Thanks for indulging me my story of the early struggles with an outdated education system. I hope we’ve come a long way since those days of industrialized factory schools churning out something; although I am not sure what.

The saving grace of my education through public schools was the few standout teachers I had (and I suspect you had as well). Hats off to those brave souls that really loved to teach and share and gave their all towards that endeavor, despite an antiquated school system that hadn’t changed much since it started, back in the Henry Ford days.

Let’s finish up with DoP and move on to other subjects. If you’ll recall, DoP is a format that permits single bit audio (DSD) to “trick” a computer or network into thinking its Multi-bit Audio (PCM). Because computers don’t recognize Single-bit Audio, they don’t know what to do with it. And that brings me back to what I asked you to memorize: that Bits are Bits. To a computer a video bit, math bit, audio bit, or mouse bit all look the same. Bits is bits. Remember?

Now, don’t get turned around just yet. Many of you wrote in to say “if bits are bits, why do cables matter, sample rates, etc.?” Ok, that means you’re thinking too much! I’ll likely call Mr. Shannon out of retirement to give you a good whack for doing so. 🙂 When I write “bits are bits” I am not referring to how those bits are delivered, their speed, their timing and all the little details critical to how those bits are going to sound. No, I am referring to the bits themselves: the ON and OFF pulses are all pretty much the same.

So if bits are bits, how do Single-bits differ from Multi-bits and how does a computer know the difference? Computers use something called a header, which is a small group of bits that represent an instruction set. The header always comes first and tells the computer “I have PCM or I have DSD or I am USB” and with these instructions, the computer (or DAC) knows what to expect next and what to do about it.

The problem we run into with Single-bit Audio is two fold: it’s a stream and doesn’t have a consistent “reminder” header telling the computer what’s going on and most modern computers were never instructed to deal with Single-bit Audio even if they did have the instruction set. They only know Multi-bit Audio. Think of this as getting a set of written instructions in a language you can’t understand. That could change, over time if operating systems of Microsoft and Apple wanted to include Single-bit audio, but for now they don’t.

So here’s what some clever guys did to get around this problem: they put sheep’s clothing on the pack of wolves. If you had a flock of sheep and wanted to get a pack of wolves into that group without the sheep noticing, you’d wrap the wolves in sheepskin so the sheep would be fooled. Now let’s relate that to Single-bit Audio (the wolf) and Multi-bit Audio (the sheep).

Single-bit Audio is a stream of on/off bits. The more ON bits the more energy we generate to make a loudspeaker move. Multi-bit Audio is not a constant stream, but rather a stream of coded packets (their bits also make more or less energy to the loudspeaker, but they must first be decoded, unlike the simpler Single-bit stream). Think of Single-bit Audio as a flowing stream of water and Multi-bit Audio as a long unbroken freight train. Each of the cars in our imaginary freight train has an identifying marker that lets an inspector know what’s inside each of the cars of the train. This is the header I spoke of.

If we want to take our continuous stream (Single-bit Audio) to a new location, one thing we could do is divert a section of the stream’s water and fill up one of the freight train cars. If we repeated this process, using all the freight train cars, we could transport an entire stream intact to anywhere we wanted. How did we manage this?

Picture our stream running in an overhead pipe with a gate on the pipe that opens up at identical intervals, releasing water. Below the pipe is our train. With each water release we fill up one of the cars of the train; the train then moves forward and the process repeats. Using this method, the train can travel anywhere it needs to go. What we’ve done is expertly divided up the water in the stream into containers (the train cars) which allows us to transport the water intact to a new destination. Once we arrive all we need to do is reverse the process and we again have a flowing stream. The water is identical, it’s in the same order it started with and it was never converted to something else for transport.

Now you start to understand how DoP does not convert Single-bit Audio to Multi-bit Audio, it simply breaks the continuous stream of bits in Single-bit Audio into identical groups, wraps an additional piece of info around it and fools the computer into thinking it’s actually something it is not. The computer’s happy, the data is intact.

Remember that the bits are bits and the computer can’t tell one bit from another? Once we add this header that is lying to the computer, falsely identifying the attached group of bits as PCM, the computer lets them through because it simply cannot tell the difference and doesn’t care (they pass through unmolested but the computer still doesn’t know what to do with the DSD bits and thus can’t play them without a program to help it understand them).

For the more technically minded here’s the details. The Single-bit Audio stream is running at 2.822mHz (2,822,000 bits per second). The DoP “converter” simply culls out 16 bits from the Single-bit stream and attaches an 8 bit header to it, then repeats that process over and over again. The bits it is grabbing have no timing information associated with them; they are simply a group of exact ON/OFF bits in the exact order they started with. 16 audio bits, plus 8 header (information) bits equals 24 bits. So a DoP packet is 24 bits long (8 info bits and 16 data bits). Each of these newly minted packets collectively run at 176.4kHz. Sound familiar? Sure, you’ve heard of high resolution audio running at 176.4/24 bits? Right. That’s single rate DSD in DoP clothing. You can do the math yourself: 16 x 176,400 equals 2,822,400 which is the exact sample rate of single rate DSD. Simple eh? And the other added 8 bits? They account for the larger file size of DoP vs. native DSD (bigger by 1/3).

Here’s a picture of what that looks like.

USB_DSDviaPCM_1v0

The orange squares to the left represent the 8 information bits attached to the 16 bits of DSD to the right. This is our freight car filled with Single-bit water (the wolf we’re trying to hide), and the 8 header bits provide the sheep’s clothing to trick the computer into believing the next set of bits are PCM, not DSD.

Lastly, one of the 8 information bits lets any interested party know the data is really DSD. Thus, if the DoP data is put into a DAC that understands that information and can process it, all it needs to do is throw away the 8 bits of information data, connect all the 16 bit wide groups of DSD together and play the DSD stream perfectly. No conversion process ever took place.

Now, let me go grab a cold glass of perfect water from the stream, uncontaminated from any dreadful impurities, despite the fact it arrived in a freight train with a wolf as engineer.