[sejarzo]

Quote:

Originally Posted by Herandu /img/forum/go_quote.gif In such a situation it would be reasonable to assume that error correction is at its minimum. Unlike analogue, a sine wave on a CD is not a continuous string of data on the disc. The actual data that makes up the sine wave is spread over a number of data blocks. It's this spreading out of the data that makes it possible for error correction. I don't know of any simple method to measure when error correction kicks in. What I have used as a guide to how much more error correction comes into play is by judging the eye pattern from the laser pick-up. A nice clean pattern means less errors being registered. That's why I recommend 3 beam laser pick up players. They are less error prone. There is a very informative article here that explains it better than I ever could.

So, do I take it correctly that if the eye pattern is fuzzy, that likely means several hundreds of samples per second or more are likely not being read correctly, so error correction must process them before being sent to the DAC...and not all of them are entirely "correctable"?

Seems to me that is a real indictment of the entire "on the fly" scheme, and that any serious audiophile should be convinced that hard drive based playback will be superior beyond any doubt, once a few final kinks are worked out (to provide a universal hardware/driver system more robust and less limited than the current USB Audio standard, eh???)

 

[little-endian]

Quote:

Originally Posted by sejarzo /img/forum/go_quote.gif So, do I take it correctly that if the eye pattern is fuzzy, that likely means several hundreds of samples per second or more are likely not being read correctly, so error correction must process them before being sent to the DAC...and not all of them are entirely "correctable"

No, luckily this isn't the case and is rather complete nonsense. As long as the "eye pattern" isn't so "fuzzy" that uncorrectable errors occur at the C2 stage, you'll end up with exactly the same user data. In the case of audio it consists of 2352 bytes every 1/75 second. Everyone is able to prove this my oneself with a decent pc-drive and some knowledge.

Whether the same data delivered over different paths (s/pdif for instance) can lead to a different sound, due to jitter, is controversily discussed. When it comes to the data per se though, there is no doubt but assurance.

 

[sejarzo]

Ah, with that username, then, little-endian, you may be able to give me my answer that I have been seeking for literally years, which no one seems to want to quantify. It seems as if everything I find is either too simplified and not quantitative, or is way over on the other end, presuming a great degree of EE knowledge.

So, if we have a "better than average" transport, in good condition, playing a disc in as-new quality, how often does error correction typically kick in? Is it hundreds of times per second? Or once per hundred seconds? Somewhere in between?

Seems to me that this answer should be readily available, but for some reason, I've never hit on the right keywords in my searches.

 

[Alanbass1]

Quote:

Originally Posted by OverlordXenu /img/forum/go_quote.gif Honestly, I think this whole paranoia over jitter is a crock of BS (a good DAC will correct for it), but copying is very different from playing real time. Using EAC in secure mode, with everything correctly set (and there is nothing better than EAC...), it reads the disk over and over again, correcting errors (to a point, of course). For me, a CD in good condition takes about 20 minutes to rip via EAC, while encoding to FLAC at the same time.

I disagree. A friend of mine was raving about the effects of having his Marantz CD63SE upgraded with a Trichord Clock:

http://www.trichordresearch.com/clockworks.html

When I listened to his player it did sound extremely good and I hadn't recalled ever being that impressed by his system before, but that was his player in his system...... Anyhow, due to too much money and not the equivalent amount of sense, I embarked on another round of upgraditis and got a loaner Mark Levinson 39 CD player from my dealer which I A/B'd with my Meridian 508 in my home for three weeks. The Mark Levinson had better soundstage and timing and I was convinced enough that the improvement was worth the investment so I purchased it.

So, I had my Meridian 508 player demoted to the living room system and thought why not have it fitted with a Trichord Clock whilst the Naim player it was replacing in that system was going through the motions of being sold. It came back from Trichord and I thought I give it the A/B treatment in my main system against my new pride and joy, the Mark Levinson. I was advised by Trichord that the clock needed a 100 hours or so of burn in, but I couldn't be arsed to wait so went straight ahead and.....it sounded better than my Levinson.

