Blue or red pill?

[esldude]

43 minutes ago, manisandher said:

 

One thing that I'm slightly surprised at is where your differences seem to lie. I was hearing differences in the sibilance of the singer's voice, which I would have thought would lie much higher than 150-600Hz.

 

Mani.

That is interesting as listening to the amplified difference file the only place the noise has any modulation, and it is very slight is I think the 13 or 14 second mark where the vocal comes in the loudest a couple times and you do hear sibilance in that area.  There isn't much in the noise there just a very slight swish for that couple seconds.  

[esldude]

29 minutes ago, pkane2001 said:

 

I did, but had to change conversion accuracy to 3 from default 4. When set to 4, it would crash at the end, every time with any comparison I ran. With 3, it appears to run all the way through.

 

Can you please post a screen shot of the advanced settings you are using with diffmaker?

 

Screenshot won't do any good.  I've found Diffmaker crashes different ways on different hardware.  Or it crashes in a chaotic enough way it is easy for superstitious humans to see it that way.  For instance if I change to 3 from 4 it crashes, but not usually on 4. 

 

Of all things it seems to work best on a Linux machine running via WINE which is how I usually run Diffmaker. 

 

For what it is worth, in this case, I change Diffmaker to the 24 bit depth, and set the sample rate (though it will do this automatically), open Advance settings and enable Compensate for Sample Rate drift.  I don't change anything else from default. 

[psjug]

9 minutes ago, esldude said:

 

Comparing other A and B captures and A vs A and B vs B the results are all very similar.

 

This is what I get, too.  Also, I have the "compensate for sample drift" setting disabled, and I still don't get the larger peaks in the diff spectra.

[esldude]

29 minutes ago, mansr said:

I'd just say, don't. It's crap. All it's good for is getting a quick idea about what's going on in a file. For the type of analysis we're attempting here, you really should use something geared more towards science, such as Matlab.

Yes, but not everyone is up to speed on Matlab like me for instance.  

 

If you want details you can export Audacity's FFT info into a text file and open it in a spreadsheet.  The FFT there works fine to my knowledge.  But doing that to examine the bins or bother to chart it with bin to bin correspondence is a pain in the rear. I usually do that or use WaveSpectra depending upon what I am trying to see.  

[esldude]

28 minutes ago, pkane2001 said:

 

Remember that we are trying to determine the difference between two analog captures. Difference in phase is a valid difference that I would want to know about. Correcting for drift is potentially destroying an important difference between two captures. For all we know, it could be responsible for these audible differences.

But that is the point.  If you don't correct for a speed difference you have no chance to get a handle on phase differences.  Or at least not via nulling you don't.  

 

To my knowledge, and I am not completely certain, Diffmaker changes the speed of the second file.  It doesn't dynamically vary it from second to second.  It simply makes one correction for overall speed.  If done closely enough finding phase differences will be much better with this correction.  

 

How well does it work?  Good enough you can measure a time difference between one meter and two meter of cable because of the 3 nanosecond differences in time it takes for the near speed of light signal propagation over that distance.  

[adamdea]

1 hour ago, esldude said:

You need to think about how an FFT works.  I did basically what Testikoff did and got the same result.  That is not what Diffmaker is doing. 

 

For instance, to do a 2048 point FFT requires a minimum of 2048 samples.  However you can do more than that.  The FFT as Testikoff and I have done basically tells you the frequency response is very precisely the same for both captures.  If you do this over the entire recording there is still much that could be happening and get missed.   You could use the FFT over shorter sections and catch some of what might happen and get missed.  

 

Diffmaker moves a compared recording in time to align with the reference file.  It can do this very precisely and actually uses very high bin FFT's in a different way to manage this.  

I think we are agreeing. Having aligned the files isn’t diffmaker then generating the time domain difference?

 

Either way, having done this have you identified any significant variation between the AB difference and the AA and B.B.? [edit apologies if you have answered this]

[adamdea]

38 minutes ago, esldude said:

I was comparing the original A and B captures. 

 

