Ones and zeros recorded on CDs

[randytsuch]

Originally posted by Wombat



A nice read what others think about this topic is here.
http://www.hydrogenaudio.org/index.p...=insanity&

I admitted I was crazy, but that hydrogenaudio board looks more like PC sound people, who already think audiophiles are crazy. They had already decide the article was BS before they read it. I admit the mouse thing does sound kind of funny, but a lot of what the genisis guy did makes sense.

Oh, and I did not do a blind test because my wife thinks I am crazy, so I do not ask for her help on audio stuff, and I do not have any local audiophlile friends, so I just make the changes myself, and see what I hear.

What I can say is I tried it, and I heard a difference. That's enough for me.

Randy

[SY]

Well, think of it as a chance to show your wife that you really ARE crazy!

When I ask mine to help out, she just shakes her head sadly, does what I ask, and then tells all her friends about what a geek I am.

[Elso Kwak]

Hi,
My wife used to say:
"What are you tinkering again, the sound is good all the same!"

[A 8]

Hello Elso,

This forum is a bit slow, why do the moderators have to approve everything before it goes public?

Anyway, I am currently playing with the CS8420 in hw mode 1 which enables reclocking.
I started with a std integrated 24,576 clock and buffer (-yes 96kHz upsampling) and are now testing my own based on "onegate logic"and a low distortion video op powered by separate very low ESR power supply built on 8 ampere 4.8v Panasonic NiMh batteries, Sanyo Oscon, Wima MKT and SMD Ceramics, there are actually no active components in the powersupply chain.

I am using the BB PCM 1702 (testing the 1704) both of these allow me to run the the bit clock directly from the clock source and as both these dac chip trigger analog current out on the third clock pulse after latch enable or word clock goes low I assume I will not have much more jitter then present in the clock (bitclock) source.

Funny enough I can still hear subtle differencies using different sources however not from different discs (copy or original) on the same machine....I find it really strange....)

[AudioFreak]

A 8,

You'll only stay in the moderation queue for a relatively short time. We have it set this way to prevent users from registering just so they can spam. As a side note, this process has already stopped a number of posts that contained virus code from going public.

Regards,
Daniel aka AudioFreak
diyAudio Moderator.

[vic2]

Hi, I stumbled across this thread and would like to add a couple of cents.

Audio playback of a CD is completely different from writing a CD or copying it. When a computer copies a CD, it makes an identical bit by bit copy. It can make it identical because it can reread the source until it has no errors and then write it to CD. This is not the same as oversampling. It reads data, stores it rereads it and compares it. It can do this over and over until it gets it right, then writes it. We know that the two copies are identical because if they weren't then text files and so forth would not be the same from disk to disk.

Playback of audio is different. The DAC has to provide a continuous stream of data to convert to an audio signal so that the music is uninterupted. If an error in reading is encountered then the error correction comes in to fill in or somehow fix the error to keep the stream uninterupted. Of course there are different forms of error correction.

Furthermore, in response to reading the pits; as the laser reads the disk, it starts of reading a 1 o 0, depending on whether it is a peak or pit. Say it reads 0 while it is in a peak, when it changes to a pit, it starts reading 0 and continues to do so until it changes back to a peak. It is the change from pit to peak and vice versa that changes the reading from 1 to 0. From my understanding, that is where oversampling comes in. It is the ability to be able to detect the changes quickly that decreases the likelihood of error.

When your computer reads a CD-ROM it is not under the constraint of needing to keep out a stream of data so it can read and reread bytes over and over to make sure there is consistency.

vic

[OliverD]

Originally posted by vic
Audio playback of a CD is completely different from writing a CD or copying it. When a computer copies a CD, it makes an identical bit by bit copy. It can make it identical because it can reread the source until it has no errors and then write it to CD. This is not the same as oversampling. It reads data, stores it rereads it and compares it. It can do this over and over until it gets it right, then writes it. We know that the two copies are identical because if they weren't then text files and so forth would not be the same from disk to disk.

Ok, this seems logical, but it isn't. You are right about the reading process. Assuming a CD is not too damaged, we can read it over and over again until the error correction algorithm tells us there is no error in the received data stream (there IS a small chance of an error passing, though quite improbable).

Writing a CD is completely different. There is no way of changing written bits on a CD-R, so what the CD writer does is simply reading a data stream from its IDE port, adding error correction bits, do some crazy other crazy manipulations, 8-to-14-modulate it and then write it on the CD, without giving a damn whether it works out or not. Later, we can verify the writing process. (This behaviour changed slightly with the introduction of the burn-proof technology, but basically there is still no way of altering a pit that was burned to the CD already)

When copying CDs, the actual pit pattern is NEVER the same, simply because we don't burn polished CDs in a clean room and thus cannot prevent dust, fingerprints or similar things to cause errors. This is why we have error corretion. Only this error correction algorithm is the reason for your text files looking the same. Remember, we are writing MUCH more data to the CD than just the directory structure and file data (or PCM audio data in case of an audio CD) -- error correction introduces a lot of overhead.

Originally posted by vic
...It is the change from pit to peak and vice versa that changes the reading from 1 to 0. From my understanding, that is where oversampling comes in. It is the ability to be able to detect the changes quickly that decreases the likelihood of error.

You are wrong. Oversampling is a mathematical manipulation of the audio data stream and has nothing to do with reading data from CD. Basically it means inserting calculated samples (not pits) between the actual samples that were read from CD. You can compare it to image manipulation programs: It's like creating a new file of 1000x1000 pixels, then inserting a 100x100 pixels image from your harddisk, stretched by a factor of ten, then applying the "blur" tool to "smear" the sharp borders of the stretched pixels and afterwards print it instead of printing it directly. It's not explained in a few words. Oversampling leads to a better "separation" of audio information and high-frecquency "crap" introduced while reducing the resolution down from near infinity in the analog world to 44.1kHz/16bit in CD audio. Because of that better separation we can use simpler filters at the DAC output that sound better. (Many audiophiles think that oversampling is a bad thing and some even ditch the filter completely, but this is a different matter.)

The reason for people hearing differences when listening to the "same" (bit-wise) datastream is jitter (phase noise) introduced during the reading process. As unfortunately the system clock of a CD-player is a PLL sync'ed to the reading and decoding logic, "unsharp" or blured edges of the pits can lead to more jitter in the system clock signal, which in turn affects the timing of the samples at the DAC output. This is very audible and explains why different brands of CD writers and CD-Rs sound different. It doesn't matter when reading text files, though. The bits are still the same.

[Henckel]

The reason for people hearing differences when listening to the "same" (bit-wise) datastream is jitter (phase noise) introduced during the reading process. As unfortunately the system clock of a CD-player is a PLL sync'ed to the reading and decoding logic, "unsharp" or blured edges of the pits can lead to more jitter, so the quality of the system clock signal is affected, which in turn affects the timing of the samples at the DAC output. This is audible.

I do not agree. A CD player has a master clock which clocks out the read bytes(PCM data) from a FIFO buffer(towards the DA). The cd players "reader" logic is done in a way that the FIFO is never empty or full. The master Clock is not PLL locked to the reading of the individual data blocks on the physcial CD ( but controlled by the empty/full indications of the FIFO.

In a PC it is the clock source of the soundcard that controls the readout of the PCM data towards digital out or the build in D/A converter. The ripper program that gets the PCM data is controlled in very much the same way as the fifo above or just read once and for all to memory.


Having said that the jitter of the master clock is audible but should be the same wheter its original Cd or a copied one( for one specific set of components).

[OliverD]

Originally posted by vic
The DAC has to provide a continuous stream of data to convert to an audio signal so that the music is uninterupted. If an error in reading is encountered then the error correction comes in to fill in or somehow fix the error to keep the stream uninterupted.

You are right in the respect that a CD-player never goes back to read some bits again when there is an error. A CD-ROM drive can do that, because it spins faster than 1x speed, and when the read buffer is full, there is enough time to go back.

But this isn't the problem. Error CORRECTION in CD-audio is a complicated, nested pattern of parity bits which allow to recognize whether an error occured, and its position in the data stream. As we only have "1"s and "0"s, we can CORRECT this error easily by inverting this bit. In fact, there is a big buffer in every CD-player to make it possible to do a number of manipulations on the data stream before passing it on to the digital filter or DAC. Error correction itself can fix (fixing meaning restoring the exact original data that was written to the CD) a drop-out of 7mm pit track length - quite impressing!

If error correction fails, "wrong" samples are inserted in the data stream - or the output is simply muted. This is not what we are talking about here - a muting CD player or failing error correction is quite audible. We are talking about subtle differences in sound quality due to different CD-R brands.

[OliverD]

Originally posted by Henckel I do not agree. A CD player has a master clock which clocks out the read bytes(PCM data) from a FIFO buffer(towards the DA). The cd players "reader" logic is done in a way that the FIFO is never empty or full. The master Clock is not PLL locked to the reading of the individual data blocks on the physcial CD (but controlled by the empty/full indications of the FIFO).

Absolutely right. I was unclear about that, because I had my setup in mind which is a CD drive and a separate DAC, connected via an S/PDIF interface, so there is a PLL in the DAC.

Originally posted by Henckel Having said that the jitter of the master clock is audible but should be the same wheter its original Cd or a copied one( for one specific set of components).

Still, people hear the difference. The system clock quality might be affected through its power supply (a worse CD-R might need more servo interaction which leads to a more polluted power supply) or it might make a difference that the signal is passed through more or other gates within the reading / decoding / buffering / error correction / whatever logic in the CD player's chipset. Often it makes quite a difference to feed the DACs directly from the master clock instead of using the digital filter's clock output. We should believe what people hear and investigate instead of stating "It can't be" all the time.