But my Levinson was only three weeks old and still obviously burning in. However, after a month the 508 with the Trichord clock was the one getting noticeable better with usage and making what was a subtle improvement to my ears into a more marked one...and I so wanted my Levinson to sound better. I spoke to my dealer who came round with the demo unit I borrowed for the three weeks trial and, when a/b'ing against my clock'd 508 he also preferred the Meridian - the most noticeable improvement/difference being the soundstage. I was fortunate enough that he took the Levinson back (although he did charge me 15% as he had to sell the unit as a demo example). I could have got the Levinson clock'd I guess, but the thing is that the clock'd 508 was a CD player that, for the first time, I preferred listening to than my Rocksan Xerxes/Artemiz/Shiraz combination.

Just my experience, but one that convinced me that transport quality is critical.

 

[fjf]

Quote:

Originally Posted by OverlordXenu /img/forum/go_quote.gif Honestly, I think this whole paranoia over jitter is a crock of BS (a good DAC will correct for it), but copying is very different from playing real time. Using EAC in secure mode, with everything correctly set (and there is nothing better than EAC...), it reads the disk over and over again, correcting errors (to a point, of course). For me, a CD in good condition takes about 20 minutes to rip via EAC, while encoding to FLAC at the same time.

Well, EAC reads in 20 min a 74 min CD...meaning that it can be done securely at more than 3x. If the reading is that fast, the timing (having a quartz clock) cannot be a problem. I am not saying there are no problems transforming digital to analog. I am sure there are a lot. But the usual jitter talk is too often used to explain just the postprocessing of the digital signal to an analog out that is pleasant, sweet, and not cold and edgy. That where engineering is, I think. The reading and writing digital was solved long ago, and that's why we have computers at home working successfully, transferring digital data through internet from/to our hard drives and DVDs all over the world.

 

[infinitesymphony]

Quote:

Originally Posted by fjf /img/forum/go_quote.gif Well, EAC reads in 20 min a 74 min CD...meaning that it can be done securely at more than 3x. If the reading is that fast, the timing (having a quartz clock) cannot be a problem...But the usual jitter talk is too often used to explain just the postprocessing of the digital signal to an analog out that is pleasant, sweet, and not cold and edgy.

It's already been pointed out that computer drives and the mechanisms employed in audio players are not the same, so there's not much reason to compare them. What does fast, asynchronous reading prove about a device's ability to send synchronized timing signals?

Jitter has nothing to do with the actual D/A conversion, it relates to either the reading of the CD (doubling or skipping of audio samples), or timing errors in the reception of the digital information from transport to source.

 

[ezkcdude]

I don't know why you guys are talking about EAC - that confuses the issue. The topic is about CD transports, right? A CD-ROM device is a completely different monster, which was originally designed to read data - not music. Obviously, when you buy Microsoft Word (heaven forbid) on a CD-ROM and install it, you expect every bit to be copied correctly, right? It probably wouldn't work otherwise. Same for music CD's, except sometimes they are scratched, and need true error correction. But copying the files from a CD, and playing a CD in a music system - in real time - are two different things, as was pointed out above (probably by more than one person). Does jitter matter with EAC or CD-ROM? No, that's ridiculous. Does it matter with playing a CD in a CD player and extracting the SPDIF signal? It may or may not, but that should be the topic of this debate - not error correction.

Edit: Infinite - you beat me to it. Argh.

 

[AS1]

Quote:

Originally Posted by ezkcdude /img/forum/go_quote.gif But copying the files from a CD, and playing a CD in a music system - in real time - are two different things, as was pointed out above (probably by more than one person).

Yes, but does it really matter?
If you rip a song from a cd, the laser won't go back to re-read and still the resulting wav file will always be the same.
If you would rip that song *realtime*, I'm sure it will be the same result again and again.
I believe it's a non-issue.

 

[ezkcdude]

Quote:

Originally Posted by AS1 /img/forum/go_quote.gif Yes, but does it really matter? If you rip a song from a cd, the laser won't go back to re-read and still the resulting wav file will always be the same. If you would rip that song *realtime*, I'm sure it will be the same result again and again. I believe it's a non-issue.

Your comment leads me to believe you still don't understand the problem we are discussing: Jitter. I think you are referring to error correction. Do you understand the difference?

 

[little-endian]

Quote:

Originally Posted by sejarzo /img/forum/go_quote.gif So, if we have a "better than average" transport, in good condition, playing a disc in as-new quality, how often does error correction typically kick in? Is it hundreds of times per second? Or once per hundred seconds? Somewhere in between?

Oh nice - may the username help me with the explanation then.

Your question is eligible but instead of "how often does error correction typically kick in?" you should ask "which error correction kicks in at all?". This is because it is a fundamental fact that - when seen over a longer distance or time - errors always occur. Every transfer or storage suffers from degration per se - with the difference that digital information (which only exists on a logical level, btw) is immune within a certain tolerance. The CD is no exception here. The read-out process could be called pretty analog (high frequency signal which occurs from the laser-beam reflection) and at the raw level the thereby reconstruced digital data will always contain errors. The stated typical error rates for the raw data vary from 10^-5 to 10^-6 which means up to 1 error every 100000 bits. Assuming a data rate of about 4 MBit/s you can count on 4~40 errors per second (!) when everything is in good shape while up to > 200 may be corrected by CIRC in the worst case. Since there are several "levels" of error correction, it is always the question at which of them which amount of errors occur. The exact number of raw levels errors which a pickup-system is able to correct depend on its implementation of decoding and correction in detail. E32-errors (up to three symbols at the C2 stage) exceed the correction capabilities of most devices that will then perform error concealment.

So maybe you see the point. One has to strictly distinguish between error correction and error concealment. Whereas the first one is mandatory and fundamental for every digital system, the second one is the last step if every other actions failed. At this point, the player tries to mask the error as good as possible. There are also differences in the implementation. Someone has tested a few devices in this regard. If you're interested, i'll post the link.

To return to your basic question: When a disc is in good condition and a transport which merits the name, there will be always errors, especially coming out of the C1-decoder. Bear with it because C2-errors normally don't occur. If they do, something already has gone wrong. You can verify this by yourself by recording the s/pdif output of any decent player and then comparing the result with that what you get via digital audio extraction. After correcting the offsets (starting points) there will be no differences if the player's output is bit perfect (not all are which is a real shame).

For further information in regard to cd technology i can highly recommend you the book "The Compact Disc Handbook" by Ken C. Pohlmann.

A note at the end: Different players may sound different due to internal jitter and different DACs used while different transports may let an external DAC sound different due to the jitter of the signal path. As long as the data is correct, there is no direct conjunction between the drive and the sound.

I hope i could bring some light into the dark of myth and confusion.

Quote:

Originally Posted by infinitesymphony /img/forum/go_quote.gif It's already been pointed out that computer drives and the mechanisms employed in audio players are not the same, so there's not much reason to compare them. What does fast, asynchronous reading prove about a device's ability to send synchronized timing signals?.

Actually they differ not that much some here seem to think. Of course, pc-drives are more advanced and thus likely proner to faked errors some commercial cds make use of (like screwed-up session pointers which would be ignored by simple single-session devices like stand-alone cd-players) but when playing an audio-cd, a pc-drive behaviors the same like any audio-cd-player whereas its error concealment strategies may be different. Please note that the conversion timing is uncoupled from the actual reading process as well (catchword: FIFO). Sure you're right - the process is more "realtime" here and thus more sensitive to dropouts and errors since there's still not the time for much (if any) retries.

Quote:

Originally Posted by infinitesymphony /img/forum/go_quote.gif Jitter has nothing to do with the actual D/A conversion, it relates to either the reading of the CD (doubling or skipping of audio samples), or timing errors in the reception of the digital information from transport to source.

If think you're mixing up things here. When it comes to the actual D/A conversion (still assuming the data per se is intact), all if anything that has to do with it is jitter. The skipping or repeating of audio samples (and unloved behavior of early drives) acutally has nothing to do with the term "jitter". Although in use, this naming is a somewhat unlucky choice for it and increases the confusion already present even more.

Quote:

Originally Posted by ezkcdude /img/forum/go_quote.gif Does jitter matter with EAC or CD-ROM? No, that's ridiculous.

Very interesting statement you gave here. And you're right. Of course it is ridiculous. But why is it ridiculous?

Latently, you seem to recognize the fact that the timing of the copying process can't have any impact to the actual data because the destination (in most cases it will be a hdd) won't care about delays since the data is reclocked anyway when reread. Good point and you are correct. But why do you guys think different when it comes to sending the same data to an external DAC? It is exactly the same with the difference that the actual realtime process starts within the DAC (in fact, s/pdif is a realtime interface as well but the data is allowed to be reclocked anyway regardless of this detail).

