|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
70.181.190.237
Today I listened to JRiver beta for OSX. It sounded very good playing PCM and DSD. The program imported my DSD library with no issues, and unlike Pure Music and Audirvana Plus, I didn't have to use the proxy setup for these files that these programs need to function with iTunes.The latest version of Audirvana Plus running in integer mode sounds a little better than JRiver to my ear. Audirvana Plus is more focused with a larger soundstage. It also has a little more definition at the low end.
I still prefer JRiver 18 for Windows with the infamous JPlay.
Edits: 07/20/13Follow Ups:
... there's no such thing as "good sound by accident".Which in turn means, taking into acount widely-publicized JRiver developers' approach, that it will always remain middle-of-the-road software (at best), sound quality-wise. The same goes for modern-day (post-Otachan) Foobar - they will never sound as good as players, created by people who actually understand what they're doing, like Audirvana or JPlay.
Of course, time and efforts spent on making a player that sounds good to his creator, don't guarantee that it will sound good for everybody. Differences in hardware, software, and more importantly - taste play huge role. That's why, for instance, cPlay never sounded good to me, in any of its iterations - despite the fact that cics definitely spent a lot of time tweaking it to sound to his liking.
Edits: 07/21/13
It would be helpful if those people who "know what they're doing" could explain some of their knowledge. Perhaps I've missed some good explanations. The explanations I've read are lacking or suspect.
Links would be appreciated.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
http://www.computeraudiophile.com/content/520-fun-digital-audio-%96-bit-perfect-audibility-testing/
Unfortunately, it takes the opposite position to the one you are asking about.
It refers to other articles posted by mitchco. Throughout this series of articles mitchco makes a pretty persuasive case that there is no difference between the output of "bit perfect" media players such as JRiver, Jplay, or Foobar.
I think that the effort that mitchco put in to isolating his samples and then demonstrating that they null perfectly down to -144dB is pretty convincing.
For people to actually "hear" a difference (as opposed to imagining one), shouldn't there actually "be" a difference? How much difference can there be if it's at -144dB or below?
The referenced link is not relevant to my comments. The article concerns the extent to which bit streams that contain different bits will sound different. My comments were about how two bit streams that contain identical bits can sound different.
If two bit perfect files null out, then there will be no difference at all, and in dB terms this is not -144 dB, rather it is -infinity dB. But this is talking about the bits, and has nothing to do with the analog signal that reaches one's ears.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"If two bit perfect files null out, then there will be no difference at all, and in dB terms this is not -144 dB, rather it is -infinity dB."
Actually, to be precise, we need to say: "If two IDENTICAL, bit perfect files..." I'm guessing a bit perfect Brahms with a bit perfect Bach will not null out. However, I'm with you about identical, bit perfect files nulling. In fact, isn't nulling an indication that the two files are indeed identical? And as you point out, how can identical files sound different?
I get confused when you dismiss the wave forms as being just "bits." Isn't that like saying coffee is just atoms? Just as the configuration of the atoms determines the type and taste of the coffee, the configuration of the bits determines the melody that makes up the wave form. When we drink coffee we're not worrying about the atoms dancing on our tongues and when we listen to music our ears follow the wave form of the melody, not the individual bits. I'd think that the wave form has quite a lot to do with the analog signal that reaches our ears, just as the type of coffee has quite a lot to do with the sensations on our tongue when we take a sip.
If you have two identical cups of coffee why would you expect them to taste different? If a taster claims that they are different, would you spend your time investigating the identical cups of coffee or the taster? http://www.youtube.com/watch?v=HxlGI4OzeBk
Similarly, we have folks who make no change to their systems except to switch between media players who claim to hear differences in the outputs of their systems as a result. By performing null tests we can determine the different media players are putting out identical, bit perfect data streams. If nothing else has changed, shouldn't the analog output be identical? If, given two identical inputs the analog output differs between the two, doesn't that indicate a flaw in the playback chain? Shouldn't we be able to insist on consistency from our stereos so that if we play the same track twice it sounds the same? On the other hand, if the playback chain is operating consistently and when given two identical inputs the analog outputs are identical yet still the listener insists there is a difference, isn't it time to start looking elsewhere besides the playback chain?
The output streams of those players may be identical if they are considered as bits, e.g. if they are transcribed as a pattern of 0's and 1's to a memory buffer. However, if the output stream is examined as a continuous electrical waveform, there may be differences. You won't see these differences by looking at the memory buffer in the DAC, but you may be able to see them by looking at the waveform on the cable using a high resolution storage scope. The tools used in the article were looking at the pattern of bits, not at their physical representation. However, a DAC doesn't work with abstract bits. It works with a physical representation, and depending on its design and construction this physical representation may have a significant effect on the DAC's output.
Here's an example of two bit streams that contain identical "bits".
0 1 10 11 01101
01101101 101
As you can see, there are identical sequences of digits, but their physical representations on your computer screen are not identical.
As to nothing changing, something always changes. No two objects or events in this universe are ever identical, but even if they were, our perception of these events would differ, if only because of our differing mental states.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"However, a DAC doesn't work with abstract bits. It works with a physical representation, and depending on its design and construction this physical representation may have a significant effect on the DAC's output."
VERY well put Tony! And broad enough to include energy possibly quite unrelated to the signal.
It's funny how the term "digital" seems to have the ability to cloud minds. I spent a fair time in the barcode biz and for good or ill that left behind a preternatural awareness of the difference between symbols and data...
Rick
I freely admit I'm not an EE. And if I'm wrong then I'm wrong. Wouldn't be the first time and certainly won't be the last. I'll give you this: if you can persuade me I'm wrong I will happily own up to it. Heck, I'm not really interested in being right or wrong. I'm interested in learning more about how this stuff works.
I'm not sure what you mean by "You won't see these differences by looking at the memory buffer in the DAC, but you may be able to see them by looking at the waveform on the cable using a high resolution storage scope." I don't think Audacity can peer into the memory buffer of the DAC, can it? I also wonder what cable you are talking about when you say you may be able to see differences on that cable by using a high resolution storage scope.
Please let me quote what mitchco posted: "The Hilo has the capability to patch (sometimes called digital loopback or route) any input to any output. As confirmed on the Lynx support forum, the audio bitstream is going from JRiver, through the ASIO driver, through the USB cable, into the Hilo, and then clocked back out the Hilo, through the USB cable, through the ASIO driver, and into Audacity. I am routing the output of JRiver to input USB Play 1&2 on the Hilo and patching it to output on USB Record 1&2 which is the input to Audacity."
How does this differ from the protocol you sketched out? Isn't mitchco in effect "measuring the cable" by using Audacity as a "high resolution storage scope?" Again, I'm not trying to say you are right or wrong, I'm just trying to figure out what is going on here.
Thanks for any comments you might have!
HI JE,
I'll try and give some real life examples here of how things other than "the bits" could have an affect on the analog output.
I've been working on a new USB DAC design recently, so I have a setup that I'm continuously looking at with scopes and logic analyzers etc. In this situation the logic analyzer said everything was fine, the bits were perfect. A logic analyzer runs the analog voltage on the wire through a "threshold" to distinguish if it is high or low, what you see on the screen is just high or low, ie "bits". But when I looked with the scope which shows the actual voltage levels of the signal I saw some extra signal riding on top of the highs and lows of the "bits". This turned out to be noise on the ground plane caused by the processor that was generating the bits. (it was much worse than it should have been due to a poor board layout of the processor reference board) That noise was enough to cause significant change to the audio out even though the "bits" were correct.
One interesting aspect of this was that you could easily see changes in this ground plane noise depending on what the processor was doing. While this was a fairly gross example of the effect, it clealy shows that things going on in the processing and transmission of the bits can have an affect on the sound at the output, even though the correct bits get to the DAC chip.
Next you might ask "well isn't that a broken system, if it was "good" shouldn't it not be an issue?" Note that this was the official reference board for the processor made by the manufacturer, who should know how to make things that work well with their processor. This just goes to show that things that can cause audible differences in digital audio are frequently not part of "it works as a digital system", the board did what it was supposed to, it delivered the bits.
A better board design could have cut this ground noise down significantly, but it would still be there.
What we DAC designers have to do is figure out ways to design products that produce analog out that is immune to this sort of thing. Unfortunately this is extremely difficult to do. There are many people on this board that expect that this is easy to do, just put in the right 50cent part and presto the design is completely immune to everything. It doesn't work that way. High frequency ground noise is extremly pernicious stuff, it will find a way to get around just about any obsticle you throw in its path.
Different designers take different approaches to try and achieve this with varying degrees of success. The different approaches will usually be affective at decreasing susceptibility to different types of noise so one DAC model may not care about a certain aspect (say cable differences) while another may be pretty immune to cable aspects but be susceptible to timing variations in packets. This may be a part of why some people say they can hear certain aspects and others say they cannot.
These techniques for noise suppression are pretty esoteric knowledge, there really are only a few people that really understand all this, there are very few places in the real world were the combined knowlege to make this really work right are required, thus very few people have a good grasp on all of this. The result is that many actual designs on the market are fairly lacking in this department, or are only targeting one aspect of it.
This is slowly changing and companies are starting to get an inkling of what it takes to do well with this and are hiring people with some knowledge in this field, but there aren't nearly enough to go around, so it's going to be some time before all digital audio systems you can buy do a good job in this regard.
Sorry, I'll get off my soapbox now.
John S.
John,
Great post!
Not only is the processor to blame for the ground noise, but also the fact that the ground connected from the PC to the USB receiver is also having an effect as well as USB it self.
But really the problem is that most of these microcontrollers have a ton of PLL's on them to control certain aspects of their working. Like you need 480Mhz for USB (some run at 960MHz for receive and 480 for transmit). You also have some basis for the Processor Clock, Peripheral Clock and then the slow stuff. All of these PLL create ground noise like crazy.
Back in the early 90's I attempted my first filtered DAC using dual Analog Devices DSP's. I could never get the thing to work because of all the freaken clock shifting and PLL's with those processors. Everything in the ground plane was a mess. I had a little better luck with some ATT processors but they were hard to get a hold of.
Today we totally isolate the USB and Processor so the noise generated by all that action above is kept away from the sensitive DAC chips and Audio Oscillators. This also breaks the ground path to the computer which is also a huge deal in keeping the sonics on par with what customers really need.
Thanks again,
Gordon
J. Gordon Rankin
Hi John!
I much appreciate your taking the time to try to educate me on this matter. Sadly, I'm still at sea and still don't understand what's going on. If this post is a TL;DR then that's OK. You nor anyone else on this board owes me any sort of explanation. But if you're feeling generous and have some time to kill, please read on! I'm perfectly happy to see you up on a soap box! At present I feel like the rube at the country fair who simply cannot grasp the magician's hat trick. The rest of the crowd seems to be able to see what's going on but for the life of me I cannot understand how he keeps pulling that rabbit out of that empty hat.
May I ask, have you read mitchco's articles: http://www.computeraudiophile.com/content/520-fun-digital-audio-%96-bit-perfect-audibility-testing/ and http://www.computeraudiophile.com/content/513-jriver-mac-vs-jriver-windows-sound-quality-comparison/ ?
I ask because the entire basis of my argument rests on the premise that the "bit perfect" outputs of the tested media players are identical and therefore fungible. To support his case, mitchco points to the deep, -144dB nulls he was able to obtain while playing the same song through different media players. If mitchco is wrong, or if I am reading mitchco incorrectly then there is no point in further discussion. I can easily grasp why different outputs would sound different. (Of course, that might throw into doubt my understanding of how computers work, but that's not the issue here!)
My second point is that all the responses I've read so far say more or less that digital audio is not fully understood yet and therefore playback equipment is not perfect and indeed can differ remarkably one from another. For this case let us presume that every DAC and amp or whatever has a unique and distinct "character" to it.
That said, may we agree that the "characters" of those various components are consistent from day to day? I think this goes without saying really, as some of the "characters" components have will be more highly prized by audiophiles and therefore command higher prices. The posters on this board may all be inmates but none are stupid. No one is going to spend money on a component that has a different character each time you use it. Still, it's important that we agree that components have consistent "characters" from day to day.
We then assemble our components into a chain, from source to transducer. Each time we play a song the media player loads the data into RAM, the CPU moves it through the PC to the USB port, the USB cable moves it to the DAC and so forth all the way down the chain. With each component having its own "character" the chain is a virtual roller coaster ride for our music, but again, the chain itself is consistent. If I listen to a song today, I will expect the media player to load the same data into RAM, the CPU to handle it the same way and every other link in the chain to handle it the same way as it did before. I fully expect the song to sound the same as it did yesterday and to sound the same again tomorrow. Indeed, I would be surprised and concerned if the song sounded different, as that would indicate that something in my personal chain of components had changed.
Note that for my hypothetical it doesn't matter if the various components or processes are imperfect, so long as they are consistent. If something is mishandled today, it will have been mishandled yesterday and will be mishandled again tomorrow. The sound, imperfect as it is, will be the same and retain the same overall "character."
This is where my confusion arises. We have two media players, say Foobar and JRMC. Both are capable of putting "bit perfect" data into my PC's RAM. If we've gotten this far, we've already agreed that "bit perfect" data is exactly alike: the same bit perfect song, even from different media players, will null perfectly, or at least to -144dB according to mitchco. Whether it came from Foobar or JRMC, it's the same data. Once that data is in RAM, I again expect the CPU to move it through the PC to the USB port, the USB cable to carry it to the DAC and so forth and so on; just like it did yesterday and just the way it will do tomorrow. I would fully expect the same song through the two "bit perfect" media players to sound the same, and would be surprised if it did not. Why wouldn't it sound the same? If the same song through the two players can be nulled to -144dB why wouldn't the rest of the chain handle it the same way?
I know this was a long read, and if you got this far I thank you heartily for your time and patience. Truly, I am not trying to troll you or anyone else. I would be happy to read any thoughts you might have on my dilemma.
Thanks again for your reply!
J.E.
Hi JE,
the issue is not about day to day consistancy, but about "how can different programms that all send the same bits to the DAC sound different?" Is this what you are really after?
The insight is to note that in my previous post I was talking about things that affect the sound that are NOT changes to the bits, but things like ground plane noise. I was trying to show that what is happening inside the computer (processor, memory acceses etc) can change the ground plane noise. Not just the amplitude but also the spectrum of the noise. I'll give some specific examples later.
Not all programs that read files and send bits to a DAC do it exactly the same way. Some may have several buffers the data goes throuigh on it's path, some may only have one or two. Some may be built using a "layered" hierachical approach with different software "modules" that call each other, where others may be fairly "flat" with just one routine that does all the processing.
The exact sequence of instructions and memory accesses is guaranteed to be different between the programs. Since it is these instructions and memory accesses that cause the ground plane noise, I hope you can see that differences in how a task is done can produce different noise.
And BTW this CAN be measured. I've built a little ground noise analyzer that can easily see the difference in the noise from different programs doing supposedly the same thing.
Now for a concrete example. Let's take a simple program that is just coppying audio data from a file to a buffer and then to an simple output port. It has two threads, one reading the file and putting the data in the buffer, and one taking data out of the buffer and putting it on the out port using an external clock to time the opperation. The first thread waits until the buffer is empty then fills it up and goes back to sleep. (in reality there would be two buffers used in a ping pong arrangement, but that is irrelevant to the issue at hand).
So lets take this program and make two copies, one which has a small buffer and one which has a large buffer. The total amount of processing is exactly the same, the code is exactly the same, but is the ground plane noise the same? NO!
In the case of the small buffer the first thread spends a fairly short period of time waiting since the buffer empties out quickly. It spends a small amount of work often. With the large buffer each time it wakes up it has to handle a lot more data, but it waits a much longer time between sessions.
So why does this matter? If you look at the "work performed by the thread" over time the large buffer version shows a very "bursty" activity, but the small buffer shows a much more uniform activity. If you look at this in the frequency domain the small buffer version is dominated by relatively low intensity at high frequencies, mostly above the human hearing range. But when you look at the large buffer version you see higher intensity at much lower frequencies that are right smack dab in the middle of the human hearing range. This latter noise is going to have a much bigger affect on audibility.
And note this was exactly the same code, just different buffer sizes. Think what can happen when you are comparing different programs that use very different program architectures.
As an analogy, think about getting a group of people from point A to point B, either using a two seater sports car or a 30 person bus. The sports car has to go much faster and more often, the bus can only take a few trips and lumber along. But the result is the same. All the people get from poingt A to point B in the same total amount of time. But if you stand at the side of the road and have to put up with the noise, is it the same?
I hope that makes sense.
John S.
John,
I talked to several software programmers about their application and all of them at one point or another has admitted that they removed a buffer copy and the software sounded better.
But let's ask this question...
Ok so if we have a completely isolated system were the USB controller, Computer and everything is powered on one side then we have optical isolators reclocked output the DAC chip and audio oscillators on the other side. Here the ground is broken into 2 sides the dirty side for the USB controller, computer ground and so forth and then the clean side with the DAC chip, reclocker, audio oscillators and audio output circuitry. Each powered by a separate power supply.
Why does software still sound different?
In my test setup I looked at the following chain for digital errors:
Computer <===USB Analyzer===> USB Receiver---I2S---> DAC chip===analog output
At the I2S level I have a Tektronix MSO scope with the audio software module which can decode I2S frames. I can also look at the EYE pattern on the USB to see how well the computer or USB cable is acting. At the analog output I have the Prism dScope III analyzer.
This proved interesting in testing cables because some would have better EYE patterns and some would have excessive over hang in turnarounds which would cause data errors.
So after selecting a suitable USB cable for testing then to the apps.
Some apps were not truely bit perfect and so they were excluded. But in the with Windows or OSX and having bit true output, there was not really any real difference in analog output.
By Bit true that means the entire file is the same. At the computer, one the USB line, at the I2S interface. None of this horse crap about recording a file then subtracting it in sample recorder. Come on... how stupid is that. Are you going to see the differences in a few bits if they are off? NO! But there is a good chance you will hear it.
Though clearly there is a sound difference.
Same true with the argument that Lossless files don't sound as good as flat PCM files. While as a programmer sure I know the Lossless file will require real time unpacking and that will take up much more processing time than just send the flat PCM file to the output device. But still the same thing.
Any thoughts?
Thanks for your time!
Gordon
J. Gordon Rankin
There are various ways that differences that have passed through an optical isolator can still affect the analog output of a DAC. For example, the amplitude of the optical signal will depend on the noise on the source side of the isolator, and this will have some effect on the power consumption of the optical receiver, thereby introducing ground plane noise on the "clean" side. There is also leakage through a flip flop even when it is unclocked so reclocking circuits are not completely "hard".
In order to progress with a plan to increase isolation it would be extremely useful to have a way to measure the amount of isolation provided by a setup. I can see two ways to make it easier to measure isolation: 1. Adjust the amplitude and structure of the noise so render any leakage easier to measure. (engineered noise injection) 2. Use coherent detection of the structured noise (synchronous averaging) so as to pull the noise signal out from far below the noise of the converters involved. I don't believe you will be able to do this using off-the-shelf measurement tools. Like any good experimental physicist it will be necessary to construct your own apparatus. Yes, I know you don't have the budget of CERN. :-(
If you are interested in ascertaining how much noise may still remain in the analog output of a DAC and yet still be unheard by a listener, then for some kinds of noise one can inject it by mixing into the analog output of the DAC and conduct listening tests. Similarly, one can inject noise deliberately into the DAC master clock and listen for audible degradation due to induced jitter.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
+1
John S.:Thanks so much! This makes sense! Let me try to rephrase what you've posted to see if I understand what you are saying.
I originally thought the media player dumped the data into RAM and then the CPU called upon set protocols to move the data through the PC and out into the wild. What you are saying is that the media players themselves use their custom routines to shepherd the data through the PC. In effect, each media player takes the clay of the PC and molds it into it's own, unique component. The topology the data follows when I use JRMC is different than what it follows when I use Foobar. I can understand how that could change the sound.
I guess what you are saying is Foobar and JRMC would have different transfer functions? While they both have "bit-perfect" output they then process that data differently enough to cause audible changes to the output?
Sorry I was so dense and took so long to get the point.
Of course, now I'm wondering what all the fuss about "bit-perfect" is if it's just going to get audibly mangled on the way to the USB port, but I guess that's a discussion for a different day.
Again, thanks so much for your time and patience with me!
J.E.
Edits: 07/25/13
The discussion that resulted was very informative. Now the big question:
What has been your experience listening to different programs on your system? Will you share with us what comprises you system?
Thanks
Hi, Mercman!
"The discussion that resulted was very informative. Now the big question:
What has been your experience listening to different programs on your system? Will you share with us what comprises you system?
Thanks"
LOL!! THAT's your idea of the "big" question? I just spent the last few days making a very public ass of myself and now you want to dance on my grave? What would Lucy say? I bet she'd think that what I could use most right now would be her giving my face a few licks and then leaning against my legs, not having my nose rubbed in the carpet.
If you haven't noticed already, mine is a slow mind. It will take a few days for the implications of this new (to me at least) idea to filter through my head. I'll try to keep you posted if anything results.
In the mean time, give Lucy a pat for me!
J.E.
I wouldn't feel bad about not understanding how these details work. The sad truth is that few people do, including people that are designing and selling digital audio hardware and software products, although the situation is better today than previously.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Hi Tony.
These aren't questions I'm asking anyone to answer, they are just the thoughts passing through my head at present:
I keep coming back to that -144dB null result. All I can think is either Audacity is broken, or mitchco's protocol is faulty, or the various changes caused by the tested media players are trivial which would then bring us right back to the original debate.
Mitchco says the signal is being generated in his PC by a media player, then passing through an ASIO driver, through a USB cable to the Lynx Hilo and then back out of the Hilo through a USB cable, through an ASIO driver and back into his PC and ultimately to Audacity. Shouldn't this introduce some sort of noise? If so, then how does he get -144dB? Are digital protocols that good?
I get that JRMC will leave its fingerprints on a file. I get that Foobar will leave its fingerprints on a file. Heck, for that matter, shouldn't Audacity, Windows and OSX also leave fingerprints on the file? Given all those smudges, how on earth can we get a -144dB null?
Just how much additional damage does a media player have to inflict on the signal before a null test would show a musically meaningful amount of change?
Eh. I can see, I think, the point mitchco is trying to make. I can see, I think, the point John Swenson is trying to make. I think that I'm going to have to wait for someone else to try to repeat mitchco's test before I make up my mind.
As promised, I admit that this board has got me doubting my own beliefs, and that's something, right?
All the best
J.E.
Hi JE,
the difference here is that the test you are refering to is a DIGITAL loopback test.
I guess at this point I'll start at the very beginning, I wish I had the skills to do some nice pictures with this, but that is outside MY skill set!
What is digital?
Digital is a nonlinear system.
Take a piece of wire with a voltage on it. These days many chips use a voltage range from 0 - 3.3V. The volotage on that wire can be anywhere in the range from 0 - 3.3V, it IS in actuality an analog signal that can take on any value in that range.
We then run that intgo a circuit that applies a threshold, lets make it easy and say the threshold is at 1.5 volts. What this circuit does is any value on it's input below 1.5V produces 0V on the output. And any value above 1.5V produces 3.3V on the output.
This circuit "quantizes" the input to just two values 0V and 3.3V (of course it is not perfect, but that is the ideal behavior).
So how does this circuit get this 0V and 3.3V for the output? It is the values on the power and ground pins of the chip. Remember we were talking about ground plane noise, well the ground pin of the chip is connected to the ground plane. The power pin is connected to a 3.3V supply that usually has even more noise than the ground plane.
So when you look at the analog voltage coming out of the chip with a scope you see noise on both the upper and lower parts of the "waveform". It is never an absolutely pure 0V or 3.3V. BUT as long as this noise never gets above 1.5V for the "low" part of the signal or below 1.5V for the "high" part of the signal, the next chip in the chain can correctly interpret it as either high or low with IT'S threshold circuit. That is the basic concept of digital, because of the nonlinear behavior (the threshold) it can withstand large amounts of noise and still keep the integrity of the data intact.
This is why somany people think "bits are bits".
BUUUT, as I was trying to point out in the previous posts it's not all just about those thresholded values. The noise on the ground plane produced by the processing and transmission of those bits can affect the sound WITHOUT being large enough to change bits.
It can cause oscillator producing the timing signals to have much more jitter than it normally would, it can cause the analog out of the DAC chip to be noisier than it normally would be, it can cause any anlog output circuitry to be noisier that it normally would be.
And here is one that is a little harder to understand. What determines that infamous threshold in the digital chips? It turns out that in most chips used today it is a ratio between the voltages on the power and ground pins. Remember that both of these pins have noise on them, that means the threshold value is going to be changing as well. So what? as long as the noise on the input is not near the changing threshold, who cares? Well it comes back to that "the output is not really ideal" statement. It takes time for the signal to go from 0V to 3.3V. This is called the "ramp time" and you can easily see this on a scope. So the input signal is a ramp (with noise embedded on it!) going into a threshold that is also dancing around, what is the result? The time at which the threshold circuit says it changed from low to high varies quite a bit, this is the dreaded "JITTER".
This jitter is directly related to the ground plane noise talked about before. Note that the bits stay intact through all this! The threshold circuit can still correctly interpet the change from low to high.
This whole thing is about there being other paths that can change the sound other than just "the bits". And those paths CAN be affected by differences in how different programs process and produce exactly the same data.
That test you are bringing up is doing a digital loopback, it takes the bits from one place into another, then sends them back out and compares them, they are the same. Thats what the circuit chain is supposed to do, and it does it. BUT every one of those parts of the chain is producing noise on its ground plane, which CAN cause changes in the sound coming out of the DAC, EVEN THOUGH the bits didn't actually change.
Does that make sense? I don't know how to better explain it.
John S.
Heck, even I understand a bit better after reading you post.
Thanks!
Thanks so much for your time, John!
This is making sense to me. What you are saying is that JRMC and Foobar and whatever other media player effectively DO reach through the USB cable to influence what is going on in the DAC.
The bits are like little ping pong balls floating on a stream. We can arrange the ping pong balls, and compare the arrangements of the ping pong balls, but that does not take into account any ripples or splashing in the underlying stream itself.
Each media player is effectively its own stream of water and flows through the PC in its own channel. That channel will affect how the water flows as it carries the ping pong balls. So even though the ping pong balls are arranged in the same way on the differing streams, the different streams will have their own characteristic "flow noise" as the ping pong balls move to the DAC and beyond.
Am I getting it now?
Thanks again for all your time and trouble with this!
J.E.
Yes J E, good analogy. If I may answer simplistically for J Swenson - the transmission of digital data is only concerned with getting the order of the ping pong balls correctly lined up at the receiving end, not losing any ping pong balls or having a half ping pong ball delivered instead of a complete one. Digital audio is different, in the way you have stated it - the transmission stream that the ping pong balls are floating in has an influence on the receiving end; the timing of the arrival of the balls also has an influence on the receiving end& ripples - none of these are of any consequence to digital data transmission - bits are bits in that world & that is all that counts!
This may seem simplistic & some will argue that nothing other than delivery of the bits is of importance upstream of the DAC, that it's only at the DAc itself that timing & noise come into play but this is simplistic thinking. As has already been said anything that causes a disturbances in the electrical transmission stream along the way could have an affect downstream at the DAC - the whole system has to be considered & the possible influences that may impinge on the final DAC's job of converting digital to analogue signals.
Thanks! While this has likely been a tortuous thread for the forum to endure, it has gathered some insanely good posts from some very smart people, and I think they all deserve a round of applause for their time and effort!
P.S. I too would like to see you report the results of your tests. I think starting a different thread would be best though. This one has pretty much run its course.
"I keep coming back to that -144dB null result. All I can think is either Audacity is broken, or mitchco's protocol is faulty, or the various changes caused by the tested media players are trivial which would then bring us right back to the original debate."That loop back was a digital loop back. The signal was not converted from the digital domain to the analog domain and then converted back to the digital domain. Consequently, there was no noise added. The difference between the input and output is exactly zero, which is not -144 dB, rather it is -infinity dB. [This is what my audio editor shows for a null test or a completely silent file.]
If you do an analog loop back you will not get back what you sent out. There will be hum, noise, and distortion. You will be very lucky if the difference signal is -120 dB if you use typical sound cards. For example, running the analog to digital converter of my juli@ sound card at 44 kHz 24 bit format the average broadband (20-20K) (RMS) noise level with no input signal is -110 dB. Even with the best available equipment you will not get nulls down to -144 dB.
I suggest you spend some time and come to understand what the difference is between a digital loop back and an analog loop back.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Edits: 07/25/13
"That loop back was a digital loop back. The signal was not converted from the digital domain to the analog domain and then converted back to the digital domain. Consequently, there was no noise added. The difference between the input and output is exactly zero, which is not -144 dB, rather it is -infinity dB. [This is what my audio editor shows for a null test or a completely silent file.]"
Doesn't this bring us back to where we started? I thought the point that John Swenson was making was that different software will move the data around the PC in different ways and that this will cause each media player to have its own unique sonic fingerprint.
What mitchco did was fire up a song clip in a media player, move it through the PC and out to his DAC. Let's say he used JRMC. Shouldn't that have put the full JRMC "fingerprint" on to the first song clip? Once the first song clip has hit the USB cable what more can JRMC do to it? Media players can't reach through a USB cable to manipulate data in the DAC can they? He then brought the first song clip back to his PC and put it into Audacity.
He then did the same with a copy of the original song clip but used a different media player, let's say Foobar. Shouldn't this have put the full Foobar "fingerprint" on to the second song clip? He then brought the second song clip back to his PC and put it too into Audacity.
At this point mitchco has two clips in Audacity: one with JRMC fingerprints all over it and the other with Foobar fingerprints all over it. He nulls them and they simply disappear. How is that possible?
What happened to the JRMC fingerprints? What happend to the Foobar fingerprints? If they differ from one another shouldn't traces of them remain after everything else has nulled? If the test was valid, and if we can't find any trace of the fingerprints, what else can we conclude except that the fingerprints were themselves identical or non-existent in the first place? How can we avoid the conclusion that the two song clips, despite coming from different media players, were identical? If the two song clips are identical, then how can we say that JRMC's output is any different from Foobar's output? If we are putting identical outputs into our system, why would we expect them to sound different when they come out the other end? Shouldn't it be surprising if they did?
Isn't this where we came in?
http://www.youtube.com/watch?v=E9d-1d0ltCM
Now I'm not saying I'm right and you and John Swenson and everyone else who has kindly discussed this with me are wrong, but it appears whatever changes the tested media players (which apparently includes JPlay too) may impose on songs are not merely negligible but undetectable, at least using Audacity.
"Media players can't reach through a USB cable to manipulate data in the DAC can they?"
Yes! By George I think you've got it...
Let me try a humanistic spin on it: you are watching a political speaker and he says of his opponent "John Doe is a good man but I believe...". However within the limits of writing he really said "John Doe is a 'good' man but I believe..." Even the latter doesn't really convey the dripping cynicism and disgusting expression of the speaker.
That's an example of identical symbols (words) whose transmission characteristics encode and additional information channel that actually inverts the meaning of the data proper. Sometimes it's not what you say, it's how you say it...
Usually that's the very thing we DON'T want in our electronic communications but it's surprisingly hard to eliminate it. Take opto-isolators, do they really isolate? No, of course not, if they did no data would get through them. They do break the path for longitudinal currents however, but at the expense of degrading the actual signals. That happens because they have substantial energy (information) loss, a limited bandwidth and a new slicer.
The stuff upwind like the driver and cable impress their characteristics on the signal and in the case of the driver that includes ground noise at the zero state, plane noise at the one state and threshold modulation in between. And naturally both the driver and cable affect the rise and fall times and the cable may pick up noise (signals that you don't want) along the way. Whatever they add to the signal becomes part of the signal at the next slicing point be it a gate, opto-isolator or whatever. Not only is the signal permanently altered, the energy that it takes to do so is a function of the input and affects the local planes and EM environment.
Digital is an abstraction that's often encoded via an electrical analog.
Rick
Some great information in this thread, guys, well done.I'm working on measurements of timing differences between different software players' output. I'm not completely ready to release the results yet as I'm checking & double-checking results.
I'm pretty sure that this is only a part of the picture & noise is one of the other parts (don't know if there are other factors?).
I would be interested in John Swenson's measured ground noise figures from different software players if he could see his way to posting some of these & I can begin to release some timing measurements also.
May be worth starting a new thread on these measurements if anybody is interested?
Edits: 07/26/13 07/26/13
"May be worth starting a new thread on these measurements if anybody is interested? "
That would be grand.
Rick
Thanks for the interest. When I have a set of measurements ready & I understand the results in a bit more depth (hopefully), I will start a new thread.
Sure we would love to see how things turn out with your measurements JK. Good to see you here (this is best), not 'what's best' :)
Yep, "What's best" forum seems to be "What's good enough" forum :)
No interest in what actually might be best!!
When I saw this thread I immediately saw some open-minded discussion (mostly) & I felt it worthwhile posting to see if there was interest.
I have some interesting results but need to solidify with more tests & trying to work with others in the background to bring some clarity to the results. I'm particularly interested in SGBK's player software as he has a number of iterations of his playback software for which he has & will share the programming details. This will be a great test bed for investigation.
I'm also particularly interested in J Swenson's ground noise results as I feel they will correlate with my measurements results i,e I suspect that both better timing & lower noise are the two factors that determine better playback (at the software AND hardware level).
It's a tiring & long process because there are so many variables to try to nail down but should be worth the effort.
I've told you where you are confused. You don't understand the difference between digital loop back and analog loop back. mitchco did a digital loopback, not do an analog loopback which others such as archimago have done.
There is no point in arguing about measurements that others have made when you don't understand what is being measured and how the measurement tools work. Rest assured that those of us who have a some understanding of the issues didn't get it overnight by reading articles and Internet posts. We got it by many long hours of study and experimentation. It isn't necessary to understand this stuff to enjoy recorded music, or even to figure out which components work well together as a playback chain for reproducing music. All one needs for that is one's God given sense of hearing. However, it is necessary to understand this stuff, both the analog part and the digital part, if one is going to talk sensibly about measurements or to make logical deductions as to the cause of something that one hears or doesn't hear.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Lucy knows what's goin' on. Good one!
Hey, Mercman!
I'm glad at least Lucy is keeping score! I'm getting so punch drunk from all this that I'm losing track of which side I'm arguing. I think I'm arguing against you right now, but please don't hold that against me! Give Lucy a hug and a pat for me.
Whatever else our differences may be, let me say that I adore dogs but am massively allergic to them. As much as I'd love to have one, I simply cannot. Can you imagine your life while never having a Lucy in it? So, when I say "give Lucy a pat for me," I'm sort of living vicariously through you. If you don't mind, I'd be very happy if you gave her an extra pat for me. I bet she wouldn't mind.
All the best...
J.E.
Time to face the day! I'll check in as soon as I can.
Just curious about your audio world.Thanks
Edits: 07/25/13 07/25/13
"Just curious about your audio world."
And you did not get an answer... LOL Just avoided the subject of what he is is listening to. Very curious...
One minute JE is Clarence Darrow, and the next a total bumpkin...
Sure... Just too funny...
And I'm sure that being a nice guy brings you all sorts of benefits. For example, no one is ever going to accuse you of being Clarence Darrow. Still, I'll do my best to improve.
All the best!
J.E.
"And I'm sure that being a nice guy brings you all sorts of benefits. For example, no one is ever going to accuse you of being Clarence Darrow. Still, I'll do my best to improve."
So entertaining... But disingenuous. If there was any sincerity in your game you would answer the simple question... What the heck are you and have you listened to? You are entitled to your opinion, if is is a REAL one. But if you are just wasting busy peoples time for foolishness, or a hidden, or not so hidden agenda. Shame on you... Maybe you are just up the River without a bit perfect paddle.
"May I ask, have you read mitchco's articles: http://www.computeraudiophile.com/content/520-fun-digital-audio-%96-bit-perfect-audibility-testing/ and http://www.computeraudiophile.com/content/513-jriver-mac-vs-jriver-windows-sound-quality-comparison/ ?"
JE,
What is the reason to keep bringing this up? Hmmm
If this is what you believe, and think you hear and cannot hear a difference then nobody will be able to change your mind, or help you...
Sad.
"I ask because the entire basis of my argument rests on the premise that the "bit perfect" outputs of the tested media players are identical and therefore fungible. To support his case, mitchco points to the deep, -144dB nulls he was able to obtain while playing the same song through different media players. If mitchco is wrong, or if I am reading mitchco incorrectly then there is no point in further discussion. I can easily grasp why different outputs would sound different. (Of course, that might throw into doubt my understanding of how computers work, but that's not the issue here!)"
If it was only that simple.
IMO his measurements are meaningless as they still SOUND different to myself and others. We need to toss the measurements and start to use your senses. Do you trust them?
I have asked you several times... Do you think everything in life can be measured? I would love for you to finally answer?
Even the brilliant people we have here like Gordon and John listen,
and ultimately trust their ears.
If this does not make sense to you, then what is the point?
regards
Bob
Hi Bob!
"JE,
What is the reason to keep bringing this up? Hmmm"
I keep bringing it up because I am trying to understand what is going on. Aren't you curious about how your music player works?
"If this is what you believe,"
You lost me there. What exactly do you mean by "this?" If I'm supposed to believe in it I'd at least like to know what "this" is.
"and think you hear and cannot hear a difference then nobody will be able to change your mind,"
Never say never! I will say that no one so far has been able to explain the situation in a way I can understand.
"or help you...
Sad."
It's not so much sorrow I feel as frustration in not understanding the process that is going on.
"'I ask because the entire basis of my argument rests on the premise that the "bit perfect" outputs of the tested media players are identical and therefore fungible. To support his case, mitchco points to the deep, -144dB nulls he was able to obtain while playing the same song through different media players. If mitchco is wrong, or if I am reading mitchco incorrectly then there is no point in further discussion. I can easily grasp why different outputs would sound different. (Of course, that might throw into doubt my understanding of how computers work, but that's not the issue here!)'
If it was only that simple."
OK, why isn't it that simple? My argument is that if we play the same song twice on our stereos, the song will sound the same each time we play it. Mitchco's tests indicate that the outputs of the tested media players are the same. Playing the same song on one of the tested players and then playing it again on a different one of the tested players is the same thing as playing it twice on the same player. Therefore the output from your transducers should be the same.
"IMO his measurements are meaningless as they still SOUND different to myself and others. We need to toss the measurements and start to use your senses. Do you trust them?"
In other words, you cannot explain how mitchco's tests are wrong; instead you choose to ignore them. Certainly I trust my senses. But neither do I throw my reason out the window. I fully accept that both my reason and my senses can be deceived. That's why I look to test results as well.
How good are your senses? If I sat you in front of a speaker, how well could you plot out it's frequency response? If I gave you an amp, could you, by listening, measure its distortion? Its power output? Could you tell me, just by listening, whether or not two tracks null to -144dB?
"I have asked you several times... Do you think everything in life can be measured? I would love for you to finally answer?"
I'm sorry. I don't answer because I don't understand the question. Let's narrow it down a bit. We're not talking about everything in life, we are talking about waveforms passing through electronics. In the case of a waveform passing through electronics, then sure it can be measured. Now whether or not our measurements are correct or subtle enough is a different topic and one I'm frankly not qualified to answer. That's why I keep asking these dumb, "what is going on?" questions.
"Even the brilliant people we have here like Gordon and John listen,
and ultimately trust their ears."
I'm guessing they also do a bit of measuring before they get around to the listening. I'm also guessing that if their measurements say one thing and their ears another they investigate to resolve the discrepancy. I can't imagine they would release a product that measures poorly while saying "but it sounds great!"
I wish it was possible to sit and chat about this stuff. Forums are fine when everyone is in agreement and happy, but not as good when arguments arise. Too often argument is seen as dispute, and I'm not trying to start a dispute here. Anyhow, thanks for taking the time to reply to my post.
J.E.
'This turned out to be noise on the ground plane caused by the processor that was generating the bits'
having just written my own player and doing extensive listening tests on different versions of memory copy routines (memcpy) written in assembler I have first hand experience of this extra signal riding on top of the highs and lows of the "bits" type noise.
What is the cpu doing ? the cpu is moving bits through different types of memory, ideally bits are moved from disk to ram, then through the cpu to the render device.
what affects the sound ? any extra activity that produces extra cpu cycles.
eg
data not aligned to page size means extra reads required when reading beyond page boundary.
memory page protection gets fired when memory read from page.
why should the memcpy routine affect the sound ?
standard memcpy will have to do o/s hecks, cpu checks, alignment checks and calculate how many loops are required to process the data. All these lead to extra cpu cycles. I have found the best sounding memcpy uses prefetching, uses 128 bit registers, bypasses the l1, l2 cache when writing out to the destination and has the loop unrolled, so my version has 64 repeats of the code to copy a fixed 8192 bytes at a time, this dispenses with 64 times dec and jmp instructions, There is also no o/s check, no cpu check and no alignment check.
It also means my player has no digital sound.
modern chips have 8 x 128 bit xmm registers, haswell has 256 bit registers. It is the extra bits and use of registers that mean modern chips sound better. The memcpy routine has to be optimal though - noisewise as well as speedwise.
here is the code I ended up using, except I unrolled the loop, use fixed size 8192 bytes and use 2 x 64 bit prefetchnta instead of 4 x 32 bit
http://stackoverflow.com/questions/1715224/very-fast-memcpy-for-image-processing
void X_aligned_memcpy_sse2(void* dest, const void* src, const unsigned long size_t)
{
__asm
{
mov esi, src; //src pointer
mov edi, dest; //dest pointer
mov ebx, size_t; //ebx is our counter
shr ebx, 7; //divide by 128 (8 * 128bit registers)
loop_copy:
prefetchnta 128[ESI]; //SSE2 prefetch
prefetchnta 160[ESI];
prefetchnta 192[ESI];
prefetchnta 224[ESI];
movdqa xmm0, 0[ESI]; //move data from src to registers
movdqa xmm1, 16[ESI];
movdqa xmm2, 32[ESI];
movdqa xmm3, 48[ESI];
movdqa xmm4, 64[ESI];
movdqa xmm5, 80[ESI];
movdqa xmm6, 96[ESI];
movdqa xmm7, 112[ESI];
movntdq 0[EDI], xmm0; //move data from registers to dest
movntdq 16[EDI], xmm1;
movntdq 32[EDI], xmm2;
movntdq 48[EDI], xmm3;
movntdq 64[EDI], xmm4;
movntdq 80[EDI], xmm5;
movntdq 96[EDI], xmm6;
movntdq 112[EDI], xmm7;
add esi, 128;
add edi, 128;
dec ebx;
jnz loop_copy; //loop please
loop_copy_end:
}
}
It would be even better if you could copy all the music for an entire playlist into one contiguous region of memory and fire up the DMA engine for the sound card to output from memory without using the CPU at all. :-)
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
someone at work said he wrote a music player that interacted directly with the DMA, shall try and pick his brains
Thanks for taking the time to educate people. Many will ignore the treasure trove that you have donated for free. It's their loss. I don't have enough energy anymore to try and educate those who don't want to learn.
Yes it was a great post! Very informative.
Charles,
Are you saying they have....
It's not my fault I have such a basic perceptual handicap!
Indeed, a very informative post by John Swenson and Gordon R. Ground noise, voltage levels, processor activity and ultra sonic level noise seem to be of primary concern.--------------
Mwheelerk, I try to be simple and practical with my musings. Yet, I am still amazed that some of the naysayers still block themselves from reason and critical thinking. I'm not an engineer and am deficient in technical matters. On the bright side, I'm learning much from fellow posters. My background is in clinical psychology and psychological testing. Perhaps that is one reason why I try to look at various angles to truth before I open my mouth, and I can be stickler towards those who ignore their God given faculties too. Abilities they have learned to denounce, such as: 'I do not have confidence in my hearing' when there may be nothing wrong with their hearing but much to do with their lack of confidence.
Anyway, glad you liked my food anaology. I also have an spl app on my phone. Currently my office is 50db (air conditioning is right above my head and is on). Loud.
One day measurements will show a connection between software differences. Until then we may have to put up with naysayer shenanigans.
One observation, many of the doubters have hidden agendas. This is my belief. Evident by them showing up on certain topics, constantly defending certain products and bringing up the same old agruments. If one really wanted the truth, he or she would spend time searching for that (differences in computer software, for example). Let's think about this! All that energy spent towards denying what we are hearing. Aren't the 'bits are bits' fundamentalists just a tad curious as to why we hear differences? A real truth seeker would be intrigued and want to know more. Instead they blame us for having bias, and succumbing to placebo effects. They chop off their own scientific inquiry right from the get go and are all to happy to support measurements that fit their own mentality full of hidden agendas. So, who really is biased now? Some go to the point of not even listening to products they are comparing. Instead they readliy jump to theoretical consclusions with the intention to denigrate the item that they dislike. Is that naive, dumb or what? Could be, and most likely, an intentional, dubious act. They don't want to know the truth yet act like they do because the truth may very well hurt their real intentions. Well, I'm not fooled.
Edits: 07/25/13 07/25/13 07/25/13
"Well, I'm not fooled."
I am not fooled either!
Isn't mitchco in effect "measuring the cable" by using Audacity as a "high resolution storage scope?"
No. Driving a DAC, be it with with a computer or a CD transport, is a real-time process. As such, it has critical temporal parameters (the dreaded J-word) to which, as a software tool, Audacity pays/ can pay no attention.
OTOH, though tools such as TL describes can offer an explanation for perceived differences, they are most unlikley to allow you to predict when observed differences will also be perceptible. For that, the only tool that works is people.
The article you cited discussed how far from "bit perfection" one can go before certain types of distortion become perceptible. Two points: first, for all the figures and graphs and numbers (not to mention some questionable experimental design), the author relied on subjective assessment of perceptibility, same as the rest of us. Second, what he's writing about is very different to Steve's points about perceptible differences in music-playing software.
In the latter case (upsampling issues to one side), "bit perfection" is assumed. What You Send Is What You Get. Anything less is not worth testing. What you cannot assume is that data are delivered with perfect timing. Inevitably, they're not.
It matters - Steve has a fine ear but even cloth-eared types like me can readily hear differences between music players.
N.T.
When they're played back on two different (software) players, that vary in their abilities...
"Asylums with doors open wide,
Where people had paid to see inside,
For entertainment they watch his body twist
Behind his eyes he says, 'I still exist.'"
.
This forum is like a broken record...... repeat, repeat, repeat.
Measurement devotees... "it outputs the same bits so it must sound the same; bits is bits."
People who actually listen... "Hey, it sounds different!"
.
The argument is not about "bits" but about "waveforms." Each one of your songs has it's own, unique waveform and it is the waveform that, after passing through your stereo, ultimately informs your transducers how to vibrate so that you hear sound.
My point is not that "bits are bits," but that if you feed identical waveforms into the same stereo you should hear identical sound coming out. Try it for yourself: play the same song twice. Does it sound the same to you or is it different each time?
Over at Computer Audiophile, mitchco performed a pretty clever test that showed that the output from different, bit perfect media players was effectively identical. That is, playing the same song on different players was the same as playing the same song on the same player.
If you are playing the same song on the same system, shouldn't it sound the same each time you play it? For some reason this observation is controversial and even engenders hostility.
I think it's pretty cool that media players have gotten so good as to be able to have outputs that are identical. That's one less thing to worry about in the playback chain. Further, since disparate products from different companies all point to the same result we can start to get a better idea of just what exactly is coming out of our PCs and going to the DACs.
nt
I love the music of ... ... Franz Joseph Haydn
bully naysayers who read on the internet, (instead of listening for themselves), try to claim otherwise....
"Asylums with doors open wide,
Where people had paid to see inside,
For entertainment they watch his body twist
Behind his eyes he says, 'I still exist.'"
Edits: 07/23/13
"Throughout this series of articles mitchco makes a pretty persuasive case that there is no difference between the output of "bit perfect" media "
players such as JRiver, Jplay, or Foobar."
Do these programs sound the same to you? Not to me.
"Do these programs sound the same to you? Not to me."
Come on Steve they all sound the same!!! And Lucy sounds exactly like a Great Dane!!! He measured it...
Of course they all sound the same to him. In fact, it's not even necessary to listen at all to determine that (so he hasn't).
Meaningless, nonsensical measurements, made with inappropriate equipment, that do not correlate with audibility in the slightest - is all that's needed for him and his kind.
The only question I have - what is he doing here? What's the motivation to discuss things, if everything sounds exactly the same?
excellent: and moved to the subject for added emphasis!!
"Asylums with doors open wide,
Where people had paid to see inside,
For entertainment they watch his body twist
Behind his eyes he says, 'I still exist.'"
With some people the psycho heavily outweighs the acoustical .
I love the music of ... ... Franz Joseph Haydn
Could be. Perhaps physiological in some cases.
With all respect, I find mitchco's demonstration that there is no difference down to -144dB between the bit perfect output of JRiver, Jplay and Foobar to be far more persuasive than your claim that you can hear a difference between them.
mitchco's comparison of Foobar to JPlay:
http://i1217.photobucket.com/albums/dd381/mitchatola/FoobarvsJPlay_zps7a294978.jpg
Note that the demonstration side steps any question of which is "better." Instead, it asks, "Is there any difference?" The flat line at -144dB would seem to indicate that no, there is not.
mitchco's comparison between JRiver on a Mac and JPlay on Windows.
http://i1217.photobucket.com/albums/dd381/mitchatola/JRiverMacvsJPlay_zpsf4c04919.jpg
Again, nothing but a flat line at -144dB.
My original question still stands: For people to be able to actually hear a difference, shouldn't there first actually be a difference?
"With all respect, I find mitchco's demonstration that there is no difference down to -144dB between the bit perfect output of JRiver, Jplay and Foobar to be far more persuasive than your claim that you can hear a difference between them."
Then I feel truly sad for you! Can you also give some measurements to demonstrate love? How about the human condition? Are we so insecure that we need measurements to prove what we know? smh
.
"Asylums with doors open wide,
Where people had paid to see inside,
For entertainment they watch his body twist
Behind his eyes he says, 'I still exist.'"
Topics like this seems to draw out the usual suspects, now myself included. Let's see how this goes again: If we can't measure it...blah, blah..blah and if measurements tell no difference then more blah blah blah. Well, ain't that sweet? Let's use this same mentality when shopping for food instead of audio products.We go to the grocery store. While looking for food to purchase some of us look at the label for ingredients and some of us don't. We buy, pack it up and go home for a taste. Now in all honesty, what is most important: a lable telling me how something might taste or my friggin taste buds telling me how something tastes? Duh, and double duh!
Therefore, he who thinks we are better off eating labels than the food itself should take heed. We don't care what you say (at least I don't, so, don't insult our intelligence).
Edits: 07/23/13 07/23/13
Darn I sure do like that food analogy post...and agree with it. About the only measurement I do pay attention to these days is my little SPL App on the iPad making sure I am not blasting my old ears away. In this case sometimes I don't realize how loud I have let the volume creep up to
"We don't care what you say"
Did you mean, What I say???
Is this bit perfect enough for them?
> "We don't care what you say" <> Did you mean, What I say??? <
Of course not Bob_C, you are good with me as is Ray Charles :). I was venting in regards to the rehashed bull constantly spewed forth by the one who has an overabundance of bile in his bloodstream thus affecting the ability to hear.
Now, while I'm on the food analogy bit, a point to consider. First the premise.
I have two bananas from the same tree. One of them picked a couple days before the other. They are both ripe, ready to eat. However, the two bananas taste different even though they each have similar chemical compositions (fiber, protein, polyunsaturated fatty acids, amino acids, and potassium). Why the difference in taste? Perhaps there is no difference in taste. Yet, that is not true because we all know that older bananas taste sweeter and have a softer texture.
Now this argument, as corny as it sounds, shows that we have not taken into consideration the particular variables that differentiates the two bananas. Without such, we would assume that both bananas should taste the same. However, after knowing what oxidation can do to fruits we do know why they taste different.
Until measurements tell us why or how software programs sound different we will correctly assume that testing is immature.
Edits: 07/23/13 07/23/13 07/23/13
Hi,
Oh.... So we are talking Bananas!
Now there is something the measurement crowd will understand!!!
I hope our friend with the ear infection does...
Even Bingo the Chimp understands :)
best regards
Bob
... disrupting discussion with "everything tastes the same" blathering?
People not interested in fine foods DO NOT go to the forums where they are discussed - why are all these "all sounds the same" drawn to fine audio?
Any ideas?
"My original question still stands: For people to be able to actually hear a difference, shouldn't there first actually be a difference?"There is a difference, but these measurements don't adequately explain what's going on. Since there is a wide range of systems and setups, not everyone will hear a difference between music programs. Given that all of these programs sound pretty good, this fact doesn't keep me up at night.
Science continually changes explanations for the physical world. I'm not against measurements, but if they don't explain what I'm hearing, I don't take them that seriously.
Edits: 07/23/13
"There is a difference,"
OK, WHERE is the difference? If the two files null perfectly, doesn't that mean they are identical? If they are identical then how can they sound different? Wouldn't you be surprised if you made no changes to your system, played the same song twice, and heard differences between the two? My point is that, so far as can be shown, Foobar and JPlay were providing the same output to mitchco's system. The surprise would be if the two did not sound the same.
"but these measurements don't adequately explain what's going on."
Mercman, I'm NOT trying to pick a fight. With all respect, if you can be dismissive of measurements, may not I be dismissive of individual claims? I mean, turn about is fair play and all that, right? What's sauce for the goose is sauce for the gander? I'd say that the measurements adequately explain what is going on. What the measurements don't explain is what people claim is going on. How could they? People can claim whatever they want. People have imaginations and biases. People have opinions. Audacity has none of that. It just captures what went through it and displays it for us to see and to analyze.
In this case Audacity lets us conclude that there are no differences between the outputs of the compared players. If you ask me, that's a good thing. That three different products on two different operating systems can all produce identical outputs is a stunning technological achievement. I mean, Wow!! Try to find two brands of phono cartridges that sound alike. I think mitchco's findings should be cause for celebration in this forum, not the basis for a dispute.
Failure to measure a difference does not mean there is a no difference. In this case, the wrong tools were used for the measurement.
There are plenty of dogmatic fools who place their faith on second hand "theories" that they don't understand, rather than taking the practical approach of using their God given senses. In other fields such as aviation these people end up killing themselves or others. With audio, that's not the case...
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Tony, did the measurements crowd ever stop to consider that two speakers can measure absolutely RULER FLAT, yet sound COMPLETELY different????
One thing to consider is how each program influences the computer. Is the CPU activity with each program the same? How does the program influence the other processes running in the background? How much "noise" is generated and passed to the DAC?I know that Rob Robinson of Channel D tries to achieve a "steady CPU state" for optimal sound.
This is just one item that can influence the way a program works with a computer and results in different sound.
Then there is the topic of time. More things to consider.
Edits: 07/23/13
too many variables....
The only thing that matters is the final result. As in the end, and until something changes, this infancy stage of computer software + interface + outboard DAC(s) as transports, is still 1 step down from previous state of the art sources.
No software companies, and no hardware companies have established themselves with years of the foundation of a Meitner, LAMM, VAC, Avalon, Karma, etc. Those elements of synergy, & gestalt of consistency over time reach far beyond the somewhat experimental code of a playback program.
When people talk about these things, and they get reviewed, they are reviewed as an individual item, which further clouds the experience.
It's all about, and only about, the experience. Either the complete experience is worth it, or it is not.
Again, this is very similar to the bullcrap (explanation) about software based "error correction" in a digital disc transport. As we've seen, "error correction" does NOT compensate for using a crappy motor, a cheap disc clamp, or not using isolation/vibration control devices.
You can't "fix" certain kinds of problems with "better" software, and what happens in the lab, doesn't necessarily equate with what happens in the living room.
"Asylums with doors open wide,
Where people had paid to see inside,
For entertainment they watch his body twist
Behind his eyes he says, 'I still exist.'"
because most are just speculative.
Some requests for 'explanations' here remind me of a former boss who insisted that management processes were more important than the results. Guess what, he was a 'business management expert'.
I compared Jriver for OSX to Amarra. It was good but Amarra edged it out.BTW, I have a customer with a hot-rodded PC that swears that XXHighend beats them all.
Edits: 07/20/13
Been running trials of PM, A+ and Amarra here from a mini with SSD into USB Hex.
Unfortunately, the Hex does not support A+ Integer Mode.
Thus far, I have a clear preference for Amarra over the others. My first efforts using the EQ did not improve on the SQ of the player without EQ, although I need to play around with it more.
I use EQ on all systems with Amarra because the speakers and room usually need it. Vapor Speakers were an exception. Great design.
I use Audiotools to do the analysis.
Is there somewhere with additional guidance on performing the analysis or is the information included with the purchase package sufficient to successfully utilize the program?
Which modules do you find most useful for say, evaluating display rooms at audio shows or for evaluating a home listening room?
Thanks.
It's been a long time since I've listened to Amarra. I'll give it a listen. No native DSD support is disappointing.
Edits: 07/21/13
Amarra finally got it right I think int he latest version, but you can still make it go out to lunch. Much better though.
"I still prefer JRiver 18 for Windows with the infamous JPlay."
Me Too! :)
Steve,
Time to step up your game a bit. You would see a major improvement with a better computer and Win Server 2012 IMO. I am still running an Atom and getting amazing results, but I will be building something faster eventually. I am using a PPAStudio USB card which is a major upgrade to built in USB, and then there are power supply considerations. A notebook is a limitation, but still sounds great. Just think... :)
regards
Bob
I need a Mac that can do OSX and Windows for reviewing. Maybe next year I'll get a new computer. This year I am replacing the amps/preamp and other changes. I also purchased the Analog Dac/Analog Power Base and will be keeping the Crimson.
Nice! So much for negative consumer sentiment. What bad economy? :)
You should still try Sever 2012 with the Audio Phil mods with your Mac.
The OS is a big improvement over Win 8
regards
Bob
Hi Bob,
Could you please explain what exactly is the Audio Phil mods ? where I will find it ?
Regards,
Alexandre.
I just put the link to his page in the other thread. You use Windows Sever 2012. Install the standard server and all your necessary music application,JPlay, drivers etc. Once done, you run the Audiophile optimizer which sets up the OS for maximum fidelity.Phil's email... info@highend-audiopc.com
regards
Bob
Edits: 07/30/13
all I see is
...when you have lost the sense of time and space, then you just arrived
I would say
...when you have lost the sense of time and space, then it's time to stop tweaking
or
...when you have lost the sense of time and space, then it's already too late to go to bed
anyone else have a better ending ?
Maybe this will help you.
.
"I need a Mac that can do OSX and Windows for reviewing."
Yes the Mac is still useful.
"Maybe next year I'll get a new computer. This year I am replacing the amps/preamp and other changes. I also purchased the Analog Dac/Analog Power Base and will be keeping the Crimson."
More toys to play with! :)
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: