Measured evidence that bit perfect playback software alters the analog output of DAC's?

[Superdad]

A "revealing" player sometimes is just making a tiny frequency shift that serves to emphasize parts of the audio that are already there. It isn't really revealing anything so much as emphasizing something.

 

Hmm Paul… If you alleging that some software players are "making a tiny frequency shift that serves to emphasize parts of the audio…", that seems tantamount to accusing them of being "tone controls" and therefore not bit accurate at all. How can that be?

[sandyk]

JRMC seems to rack up there as one of the better and more accurate players, despite J. River's insistence that you can't get better than bit perfect. (grin) That is especially true on the Mac with Integer mode enabled. Sweet.

 

-Paul

 

Paul

It would be interesting to revisit those comments after you try a Linear PSU in your Mac Mini.

 

if a s/w player makes different DACs or music tracks sound the same, then it is obvious where to point the finger.

 

+1

[Paul R]

Pretty much every piece of equipment in the chain acts more or less like a tone control, to a greater or lesser degree. Why should software be all that different? (grin)

 

But yes, causing small frequency shifts is not unknown to happen, though I think it more often happens through distortions in the time domain than anything else. A little delay here, a phase shift there, and voila! Instantly this or that player is more "revealing" or more "transparent" or more "tube like" - though why anyone would want to be more like a tube is beyond me...

 

 

-Paul

 

 

 

Hmm Paul… If you alleging that some software players are "making a tiny frequency shift that serves to emphasize parts of the audio…", that seems tantamount to accusing them of being "tone controls" and therefore not bit accurate at all. How can that be?

[sandyk]

Hmm Paul… If you alleging that some software players are "making a tiny frequency shift that serves to emphasize parts of the audio…", that seems tantamount to accusing them of being "tone controls" and therefore not bit accurate at all. How can that be?

 

Alex C.

That's a leading question. During initial testing with "Silverlight" from NYC around 4 years ago, I used a Silicon Chip designed USB Power Injector kit with a USB Memory stick. The .wav file was reported to sound ultra detailed with a blown out soundstage, and fatiguing to listen to. The 7805 regulator in the original circuit had a 10uF tantalum at the input to the 7805, and a 100nF ceramic at the output of the 7805. Changing those capacitors to electros of values more commonly used with 7805s in audio circuits restored the tonal balance. Paul sometime back was able to change the sound of a file with the same binary data by using drastic measures, which IIRC included massive fragmentation of the file. A new member at the time took Paul to task but he was able to verify those results.

I may be incorrect about this, but I believe that Peter St. may be improving HF response using his software, but still retaining bit perfect output.

Alex

[4est]

I do not recall any to claim that they measure better. If that were the case, then maybe they should provide measurements. As it is, a lot would depend upon when (and what) you consider to be audible. For either Miska or PeterSt that would be a set up. Besides, bit perfect is not their software's purpose anyway.

They aren't being obligated to show their measurements; they (and generally) are being asked if such measurements exist.

 

On the other hand, why shouldn't they be obligated to show measurements that prove that their claims are real - is it really any different to a motor manufacturer having to show that their car does 62mpg; rather than just being able to say "our new car offers better fuel efficiency"? If you were a sports car fan, do you buy a car because it feels quicker (0-60) or do you actually want to have a measured performance? I'm not suggesting the situations are identical but there is a valid element of comparison.

 

 

Yes, but the point is that what Dennis is asking for are not measurements showing what causes a difference, all Dennis is asking for is measurements which show there IS a difference.

 

Now I think about it ... I have a recollection that PeterSt did have some measurements which he said showed difference in the output when using GUI and non-GUI modes for his software (sorry I don't have links for them its just a memory) though I don't recall exactly how they were created.

 

Eloise

[esldude]

Pretty much every piece of equipment in the chain acts more or less like a tone control, to a greater or lesser degree. Why should software be all that different? (grin)

 

But yes, causing small frequency shifts is not unknown to happen, though I think it more often happens through distortions in the time domain than anything else. A little delay here, a phase shift there, and voila! Instantly this or that player is more "revealing" or more "transparent" or more "tube like" - though why anyone would want to be more like a tube is beyond me...

 

 

-Paul

 

None of those would be bit perfect Paul. Unless people have figured out how to control phase or delay without changing bits. The only other variable in playing back the same bits is timing. There is nothing else. Timing that alters frequency response would be pretty severe and easily measured. Noise that effects the clock on the DAC could do some of it, but doing that with precision and in software....quite the trick. And even then such results would be measurable. Either that or we are back to such teeny, tiny, infinitesimal signal changes being hugely audible for some other strange thus far unknown reason which also fails to alter the signal output.

 

So far Miska is the only one showing actual differences measured, and those are from hardware/grounding issues. Unless I misunderstood him he isn't claiming playback software caused them.

[esldude]

well, it's only a very small minority who either won't or can't hear the differences so why bother with measurements. There are thousands of factors that affect the SQ so measuring a couple of attributes won't point you to how to optimise the player - if that was your aim.

 

The aim is to document that these players do change the signal. Claiming they do is a pretty large claim to make in fact. But claiming they sound different means they must be changing the signal. If they are changing the signal it should be measurable. Measuring how the changes differ between different sounding players would perhaps point to what kinds of changes are best or perhaps show deficiencies in playback ability. That would possibly paint the outlines to an optimum target. One a person could shoot for with software and other ways to get the most transparent playback.

 

Now saying a small minority won't or can't hear these changes is making another claim that gets into a usually nasty debate that appears endless. So for my purposes here, to document and characterize what software players change I wish to stay with measurable differences and not discuss sighted listening evaluation.

[Jud]

The question here is not about DACs. Both of these gentlemen's software does far more than a variation on bit perfect playback. If they thought bit perfect done well is enough they wouldn't have gone so much further.

 

True. I would say *very* generally (inviting comments from the developers on anything I have unintentionally misrepresented) for both Miska and PeterSt the ability to be bit perfect is a necessary starting point but not nearly sufficient. Beyond that, they are both concerned with filtering and noise. Miska offers a number of filters, a number of dither selections, and a hardware solution for noise to be used with one's own DAC. PeterSt offers one filter, no express dither selections, a DAC, and perhaps the widest range available of software controls to tailor PC performance and noise.

[esldude]

I do not recall any to claim that they measure better. If that were the case, then maybe they should provide measurements. As it is, a lot would depend upon when (and what) you consider to be audible. For either Miska or PeterSt that would be a set up. Besides, bit perfect is not their software's purpose anyway.

 

Well this gets back to what Eloise said already. The sound from speakers being different, means signal from amp is different, means signal from DAC is different. So saying your software sounds different is claiming a different signal. Which implies they measure different even if we can't agree on what measuring better is. Unless you can come up with some way the sound is different and the signal is not, and one which is controllable via playback software.

 

Looking I think PeterSt says his software is bit perfect. I thought it also did more, but that doesn't seem to be the case.

 

Miska has already said his software can be bit perfect, but using it this way throws away about 75% of the work he has done on it.

[sandyk]

esldude.

I don't suppose that you verified that 100th copy of a digital file that you agreed sounded a little different, still had the same binary contents after all those copies ?

[4est]

Both are capable of bit perfect, but because both are meant to be used as upsamplers it is not the intended use per se. I agree that there needs to be a measurable difference if there is an audible one. The crux lies within how far down into the noise you deem discernible.

Well this gets back to what Eloise said already. The sound from speakers being different, means signal from amp is different, means signal from DAC is different. So saying your software sounds different is claiming a different signal. Which implies they measure different even if we can't agree on what measuring better is. Unless you can come up with some way the sound is different and the signal is not, and one which is controllable via playback software.

 

Looking I think PeterSt says his software is bit perfect. I thought it also did more, but that doesn't seem to be the case.

 

Miska has already said his software can be bit perfect, but using it this way throws away about 75% of the work he has done on it.

[esldude]

esldude.

I don't suppose that you verified that 100th copy of a digital file that you agreed sounded a little different, still had the same binary contents after all those copies ?

 

Well this is actually from a comment in another thread about DAC's sounding the same. That has been some18-20 years back. I believe it was an AD-DA loopback. If I still have the CD I will look and see. Not even sure which Test CD that one is on. If anyone remembers it maybe than can tell us.

[sandyk]

Well this is actually from a comment in another thread about DAC's sounding the same

 

Nevertheless, it is not out of place in this thread despite what the "ill tempered audiophool" may wish to believe.

[esldude]

This is part of a comment from Gordon Rankin on the audiostream Q&A with John Swenson.

 

Q&A with John Swenson. Part 3: How bit-perfect software can affect sound | AudioStream

 

I have edited this somewhat for some of the comment not related to this one. Not trying to bamboozle anyone, you can check the original at the link above.

 

With pretty good arrangements to measure most of what could matter, you will see Gordon Rankin says, "I give up" trying to figure out why bit perfect software players sound different. He then suggests looking at EMI/RFI. He could find no measure that correlates with anything he hears. Now he, apparently like John Swenson, designs empirically. While very knowledgeable people they alter and listen to detect changes if a change was worthwhile.

 

Now myself, I would begin to wonder about that listening being correct. They appear to have no such doubts.

 

Measuring and characterizing EMI/RFI is a lot messier an endeavor than measuring noise on grounds. Plus moving and or shielding items should make a big difference in its effect. Move a computer from one foot (30 cm) to 20 feet (6 m) away and EMI should drop by factor of 400.

 

So this isn't measurement evidence of software player differences, but rather a finding that there aren't differences. Just the reverse. It is not definitive proof there is no difference. But it narrows down where those differences must lie. Gordon's results would appear to narrow it down to something very tiny in time or amplitude indeed. I have to ponder how something in those tiny time or amplitude differences could be so largely audible.

 

 

First a little clarification, USB packet jitter is the timing between packets. USB Jitter is the movement of framed data and EYE pattern (the ability to decern the difference between a 1 and 0) from ideal. Audio related jitter error is the re-serialization of the received audio data and put into an audio format like I2S.

 

John this is my crazy USB test set:

 

MacBook Pro (dual boot) <==USB Analyzer==> DAC--->Prism dScope III

 

Symmetricom jitter/phase noise analyzer

 

Tektronixs MSO4 Scope with Audio Module and USB Module. Audio allows me to look at I2S framed data, USB module allows testing of USB EYE patterns and data in Full Speed and High Speed networks.

 

Two years ago I posted that USB Packet jitter really didn't happen. With the USB Analyzer I can see the variation of packets sent and it's less than 1ns on High Speed links. FYI... Full Speed we receive data frames every 1ms. High Speed we receive 8 packets per every 1ms (every 125uS) microframes.

 

I sent a email to John Atkinson and Charlie Hansen saying I give up what's making the applications sound different or for that matter file type sound different. To me my research showed that more processing made for worse sound. That is why an ALAC or FLAC file will not sound as good as a flat PCM file like AIFF/WAV does.

The data found in the files and on the USB link were identical with identical timing. The data received at the DAC and verified on I2S was the same. The Symmetricom found the bit clock jitter to be the same.

 

To me I think we need to look harder at what is going on here. I also think the term JITTER to reflect all digital errors to be really lacking at this point.

 

~~~

 

snippage at this point.

 

I think that maybe RFI/EMI, power spiking is a more relevant area that should be looked at.

 

Thanks,

 

Gordon

[mayhem13]

To what purpose however? Miska basically builds DACs and matching software systems. So does PeterSt. So do a few others around here. It often seems their opinions, quietly voiced but glaringly present are ignored. At the basic level, why would either of them have to build their own DACs if they believed that all DACs sounded the same?

 

-Paul

 

Maybe you didn't understand the post?........my query would be for them to 'explain' why posting such measurements would be detrimental to their respective businesses? It may provide some insight into what, if anything is happening in bit perfect software. At least their would be some supporting evidence that such measurements do in fact exist as queried by the OP and this thread. Can't see a logical arguement against it.

[sandyk]

At least their would be some supporting evidence that such measurements do in fact exist as queried by the OP and this thread.

 

Why should any software or hardware designer jump to attention every time some dude in a forum somewhere demands proof of their claims ? It's not as if is likely to result in further sales for them.

[Paul R]

Um- no. You do not have to change the data to change those in the output. Remember, you can play all you want with timing.

-Paul

 

None of those would be bit perfect Paul. Unless people have figured out how to control phase or delay without changing bits. The only other variable in playing back the same bits is timing. There is nothing else. Timing that alters frequency response would be pretty severe and easily measured. Noise that effects the clock on the DAC could do some of it, but doing that with precision and in software....quite the trick. And even then such results would be measurable. Either that or we are back to such teeny, tiny, infinitesimal signal changes being hugely audible for some other strange thus far unknown reason which also fails to alter the signal output.

 

So far Miska is the only one showing actual differences measured, and those are from hardware/grounding issues. Unless I misunderstood him he isn't claiming playback software caused them.

[Paul R]

Well, if you have something that was pretty unique and you could sell, would you publish all the internals and details?

I sure wouldn't. In fact, in stuff I have written that sells commercially, I don't. That seems like a perfectly clear and obvious line of reasoning to me, but I know that sometimes people do not think of software as having any value.

 

I usually remind those people that software is what is calculating and printing their paychecks....

 

-Paul

 

 

Maybe you didn't understand the post?........my query would be for them to 'explain' why posting such measurements would be detrimental to their respective businesses? It may provide some insight into what, if anything is happening in bit perfect software. At least their would be some supporting evidence that such measurements do in fact exist as queried by the OP and this thread. Can't see a logical arguement against it.

[Paul R]

There's the odd part Dennis - instead of doubting yourself, perhaps you should trust yourself - and your ears - a little bit more. All wonder is not gone from the world you know.

 

Gordon is a very talented designer, and his DACs and amps are coveted around the world, even the little ones like the Proton he designed and built to prove something could be done.

 

-Paul

 

 

This is part of a comment from Gordon Rankin on the audiostream Q&A with John Swenson.

 

Q&A with John Swenson. Part 3: How bit-perfect software can affect sound | AudioStream

 

I have edited this somewhat for some of the comment not related to this one. Not trying to bamboozle anyone, you can check the original at the link above.

 

With pretty good arrangements to measure most of what could matter, you will see Gordon Rankin says, "I give up" trying to figure out why bit perfect software players sound different. He then suggests looking at EMI/RFI. He could find no measure that correlates with anything he hears. Now he, apparently like John Swenson, designs empirically. While very knowledgeable people they alter and listen to detect changes if a change was worthwhile.

 

Now myself, I would begin to wonder about that listening being correct. They appear to have no such doubts.

 

Measuring and characterizing EMI/RFI is a lot messier an endeavor than measuring noise on grounds. Plus moving and or shielding items should make a big difference in its effect. Move a computer from one foot (30 cm) to 20 feet (6 m) away and EMI should drop by factor of 400.

 

So this isn't measurement evidence of software player differences, but rather a finding that there aren't differences. Just the reverse. It is not definitive proof there is no difference. But it narrows down where those differences must lie. Gordon's results would appear to narrow it down to something very tiny in time or amplitude indeed. I have to ponder how something in those tiny time or amplitude differences could be so largely audible.

 

 

First a little clarification, USB packet jitter is the timing between packets. USB Jitter is the movement of framed data and EYE pattern (the ability to decern the difference between a 1 and 0) from ideal. Audio related jitter error is the re-serialization of the received audio data and put into an audio format like I2S.

 

John this is my crazy USB test set:

 

MacBook Pro (dual boot) <==USB Analyzer==> DAC--->Prism dScope III

 

Symmetricom jitter/phase noise analyzer

 

Tektronixs MSO4 Scope with Audio Module and USB Module. Audio allows me to look at I2S framed data, USB module allows testing of USB EYE patterns and data in Full Speed and High Speed networks.

 

Two years ago I posted that USB Packet jitter really didn't happen. With the USB Analyzer I can see the variation of packets sent and it's less than 1ns on High Speed links. FYI... Full Speed we receive data frames every 1ms. High Speed we receive 8 packets per every 1ms (every 125uS) microframes.

 

I sent a email to John Atkinson and Charlie Hansen saying I give up what's making the applications sound different or for that matter file type sound different. To me my research showed that more processing made for worse sound. That is why an ALAC or FLAC file will not sound as good as a flat PCM file like AIFF/WAV does.

The data found in the files and on the USB link were identical with identical timing. The data received at the DAC and verified on I2S was the same. The Symmetricom found the bit clock jitter to be the same.

 

To me I think we need to look harder at what is going on here. I also think the term JITTER to reflect all digital errors to be really lacking at this point.

 

~~~

 

snippage at this point.

 

I think that maybe RFI/EMI, power spiking is a more relevant area that should be looked at.

 

Thanks,

 

Gordon

[esldude]

Um- no. You do not have to change the data to change those in the output. Remember, you can play all you want with timing.

-Paul

 

Yes, but are you saying they can alter the timing via the playback software with precision without breaking the SPDIF connection in the process? I don't think so.

[esldude]

Maybe you didn't understand the post?........my query would be for them to 'explain' why posting such measurements would be detrimental to their respective businesses? It may provide some insight into what, if anything is happening in bit perfect software. At least their would be some supporting evidence that such measurements do in fact exist as queried by the OP and this thread. Can't see a logical arguement against it.

 

It strikes me that offering measurements to prove a given software really helps could be beneficial. On the other hand when selling things, the customer often doesn't know either, so it wouldn't do nearly so much for sales as having someone in the biz (like mag biz) say, "why this player made me re-listen to my entire collection such a revelation in the sound improvement was heard".

 

The other possibility is like Gordon Rankin they could find no measurement.

 

And finally if people think they hear improvements, and customers put down money they have nothing to gain. Though again one is left with a very murky design and revision process in that case. Still as long as it seems to work, no reason to enter a measurements arms race.

 

Of course a few of these are now firmly entrenched, and those handful will roll off people's tongues as suggested when a newbie asks. Eventually some startup without the built in rep would find it in their best interest to show some measurements, and show their unknown software is in fact better than the industry standards.

 

And then there is the dastardly, mean, skeptical perspective. They know it does nothing, but as long as the charade continues they make happy customers which makes for happy software writers. No measurements desired in that scenario. And look at how long that has worked in wire. Occasional pseudo-science measures, white papers with lots of hot air and little substance, some talk of materials or winding geometry. Going strong to this day with no signs of letting up. Every year more expensive cables are out there than the year before. And while this isn't the DAC thread, wow, I know it isn't exactly news, but I have read in the past week of a $50K DAC, Stereophile has a review of a similarly expensive one in this issue (the whole thing USB, upsampler and transport is more than $100k), and another at $120k is being discussed here at CA now. Plus the first one in my list is available with extra abilities on custom order that can push that to $250k, yes a quarter million for one DAC. So regardless of whether it works or not, plenty of room for software to go yet.

[Paul R]

Think again - certainly you can. Depends upon the code you use. It is easier with USB connections though.

 

Yes, but are you saying they can alter the timing via the playback software with precision without breaking the SPDIF connection in the process? I don't think so.

[esldude]

Think again - certainly you can. Depends upon the code you use. It is easier with USB connections though.

 

So let me get this straight. You are feeding over USB, usually here we are referring to an asynch connection, into a device which will reclock the bits it is fed (I believe at least some of these devices use a small amount of buffering). And you can in software change the code and play with the timing of such a device? I still don't think so. Most such devices have their own local clock running off a crystal. Changing the code won't mess with that unless it does so enough to have a dropout in the SPDIF bitstream flowing out of it.

[Superdad]

Nice to find everyone being so civil in the debate today. I do so wish that some of you--especially Dennis--lived closer to me in California. Honestly, in less than an hour I could demonstrate so clearly the ways in which a half dozen or more of these crazy things make a material difference in the presentation and "reality" of the music. I would not in the least be able to measure or point you at exactly what to measure, but I have no doubt that all skeptics would walk away scratching their heads at what they hear with their own ears. Even Ethernet cables between two computers with one sharing its hard drive for music transport. John Swenson spent the weekend at my place early this month and that was one comparison that floored him because it makes no sense!

 

Good evening to all,

AJC

 

P.S. SandyK: I still sense you pushing the idea that a better power supply (for the computer in this case) will reduce the differences heard between other variables. I continue to find that the opposite is true--as it has always been with just about everything in audio: The better you make things, the more readily differences between other elements will be heard.

[Paul R]

MM- I'm sorry Dennis, but what you think can be done, and what can be done are not the same. One can do just about *anything* in software, including mucking about with the drivers. Not even particularly difficult to do if one knows what one is doing. Rather different for S/PDIF and USB, but the idea is the same. And yes, there are limits to how much you can do and still have the system operate without error.

 

It doesn't take much change at all - think in terms of jitter to get an idea of the scale. And there are other, better things you can modify to make changes too.

 

For example, we used to program music on AM radios by mucking around with processor, memory, and IO activity in computers. (Bigger computers than you are used to today of douse, like PDP 11/45s...) That was a game we played decades ago.

 

Most machines are better shielded now, but it is quite possible to do the same thing. If you mess about with HDMI it is *very* easy to do, though you had best put a test loop on the cable instead of a video monitor. Modifying system activity, and different types of system activity, is a quite plausible way to change the sound and still retain a bit perfect data stream.

 

Actually, I am a little surprised you even have a question about that- but then I guess unless you have been neck deep in data transmissions it may not be quite as blindingly obvious. And while it is easy, it is easy only when you already know what to do. I might have assumed there.

 

I don't have any special knowledge about what the player guys are doing, but all the "big" players are here on CA. I was not being facetious or ornery when I suggested you ask them.

 

-Paul

 

 

 

So let me get this straight. You are feeding over USB, usually here we are referring to an asynch connection, into a device which will reclock the bits it is fed (I believe at least some of these devices use a small amount of buffering). And you can in software change the code and play with the timing of such a device? I still don't think so. Most such devices have their own local clock running off a crystal. Changing the code won't mess with that unless it does so enough to have a dropout in the SPDIF bitstream flowing out of it.