Comparing other A and B captures and A vs A and B vs B the results are all very similar.  Nulls in the 90 db range.  I added back 18 db that Mani said the file was reduced by for playback and the nulls deepen a little more.  Not 18 db, but a few db.  Some are around -100 db that way.  

 

Thanks. Not sure where that leaves us.

[PeterSt]

 

This took me 80 seconds (including unzipping) :

 

 

This is still way way NOT zoomed.

Does it look the same to you all ?

 

Read more  

So explain what we are seeing here.  I also wish you would not post graphs with no scale on one axis.  If you are trying to communicate having scales on both axis would be a big help. 

 

 

 

Apologies (it was a quick job).

 

 

Say 1% for the level max where this was taken from.

Where 0.8 shows here, the maximum is 100 (linear vertical scale) ... 

[esldude]

28 minutes ago, adamdea said:

I think we are agreeing. Having aligned the files isn’t diffmaker then generating the time domain difference?

 

Either way, having done this have you identified any significant variation between the AB difference and the AA and B.B.?

I've not found any important difference in AA, BB or AB.  

 

Diffmaker does two things in regards to time to my knowledge. 

 

If I record a DAC with an ADC the clocks are not locked.  The odds I'll do this twice with the same file and sample the signal of the DAC at the same exact time are nearly zero.  Diffmaker will take the second file and change the file in time so the result is the same as if I did get samples at precisely the same time. 

 

However, the clock in either the ADC or DAC may run slightly faster or slower than it did at another time.  So if Diffmaker checks and sees the sample times drifting apart because one clock is running at a different speed it makes a speed adjustment so that in theory you end up with samples occurring at exactly the same time and sampling clocks effectively at exactly the same speed.  Diffmaker will ignore the speed adjustment if the difference is small enough not to corrupt results and it will say this briefly while it is running.  It also reports what it did in the text file of the results.  Here is one as an example. 

 

parameters: 718nsec, -0.001dB (L),  -0.001dB (R). rate adj=0.023 ppm.Corr Depth: 99.9 dB (L), 105.8 dB (R)

 

It moved the second file 718 nanoseconds.  Typically this is in microseconds.  It adjusted the volume .001 db so levels matched.  It adjusted the speed of the second file by .023 ppm.  

 

Another example.

parameters: 9.241usec, 0.001dB (L),  0.000dB (R). rate adj=0.0323 ppm.Corr Depth: 110.4 dB (L), 102.1 dB (R)

 

It moved the second file 9.241 microseconds ( nearly two samples at 176khz), adjusted one channel for level slightly, and adjusted speed by .0323 ppm (which is 32.3 parts per billion).  

 

 

[fas42]

11 hours ago, PeterSt said:

 

Frank, if it was only well after 50ms in the file(s) ...

 

Well after half a second in - another quick look, there is tonnes of of glitchy variations between the two, only about 40dB down from the magnitude of the of the signal itself at a particular point - I would be amazed if this wasn't audible to least some people.

 

Now, is this 'noise' an artifact of the recording process, or an indication of something meaningful - will need much more careful investigation, to be looked at in a day or two ...

[fas42]

I note that I'm way behind where people are at - need to read all this carefully, before adding anything further, .

[pkane2001]

3 hours ago, esldude said:

parameters: 718nsec, -0.001dB (L),  -0.001dB (R). rate adj=0.023 ppm.Corr Depth: 99.9 dB (L), 105.8 dB (R)

 

This is very different than the results I get when I use diffmaker, regardless of whether I turn on drift correction or not. Strange. I'll see if moving it to another PC/OS might help.

[STC]

9 hours ago, adamdea said:

26/36 would be interesting. But it has to be in the test within the predetermined test length, not in the warm up. If you perceive a change in the image then that should show up in the test results.

 

I think I was right about the image change. With my main system I sense the vocal was very slightly closer and focused (subjective) in 3 with my main system. 

 

With my laptop (a very old one), when I use 16/44.1 setting there was some sort of whitenoise like sound which have a slight different pitch. It requires immense concentration and absolutely quiet environ. Unfortunately, with the newer pc the whitenoise noise not heard in the newer pc. So DAC and other noise can cause some audible difference of what's coming out at the DAC's output.

 

Going back to image shift.

 

Play from 8.347s to 8.349s. In 3 the left will be louder and in 4 the right will be louder. Such minor difference would be amplified in my main system due recursive nature of the crosstalk. So some difference could be heard but they are just too small to be consistent. 

[PeterSt]

FWIW : It is my conclusion that we can't do a thing with the recordings of the analogue output.

 

(btw, channels seem reversed)

 

Top is the recording of analogue out, bottom is the digital take. You can see that the ADC's modulator is constantly guessing where to be. This is NOT noise - it is just a poor ADC (and if it is a good ADC I would never use ADC's in my life).

The crux for this is the beginning of the file(s) as you see here. All (sufficiently) clean at the start and the more things "move" the more it needs to guess (oops - too high, let's go down ... oops - too low now, let's go up) always overshooting. The steeper going up and down of the general wave is the cleanest :

 

 

which is fairly normal in itself.

 

Anyway, the bottom traces in the first picture show the reference which is the original, though digitally recorded from the digital output. Let's notice that it is that stream which normally goes into the DAC and that this super clean file implies the minute differences we can hear (at changing parameters like SFS). If we'd compare this with what the ADC makes of it after the D/A conversion (which conversion itself is not important) then I hope we now can all imagine that there is no single way we can - or should attempt to listen for the differences originally implied. The "noise" is almost higher in level than the music signal itself. Remember, this is not noise but how the SDM(odulator) works.

 

I am afraid that here this exercise stops. No need to apply this again with tracks "made to suit" as I suggested myself 16 hours or so ago. Sorry guys ... 

[sandyk]

2 hours ago, PeterSt said:

I am afraid that here this exercise stops.

 

  Well you can all ridicule me all you like, ( I don't give a damn !) but I believe that I CAN repeatedly hear small audible differences between the Digital Captures with her voice, (especially a little after 12 seconds) with Digital B sounding slightly  cleaner and more realistic. It's a shame that the clips weren't longer, with less attenuation to further improve S/N.

 I reported this via a PM to Mani not long after the files were released, but didn't post about it.

 My  remark to Mani about around 12 seconds in my PM,  pre-dated other reports in this thread.

 I have tried again several times in the last day or so with the same conclusion.  

The only time I couldn't hear a difference was earlier yesterday evening BEFORE taking my BP medication.

 ( The TV didn't sound so great at the time either )

 

Yes, I know, I must be DELUSIONAL !!!  

[Ralf11]

one way to find out

 

do a test

[sandyk]

45 minutes ago, Ralf11 said:

one way to find out

 

do a test

 

 

It is completely immaterial to me whether you (or others from the Objective side) believe me or not.

 

[esldude]

5 hours ago, pkane2001 said:

 

This is very different than the results I get when I use diffmaker, regardless of whether I turn on drift correction or not. Strange. I'll see if moving it to another PC/OS might help.

Whether those are strange results or not depends upon what you were comparing.  

 

I can post results to one of these available files if you wish to compare.  

[PeterSt]

1 hour ago, sandyk said:

Yes, I know, I must be DELUSIONAL !!! 

 

Strange way of being delusional.

Alex, try to understand : the two recordings are different all over the place. If you wouldn't perceive a difference from them then something is wrong with your ears. In your case we know there's something wrong with your ears so we can try to blame your gear but ...

It IS all over different and even with your ears and gear you can hear it.

 

Confused ?

 

Anyway, the two recordings are all over different because the ADC is a kind of doing what it likes at a way high level.

 

 

If you take this as an example (at just over 12s) and watch the top trace just before the end of the screenshot and compare this with the same channel of the other recording (bottom pair top trace) - you see the wave at fairly low level exhibiting those 3 blurps in the former and in that same area nothing in the latter (still ADC things going on but relatively "not"). Now project the peak to peak of the former to under the general wave and see that its peak-peak is almost as high as the height of the general wave of that moment. Say that this lower frequency of the base wave (that's what it is - a lower frequency) has an amplitude of 10mV then this ADC "hunting frequency" of on estimate 80 times higher as this base frequency is also (close to) 10mV. In the top pair this is so and in the bottom pair it is not. If you don't hear that than something is amiss (but can easily be noisy gear itself).

Whether you would recognize it as in "discern from the other for whatever absolute merit" ... no, of course not. This is because of how the ADC operates and how it also response to noise itself. So have 1 million takes and each will be different.

 

What we also need to understand (for the subject of this thread) is that the output of the NOS1 will look fairly much like this (bottom pair and keep in mind that the channels are reversed) :

 

 

which will be after the ADC and when viewed from the analyser. So where the ADC "hunting noise" of the Tascam seems to be 10mV, my analyser will show 30uV p-p which of course includes the ADC itself (because the analyser works with an ADC just the same). And then to think that the 30uV is from the NOS1 and not from the ADC (I think this will show 5uV max but I didn't look really as of now).

 

Moral : with so much ADC anomaly no "fine tuning" of that clean wave will be visible nor audible.

[manisandher]

2 hours ago, sandyk said:

Well you can all ridicule me all you like, ( I don't give a damn !) but I believe that I CAN repeatedly hear small audible differences between the Digital Captures...

 

3 minutes ago, PeterSt said:

... the two recordings are different all over the place.

 

Peter, Alex is talking about the S/PDIF captures, you're talking about the analogue out captures.

 

FWIW, I can't hear a difference between the analogue captures, because they're clearly degraded compared to the S/PDIF captures, and not enough detail is coming through.

 

Mani.

 

[sandyk]

9 minutes ago, manisandher said:

FWIW, I can't hear a difference between the analogue captures, because they're clearly degraded compared to the S/PDIF captures, and not enough detail is coming through.

 

 

Neither can  I, and for the same reasons.

[manisandher]

4 hours ago, PeterSt said:

 

(btw, channels seem reversed)

 

The Tascam back to its 'auto sync' tricks again?

 

4 hours ago, PeterSt said:

You can see that the ADC's modulator is constantly guessing where to be. This is NOT noise - it is just a poor ADC (and if it is a good ADC I would never use ADC's in my life).

 

Peter, so you're sure the issue is with the ADC and not the DAC, right?

 

In any event, I never liked the sound of the Tascam . I have a much better-sounding ADC here, but it's only 24/44.1 (or 24/48), and I felt we needed to go to 176.4 for the captures. If you think 44.1/48 is good enough, I can quickly repeat things with my preferred ADC.

 

4 hours ago, PeterSt said:

I am afraid that here this exercise stops. No need to apply this again with tracks "made to suit" as I suggested myself 16 hours or so ago. Sorry guys ... 

 

Yep. No point in continuing with the current analogue captures. A massive "sorry" to all of you who put in lots of effort in analysis - I thought a well-regarded modern ADC would have been good enough for this exercise. It seems I was wrong.

 

Mani.

[sandyk]

18 minutes ago, PeterSt said:

In your case we know there's something wrong with your ears so we can try to blame your gear but ...

 

 Yes, and we can say the same about your ears, in which the hearing is quite different in both ears, and like mine has even apparently shut down on a few occasions.

Nevertheless, it hasn't prevented you from designing one of the best regarded software players. AND DACs on the planet.

[sandyk]

25 minutes ago, sandyk said:

 

Neither can  I, and for the same reasons.

 Mani

Were the Digital Captures that you listened to already in your possession, or were they forwarded to you via a download from Mansr ?

Alex

[adamdea]

No surprise: at some level the ADC output differs from the original data. Dac or ADC? Does it matter?

 

Next step. Assuming they are level-matched, ABx analogue and digital captures? Hmmm. 

 

Redoing with another ADC might be a good idea. It would help if the dac/ADC loop is transparent. It might be already (hence previous suggestion) Or alternatively it might conceivably be impossible due to the dac.