Measuring objectively real differences in files with identical checksums

[fas42]

The process of retrieving digital data which contains the recording can be 'different', every time; even if it's the same data, each time! For a myriad of subtle, but non-trivial reasons. For an analogue analogy - you play the same track of a record, one following the other - the cartridge has warmed up a bit more, the plasticity of the record has slightly altered, the dust in the grooves has been pushed aside; and on it goes.

 

But digital is different!!!, you say ... umm, good theory, but the reality I've found is that there are enough leaks through the supposed barrier to the analogue areas, to cause an audible variation.

[Archimago]

On 2/26/2020 at 4:59 PM, fas42 said:

The process of retrieving digital data which contains the recording can be 'different', every time; even if it's the same data, each time! For a myriad of subtle, but non-trivial reasons. For an analogue analogy - you play the same track of a record, one following the other - the cartridge has warmed up a bit more, the plasticity of the record has slightly altered, the dust in the grooves has been pushed aside; and on it goes.

 

But digital is different!!!, you say ... umm, good theory, but the reality I've found is that there are enough leaks through the supposed barrier to the analogue areas, to cause an audible variation.

Easy to say... But unless you have some suggestions as to how one verifies this belief/claim/idea/suspicion/article of faith, there is no path forward in these discussions.

 

I've tried. I hear no difference. I measure no difference (eg. between lossless file formats). Jitter these days is very well controlled without the use of any doohickeys and IMO inaudible. Noise is absent (significantly below -100dBFS) from inexpensive modern DACs and CD players. If anything, it's the amplifier and speakers creating more distortion and limiting noise floor; not to mention the ambient noise in one's listening room.

 

Even if retrieval & reproduction is a little different each time, the variance is way below audibility with repeated measurements. Essentially bits are bits given the accuracy of modern digital systems.

 

Where is your evidence/rationale to show otherwise beyond an idiosyncratic belief system unsupported even by controlled listening, so as to have a reasonable/meaningful discussion going forward??? This is of course not just a challenge to you Frank, but basically a broad question to all those who insist that there is still some significant issue that can be affected by cables/regenerators/filters/etc.

[sandyk]

6 hours ago, Archimago said:

 

Where is your evidence/rationale to show otherwise beyond an idiosyncratic belief system unsupported even by controlled listening, so as to have a reasonable/meaningful discussion going forward??? This is of course not just a challenge to you Frank, but basically a broad question to all those who insist that there is still some significant issue that can be affected by cables/regenerators/filters/etc.

 Archimago

 Please check your PMs for an FYI ONLY reply

Alex

[fas42]

6 hours ago, Archimago said:

Easy to say... But unless you have some suggestions as to how one verifies this belief/claim/idea/suspicion/article of faith, there is no path forward in these discussions.

 

Multiple, separate in time passes through the same playback chain will yield slightly different waveforms, each time - people using, say DeltaWave, can see this quite clearly ... so, it's trivially easy to show the 'imperfections'; the real question is whether it's audible.

 

Quote

 

I've tried. I hear no difference. I measure no difference (eg. between lossless file formats). Jitter these days is very well controlled without the use of any doohickeys and IMO inaudible. Noise is absent (significantly below -100dBFS) from inexpensive modern DACs and CD players. If anything, it's the amplifier and speakers creating more distortion and limiting noise floor; not to mention the ambient noise in one's listening room.

 

Yes, amplifiers plus speakers cause issues - but the analogue side of the DAC portion of the chain also contributes, IME.

 

Quote

 

Even if retrieval & reproduction is a little different each time, the variance is way below audibility with repeated measurements. Essentially bits are bits given the accuracy of modern digital systems.

 

The real debate is whether the variance is below audibility. I have zero problems believing it is audible, because my first good rig, decades ago, had a 100% repeatable characteristic that its SQ could either be holographic and convincing, or merely a conventional stereo presentation. The only thing that varied was the time since the last resetting of the electronics.

 

Quote

 

Where is your evidence/rationale to show otherwise beyond an idiosyncratic belief system unsupported even by controlled listening, so as to have a reasonable/meaningful discussion going forward??? This is of course not just a challenge to you Frank, but basically a broad question to all those who insist that there is still some significant issue that can be affected by cables/regenerators/filters/etc.

 

The rationale is that every rig - even mine, 😜 - are not "perfect" ... what one hears when they sound different are the precise qualities of the distortion artifacts; the brain can quite easily focus on the one or two things that in a consistent pattern mark one version of the sound of a particular recording from replay on another system, or a variation of the same system - this is often talked about in a positive way, people say that the rig had a "warm" signature, or a "clinical" signature, or whatever.

 

The cables/regenerators/filters have, or should have, maximum impact on the signature of the distortion - hence, make the SQ vary ... the ideal is to attenuate the signature of the system to zero; which then will mean that any extra fiddling with these type of tweaks will have zero audible impact.

[John Dyson]

On 2/26/2020 at 9:09 AM, jabbr said:

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?

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.

 

There are cases where CD data can cause errors, but they are DISCRETE errors and not noise in the traditional analog sense.  If there is a noise coming from CD, it is a discrete GLITCH, which might or might not be corrected by ECC.   Any timing errors are buffered and resynched to a clock -- usually some kind of on-board circuit.  That clock, however lousy is meaningless WRT audio jitter unless a D/A is onboard, and there are bad design analog leakages in the circuit.

 

When differences might occur in the audio, the strongest comes from analog conducted noise caused by suboptimal physical circuit layout.  The second layer of noise comes from a capacitive or inductively coupled noise, but tends to be weaker than the conducted noise.  The third layer of noise comes from radiated sources -- but isn't really very strong on a sanely designed circuit.

 

Any non-error causing deviations on a CD media cannot come into play -- because the CD data is NOTHING like the audio that it represents.   Any small noise changes mostly come from ham-handed grounding issues where the digital ground leaks into the audio ground path (conducted), or insanely bad layout causing conducted or radiated interference.

 

As each group of bits from a CD is read and correct -- it is either 100% accurate or meaningless garbage.  The various groups of bits are re-assembled after ECC, and the resulting output is either accurate, or gross/glitch fill-in.

 

The similar higher level reading techniques are used on your *CD/DVD/Blue-ray* technologies as your HDD.   If you have little errors that create noise in the digital domain, then heaven help you when trying to read a CD for data.

 

Sub-bit errors don't happen, unless there is ham-handed design in the circuitry, and the signal is resolved to analog.   Clock jitter also need not apply in this case -- the only way that clock jitter comes into play on this matter is if the jitter is so very bad that the circuitry/reader design can no longer lock onto the CD (super unlikely), or the jitter leaks directly into ANALOG audio because of the ham-handed circuit layout described above.   If your CD drive doesn't resolve directly to analog, then the clock jitter is like internet timing jitter -- it is all resynched at the D/A conversion.

 

This is NOT religion, but comes from a developer type who comes from AT&T Bell Labs research -- no longer a person with engineering discipline, but still does a modicum of research.  If I still 100% subscribed to engineering discipline, my current project wouldn't function -- but the same rules apply, that is: REALITY.

 

The singular place where clock issues come into play is at the D/A conversion point, and the analog output is partially dependent on the ANALOG design of the circuit board, and also the clock jitter at that point.   (Clock jitter can even be added by bad design, even if you use a precision external clock unit.)

 

John

 

 

[sandyk]

52 minutes ago, John Dyson said:

This is NOT religion, but comes from a developer type who comes from AT&T Bell Labs research -- no longer a person with engineering discipline, but still does a modicum of research.  If I still 100% subscribed to engineering discipline, my current project wouldn't function -- but the same rules apply, that is: REALITY.

 

Sorry John, but That comes across as just a wee bit conceited ..😉

I have been able to burn pairs of tracks on to comparison CD-Rs, where despite them  being adjoining tracks on the same CD-R, they sound different despite no data errors.. You are already aware of who both the people were that verified this under non sighted conditions, and they are both well respected in their professions , just as you were.

 Alex 

[John Dyson]

7 minutes ago, sandyk said:

 

Sorry John, but That comes across as just a wee bit conceited ..😉

I have been able to burn pairs of tracks on to comparison CD-Rs, where despite them  being adjoining tracks on the same CD-R, they sound different despite no data errors.. You are already aware of who both the people were that verified this under non sighted conditions, and they are both well respected in their professions , just as you were.

 Alex 

They sound different because of 1) electronics differences causing analog based noise (bad circuit/layout design -- different currentt flows ), or 2) brain-state/hearing differences.   Digital difference -- NADA.

Truly control the experiment, anecdotal evidence is NOT evidence in controversial and technically unsupportable claims.

 

Dont make claims about digital bits being different, unless the experiment is truly controlled as such.   I sometimes hear differences when they aren't there, and have learned that audio/listening memory is approx 10-15seconds.  Sure, general sounds are longer, but precision hearing is extraodinarily short.

 

John

 

[sandyk]

13 minutes ago, John Dyson said:

They sound different because of 1) electronics differences causing noise, or 2) brain-state/hearing differences.   Digital difference -- NADA.

Truly control the experiment, anecdotal evidence is NOT evidence in controversial and technically unsupportable claims.

 

JOhn

 

 John

 I am not going to discuss this further with you as Admin will remove all my replies.  , but perhaps yoo would care to explain how analogue based noise is burned  to CD-R along with the binary Data on only one track of the adjoining pair of tracks.

[John Dyson]

11 minutes ago, sandyk said:

 John

 I am not going to discuss this further with you as Admin will remove all my replies.  

Don't give up -- listen to reason...  You are actually important to me -- I want to help (probably causing more friction -- but I really want to help the general understanding.)

 

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.  (Actually, it is possible for it to jitter as much as 1/3 second or more.)   Do you hear even a dropout in the recordings?  (Only if the CPU is overwhelmed during realtime play.)   Do you hear the myriad of rate conversions (even though I limited them)?  Do you know how much stuff that would JUST NOT WORK if the 'common knowledge' prevailed...  Not even a CD player would work.

 

The problem with all of this is that claims are made based upon defective experiments and anecdotes.

 

Here is my anecdote -- I took the 'brickwall ringing' as fact a long time ago, until I realized that the ringing wasn't really ringing.  Superficially, things might look one way, but the reality might be very very different.

 

John

 

[sandyk]

John

 I don't wish to fall out with you on this area, but I would remind you that your project since around March 2019 hasn't always been plain sailing,  and you have had to rely on what I reported hearing on quite a few occasions . yet you always followed up what I reported, and I wasn't too far off the mark most of the time.

 That is also a matter of record in your Group PM thread (now 37 pages) as several other members, (perhaps Paul as well ? ) ,  can verify.

 

 I will not be posting further replies in this thread as they would almost certainly be removed by Admin. . 

 G'night .

 

P.S. 

 It's a shame that you couldn't let this older thread rest in peace

 

[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? 

[John Dyson]

1 hour ago, jabbr said:

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? 

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.)

 

The buffered software steps and the equivalent HW steps are TOTALLY analogous.

 

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.

 

This is not dogma referring to another post, unfortunately, I am stuck in scientific/engineering/mathematical reality.  I try not to make things up, and  I don't trust false authority.

 

* PS: never appeal to authority when it is benefiting in one way or another from the dogma.

 

John

 

[John Dyson]

8 hours ago, sandyk said:

John

 I don't wish to fall out with you on this area, but I would remind you that your project since around March 2019 hasn't always been plain sailing,  and you have had to rely on what I reported hearing on quite a few occasions . yet you always followed up what I reported, and I wasn't too far off the mark most of the time.

 That is also a matter of record in your Group PM thread (now 37 pages) as several other members, (perhaps Paul as well ? ) ,  can verify.

 

 I will not be posting further replies in this thread as they would almost certainly be removed by Admin. . 

 G'night .

 

P.S. 

 It's a shame that you couldn't let this older thread rest in peace

 

Yes -- I am doing something on the project that has never been done before...   There are lots of complications.  I found *JUST TODAY*  that one of the biggest problems is that the material is double-encoded.   Would you or me have even guessed that?   You see the problem -- I actually try to solve NEW problems, not just copying someone elses schematics, adding some magic dust, and proclaiming 'invention.'   Truly NEW stuff is a lot more difficult than copy/modify/copy.   That is the difference between research  engineering, and just designing or in the most positive light, designing product.  I get bored with easy things -- why do them, easy things have already been done (usually better) 1000's of times before.

 

The old thread came in because of a response a few hours ago.  Then, I noticed a faulty statement which was totally untrue.  It was important to answer to make sure that there were no misunderstandings.

 

John

 

[sandyk]

5 hours ago, jabbr said:

How can software introduce jitter exactly? 

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

[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.

[sandyk]

Do you have a decent EXTERNAL PC monitor, NOT a Laptop ? (not a special CALIBRATED monitor)

 

I would be interested to see if any members are able to see differences in Colour Saturation and detail 
between these 2 Hi Res Music Videos , the first pair of which is preceded by 20 seconds of Test Pattern, 
which also permits quickly switching between videos.
They would need to be viewed under low ambient light conditions, preferably after Downloading them,
 and played using a high quality S/W such as JRiver 26,although you may be able to reliably both see and hear the differences directly using the lacklustre Dropbox player directly. 
The file sizes are however quite large ,as they were converted to Blue Ray mpeg format with 24/48kHZ Audio from the hidden tracks of the original YouTube Videos in order to make them more universally playable 

 

https://www.dropbox.com/s/fn3w6000o31i3ue/Slideshow W3.m2t?dl=0
https://www.dropbox.com/s/w5i1izg546cbdi0/Slideshow ZL3.m2t?dl=0

https://www.dropbox.com/s/bha25987qutt9gu/Miley Cyrus - Malibu L3.m2t?dl=0
https://www.dropbox.com/s/d6x0bm8hpnf5mqq/Miley Cyrus - Malibu ZL3.m2t?dl=0

[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. 

[sandyk]

3 minutes ago, jabbr said:

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.

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 .

[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".

[John Dyson]

18 hours ago, jabbr said:

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.

Most digital systems are clocked at one level or another.   Same as audio processing software.

Note that the DHNRDS is not a simple program as most people think -- it is a linked set of complex threads, each with a set of input and output buffers, where the audio signal is passed across from thread to thread along with all kinds of state and timing information.

 

The complexity level is likely imponderable for someone not used to complex, buffered multithreaded software with tight real-time controls.  Every sample is accounted for WRT time, just like the attack/release signals.   The audio signal is not just 'audio', but is a complex set of values associated with the audio.

 

It is only resychronized at the end, when the audio signal appears, very analogous to a digital signal being realized in analog at the output of an D/A.   There are lots of analogies between the SW and HW, and they directly apply.

 

John

 

[John Dyson]

17 hours ago, jabbr said:

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. 

The jitter in the pits are real -- that is definitely true.   The pits are self-clocked though, along with some kind of sync scheme (often using something like a PLL), the pits are detected.   There is seldom enough error that the location of the pits or the 'strength' of the pit patterns being so weak that they cannot be detected after appropriate detection and error management.   There is no separate clock, as the pits also represent their own clock.   Clocking is based on patterns, not on individual pits.  (When I say "seldom", I don't mean that disks are always error free, it is that the errors are exceptional.)   CDs are about PATTERNS, just like more advanced digital mag tape, they aren't about single pits.

 

Instead of the pits individually representing audio, the pattern of pits, spread in different parts of the tracks is what, once the patterns  decoded, represents the audio signal.   This is where people confuse the CD (sparse patterns of bits) vs laserdisk (FM representation of video and associated data).   The noise (variations) of the FM signal on a laser disk have a direct TEMPORAL effect on the video signal.  Speed variations can even shift the color (esp in NTSC type systems), but everything is compensated by both PLL and TBC of one level or another to make the picture viewable.  There is no such precise mapping on a CD, except when entire blocks are damaged beyond ECC repair, and some kind of audio-fill in (or just a glitch) has to happen.

 

On the other hand CD, DVD, Blue Ray, do not represent an audio signal (or video directly.)   They represent 'streams of accurate bits' in chunks.  (at least, hopefully accurate.)   Errors in individual bits can often be corrected.   Spatial glitches (bad spots) are mitigated by the ECC bit patterns being spread so that a scratch doesn't cause as severe damage to the resultant stream.  In ALL cases, these digital schemes result in 'good signal' or 'errors', but nothing in between.   The quality of actual reproduction given actual errors in the streams depends upon the quality of the MPEG decoders or, in the case of audio, we normally hear the discrete glitch or glitches if long enough.

The resulting data blocks are either 100% correct, or an error.  (In some cases, an ECC can provide an approximate result -- but that can be gross as much as a small glitch.)

 

Where we DO get noise in these systems is when the various digital clocks/signals REALLY MIGHT leak into the audio by vitue of the ANALOG world.  These leaks are analog in nature, related mostly to ground currents.   The much feared flip-flop window issues do not apply, because they represet discrete glitches, which would happen either in the ECC corrected regime, or as an entire sample error...   A flip-flop error on an unprotected stream can just as easily modify a most significant bit as a least significant bit -- little decreases in SNR don't happen in the digital domain.   Little decreases in SNR (that is, increase in noise) happens in the analog domain, but can happen from digital electronics (often relatively large/fast current glitches) leaking into the ground paths with inductance.   "speed&size of current glitch times inductance + size of current glitch * resistance" equals voltage glitch.  THIS  is how you get varying noise in your analog output.

 

Digital signal errors equally mess with both high and low level signals (unless specially coded.)   In fact, that is one way to start narrowing down where an error might be -- in the digital or analog subsystem.  Digital subsystems typically don't make solely small errors -- they are equal opportunity.

 

John

 

[John Dyson]

18 hours ago, jabbr said:

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.

The jitter that happens in SW and HW are essentially the same thing, and have similar resolution techniques, one has an endpoint where everything is resynched.   The total visible jitter on the output is totally determined by that final clock at the time of resolution.   For some cases in HW, there is the infamous D/A.  In the case of the software queues and the varying processing times, etc -- the resolution is at the FIFO that buffers the data.   The DHNRDS queueing is a lot like the little caterpillar toy or like a slinky -- timing is ALL OVER THE PLACE until resolution points.

 

All of the crazy SW/HW delays are resolved at the final D/A.   No-one cares about the SW or HW timing needed to get the  signal into the analog domain (that is, unless buffers become empty, or there is a severe enough error in HW that there is a glitch.)   Digital HW glitches tend to be equal opportunity -- they can be MSB or LSB.   You know when you are getting Digital HW glitches -- they can hurt your ears.

 

The little (low level) noise issues are analog infiltrations.

 

John