Bits are bits

[RayDunzl]

I had seen the format of the ,WAV file, but it makes little sense to me. I "understand" at a basic level bits and bytes and ASCII characters.

Overview:

The sound data is numeric. For 16 bit the values range from +32767 to 0 to -32767.

Sound waves are air pressure changes (rapidly) over a period of time. The sound waves cause local pressure of the air to rise above (compression) and fall below (rarefaction) the local undisturbed (silence) ambient air pressure.

A microphone mechanically "senses" the pressure variations and outputs a varying voltage, which is an analog of the pressure changes. No gaps or steps or numbers yet. More pressure (compression of the air by the musician) gives a higher positive voltage, less pressure less voltage, negative pressure (rarefaction) gives a negative voltage output.

This voltage from the microphone could be fed to an amplifier and drive the speaker and you hear the sound. This would be like a live singer with a mic.

The problem is to store the output of the microphone so you can take it home and listen to it later.

That has been done by plowing a wiggly groove in vinyl, or putting a varying amount of magnetism (more or less) onto a magnetic tape.

Digital:

An Analog to Digital Converter takes the voltage from the microphone, and, for example (CD rate) measures it 44,100 times per second.

A stream of numbers (digits) comes out of the ADC, 44,100 times a second, each number is the instantaneous voltage of the microphone output, scaled to fit within the 16 bit range, depending a little on the twist of the gain knob.

It is this stream of numbers that go onto a CD or into a WAV file. (there are complications as to how the data is "encoded" on the CD, but it still decodes to the stream of numbers the ADC output).

It is this stream of numbers that is read from a CD or a WAV file and sent on to the Digital to Analog Converter.

The DAC takes the numbers and turns them back into a voltage that changes over time, scaled again, typically within the range of +/-2V, which can be fed to an amplifier, then fed to a speaker, to produce air pressure changes that propagate to your ear, similar to the air pressure changes that tickled the microphone in the beginning.

100 milliseconds of air pressure variation (music), one channel, 4,100 samples

The dots represent the numerical samples that make up the "wave".

The numbers on the left are not the numerical values in the file, they go from 1 to -1. Multiply by 32768 to get an idea of what the actual sample values were.

 

[RayDunzl]

For CD audio probability of error is on the average of 10 times per second.

That's about the same rate I achieved as a kid playing clarinet in school band.

 

[RayDunzl]

My DAC2:

Input Status Display
Under normal operation, the Input Status Display shows which of the inputs is selected.
A single steady light indicates that a proper signal is present.
A flashing light indicates that an error is occurring on the selected input.

Input Error Codes:
Very slow flashes – No signal – audio muted
Slow flashes – Data transmission errors or Non-PCM – audio muted
Rapid flashes – Non-audio – audio muted
Very rapid or intermittent flashes – Invalid sample(s) (v-bit) – no mute

I've never noticed an indication while playing a playable CD or other PCM sources (TV, HDRadio, stream from PC).

 

[Cosmik]

So what was the original post all about..?

The test of the same CD after 2000 copies.(any question about pressing process or how to read these measurements just ask)
After rip with error correction, you will get the same check sum.
With the bits are bits theory they should sound exactly the same.
How do you explain that?

My explanation is that they do, indeed, sound the same, and that bits are bits.

Do you disagree?

 

[Jinjuku]

3 billions pits in a CD without reading errors, it's called the magic of error correction
And I can say the same thing about SSD and HDD.

Same when I wiresharked 240 GB of wireless music streamed from my NAS (SMB 3) and zero errors.

 

[Jinjuku]

Because you think that same check sum=same bits.

PS:I added a link for reading the two test.

So two same CRC 32Bit checksums don't equal the same bits? (1 untrapped error in 4 billion bits)

 

[amirm]

I think our rudder is broken in this thread.

We are using a common expression in audio so we need to stick to its meaning:

1. According to some objectivists: "bits are bits" means that once you are dealing in digital domain, no changes upstream of a DAC can make a difference. Alas, this is wrong as I have shown in my measurements. The reason is that DACs don't just operate on digital data. They also need analog voltages and timing (which *is* analog) to create their output. Therefore upstream changes can and will change the output of the DAC.

The correct argument here then is how audible it is and in vast majority of cases, audibility is not impacted due to small level of differences in output of DAC in all but the worst DACs.

No one has applied bits are bits to what is on the optical media is the same as what is captured on a computer as a result of ripping it. The argument applies to bits once they are stored in the computer.

 

[DonH56]

I think our rudder is broken in this thread.

We are using a common expression in audio so we need to stick to its meaning:

1. According to some objectivists: "bits are bits" means that once you are dealing in digital domain, no changes upstream of a DAC can make a difference. Alas, this is wrong as I have shown in my measurements. The reason is that DACs don't just operate on digital data. They also need analog voltages and timing (which *is* analog) to create their output. Therefore upstream changes can and will change the output of the DAC.

The correct argument here then is how audible it is and in vast majority of cases, audibility is not impacted due to small level of differences in output of DAC in all but the worst DACs.

No one has applied bits are bits to what is on the optical media is the same as what is captured on a computer as a result of ripping it. The argument applies to bits once they are stored in the computer.

I didn't quite follow point #1... Do you mean that even though the actual digital data is correctly delivered to the DAC, the DAC may fail to properly recover it? Or that things like power and ground noise coupled from the digital source can still corrupt the DAC's analog output?

Actually, the whole "bits are bits" bit I find a bit confusing since some define and use words like bits a bit differently.

 

[amirm]

I didn't quite follow point #1... Do you mean that even though the actual digital data is correctly delivered to the DAC, the DAC may fail to properly recover it? Or that things like power and ground noise coupled from the digital source can still corrupt the DAC's analog output?

The latter of course. The digital bits travel error free there.

 

[DonH56]

Got it, too little sleep last night, thanks Amir.

 

[Jinjuku]

I think our rudder is broken in this thread.

We are using a common expression in audio so we need to stick to its meaning:

1. According to some objectivists: "bits are bits" means that once you are dealing in digital domain, no changes upstream of a DAC can make a difference. Alas, this is wrong as I have shown in my measurements. The reason is that DACs don't just operate on digital data. They also need analog voltages and timing (which *is* analog) to create their output. Therefore upstream changes can and will change the output of the DAC.

I don't think that's correct. Most objectivists understand that Bits are Bits and DAC's can suffer interference regardless.

 

[Cosmik]

We are back onto the supposed impossibility of digital streaming, I see. That is, if timing and jitter inherently affect what comes out of the DAC, then the bits that have made their way across the world, often diverting dynamically via space or under the sea, often arriving out of sequence, cannot possibly give us the same measured performance as really high quality bits coming off a gold-plated glass CD or the world's most expensive hard drive via silver wiring. But they do.

I feel a dispute in the air, too: I say that the bits coming off a CD get buffered in a FIFO and that the transport speed is slaved to the fill level of the FIFO. In other words, the timing of the bits upstream of the FIFO is irrelevant as long as the FIFO does not empty. As long as there is a bi-directional on-demand system in place, the World Wide Web, CD, WiFi network are all exactly equivalent when it comes to what the DAC sees. As long as the DAC and its FIFO readout are driven from a fixed frequency master clock, bits really are bits.

It is only in S/PDIF and other 'unidirectional' systems with separate clocks that timing errors and jitter can reach the DAC - and even then they will be attenuated greatly. But I know that some people round here think that CD is such a system - it isn't.

 

[Jinjuku]

I would like to say this another way: You can have noise coming out of a DAC and still have bit perfect reproduction.

Bit's are still Bit's.

 

[Cosmik]

CRC detect all errors that span less than 32 contiguous bits within a packet and all 2-bit errors less than 2048 bits apart.
CD rom 2048 bytes.
CD audio 2352 bytes.

Is there some dispute or doubt about CRCs and their effectiveness? Is there a suggestion that CRCs aren't detecting some errors?

As so often happens, the fundamental ideas are being buried in the low level technician stuff. A CRC is one way of comparing two sets or streams of data to ensure they match to a high level of reliability. But, grist to the audiophile's mill, there's a minuscule chance that you can get a CRC match on two non-identical sets of data. Aha! That's why they are imagined perceived by audiophiles as sounding different!

But the obvious way to compare two sets of data if you have the memory and time (as we do in the 21st century) is simply to compare every value explicitly. Are they identical? Yes. Case closed. Bits are bits.

 

[Cosmik]

Any storage medium use error correction and don't compare every value explicitly.
I posted a test with burst length.
Because of overlapping same checksum do not mean same bits, and it happen more often than you think.
I already told you that bits are bits no need to try to convince me.

Again, it is spreading FUD. Anyone reading this would think that digital audio (and in the wider context, Information Technology in general) is fundamentally broken.

 

[Brad]

As far as I'm aware the CRC is not part of the reed-Solomon decoder. That is, the parity bits will correct errors in the reed-Solomon decoder, and the CRC is not used as a 'trigger' for this.

 

[Cosmik]

I already told you that bits are bits no need to try to convince me.

So you say, but you are then claiming that we have no way of knowing that the bits are the same! Quite clever actually: claim the rational high ground by stating that bits are bits, but still manage to convince yourself and other audiophiles that stuff really does sound different for unquantifiable reasons. It's all still up for grabs even if the checksums match! Audiophile cables, CD treatments, anti-vibration platforms, cable lifters, etc. The fun doesn't have to stop just because it's digital!

 

[March Audio]

Load a track into an audio editor, load it again and invert. Subtract one from other. If the result is zero then bits are bits and the reed solomon code did its job.
Whatwver point Alfe is trying to make, and I cant for the life of me figure out what it is, becomes moot.
End of thread.

 

[Cosmik]

I don't buy all these tweaks but also don't buy the bit perfect BS.

So the test BE718 suggests above doesn't prove* that the files are bit perfect?

* to a level of probability so strong that doubting it stretches incredulity to its limits

 

[FrantzM]

Because you think that same check sum=same bits.

PS:I added a link for reading the two test.

, Same checksum but different files is indeed possible but the probability of such is 2 ^128 ... which is, to put in mildly: exceedingly rare ... coming from two CD which more than likely would have a lot of similar bits ... the likelihood dwindle to impossibility IME. I could be wrong and will learn from being corrected. .