Measuring objectively real differences in files with identical checksums

[jabbr]

I tried to listen for differences in sound from two but identical files, but couldn’t hear any. Then I realized that my file system (ZFS) automagically maps identical files to the same location (actually it does block level de duplication) , so I can’t even test this. 

[jabbr]

6 hours ago, Archimago said:

 

Well then, that "version" stored on your file system could be the absolute best or absolute worst copy of the music...

 

Which is it based on the theory of how this is supposed to work? Or is it all just "different" and equal with no relative judgment possible!?

In all seriousness files stored on media could certainly, no, will have different levels of readout noise. That could be audible. However, the readout noise is not preserved with file copy. In the case of ZFS, the data is also mirrored, and read into RAM cache. In my case, from RAM cache, it is transmitted across network so whatever is going on the NAS is entirely electrically isolated from the streaming endpoint. My network is 10G fiber and assuming my switch meets the compliance testing standard, there is extremely little noise in the bits. Of course there is zero common mode noise  

 

Absolute best or worst stored in my magnetic media, as long as the bits are readable, the bits sent to my DAC do not reflect this noise with virtual certainty (we have no reason to invoke entanglement 😂) and this issue is moot for me.

[jabbr]

On 2/17/2020 at 8:41 PM, kumakuma said:

I agree. I have received test files from the individual in question on several occasions and have tested them using every means available to me but I can't find a difference. I'd really like to know what I'm missing here.  

It’s really quite easy if you have the equipment. Make two copies on a CD and then magnify and look at the pits. They will be different. Or measure the magnetization, again different. 
 

At a fine level all digital bits are represented by analog processes and the analog is different from bit to bit.

 

(of course digital systems are explicitly designed to deal with this)

[jabbr]

Just now, plissken said:

 

I'm sure the 7nm lithography they use to make IC's matters to. Best get one cherry picked from the center of the wafer.

Snark aside: 

 

1) are there differences in bit-identical files?: yes, always

2) are the differences meaningful for SQ in my system?: no, never 

[jabbr]

6 minutes ago, Teresa said:

I just want to state for the record that I expect the music files I've created to not change sound. Thus, I'm praying that no one finds any differences in files with identical checksums objectively or otherwise measured. 

Think of your music files like digital photographs. They might appear different in different screens, or when printed out differently, but all of the information is perfectly preserved. 

[jabbr]

34 minutes ago, John Dyson said:

The only time that there is a difference in actual sound is when the audio data in the files is different and/or the reproducing system/environment is different.

What is the basis for this dogma? 
 

A CD has pits on a surface. The pits have different characteristics. 
 

What you are calling “audio data” is a mapping of one set of pits having certain shapes into a pile labeled “0” and the other pits into a pile labeled “1”

 

Audio files are convenient digital abstractions but the CD surface us analog.

 

You are assuming that two CDs each mapping into the same piles of 0 and 1 will be reproduced the same. What is the basis for your assumption? Do you believe that every CD audio playback system is perfect?

[jabbr]

4 minutes ago, kirkmc said:

The person was talking about files, not CDs. CDs can certainly have problems in their plastic and pressing, though these would not affect the "sound" but rather introduce artifacts. 

Do what you can “artifacts” change the sound? Clicks, pops are sound right?

 

Files are an abstraction. Let’s get real.

 

*** as I’ve said many many times, my own system is not subject to these issues of analog differences between files. My own files are mirrored at block level and scrubbed which also helps with checksum errors over time from cosmic rays etc ...

[jabbr]

7 minutes ago, kirkmc said:

Unless you're just trolling... 

no this is the thread title, I’m talking about measurable differences between files with identical checksums ... in order to do that you need to look at an actual real world files stored on a media ... obviously the numerical abstractions are the same. Surely you recognize that a file is an abstraction, no?
 

Let me restate this for you:

 

“Files with identical checksums should not sound different in a well engineered digital audio system“

[jabbr]

4 minutes ago, kirkmc said:

So why mention CDs?

For @alfe 😂

[jabbr]

1 minute ago, John Dyson said:

If you do two reads of the same CD, and the data is the same in the two reads, then the results will be the same.  There is no secret pathway for jitter noise to propagate through the data path, well unless you are talking about bad grounding, weird conducted noise problems, or in the worst case RF radiation.  (That is, really bad design -- jitter fixes are in the realm of better grounding noise control -- most circuits don't have neough sampling window issues to cause errors.)

 

If the data is read from a CD differently in two reads, and ECC doesnt' catch it, or the ECC scheme is hamhanded with poor buffering, then you can get error propagation, but not jitter.   This is either cr*ppy equipment or a poor quality CD that reads differently very often (or a dirty one at that.)  There can be sporadic errors anywhere, but I hope we aren't talking about that kind of thing as an important behavior.

Jitter???

 

I'm not talking about any of this as an "important behavior"

3 hours ago, jabbr said:

“Files with identical checksums should not sound different in a well engineered digital audio system“

 

The title of this thread is "Measuring objectively real differences ..." and I am saying that give me two copies of a file stored on any media, and I can measure (given proper equipment) "objectively real" differences (at the analog level) between any two file copies.

 

Y'all are missing the point.

 

These differences do not have a practical effect on the output of a well engineered digital audio system.

[jabbr]

18 minutes ago, John Dyson said:

I am speaking data and data files on a storage medium, and a CD stores audio data similar in some ways as files.  IT IS dogma when you start talking about jitter propagation, unless you are talking about true data errors.

 

Anyone who actually knows how the errors and data propagation work -- jitter is all factored out of the mess, unless it causes errrors...  I know, as I do that kind of thing at the lowest levels -- no problem.

 

 

Have I mentioned jitter propagation??? You must be reading something into what I've wrote. My own system, and I've said this many times, uses 10Gbe optical Ethernet, and the specified compliance testing explicitly measures for propagated jitter -- and ensures this doesn't exist -- this is called "stressed eye pattern" ...

[jabbr]

3 minutes ago, John Dyson said:

'Readout' noise doesn't propagate through the data, but is the result of poor grounding or other bad EE design.  Don't mistake various side-noise sources as having anything to do with the 'data' per-se.   If you have system noise, then chase down the problem, but the file reading method or where it comes from has NOTHING to do with noise or jitter, unless it is a really attrocious design where the diskdrive radiates energy or causes so much conducted noise through a common ground that you can see it.  Note that a CPU can have 100-200 amp spikes, but the noise from them are also well controlled also.  A 10ma glitch (changing into a voltage, or coupled to the ether as radiated) shouldn't be a problem, unless it is a wiring, bad circuit board or other similar problem.

 

John

 

 

 

I can't tell if you are trying to agree or disagree with what I wrote...

[jabbr]

2 hours ago, John Dyson said:

 

I aplogize if I misread what anyone wrote.  I feel really bad when claims become metaphysical about how noise can propagate.   I get a little heavy when try to make sure that things stay 'real' and based on the world -- not an alternative idea of reality. 

 

No problem. I am trying to be very clear about what is real, and if I speculate, state that clearly. 
 

It’s abundantly evident that there is a serious rift between so-called objectivists and subjectivists here. I read people on both sides stating dogmas as facts without examination. 
 

The whole issue of files and file formats having “sound” is one of the fault lines. I’m trying to shed light not heat on these arguments. For example my file system may compress data on disc and decompress to memory — files really are a useful abstraction so we shouldn’t get caught up on these details and just use a well designed network. No noise on my NAS makes it to my DAC!

[jabbr]

5 hours ago, John Dyson said:

The pits represent a complex digital coding which either produces errors or accurate signal after proper demod.  CDs aren't like laserdisks where the noise pollution in the signal can reach the target (even after massaging with TBC.)   CDs are a totally different animal, where bits are either erroneous or not -- there is no in-between in the case of CD data.   CD data comes in coherent blocks, and if there are little 'wobbles' in the data, then the entire block (pretty big chunk of data) is rejected or attempted corrected back to data-perfection -- NOTHING in between.

 

Right, we all know about digital circuits. You are repeating the digital dogma.

 

Let’s not talk about bits because that’s just not helpful in understanding what noise may or may not be transmitted in a digital circuit. You need to look at the circuit from an electrical point of view. Are all pits identical (no) — how is a pit converted to a voltage. Are all the voltages either exactly 0V or 3.3V or 5V?

 

Its easy to accept the dogma with absolute certainty. It’s much harder to prove the dogma with equal certainty.

 

If @alfe were still here, he could give much more clarity from an electrical POV.

[jabbr]

4 hours ago, John Dyson said:

Here we go -- do you hear the 5msec jitter in the DHNRDS?   That is how much (AND MORE) jitter that is happening in the DHNRDS all of the time.  Why does it not make any difference?   Buffering to the final clock. 

Could you define exactly what you mean by jitter here? There are different types of jitter eg correlates and random ... and then people take all sorts of liberties with so called jitter in software. Are you introducing time domain fluctuations? How can software introduce jitter exactly? 

[jabbr]

7 hours ago, John Dyson said:

In fact, there are many places where multiple parts of the audio are all separated and then recombined -- no-one can hear it.  You would not believe how violent the DHNRDS is to the signal -- it is still better than a true DolbyA.   I guess that someone who believes in audio-religious dogma might have problems making the project work -- but there is a big difference between dogma, and understanding the reasons for the mistaken beliefs.

Often software processing is not being played in real time. In those cases why would I care how long it takes to process a time sample because it’s just written to a file. When the file is played out, and the playback software properly buffers, the “jitter” should only be an effect if the hardware.

 

Unless you are using another definition of “jitter”. Perhaps try not to explain using prose such as “violent”. Suppose a pure tone input, are you saying there is peak widening on output, such as occurs with random jitter? It’s still not what I call jitter, rather frequency blurring.

[jabbr]

2 hours ago, sandyk said:

Jon

 The designer of CPlay for Windows actually discussed S/W Jitter some time back without delving deeply into it's causes . It's also most likely the reason that Foobar 2000 sounds 2nd rate compared with JRiver 26 for example.

 

Alex

Software can introduce all sorts of distortion if it wants to but calling this “jitter” confuses the issue. I mean I guess you could call anything jitter at this point.

[jabbr]

7 hours ago, John Dyson said:

It is where each step in the process has that much jitter and more.  I am speaking of EXTREME time slew rates of zero to full in one clock or less..  Little jitter is easy, the mass 'jitter' that I deal with can only be a deal breaker if the delays become extreme and buffers empty.   There is ZERO time coherency until the final clock (the output sample rate), just like normal HW digital systems work.   In software or hardware, it is all the same...  It is all about the final clock.   That final clock is a resynch point which then becomes unimportant once it is reclocked again, eventually into the final D/A.   The internet propagation is similar - it doesn't make any difference how the accurate digital data gets there, it is alll about the final clock (and buffers not being emptied.)

I have no idea which clock you are talking about. Do you mean the 4 GHz CPU clock that runs your software? Are you internally modeling a clock? You may call it a clock, but it’s not an actual clock, rather software. Right? Please explain.

[jabbr]

Look this is a perma discussion. I am saying that the same checksum identical file on two different CDs will have objectively measurable differences in the pits. This shouldn’t be controversial. There must be a Law of Audiophile discussions that eventually “jitter” is introduced into any discussion of given enough time. 

[jabbr]

15 hours ago, sandyk said:

In my case,  I was talking about adjacent  pairs of wav files on the SAME CD-R, which is what Barry was supplied with and reported about .

 

First and foremost, there is ZERO evidence that the differences in pits between two copies of the same (checksum identical) files somehow makes its way onto a hard drive or across a network. I understand that you hear differences but here on the Objecti-Fi subforum, we would ask for a measurable difference, and there has been ZERO demonstration of objective measured differences. For the sake of this discussion, I would accept an oscilloscope measurement or another piece of actual test equipment and am not interested in listening based experiences i.e. subjective.

 

Second, sure there are easily measurable differences in pits even though the pits encode a "0" or "1".

[jabbr]

On 7/12/2020 at 7:00 PM, sandyk said:

I am damned if I do, and damned if I don't.  I get it that NOBODY likes their long held POV challenged, yet will spend all day arguing with a keyboard instead of a few minutes checking out supplied comparison files..

Alex,

 

I did listen awhile ago and couldn’t tell a difference. I’m not going to listen to each incantation nor look at each file. 

 

Regardless, this is the Objective subforum and we should be talking about objective measurable differences, not subjective impressions. If you can’t produce objective data, that’s ok, just don’t discuss here.

[jabbr]

On 7/16/2020 at 7:20 PM, sandyk said:

This thread should never have been started in this Area of the forum as it was a thinly disguised personal arrack

Good arrack is tasty.

 

Please do not endlessly repeat that I refuse to listen to your files because I have and do not hear a difference. Do not accuse my equipment of being inadequate to hear the differences because that is simple offensive.

 

I agree that it’s best for you to avoid having objective discussions, but if you do please try not to be offensive.