Jitter of a transport system may lead to audible differences. I can't say much about it since i never heard any jitter artefacts so far. However, trying it the fix it on the source is the wrong way.
Thus my suggestion is: Use any source which is just able to provide you the correct data in a timing which still makes it possible for a receiver to recognize and spend all the effort into the DAC.

Regards,

little-endian

 

[parrot5]

Quote:

Originally Posted by AS1 /img/forum/go_quote.gif Yes, but does it really matter? If you rip a song from a cd, the laser won't go back to re-read and still the resulting wav file will always be the same. If you would rip that song *realtime*, I'm sure it will be the same result again and again. I believe it's a non-issue.

In EAC's log, whenever you see a track's quality is not 100%, EAC made attempts for error correction/re-reads.

A more obvious example: For data files, CD-ROM drive in the computer will make multiple attemps to re-read the parts that it can't read on the first try. When you verify a badly-burned CD, at the sector that it can't read, you can hear your cd-rom's motor spinning up and down (and maybe clicks too), those are attempts to read the data again.

Another example: I've got a program CD that sometimes won't install successfully, saying the disc cannot be read. Then I use a dedicated disc image creation/burning program to rip the CD. It took a long time (3 hours), but the process finally completed. I then burn the image to a new CD and then the program can be installed.

Yet another example: For data copying, the computer attempts to do re-reads automatically, without telling you. It is only after a certain number of trials and it still fails, then it will tell you.

Lesson: Sometimes when real-time reads fail, re-reading helps. Though I think I'm stating the obvious.

So, I believe that yes, sometimes when ripping songs to a CD (or copying data), re-reads do happen, contrary to your belief.

 

[ezkcdude]

There are two ways to ameliorate jitter: reclocking at the DAC, or routing a high quality master clock back to the transport. Either way, it's all about the quality of the clock - you know, like a comedian - it's all about timing. I am not a jitter alarmist! I think reclocking at the DAC, for example, using an ASRC (as my ezDAC does), is just about the best solution readily available, and will probably make the differences between different transports minimal. Having said that, I was always taught that it is dangerous to use absolute terms like never, none, no difference, etc. Get my point? Ok, now I will violate my last statement

There is no perfect clock, so we can not ever eliminate jitter completely! Does that means it is audible? I have no idea. The burden of proof lies with those people who claim that jitter is audible. I'm just saying - to be technical about it - jitter cannot be removed 100%.

If you want to hear this from someone who knows more than I do, read this thread over at diyaudio:
http://www.diyaudio.com/forums/showt...675#post332675

 

[sejarzo]

Quote:

Originally Posted by little-endian /img/forum/go_quote.gif So maybe you see the point. One has to strictly distinguish between error correction and error concealment. Whereas the first one is mandatory and fundamental for every digital system, the second one is the last step if every other actions failed. At this point, the player tries to mask the error as good as possible. There are also differences in the implementation. Someone has tested a few devices in this regard. If you're interested, i'll post the link.

Thanks for clearing that up. When I have asked EE friends about that, they didn't bother to ask me what I was asking about--the correction or concealment.

What I was asking about is really error concealment, and how often that occurs with a good transport and disc.

I'd be very interested in reading the info if you would kindly post the link!

 

[infinitesymphony]

Quote:

Originally Posted by little-endian /img/forum/go_quote.gif If think you're mixing up things here. When it comes to the actual D/A conversion (still assuming the data per se is intact), all if anything that has to do with it is jitter. The skipping or repeating of audio samples (and unloved behavior of early drives) actually has nothing to do with the term "jitter". Although in use, this naming is a somewhat unlucky choice for it and increases the confusion already present even more.

I guess I was visualizing the D/A conversion as taking place only inside the DAC, with the clock acting as a separate system (even though they're connected).

I have a question that when answered may clarify a lot of things for a lot of people

... Where is jitter created? It's been attributed to a lot of different sources: clock quality, cable quality, DAC quality, drive/lens quality, etc.

 

[AS1]

Quote:

Originally Posted by parrot5 /img/forum/go_quote.gif So, I believe that yes, sometimes when ripping songs to a CD (or copying data), re-reads do happen, contrary to your belief.

Yes it does happen. That was BS from me, sorry.