![]() ![]() |
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
68.126.29.64
In Reply to: RE: JPlay and CPlay = garbage posted by Scrith on February 10, 2012 at 14:11:09
What is it about Friday on this Forum ??
Seems equivalent to:
" No - I said the Enterprise should be hauled away AS garbage ! "
PS There is no way you can win the "number of years programming" contest...
Follow Ups:
I'm not trying to win some "number of years of programming" contest (in fact, I'm sitting near a couple of guys at work who have more experience than me as I write this). :-)Just making a few comments about some programmers who seem to be making some claims that any experienced programmer would laugh at.
Edits: 02/11/12
And clearly you are not understanding the claims, because plenty of experienced programmers think differently.
In my case, there cannot be "placebo effect", because my preference is for all the players to sound alike, and then use a convenient and feature-rich free player like MusicBee.
But unfortunately, it is not true.
In case you have never read anything on the subject, "bit perfect" is not enough, because audio playback is real-time.
BTW, all this is tiresomely similar to the 1980s, amidst "all CD players must sound alike, bits is bits".
So... why exactly did you post about this. The author of cplay charges no money, and is anonymous, so he can't be as you describe, a "snake oil salesman".
From what we've seen so far, pre-requisites are:1. 20+ (30+ or 40+ even better) years of experience developing software, that doesn't have to have any relation to audio.
2. (preferably, but not necessary) Using crappy hardware, like analog outs of $120 soundcard, in a system with limited resolution.
3. (highly desirable) Hearing that is removed from perfect as far as posssible.
4. (MUST HAVE) Full mental block, that doesn't allow to hear any differences in sound quality, even if they are plainly obvious.
Edits: 02/13/12
> > > In my case, there cannot be "placebo effect", because my preference is for all the players to sound alike
Agree. In my case, I was really hoping Jplay *would* knock my socks off and yet I thought it sounded identical to foobar except for a minority of samples wherein it did seem to present just a bit more texture. So much for expectation bias.
> > > The author of cplay charges no money, and is anonymous,
Good point.
"BTW, all this is tiresomely similar to the 1980s, amidst "all CD players must sound alike, bits is bits"."
But, hey, it's been "scientifically proven" that all CD players do sound alike. :-)
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
I never claimed there was no sound difference, just that if you are hearing one it is the DAC's fault (because it can't deal with jitter in incoming data). I think you are much better off trying to find a DAC that isn't prone to such problems, rather than trying the nearly infinite combinations of software, hardware, cables, OS Settings, Audio Playback settings, drivers, and so on that makes your DAC sound best.
it is the computer's fault for producing jitter and destroying waveform integrity.
''just that if you are hearing one it is the DAC's fault (because it can't deal with jitter in incoming data)''.
"it is the computer's fault for producing jitter and destroying waveform integrity."
The data can always be reclocked so long as the jitter is not extreme. There is no basis for ascribing "fault" to a computer. It is a data moving device and as long as there is sufficient signal integrity that the data can be decoded the computer has done its job. Since the time between bit transitions on SPDIF is many ten's of nanoseconds there is no problem decoding signals with several nanoseconds of jitter. Looking at an eye pattern, the eye has to be clearly open, but it does not have to be anywhere near perfect. By contrast, the master clock in the DAC must have jitter below 10 picoseconds for full 24 bit accuracy. Given that a perfect signal created at the computer with zero jitter may still have several nanoseconds of jitter when it arrives at the DAC, it is absurd to place the blame on the computer for small amounts of jitter. The DAC will have to have excellent jitter rejection in any event so as to deal with the effects of the cable. If a DAC lacks this degree of jitter reduction then one can put a reclocker between the computer and the DAC. This is a band-aid in that the DAC will still have to deal with jitter introduced on the cable from the reclocker. Given that it is physically impossible to remove the jitter problem from the domain of the DAC, if "fault" is to be allocated, the fault must lie with the DAC.
With the typical SPDIF configurations, the DAC gets its clock from the computer, and thus it has to use a PLL or some other means to clean the clock. This is a poor architecture. Instead, if the clock starts at the DAC and goes in the opposite direction then there won't be any need for PLLs to clean the received clock. The DAC can work off its own clean local clock that has never had to traverse any noisy cables with limited bandwidth. If you use the juli@ with external clock you can slave the computer to the DAC and put the DAC in internal mode. Unfortunately, there may be two problems with this: (1) It will be a pain in the ass whenever the DAC sampling rate must change. Since the clock starts at the DAC some means will be needed to put the DAC at the proper speed. (2) most DACs are designed to work in both internal and external mode and may have designed their clocking to use common circuitry for both modes rather than have a separate clock circuit for each mode. I don't know how your various DACs deal with this problem when running on internal clock, but I do know that many proaudio DACs do not use a separate clean signal path for clock when running in internal clock mode.
The advantage of the async USB method is that it avoids the extra cabling of reverse clocking while still allowing the DAC designer to use a fixed master clock. In addition, the USB protocol allow the computer to tell the DAC the correct sample rate. Thus an async USB only DAC can avoid both pitfalls mentioned above. The unfortunate downside, however, is the baroque USB protocol. There will be a lot of digital logic inside the DAC that can interfere with noise critical circuitry, much more circuitry than needed for an SPDIF based DAC.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
a pointless open ended argument. DACs being dacs are what they are and cannot be perfect, Nor can computer audio outputs.
Your long posts on the subject adds nothing new.
Yeah, what he said.
Here's another simple example: if your hard drive generated errors that caused you to lose data sometimes, would you blame the computer, the OS, the driver, the I/O protocol, the brand of memory you are using, the cable, the software that was trying to write data to the hard drive, etc? Or would you blame the hard drive? Hard drives have MUCH more stringent data timing requirements than any audio device will ever require (you know, the part about writing bits to tightly spaced positions on a platter that is spinning at 10,000 RPM at rates that support speeds way beyond what even USB 2.0 is capable of).
The data corruption could be from the computer, especially from a bad power supply. Also, some data corruption could be caused by the operating system and might not be the fault of the drive, even though it might appear to be that way. Perhaps I'm just being the devil's advocate. But there is a point to my observation. If one stores two copies of one's data on two separate drives in the same computer one will not get the increased reliability that one might expect due to the possibilities I've described. If the two drives are in separate boxes and powered separately the data will definitely be safer.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
> just that if you are hearing one it is the DAC's fault
> (because it can't deal with jitter in incoming data).
Or noise on a signal or ground line in the case of USB.
> I think you are much better off trying to find a DAC that isn't prone
> to such problems,
I agree. A $ 150 DAC or even a $ 300 DAC can be forgiven some flaws. I'd expect more from a $ 2000 DAC.
> rather than trying the nearly infinite combinations of software,
> hardware, cables, OS Settings, Audio Playback settings, drivers,
> and so on that makes your DAC sound best.
Before they started tweaking computer audio, the same audiophiles were swapping interconnects, trying cable lifters and doing many other tweaks. Tweaking and hearing differences is the point of the hobby for some people.
Bill
So... why exactly did you post about this. The author of cplay charges no money, and is anonymous, so he can't be as you describe, a "snake oil salesman".
Well maybe he thinks he is a snake oil philanthropist??? :)
1. There is nothing but "data" up until analog stage of a DAC, and the only problem is to deliver that data bit-perfectly.2. Neither he, nor his wife, who is a musician, and has much better hearing than him, can't hear any difference whatsoever between pretty much anything at all in casual blind tests.
3. He has 20+ years of experience developing video games.
I say - he should've been a clown instead...
Edits: 02/11/12
Perhaps not - but 30 million copies is damn impressive.
Regards,
Geoff
If you look at this profile, the "software" is a video game.
Which, of course, still requires very significant programming skills, but is a lot easier to sell 30 million copies of. :)
I started programming in 1960. I wouldn't be surprised if a few inmates started earlier. I've met people who were programming in the 1950's. Video games started around 1960 but computers would remain too expensive for a mass market for another twenty years.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: