|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
I wonder why all those golden minded engineers in audiophile oriented CDP developers can't implement very straight and simple idea absolutely removing any jitter (intrinsic to CDP).We read the whole CD revolution to some buffer and then simply pull data out using super stable, temp-compensated but still very low-priced quartz generator (powered if you'd like from separate power source). So we do not have to regulate revolution speed in order to get correct bitstream frequency and hence remove this 'feedback' jitter. The only drawback of this technology is that we are reading CD faster than 1x (8..16x should suffer). But that no big deal if you take a look at those huge numbers written on your PC CDROM drive.
Is there such CDPs on the market?
Best regards,
-up
Follow Ups:
It was done by Technics for one (or some) of the first-generation MASH designs. The time frame was probably around 1990, perhaps a bit earlier.Yes, it was effective. OTOH, a Technics designer mentioned to me that it sounded considerably better again when the drive and servo electronics were completely turned off, so it would seem that the issue is a bit more complex than simply using a RAM buffer.
Today, I believe that the Chord DAC includes a RAM buffer and a free-running clock, and so does the Meridian. They sound quite decent. :-)
"uper stable, temp-compensated but still very low-priced quartz generator (powered if you'd like from separate power source)"Seems expensive. At least, when you do it good enough to effectively
avoid jitter.
KDS packaged oscillator "DSO751S".
Fighting jitter is not solely about selecting a nice crystal. It goes much deeper than that.
"Fighting jitter is not solely about selecting a nice crystal."
Meridians 588 player uses a DVD-ROM that reads the CD multiple times. The 588a also use a triple memory buffering and re-clocked scheme.
the Meridian approach sounds cute, but over $2500?The mecahnisms that let you do this cost $25, a memory buffer to hold ALL of the CD's data and then some probably costs $100
What's so expensive about the software? EAC (a freeware CD copy program) can do all this as well, but not in real-time of the CD does have read issues (it reads some sectors up to 50 times to make sure it gets the best extraction)
Playing a WAV file from a computer hard drive is a no-jitter issue - so why not just build a PC to do all this, run it through the SPDIF out and plug it into a fancy DAC?
Combining all this in a turnkey little box seems to be where the markup comes in, but hey - you can do this at home with your obsolete PC - all it needs is really large hard drives to store your favorite CDs in no-jitter WAV format.
I guess it is the convenience factor, since a PC will most likely have drive noise and fans humming - keeping your playback device in another room is a pain (but not impossible with a long SPDIF cord and a laptop in the listening room to remote control the "audio server"
ah - geek stuff :)
"Playing a WAV file from a computer hard drive is a no-jitter issue "Really?
take a look at the "technology" link on the page belowit reads the audio up to 82 times before it decides what to stuff into the wav file.
Playing data off a computer file system is a rather different affair, and none of the issues that EAC addresses are relevant anymore.
The only thing that remains is to convert digital to analog, and that can be done in an external DAC just like with any other CD player.
HowdyActually I'm pretty sure Werner knows exactly where you are coming from.
The issue is that even with perfect data in a buffer it's not that easy to achieve a low jitter output. Anyone who thinks it is will either learn different as they try or make a million bucks :)
good for Werner that he knows so much. He's also so liberal in sharing knowledge that I am just about ashamed for even opening my stupid mouth with the few things I know about this. I better go back home and burn my CD player and get back to analog where I don't need to worry about perfect data in buffers.
I am very short on time these days.These things have been explained here for about 1025 times. PLease
do a search on postings by the jitter masters like Guido Tent
en Elso Kwak.As for going back to analogue: please feel free to do so, as
I am in the turntable business, among other things :-)
HowdyI could have been a little more diplomatic about pointing out that getting perfect data into a buffer is only half the battle.
I didn't mean to demean you or be an apologist for Werner's terse postings. Never the less your post was dismissive of his knowledge. Many of us don't take the time to explain ourselves as well on the Nth thread on a subject as we might have on the first couple.
Me thinks you didn't understand what I am saying because you have no idea what EAC does.once the file is in WAV format, none of the transport related "jitter" matters anymore, and a program like EAC can totally take the transport out of the equation, all on a $25 CD-ROM drive.
Yes, Meridian players are not cheap, but compared to many other high-end cd-players they are not that expensive. You can try and build one your self, but it will not be that easy and cheap to reach that level of performance.When it was time to upgrade my Cambridge cd6 I tried a lot of different players in the 1000-2000$ range, but it was not until I encountered the Meridian that I found something that I felt was worth changing to.
Stereophiles review of the 508 also showed that it had very low jitter for its time, and really good measurements performance overall, so it is safe to say that Meridian knows what they are doing.
And 10 power sources and many more.What you are saying is that these people getting 2000% income per each sale can't implement simple buffer/reclock scheme?
I think they simply do not want. Because such CD-transport stops all further talks on "source quality" and leaves source developers with no chances of hitting the market...
I believe that physics (not magic) rules the world. And buffer/reclock removes ABSOLUTELY all influence of drive/power-cords/CD-tweaks etc.
I don't know if they manage to completely remove jitter though.
To completely remove jitter is probably impossible. The question is if they can make it so small that it is almost impossible to even measure it.
I have been experiencing a very weird problem with many CDP, DVD and SACD players. All the 50 or more players that I have tried will sound different depending on how the track is selected. Lately I am beginning to suspect that the jitter I hear is inherent in the discs itself due to the subcode data that are encoded alongside the audio data. Stereophile article by Harley briefly mentioned this.Even the much touted memory buffer and reclocking technique employed in the Pionner VSX-A10i's IEEE 1394 receiver has failed to eliminate this problem.
See my prevous posts on this subject:http://db.audioasylum.com/cgi/m.pl?forum=hirez&n=134771&highlight=jeromelang+downside&r=&session=
http://www.audioasylum.com/forums/dvda/messages/4611.html
http://www.audioasylum.com/forums/hirez/messages/137391.html
One problem is that many enginners and reviewers still have not been fully exposed to this problem. Those that might have, may lack the enginnering and financial resources to address this problem as it is an intrinsic problem with the whole optical disc retrival system itself. I have been told by a trusted source that the Ed Meitner new DAC has been able to solve this problem quite successfully. Ole Lund Christensen has also promised to address this problem in his upcoming SACD player.
Here're the links:
(a possible explanation that attribute the jitter problem to transport designs)
http://db.audioasylum.com/cgi/m.pl?forum=hirez&n=107423&highlight=ole+swingarm&r=&session=(discussion on possible remedies)
http://db.audioasylum.com/cgi/m.pl?forum=hirez&n=112822&highlight=ole+swingarm&r=&session=
Feedback jitter is induced by "spin faster"/"spin slower" commands.
The good Dr. claim to be an engineer who is working at a semiconductor company developing 1394 equipment, and that he has a test bed where he can capture 44.1/16 PCM bitstreams directly from a Pioneer DV-47Ai(same model as DV-S755Ai) 1394 link.He completed some tests that he and I agreed upon. Test disc was CCR Cosmo Factory, CD layer of the SACD. Test track was track 9, Who'll Stop the Rain.
He made 3 captures from the 1394 link of the DV-47ai:
1) From the stop state, hit button 9 on the remote. Capture 8
megabytes or about 47 seconds of bitstream.2) From the stop state, hit button 9 on the remote, then wait
11 seconds and hit track repeat.3) From the stop state, hit button 8 and let this track play.
Then start capture at the last 7 seconds of track 8 and the
first 40 seconds of track 9.Results:
Same bits every time.
His contention is that if his "fc /b" program in a DOS window is showing that the same bits are delivered for each iteration in a captured bitream data, the bitstream was exactly the same each time, irregardless of how the tracks were being sequenced, then for all intend and purposes, it would be jitter free and there should be no audible differences.
That still doesn't explain why I am still hearing the problem in the Pioneer combo though.
Did this guy just measured the wrong things perhaps?
Frankly, the measurements he had made did not surprise me. Jitter does not usually change the data. It only corrupts the clock or timing of the data. So it will not show up on absolute measurements of bits. He would need to do a specific jitter measurement or capture the data stream (and clock) on a digital oscilloscope, for example.
The timing information must be viewed. The reason jitter causes sonic problems is not because of changed data. It is because DACs can be negatively affected by jitter, causing compromised performance or data CONVERSION errors. A DAC's analog output can be degraded by jitter in terms of added noise, distortion or in extreme cases, conversion errors.
If we were to repeat the measurements using a high speed digital storage oscilloscope and compare the amplitude versus time data (waveform), we might see differences. Note this is the same way an analog signal is being measured, just much, much faster. If the differences in the waveforms are significant, you will get differing sound out of the DAC. Bit for bit measurements would show only huge data errors, unlikely to be caused by jitter.
Regarding 1394. Some designers like Ed Meitner have decided against using it for several reasons:
1. the clock is integrated within the data stream and is NOT discrete;
2. recovering the signal and clock from 1394 is a VERY difficult and complicated process where there is ample opportunity to screw it up
If digital transmission to the DAC uses an embedded clock the only way to deal with the Jitter issue would be to throw away the clock and re-clock the data using a newly generated clock signal. Then there are also some other protocol in the pipeline like the Super-MAC, which is said to be superior in every way over 1394, and a whole lot simpler.
Within a couple years, HDMI will probably replace 1394 anyway. But that's probably worse and we'll still have to content with the jitter issue as the audio, timecode plus video data will be meshed through one single cable.
Assume spindle speed commands affect jitter (and I think they do in ALL CDPs that do not have giant buffers for 5-10 sec of PCM).Revolution speed is different if CDP comes to the track from previous one / from far away track / and from +12 sec offset. When playing near outer edge of the disk spindle rotates slower and that's why spindle-speed-control should seriously adjust speed on seek to the inner edge. Maybe this process of revolution speed adjusting has some resonances or oscillations in nature resulting in jitter anomalies.
This post is made possible by the generous support of people like you and our sponsors: