Can two audio files with the same checksum, played from the same devices, sound different?

[Jud]

 

Imbedded jitter - don't buy this one. Jitter has a fundamental criteria for existing : time. It is not possible to imbed and capture jitter in a stationary object where the time scale is 0. Voltage disturbances, amplitude irregularities, rounding errors (sloping wavefronts) magnetic media saturation effects, yes, these can reside in the file at the time of storage. Depends of course how bad these artefacts are and whether the playback or storage system ignores these errors.

 

 

So let's think about why an engineer who designs both audio electronics and data storage hardware (John Swenson) apparently disagrees. How does jitter manifest on an oscilloscope? Or to put it another way, if due to jitter the sample is taken at time t-n rather than time t, what is the measured amplitude? If the amplitude is falling, the measured amplitude at t-n will be higher than at time t. If the amplitude is rising, the situation will be reversed, and the measured amplitude at t-n will be lower than it would have been at time t. Now you store those measurements as electromagnetic values. According to John Swenson, the slight variation between the measurements at t-n and t can be reflected in slight variations in the stored electromagnetic values that are not enough to "flip the bits." OK, now precisely because timing isn't stored on disk, what happens on playback? The system doesn't "know" the measurement in data storage location x was taken at time t-n rather than at time t, and so that t-n measured value (higher if amplitude is falling, lower if it's rising) is taken as if it occurred at time t. Thus the reconstruction of the sampled wave will show one that is rising or falling slower than was actually the case, and voila! - "embedded" jitter.

[Jud]

Hi Roch- for the moment assuming there is embedded jitter in the file, and there always is, at the end of your multi-lightyear transmission, the reconstructed file will have exactly the same jitter embedded in it as the original file.

 

If there were no transmission errors, then the checksums will match, they will be bit for bit identical, and they should sound the same- if you play them on the same equipment. If they do sound different, it will be From some other cause than the data or files being different.

 

I dunno, are checksums affected by redshift?

[Jud]

I get that but these electromagnetic values would change each time the file is copied or sent over a data network or refreshed in memory, etc.

 

Correct - as I mentioned in the prior comment I referred you to, John Swenson could not think of a mechanism by which "embedded jitter" would be propagated from any data storage or action prior to the most recent storage on disc/SSD/SD etc.

[Paul R]

So let's think about why an engineer who designs both audio electronics and data storage hardware (John Swenson) apparently disagrees. How does jitter manifest on an oscilloscope? Or to put it another way, if due to jitter the sample is taken at time t-n rather than time t, what is the measured amplitude? If the amplitude is falling, the measured amplitude at t-n will be higher than at time t. If the amplitude is rising, the situation will be reversed, and the measured amplitude at t-n will be lower than it would have been at time t. Now you store those measurements as electromagnetic values. According to John Swenson, the slight variation between the measurements at t-n and t can be reflected in slight variations in the stored electromagnetic values that are not enough to "flip the bits." OK, now precisely because timing isn't stored on disk, what happens on playback? The system doesn't "know" the measurement in data storage location x was taken at time t-n rather than at time t, and so that t-n measured value (higher if amplitude is falling, lower if it's rising) is taken as if it occurred at time t. Thus the reconstruction of the sampled wave will show one that is rising or falling slower than was actually the case, and voila! - "embedded" jitter.

 

Yes, but this is "embedded" at A2D time, and remains in the data essentially forever. It is, in fact, part of the data, and two copies of the file will checksum identically, and pass a bit for bit comparison.

 

The question would be, can two identical copies of this file - including the embedded jitter - ever consistently sound different if played on the same equipment from the same media, etc., because of any kind of mysterious noise embedded in the file at RIP time or due to multiple copies of the file? Whew that's a mouthful.

[Paul R]

I dunno, are checksums affected by redshift?

 

Only in the Bass Register.

[Jud]

Yes, but this is "embedded" at A2D time, and remains in the data essentially forever.

 

 

Yes, what I described is. But essentially identical effects can be caused by anything that slightly changes the electromagnetic values stored on disc/SSD/SD etc. - i.e., there's no way at playback to differentiate between slight differences in stored values from the A2D process, and slight differences caused by, e.g., EM noise at the time the values were stored via ripping a CD.

[Audio_ELF]

Photographers say there are differences in files copied straight from the camera vs from the sd/cf card storage, presumably these differences are visible in picture.

Which photographers... This is not a claim I have ever come across. You can't copy straight from any camera I've come across*. Even if you attach the camera via USB direct (as opposed to removing the SD card) then the photographs are still being read from the SD card.

 

Eloise

 

*there are still a few cameras which have built in memory but the principle is the same it's just not removable.

[Audio_ELF]

Reading several of these posts the wisdom of Princess Bride comes to mind "I do not think that means what you think it does..."

[Jud]

Reading several of these posts the wisdom of Princess Bride comes to mind "I do not think that means what you think it does..."

 

Any in particular?

[Audio_ELF]

Any in particular?

Well as I remember it.. John Swenson was talking in complete hypotheticals and theory yet some people have taken his comments as proof that things may occur and have a reason to sound different.

 

I believe that John was talking about things similar to the concept that each time a drive is written to there is a memory of the previous data ... Something that could only be read using theoretical analysis with an electron microscope - that doesn't stop the idea being at the heart of many espionage based television episodes.

 

Eloise

 

PS my apologies to John if I am misrepresenting his comments.

[Jud]

Well as I remember it.. John Swenson was talking in complete hypotheticals and theory yet some people have taken his comments as proof that things may occur and have a reason to sound different.

 

I believe that John was talking about things similar to the concept that each time a drive is written to there is a memory of the previous data ... Something that could only be read using theoretical analysis with an electron microscope - that doesn't stop the idea being at the heart of many espionage based television episodes.

 

Eloise

 

PS my apologies to John if I am misrepresenting his comments.

 

I recall this the same way you do in terms of John speaking of possibilities rather than definitive realities, though I did not take the mechanism to be necessarily related to memory effects. (But granted, memory effect would allow for various electromagnetic values of binary zero and one.)

 

Thus folks should also take my remarks here as referring to physical possibility, not The Way It Works. And to repeat one more time: Based on this discussion you can decide to be careful of electrical noise, etc. when you rip, or not, just as you like.

[RealAudio]

So let's think about why an engineer who designs both audio electronics and data storage hardware (John Swenson) apparently disagrees. How does jitter manifest on an oscilloscope? Or to put it another way, if due to jitter the sample is taken at time t-n rather than time t, what is the measured amplitude? If the amplitude is falling, the measured amplitude at t-n will be higher than at time t. If the amplitude is rising, the situation will be reversed, and the measured amplitude at t-n will be lower than it would have been at time t. Now you store those measurements as electromagnetic values. According to John Swenson, the slight variation between the measurements at t-n and t can be reflected in slight variations in the stored electromagnetic values that are not enough to "flip the bits." OK, now precisely because timing isn't stored on disk, what happens on playback? The system doesn't "know" the measurement in data storage location x was taken at time t-n rather than at time t, and so that t-n measured value (higher if amplitude is falling, lower if it's rising) is taken as if it occurred at time t. Thus the reconstruction of the sampled wave will show one that is rising or falling slower than was actually the case, and voila! - "embedded" jitter.

 

 

There is no way that can be correct. For every magnetic hard drive, reading (or writing) is a three step process. First, you read the bits off the disk, and yes there can be inconsistency in the levels that constitute 0s and 1s and perhaps some speed inconsistency that you can interpret as "jitter". The next step is the bits go to a reed-solomon ecc chip. Finally, the data is put in the disk's cache. The data retrieved is always data that's in the disk's cache. So, all that hoo haa about the magnetic levels and "jitter" on the disk is nonsense.

[Paul R]

Yes, what I described is. But essentially identical effects can be caused by anything that slightly changes the electromagnetic values stored on disc/SSD/SD etc. - i.e., there's no way at playback to differentiate between slight differences in stored values from the A2D process, and slight differences caused by, e.g., EM noise at the time the values were stored via ripping a CD.

 

I am not sure I follow you here Jud - when the file is read in from the disk (or disc) to RAM, the values stored in RAM are not subject to EM or noise from the physical media, save the case where the EM or noise on the media is of such magnitude as to cause an error. The very act of reading the data eliminates the possible effects from that, as timing is not a concern when reading pure data.

 

This still equates when the data is read from CD and copied to RAM, any possible effects of of embedded EMI noise are eliminated. A value on disk of 32764 is going to be read as a value of 32764 into RAM. Now RAM is hellishly noisy, but that is a whole different subject.

 

It is still reasonable to assume reading a CD and playing the resulting data might sound different than reading from a disk and playing it, because the two processes are wildly different. (i.e. Processor Activity Signatures.)

 

But two identical files read from CD and two identical files read from disk? I am not sure I see a way for anything on the media to affect them once copied into RAM.

 

Fortunately, I do not know everything though, so I expect someone will point out a mechanism.

[AlainGr]

So let's think about why an engineer who designs both audio electronics and data storage hardware (John Swenson) apparently disagrees. How does jitter manifest on an oscilloscope? Or to put it another way, if due to jitter the sample is taken at time t-n rather than time t, what is the measured amplitude? If the amplitude is falling, the measured amplitude at t-n will be higher than at time t. If the amplitude is rising, the situation will be reversed, and the measured amplitude at t-n will be lower than it would have been at time t. Now you store those measurements as electromagnetic values. According to John Swenson, the slight variation between the measurements at t-n and t can be reflected in slight variations in the stored electromagnetic values that are not enough to "flip the bits." OK, now precisely because timing isn't stored on disk, what happens on playback? The system doesn't "know" the measurement in data storage location x was taken at time t-n rather than at time t, and so that t-n measured value (higher if amplitude is falling, lower if it's rising) is taken as if it occurred at time t. Thus the reconstruction of the sampled wave will show one that is rising or falling slower than was actually the case, and voila! - "embedded" jitter.

 

Thanks for a clear explanation Jud. Now I understand what "embedded" jitter is about. Maybe it's the word "embedded" that was confusing me, as if some timing information was there (...). In a sense it is, as a result of the ADC with a sampling at the wrong time, but it's the sample that is not good then... Hope I have it like I think

[Jud]

So let's think about why an engineer who designs both audio electronics and data storage hardware (John Swenson) apparently disagrees. How does jitter manifest on an oscilloscope? Or to put it another way, if due to jitter the sample is taken at time t-n rather than time t, what is the measured amplitude? If the amplitude is falling, the measured amplitude at t-n will be higher than at time t. If the amplitude is rising, the situation will be reversed, and the measured amplitude at t-n will be lower than it would have been at time t. Now you store those measurements as electromagnetic values. According to John Swenson, the slight variation between the measurements at t-n and t can be reflected in slight variations in the stored electromagnetic values that are not enough to "flip the bits." OK, now precisely because timing isn't stored on disk, what happens on playback? The system doesn't "know" the measurement in data storage location x was taken at time t-n rather than at time t, and so that t-n measured value (higher if amplitude is falling, lower if it's rising) is taken as if it occurred at time t. Thus the reconstruction of the sampled wave will show one that is rising or falling slower than was actually the case, and voila! - "embedded" jitter.

 

 

There is no way that can be correct. For every magnetic hard drive, reading (or writing) is a three step process. First, you read the bits off the disk, and yes there can be inconsistency in the levels that constitute 0s and 1s and perhaps some speed inconsistency that you can interpret as "jitter". The next step is the bits go to a reed-solomon ecc chip. Finally, the data is put in the disk's cache. The data retrieved is always data that's in the disk's cache. So, all that hoo haa about the magnetic levels and "jitter" on the disk is nonsense.

 

I see what you and Paul are saying. Surprised John Swenson would not think of it, considering his employment. So we have an at least potentially fatal objection to our possible explanation.

[sandyk]

There is no way that can be correct. For every magnetic hard drive, reading (or writing) is a three step process. First, you read the bits off the disk, and yes there can be inconsistency in the levels that constitute 0s and 1s and perhaps some speed inconsistency that you can interpret as "jitter". The next step is the bits go to a reed-solomon ecc chip. Finally, the data is put in the disk's cache. The data retrieved is always data that's in the disk's cache. So, all that hoo haa about the magnetic levels and "jitter" on the disk is nonsense.

 

It's interesting that many people are nevertheless reporting SQ differences between various makes and size HDDs, with the much larger capacity varieties usually being less favoured for audio.

[Kees de Visser]

It's interesting that many people are nevertheless reporting SQ differences between various makes and size HDDs, with the much larger capacity varieties usually being less favoured for audio.

Human hearing can be quite unreliable. First thing I'd do is measure/compare the audio data that arrives at the DAC. If they are identical, measure the DAC's analogue output. As a last step I'd do a double blind listening test to make sure I'm not imagining things.

Studio recording projects can easily take up 50 to 100 GB of data. A CD is about 700 MB, which is about 1% of the original data. If potential problems are related to the amount of data, they are more likely to happen in the studio.