Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CIRC & Jitter (Read 8564 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CIRC & Jitter

Guys, I have some questions for you. Yesterday I stumbled upon an article at Wikipedia. I was reading about the Cross-interleaved Reed-Solomon coding, specifically about the Reed-Solomon error correction. There it was stated:

Quote
The properties of Reed–Solomon codes make them especially well-suited to applications where errors occur in bursts. This is because it does not matter to the code how many bits in a symbol are in error—if multiple bits in a symbol are corrupted it only counts as a single error. Conversely, if a data stream is not characterized by error bursts or drop-outs but by random single bit errors, a Reed–Solomon code is usually a poor choice.


To my knowledge jitter (I don´t mean the seek jitter) is exactly that: random errors or random noise but you may of course correct me on that. When I read it that way, I tend to think that CIRC is a poor choice when it comes to jitter but a wonderful choice for burst errors. Wouldn´t that mean, that the CRC codes derived from CIRC during the ripping process of a CD with e.g. ExactAudioCopy are meaningless because they only say something about the presence of burst errors? Wouldn´t that also mean that the interfaces used today (SATA, IDE) could introduce jitter that won´t show up at all? Wouldn´t that mean that the same goes for the basic reading process? That the whole process of CRC codec is flawed and therefore AccurateRip is pointless?

I´ve read somewhere (I don´t know where) some time ago that re-clocking devices are used in every interface and that with an interface like IDE jitter can be as high as 1000 ps (When would jitter become audible anyway, at 100 ps, at 500 ps or at 1000 ps?). I don´t know if this true. How capable are these re-clocking devices? Are they able to completely erase jitter so that any D/A converter wouldn´t be affected?

Subjective opinion: I suspect that they are not because I was always under the impression that different CD drives are sounding slightly different. You may find that hilarious but I have been thinking this for years - and I still want to know why. Even if the outcome would be that I´ve believed in the biggest placebo effect ever. I also know that many people are drawing jitter as an explanation when they can´t explain or measure at all so forgive me if I jump to conclusions. I also think that jitter is highly exaggerated as a source of "bad" sound. But even if the harm caused by jitter is miniscule should we ignore it? Furthermore, to my knowledge there doesn´t exist any software to measure jitter (which I´d love to do) on the computer since you would need a non-jittery reference which you would compare to the same file, now with jitter. It also would need to do an analogue loopback to be successful. I would love to see some measurements.

I also would like to know opinions on this and - if possible - measurements for re-clocking devices.
marlene-d.blogspot.com

CIRC & Jitter

Reply #1 –
Quote from: Cavaille on
Guys, I have some questions for you. Yesterday I stumbled upon an article at Wikipedia. I was reading about the Cross-interleaved Reed-Solomon coding, specifically about the Reed-Solomon error correction. There it was stated:

Quote
The properties of Reed–Solomon codes make them especially well-suited to applications where errors occur in bursts. This is because it does not matter to the code how many bits in a symbol are in error—if multiple bits in a symbol are corrupted it only counts as a single error. Conversely, if a data stream is not characterized by error bursts or drop-outs but by random single bit errors, a Reed–Solomon code is usually a poor choice.



If you're talking about ripping, you have nothing to worry about unless your media is in really bad shape. A good ripping problem like EAC will IME almost always deliver bit-perfect digital files that are *exact* representations of the digital files used to make the CDs. Jitter doesn't relate to this kind of work.

Quote
Subjective opinion: I suspect that they are not because I was always under the impression that different CD drives are sounding slightly different.


CD drives and and do sound different, at least from time to time.  Nobody knowlegeable says that all CD players sound the same. Instead, we say that the good ones sound the same. The bad ones are obsolete or broken or badly-designed.

Here are some examples of CD players that I have personally encountered that sound different:

(1) The original CDP 101 colored the sound in ways that were barely audible on occasion, because it used analog filters that intruded on the audio band, and because one channel output was slightly delayed from the other. In general it was sonically transparent, but in certain cases it wasn't.  It was ABX-able, as was published in the latte 1980s.

(2) For the longest time portable CD players with electronic anti-shock memories did not have anything like 16 bit precision when the anti-shock memory was turned on.

(3) I have a Sony CD player that rather quickly developed a case of capacitoritus. Certain critical coupling capacitors (ironically marked "audiophile grade") lost over 90% of their rated capacitance and became high pass filters, severely attenuating music below 120 Hz.  Yeah, if you have a good system, you can hear that, big time!

Quote
You may find that hilarious but I have been thinking this for years - and I still want to know why.


The idea that every audio component has a unique personal sonic signature is still widely preached. As I've pointed out with some real-world examples, there are enough examples of CD players that *do* sound different roaming around to make it seem credible to many.

Quote
Even if the outcome would be that I´ve believed in the biggest placebo effect ever. I also know that many people are drawing jitter as an explanation when they can´t explain or measure at all so forgive me if I jump to conclusions. I also think that jitter is highly exaggerated as a source of "bad" sound.


Again, I can cite several occasions where jitter does explain audible problems. It is just that they are not nearly as common as many believe.

Quote
I also would like to know opinions on this and - if possible - measurements for re-clocking devices.


These days the digital inputs of even fairly cheap modern surround receivers and decoders are in themselves decent re-clocking devices.  CD players have always had re-clocking as one of their main functional units. If you rip your CDs on a PC, the whole operation takes place in the digital domain where there is simply *no* added noise or distortion of any kind.

CIRC & Jitter

Reply #2 –
Thank you for your insightful answers, Arnold. I really didn´t know that about the first Sony CD-player! But then, I´ve never seen or heard that component personally.

So, you´re saying that inside my PC which I use all the time as a playback device there isn´t any possibility of added noise? At least when it comes to the pure stream of data? Correct me, if I understood it wrong. I´d love to think that - and I still think that it is true. But as you know from the dreadful thread "Why we need audiophiles" I tend to embrace both sides, objectivists and subjectivists.

The reason for my OP and for my reading about CIRC was actually quite simple and hilarious. I can´t believe I´m writing that now... well, here it goes: I bought a new power cable as an experiment some days ago, you know... the usual stuff the audiophiles are playing with  . It was a cheap one, it is thicker (2.5 mm² compared to 0.5 mm² - overkill) than the one provided with my external DVD-drive (Samsung SE-S224Q USB) and it is shielded. I always do my ripping with EAC in the secure mode. Before I changed the cable I ripped a CD (the score to Star Trek VI: The Undiscovered Country by Cliff Eidelman). I ripped it again after I changed the cable to the one I recently bought.

The sound difference I percepted afterwards was huge to my ears - and I did not even waiting for it. Quite frankly, I was surprised. The CRC codes given by EAC were the same, even the bit-to-bit-comparison showed that there was no difference at all. But every time I compare the rips with my headphone the sound difference is there. How could this be? I did not make an ABX yet.

Could it be that I´m hearing a placebo effect? If so, it would be my biggest placebo effect ever. Since I did not doubt myself    I suspected that the CRC codec (and therefore CIRC) do not provide the user (us) with every information there is. If I understood CRC and bit-to-bit-comparison right they are counting bits, right? They sum the bits up and compare the results. Please correct me here because I only found information about CRC at Wikipedia but none about bit-to-bit-comparison. If I trust them there should not be any difference at all. Whom should I trust? My ears or the numbers given out ("measurements")?

If my "hearing" is valid wouldn´t that mean that the usual ways of describing the ripping quality are flawed? If it is not valid, well then I´ll bow my head.

P.S.: To the mods: you can move my post in the appropriate forum - I didn´t know a better place for something like this, but maybe it doesn´t belong here.
marlene-d.blogspot.com

CIRC & Jitter

Reply #3 –
Bit for Bit comparisons do not lie, this is digital data that is not subject to alteration unless there is a fault on the system (in which case next time you restart windows it will not load).

CIRC & Jitter

Reply #4 –
Quote from: Cavaille on
To my knowledge jitter (I don´t mean the seek jitter) is exactly that: random errors or random noise but you may of course correct me on that. When I read it that way, I tend to think that CIRC is a poor choice when it comes to jitter but a wonderful choice for burst errors.

When it comes to reading pits and lands off an Audio CD and turning them into PCM data, jitter is not an issue.

Maybe you can provide some technical justification demonstrating how it can be an issue?

CIRC & Jitter

Reply #5 –
Quote from: spoon on
Bit for Bit comparisons do not lie, this is digital data that is not subject to alteration unless there is a fault on the system (in which case next time you restart windows it will not load).
Thanks for that clarification. Then I either have a faulty system or I have listened to a placebo effect - seems to be the most likely conclusion.
marlene-d.blogspot.com

CIRC & Jitter

Reply #6 –
Quote from: greynol on
Quote from: Cavaille on
To my knowledge jitter (I don´t mean the seek jitter) is exactly that: random errors or random noise but you may of course correct me on that. When I read it that way, I tend to think that CIRC is a poor choice when it comes to jitter but a wonderful choice for burst errors.

When it comes to reading pits and lands off an Audio CD and turning them into PCM data, jitter is not an issue.

Maybe you can provide some technical justification demonstrating how it can be an issue?
Sadly I can´t. I´d love to. I was merely quoting Wikipedia and I thought about this particular fact. With everything else, CIRC seems to be a wonderful and powerful choice for the CD to correct errors. I only was concentrating myself on that quote where it was stated that CIRC has problems with random bit errors. If you would point me to a solution to test that I´d do it immediately. Or do you mean ABX? I could provide you with it if you´d like to. But for me this doesn´t serve as a justification. It either proves that my system is faulty or I´m hearing ghosts. Right now, the latter seems to be the case and now I´m sorry I was even talking about it...
marlene-d.blogspot.com

CIRC & Jitter

Reply #7 –
You never told us exactly what you're listening to: tracks ripped from the CD or the CD itself.

If you're comparing tracks ripped from a drive using two different power cords that produce the same CRC then yes, you're completely imagining the differences since the files are identical.

FWIW, CRC and CIRC are two completely different things.  The former is a number that is used as a signature for data; it is not a codec.  The latter is a method of error correction which is implemented on the CD itself.

Concerns about jitter, legitimate or not, deal with the transmission of the data stream after it has been created from the pits and lands off a CD.  The mere fact that you get identical CRCs from ripping should tell you with absolute certainty that there is nothing affecting your drive's ability to deliver consistent data.

CIRC & Jitter

Reply #8 –
Quote from: Cavaille on
The sound difference I percepted afterwards was huge to my ears - and I did not even waiting for it. Quite frankly, I was surprised. The CRC codes given by EAC were the same, even the bit-to-bit-comparison showed that there was no difference at all. But every time I compare the rips with my headphone the sound difference is there. How could this be? I did not make an ABX yet.


I think you should do the ABX test.  Try to remember a few-seconds-long passage of the recording which apparently sounded very different between the two rips. Then do an ABX test of this passage. Then you can see for yourself (without trusting us) whether there are really differences or whether your ears fooled you. Your audio setup seems excellent for that purpose.

Christian
If I don't reply to your reply, it means I agree with you.

CIRC & Jitter

Reply #9 –
Quote from: greynol on
You never told us exactly what you're listening to: tracks ripped from the CD or the CD itself.

If you're comparing tracks ripped from a drive using two different power cords that produce the same CRC then yes, you're completely imagining the differences since the files are identical.
I was listening to the tracks ripped from the CD - and yes, I compared that tracks.

Quote from: greynol on
FWIW, CRC and CIRC are two completely different things.  The former is a number that is used as a signature for data; it is not a codec.  The latter is a method of error correction which is implemented on the CD itself.
So that means, that the CRC values aren´t derived from CIRC but that they are simply a hash function. At least that part of my theory doesn´t work out.
marlene-d.blogspot.com

CIRC & Jitter

Reply #10 –
Quote from: C.R.Helmrich on
I think you should do the ABX test.  Try to remember a few-seconds-long passage of the recording which apparently sounded very different between the two rips. Then do an ABX test of this passage. Then you can see for yourself (without trusting us) whether there are really differences or whether your ears fooled you. Your audio setup seems excellent for that purpose.

Christian
I´ll do it. Along with the logs provided by EAC. And the sound difference seems to me to be overall. It´s as if someone tinkered around with the "Multiband Stereo Imaging"-tool in iZotope Ozone 4. I can´t explain it. There must be some faulty component inside my PC or my drive or something I´ve overseen. I don´t know... I´ll do an ABX next week.
marlene-d.blogspot.com

CIRC & Jitter

Reply #11 –
Quote from: Arnold B. Krueger on
(1) The original CDP 101 colored the sound in ways that were barely audible on occasion, because it used analog filters that intruded on the audio band, and because one channel output was slightly delayed from the other. In general it was sonically transparent, but in certain cases it wasn't.  It was ABX-able, as was published in the latte 1980s.
...
Again, I can cite several occasions where jitter does explain audible problems. It is just that they are not nearly as common as many believe.

Can you provide references for the claims above?

-k
 

CIRC & Jitter

Reply #12 –
Quote from: knutinh on
Quote from: Arnold B. Krueger on
(1) The original CDP 101 colored the sound in ways that were barely audible on occasion, because it used analog filters that intruded on the audio band, and because one channel output was slightly delayed from the other. In general it was sonically transparent, but in certain cases it wasn't.  It was ABX-able, as was published in the latte 1980s.
...
Again, I can cite several occasions where jitter does explain audible problems. It is just that they are not nearly as common as many believe.


Can you provide references for the claims above?


As far as jitter causing audible problems, I'm referring to those well-known cases where jitter causes data errors.

I've also done ABX tests with a test setup that stimulated jitter, but my results were in the same range as those published in the JAES by "Theoretical and Audible Effects of Jitter on Digital Audio Quality", Benjamin, Eric and Gannon, Benjamin.

As far as the audibility of CDP 101,

Masters, Ian G. and Clark, D. L., "Do All CD Players Sound the Same?", Stereo Review, pp.50-57 (January 1986)

and

well, I can't find the exact issue, but I wrote an article about ABXing and correcting the time-synch problem between the channels, in the mid-1980s for Audio Amateur.