Crikey Carl what have you started!
😉
Hacker would just a like a recommendation as to what clock to use in his next diy adventure. I'd just go with the Tent Carl, you've used it before so do more of the same but again refine the P/S
Oh and ppm that'll be parts per million (i think). ****** all to do with 11.2896Mhz or any other frequency just a ratio of what drift is allowed. Its used in many sciences for example no more than Xppm of water must contain toxins. You guys need to check your water supplies 😉
😉
Hacker would just a like a recommendation as to what clock to use in his next diy adventure. I'd just go with the Tent Carl, you've used it before so do more of the same but again refine the P/S
Oh and ppm that'll be parts per million (i think). ****** all to do with 11.2896Mhz or any other frequency just a ratio of what drift is allowed. Its used in many sciences for example no more than Xppm of water must contain toxins. You guys need to check your water supplies 😉
We have been here before. It is generally agreed that under optimal conditions some trained musicians are able to detect a one cent change in pitch. At the absolute limit of the above claimed ability, a 1 in 500 change is 3.4 cents. 1 in 70 is 25 cents - or a quarter semitone. Which is pretty easy for many musicians.
A 100ppm change in tone is 0.173 cents. Almost 20 times less than the absolute upper limit of the claimed 1 in 500 detection, and nearly 6 times better than the generally accepted best ever detection for musical pitch shift.
Not that this seems to matter a great deal - the reference frequency for musical pitch has moved quite a bit over time. The reference pitch for A has varied from historical lows of 390Hz to highs of 455Hz before being settled on 440Hz in modern times. Even discounting the rather anomalous 390Hz, variations between 436Hz and 455Hz were common. That is 73 cents, or almost three quarters of a semitone. Worrying about the accuracy of a CD player's clock in this context is clearly a waste of time.
A 100ppm change in tone is 0.173 cents. Almost 20 times less than the absolute upper limit of the claimed 1 in 500 detection, and nearly 6 times better than the generally accepted best ever detection for musical pitch shift.
Not that this seems to matter a great deal - the reference frequency for musical pitch has moved quite a bit over time. The reference pitch for A has varied from historical lows of 390Hz to highs of 455Hz before being settled on 440Hz in modern times. Even discounting the rather anomalous 390Hz, variations between 436Hz and 455Hz were common. That is 73 cents, or almost three quarters of a semitone. Worrying about the accuracy of a CD player's clock in this context is clearly a waste of time.
Francis_Vaughan said:
Well, clearly not! As all the debate, over whether clock jitter matters, testifies! The brain may not be able to detect a change in pitch but it can detect minute other changes which affect perceived positional/spacial information.
The point I was tying to make earlier is:-
If the data rate is not at the clock frequency, would the effect be similar to the results of async. reclocking?
If we have reached the ultimate in aftermarket clocks, should the next step in 'Clock Wars' be ensuring that the data rate is 'tied' to the clock rate ie a master clock?
I think you are missing the point. We all agree jitter - or phase noise - is a critical problem. What has just been discussed is that the red book spec of 100ppm clock accuracy is not the right specification. It ensures a vastly better than needed pitch accuracy, and yet specifies nothing at all about jitter. You could have a CD player that has perfect pitch, with clock accuracy in the 1ppm regime, that still has dreadful jitter. The frequency accuracy specification says nothing about the manner in which the clock accuracy is measured, and in general it is understood that it is a simple frequency measure - i.e. one that is measured over a significant time, and hence averages out any phase noise.
This argument goes round and around like this. Jitter seems to be misunderstood on many fronts. There were a couple of lads a while ago that seemed incapable of understanding that jitter was not a constant delay in the clock. And on the other front people who misunderstand that jitter is not the same as a frequency inaccuracy.
Jitter can be understood as modulation of the phase of the clock. (Hence the term phase noise.) The spectrum of energy in that modulation is of critical import. And of even more significant import its correlation with the audio signal that the digital stream is conveying.
This argument goes round and around like this. Jitter seems to be misunderstood on many fronts. There were a couple of lads a while ago that seemed incapable of understanding that jitter was not a constant delay in the clock. And on the other front people who misunderstand that jitter is not the same as a frequency inaccuracy.
Jitter can be understood as modulation of the phase of the clock. (Hence the term phase noise.) The spectrum of energy in that modulation is of critical import. And of even more significant import its correlation with the audio signal that the digital stream is conveying.
Donald Duck
Hey poynton, the speed of the CDP is proportional to the clock frequency. I once installed a 33.8684MHz clock in my Sony and it sounded like Donald Duck (double speed). Please don't confuse jitter (=speed variations) with speed accuracy (=pitch). Jitter gives rise to reading errors, hence distortion of the original signal. See Kusunoki for an explanation:
http://www.sakurasystems.com/articles/Kusunoki.html
The data rate is already "tied" to the masterclock, that's how the thing works. Bringing up asynchronous reclocking is confusing the reader😎
poynton said:
Hey poynton, the speed of the CDP is proportional to the clock frequency. I once installed a 33.8684MHz clock in my Sony and it sounded like Donald Duck (double speed). Please don't confuse jitter (=speed variations) with speed accuracy (=pitch). Jitter gives rise to reading errors, hence distortion of the original signal. See Kusunoki for an explanation:
http://www.sakurasystems.com/articles/Kusunoki.html
The data rate is already "tied" to the masterclock, that's how the thing works. Bringing up asynchronous reclocking is confusing the reader😎
I'm not sure I really understand the question. Reclocking is a very complex issue. Simple reclocking would sound dreadful - it would of necessity involve either dropping or duplicating samples. So it is never done. Proper reclocking is termed resampling. That involves a very long filter with parameters chosen on the fly to match the clock rates. (Or at least that is one way of looking at the problem - there was a wonderful explanation of this in another thread a while ago.) Very interestingly a resampler fed with a good quality clock is capable of acting as a very effective jitter remover.
Sorry - I was not very clear!
To quote Kusunoki :-
'The real problem is the constant fluctuation of the time axis caused by PLL. ......we can still hear the different characteristics of transports. '
Can this be improved?
If we have reached the limit of DAC clock development, surely the 'source' of the data is the next target?
To quote Kusunoki :-
'The real problem is the constant fluctuation of the time axis caused by PLL. ......we can still hear the different characteristics of transports. '
Can this be improved?
If we have reached the limit of DAC clock development, surely the 'source' of the data is the next target?
Francis_Vaughan said:
Ah yes, the longest ever advert in favour of using the ASRC for jitter removal. There are alternatives.
I guess it is to some extent a matter of semantics. And one of degree. What Kusunoki is complaining about is almost what we used to call flutter. But he is also complaining about the implementation of the PLL, not the principle. A PLL is a low pass filter, and it filters out timing variations. But if you set the filter period too high it will admit some level of low frequency frequency variation. That is a designer's problem. Look at Guido Tent and Co's DAC, it has an aggressively low filter value. For good reason. The counterpoint to an arbitrarily low value is that the PLL won't lock in an acceptable time. Where acceptable is typically defined as soon enough that the user won't notice. So it is never easy. (But even here there are techniques to help.) Also, too low a value and the PLL won't track any variations in speed, and will end up dropping, or being starved of, samples. But transports should be themselves crystal controlled, so this extreme level of variation should never happen, unless they are broken.
But the alternative has been known for ages. Slave the transport from the DAC. There are many proprietary two box solutions (heck, Guido even sells his own solution) and many other one box CD players are smart enough to slave the transport. Even my ancient Sony CDPX-777ES does this.
The matter of semantics is one of where jitter ends and frequency error starts. Personally, and with no idea what any official definition would be, I would say that as soon as the phase error exceeds 2 pi radians it is no longer jitter and has become a frequency problem. However even here there is weasel room, because I have not specified how long a time I am prepared to wait for that error to accumulate. For a useful definition in audio we need to refer back to the human auditory capabilities. It may simply be useful to say that if the error is perceivable as a tone shift, or phase shift in a tone, then it is frequency error, if it is perceivable as energy in its own right in the audible range, then it is jitter. There is of course a range where the energy is neither. Which is why knowledge of the spectral distribution of the energy is so crucial.
I think getting a pure enough clock is close to a solved issue. What is not solved is maintaining the purity right through the remainder of the DAC.
Accuracy of the clock in the recording chain is of course an entirely separate issue. As is the quality of any part of the recording chain. Read some of the reviews about how new ADC systems in the studios quite superior to the old gear, and then realise all your old recordings are by definition now inferior, as will be your listening experience from now on. And you can't do anything about it.
But the alternative has been known for ages. Slave the transport from the DAC. There are many proprietary two box solutions (heck, Guido even sells his own solution) and many other one box CD players are smart enough to slave the transport. Even my ancient Sony CDPX-777ES does this.
The matter of semantics is one of where jitter ends and frequency error starts. Personally, and with no idea what any official definition would be, I would say that as soon as the phase error exceeds 2 pi radians it is no longer jitter and has become a frequency problem. However even here there is weasel room, because I have not specified how long a time I am prepared to wait for that error to accumulate. For a useful definition in audio we need to refer back to the human auditory capabilities. It may simply be useful to say that if the error is perceivable as a tone shift, or phase shift in a tone, then it is frequency error, if it is perceivable as energy in its own right in the audible range, then it is jitter. There is of course a range where the energy is neither. Which is why knowledge of the spectral distribution of the energy is so crucial.
I think getting a pure enough clock is close to a solved issue. What is not solved is maintaining the purity right through the remainder of the DAC.
Accuracy of the clock in the recording chain is of course an entirely separate issue. As is the quality of any part of the recording chain. Read some of the reviews about how new ADC systems in the studios quite superior to the old gear, and then realise all your old recordings are by definition now inferior, as will be your listening experience from now on. And you can't do anything about it.
Asr
Hi Francis,
thanks for your patient and good explanations. I no longer have the spirit for that, after so many years here.
I do not agree however that simple reclocking is sounding awfull. My Asynchronous Reclocker with synchronizer does not loose samples and has no dropouts due to metastability problems. Why and how it works is not very clear to me: good results with AD1865 and TDA1541 but not so good with TDA1543, all NON-OS.
😎
Francis_Vaughan said:
Hi Francis,
thanks for your patient and good explanations. I no longer have the spirit for that, after so many years here.
I do not agree however that simple reclocking is sounding awfull. My Asynchronous Reclocker with synchronizer does not loose samples and has no dropouts due to metastability problems. Why and how it works is not very clear to me: good results with AD1865 and TDA1541 but not so good with TDA1543, all NON-OS.
😎
With some controllers you have to tell it that you use a 33.8688 instead of 16.9344. And some even include pitch adjustment (CXD2550)
DragonMaster said:
hi DragonFighter,
The 33.8684MHz clock was only inserted in my Sony for testing purposes. It was NOT meant as a serious application in that machine as it uses 16.9344MHz.😎
Hacker said:
Buy a Tent module and be done with it. It is inexpensive as these things go, easy to fit and I'd wager it is at least 95% as good as the rest and for a lot less money.
Re: Re: Re: The 'best' performing clock?
Most definitely. On unit to unit consistency for one, I'd say it has an example or two knocked into a cocked hat.
Elso Kwak said:
Most definitely. On unit to unit consistency for one, I'd say it has an example or two knocked into a cocked hat.
rfbrw said:
You don't want to know how many times guys have tried to insert Guido's "crystal" in my clock. Not sure if they were all photographers.
- Status
- Not open for further replies.