Blue or red pill?

[fas42]

3 minutes ago, PeterSt said:

 

Frank, then you didn't get what I was talking about.

 

Well, your use of English makes it a bit of minefield trying to work out precisely what you're saying - perhaps, an alternative phrasing, .

[PeterSt]

Just now, PeterSt said:

Frank, then you didn't get what I was talking about.

 

It is not about aligning the takes. It is about the sheer impossibility to start the take at an e.g. 1/192000 of a second so the ADC sampler will start at the exact same time of the analogue wave thrown at it. This is how I said that only infinite sampling rate can do it; then you can shift afterwards to any point for alignment as there are no points (it's analog now).

 

I also said (earlier on) that "of course" this can be done with connected clocks hence one clock for DAC and ADC.

When that is arranged for (doable) we must still take care that all happens in the bit perfect domain of the OS (quite difficult) and we, for example, notice that it must happen on two different PCs (never mind the why for now and go ahead if you think you can avoid that).

 

That then you still have trouble in the alignment itself which is an aftermath thing, yes, that can be a clumsy task. So the software does that too to gain many hours of time and try things without hassle.

[sandyk]

6 minutes ago, fas42 said:

 

Well, your use of English makes it a bit of minefield trying to work out precisely what you're saying - perhaps, an alternative phrasing, .

 Many people have trouble understanding Peter !

 However, given that his first language isn't English, he does remarkably well without the need for the Google translator.

[fas42]

For the amusement of some - and related to hearing "subtle differences", I was visiting the audio friend down the road a couple of hours ago  - and his SQ was "not there". I realised that a power cord was not optimally held in position, and it was easy to hear the variation by very slightly altering this - leading to doing some "furniture" hardware mods to stabilise this - problem solved! Many here would have a fit if they saw how 'dumb' this change was - but, it did matter ... doing captures of this variation and finding a significant difference would be of the same level of difficulty as this exercise, here.

[PeterSt]

Still in the mood ? (of not skip) 

 

 

This is "some" representation of the far more difficult part (you will find this hard to believe) as this is about comparing digital to digital as in : compare the native file data with a capture of it via analogue which has been digitized again (the latter always happens). So this is not about a reference file but about absolute comparison.

 

The fun of this one is that I show two channels here. Say left is the top and right is the bottom.

What this so nicely shows is that my DAC of the time is more slow in the left channel than it is in the right channel. And oh, let's not forget, this is all about music and not test signals.

 

The lag you see is from input (the file data of the moment in time) to the output (captured and registered by the ADC). It is just stereo (2 channel) data and the left channel and right channel are not equal to begin with. Still the left channel shows a vagueness it its lag/deviation from the original which again is the red line.

That the left channel is literally more slow must be explained in another post and another picture. It also requires the experience of the analysis but also of the 100% repeatable character of everything (and this is hard to show here so you must trust me on it).

 

[PeterSt]

6 minutes ago, sandyk said:

he does remarkably well without the need for the Google translator.

 

That's what you think !

haha

[sandyk]

Mani

 At your next GTG with Mansr, would it be possible for you to educate him on what you listen for, and give him  some demonstrations?

 I have found that most are able to hear these things too, provided that they aren't extremely subtle, after a little guidance.

 After a few initial successes, they usually end up becoming quite proficient in this regard.

 It would be very helpful if he was able to home in on these things for himself too.

Alex

[fas42]

12 minutes ago, PeterSt said:

 

It is not about aligning the takes. It is about the sheer impossibility to start the take at an e.g. 1/192000 of a second so the ADC sampler will start at the exact same time of the analogue wave thrown at it. This is how I said that only infinite sampling rate can do it; then you can shift afterwards to any point for alignment as there are no points (it's analog now).

 

I also said (earlier on) that "of course" this can be done with connected clocks hence one clock for DAC and ADC.

When that is arranged for (doable) we must still take care that all happens in the bit perfect domain of the OS (quite difficult) and we, for example, notice that it must happen on two different PCs (never mind the why for now and go ahead if you think you can avoid that).

 

That then you still have trouble in the alignment itself which is an aftermath thing, yes, that can be a clumsy task. So the software does that too to gain many hours of time and try things without hassle.

 

It's all about the fact that there will be some remarkably small measure of time misalignment - even if the clocks are synchronised, there will be a tiny time delay because of the finite time for the signal to pass through the circuit - one way to get around this is to resample at very two high, different  rates, with only a single digit difference in the rates; at a certain time the two will be in perfect sync.

[alfe]

10 minutes ago, PeterSt said:

 

What this so nicely shows is that my DAC of the time is more slow in the left channel than it is in the right channel. And oh, let's not forget, this is all about music and not test signals.

 

 

 

 NRZI  Peter not your DAC.

 

 

[PeterSt]

 

To be sure I don't molest the "pixels" (I talked about granulation vs screen resolution which I took care of) I first put up the original above, to next show what you should look at via the below mouse pointer which picture is now a screen capture of the above one :

 

 

Dim the lights. Look at the monitor's screen a bit from the side, so you will see a sub-graph in white. Above the mouse pointer this shows above the red line.

This white graph shows the transients.

 

On a side note I can tell you that this is the same plot as the one in my previous post, but zoomed in more (the software can zoom infinitely (really)).

 

Assumed you are still with me, now try to see that where the transients (as derived from the file data) go up (towards positive voltage), the deviated (deviating) signal goes down because it lags behind. Thus, compared to reality (depicted by the file data) the signal is slow, and the higher the transient the more the lag.

Thus these things too can be seen and in the end this is all current related again but also very much depending on the DAC under test. The coincidental fact that this showed up in my own DAC makes it a nice case for you because what you see here in two channels can just as well be two different DACs (yours and mine). Mine, shown in the top is slower in following the transients than yours.

 

But is it better to be faster ? this depends on countless things in the whole chain and an other subject.

But in the end these things can be influenced. Just look back a few pictures and how all can be made "vague" for following transients. But of course you like a better example of it :

 

 

The practice and purpose was a little different, but say that the first graph in there is how things can be for a certain amount of zoom and reference, while the second two show the "making vague" (call it more analogue if you like). The fun (for me) is that this making vague is literally in the code by very indirect means, but it really works out as this shows.

 

In not a single post from today I was working with the SFS. It probably didn't even exist back at the time.

ALL matters and all can be measured. ALL has a different influence. And you can use ALL together if you like.

... And in your player this IS used all together. But with not many or no options (no dials for it).

 

I hope this sufficiently shows that we can measure these matters but also that it won't be an easy task.

 

[PeterSt]

23 minutes ago, fas42 said:

one way to get around this is to resample at very two high, different  rates,

 

Yes, I thought you would be funny to come up with this.

And of course you next claim that you wouldn't "resample out" these subtle differences, right ?

So again go ahead with that but I don't believe you will be left with some result (differentiation).

 

Otoh I am almost sure that Mans is - or has been trying this. So yes, I'd expect something in that realm.

Thus Yes, technically that is a possibility. Practically I'm afraid not.

[PeterSt]

26 minutes ago, alfe said:

NRZI  Peter not your DAC.

 

Hey, since when are you around again eh ?

 

But Alfe, I miss the context !

And if I'm allowed to make up my own context, how to implement it ?

 

BBbbut ... FYI : with the digital capture (thus compare file contents with analogue out) I do make use of sneaky markers.

That is what you meant, right ?

[manisandher]

On 3/26/2018 at 9:23 PM, mansr said:

 There has to be an explanation.

 

Perhaps we're getting there?

 

Unfortunately, I can't see how anything Peter's put forward in his last few posts could be applied to the analogue captures we have from test.

 

Mani.

[fas42]

2 minutes ago, PeterSt said:

 

Yes, I thought you would be funny to come up with this.

And of course you next claim that you wouldn't "resample out" these subtle differences, right ?

So again go ahead with that but I don't believe you will be left with some result (differentiation).

 

Otoh I am almost sure that Mans is - or has been trying this. So yes, I'd expect something in that realm.

Thus Yes, technically that is a possibility. Practically I'm afraid not.

 

Given sufficient accuracy of the ADC, and the best methods for processing the data then there should be something there - I haven't pursued this far enough to be sure; and you may have taken this further without finding anything worthwhile - but there has to be some method for identifying the variation, if the ears can hear it.

[PeterSt]

1 minute ago, fas42 said:

but there has to be some method for identifying the variation, if the ears can hear it.

 

OK, you didn't understand any of my today's posts.

Too poor English on my side. Sorry ... 

[manisandher]

1 minute ago, fas42 said:

Given sufficient accuracy of the ADC, and the best methods for processing the data then there should be something there - I haven't pursued this far enough to be sure; and you may have taken this further without finding anything worthwhile - but there has to be some method for identifying the variation, if the ears can hear it.

 

I'll happily release the digital and analogue captures once Mans has reported back. Do with them what you like...

 

Mani.

[manisandher]

3 minutes ago, PeterSt said:

OK, you didn't understand any of my today's posts.

 

Hey Peter, if people want to try, let them try, no?

 

Edit. I'd even like to make a bit of a competition with a prize out of it.

 

Mani.

[PeterSt]

38 minutes ago, fas42 said:

It's all about the fact that there will be some remarkably small measure of time misalignment - even if the clocks are synchronised, there will be a tiny time delay because of the finite time for the signal to pass through the circuit

 

No. This only happens with the "digital" comparison I talked about and this was/is covered for (a hard pain, but it was/is).

For what the subject of the thread ia about, this is harmless because we talk about two (or more) takes and all will behave the same (delay and such is always the same).

We're not looking at molecule level, right ?

(too much noise for that )

[fas42]

1 minute ago, PeterSt said:

 

No. This only happens with the "digital" comparison I talked about and this was/is covered for (a hard pain, but it was/is).

For what the subject of the thread ia about, this is harmless because we talk about two (or more) takes and all will behave the same (delay and such is always the same).

We're not looking at molecule level, right ?

(too much noise for that )

 

Doing a "digital" comparison is the only worthwhile option - an analogue comparison is so dependent on the recording apparatus, so much distortion and noise will creep in that it would be a nightmare ...

 

An immediate capture to digital representation at the "horse's mouth", at the highest possible accuracy, would be the starting point - then, maths can take over and make of it something worthwhile.

[sandyk]

Mani

 Are you also able to hear clear differences between any of your files saved at different locations (e.g. internal and external ) when played using the same player settings ?

 These wouldn't need to be "captured" , as they could be saved to another medium (with a small degradation) or uploaded directly.

Alex

[sandyk]

8 minutes ago, fas42 said:

Doing a "digital" comparison is the only worthwhile option -

 

 No. It isn't an option. It does not show any differences between files that sound different, but have the same Binary Data.

 

[manisandher]

9 minutes ago, fas42 said:

An immediate capture to digital representation at the "horse's mouth", at the highest possible accuracy, would be the starting point - then, maths can take over and make of it something worthwhile.

 

You mean before any digital-to-analogue conversion has taken place?

 

But Mans has already done this analysis and has concluded categorically that the 24/176.4 digital captures taken during the A/B/X are bit-identical (ignoring the first 10k samples on some of them).

 

What would you be able to do that Mans can't?

 

Mani.

[sandyk]

3 minutes ago, manisandher said:

 

You mean before any digital-to-analogue conversion has taken place?

 

But Mans has already done this analysis and has concluded categorically that the 24/176.4 digital captures taken during the A/B/X are bit-identical (ignoring the first 10k samples on some of them).

 

What would you be able to do that Mans can't?

 

Mani.

Mani

 Would I be correct in saying that you were unable to hear the differences that you originally heard when listening to the digital "captures" ? 

 

Alex

[PeterSt]

1 minute ago, manisandher said:

I'd even like to make a bit of a competition with a prize out of it.

 

Well, didn't I call out for the bookmakers ?

haha

 

Point is (I think !) that you/one can't really deal with the few samples only, never mind you have a dozen of the same of them. Point is, they are the same and people will not be able to see what they are looking for. So there would be one test set only. Remember my remark (which is totally crucial) that I could repeat the tests however I want with the music I want and as often I want. Allow me to give an example again :

 

 

Keep in mind that this could be Child in Time or White Christmas as this is data (music) independent .

But how can one tell it is about this, while I by now showed 6 or so examples of all very different kind, while I also seem to know what I am doing to incur for such a distortion (which of course is still bit-equal). With only one example (your test files) one wouldn't know what to look for.

If I repeat this 10 times (through different music) then I can be 100% confident that what I see is the subject. Also I can scroll through the whole recording (and not only have 1 few seconds of it). I have means to find the differences, etc. (you might have no idea what it takes to even find the deviations, which is all related to the zoom level). Or some other way around, where the last example above was about : the mouse points at something which I could detect in an other take (the two below) and only therefore could identify the residu in the top trace.

Analysis is just that I'm afraid - A lot of time and special means to do it. I just made them because I am crazy.

 

For fun : look closer at the anomalies above. You can see that the repetition is the most frequent in time. Use the large excursions to see the smaller ones throughout. The distance is e.g. 00:0048.010 to 00:0048.030 (merely 0.08 to 0.28). The 48 is seconds. So this happens each 2/100 of a second. You know what ? this is 20us. And you know what more ? this is the actual Windows time resolution (at least back then).

Now that ...

Find that timer (or in your own software or in other software running), eliminate it and have again better sound.

or (for fun !) :

Imply an SFS lower than 20us, be thus confronted with this best Windows timing (for user code), have this distortion applied and there you go. Set the SFS to 200 (meaning 30 seconds or whatever) and you won't find back this timer distortion because the timer goes off once per 30 seconds only.

If I'd use timers of course. But I don't.

But I am full with tricks.

 

Still I wouldn't take up that challenge in this case. I seriously think it can't be done (by means of what is available).

[fas42]

8 minutes ago, manisandher said:

 

You mean before any digital-to-analogue conversion has taken place?

 

But Mans has already done this analysis and has concluded categorically that the 24/176.4 digital captures taken during the A/B/X are bit-identical (ignoring the first 10k samples on some of them).

 

What would you be able to do that Mans can't?

 

Mani.

 

No. Where the "damage is done" is in the conversion to analogue, within the playback chain. A capture of that analogue, using a precision ADC at a point close to where that first conversion took place, is the "horse's mouth". Of course, there is always a possibility that the presence of the capture ADC in turn interferes with, degrades the analogue input, via some subtle coupling mechanism - can the measurer take a reading in an experiment, without unduly affecting what he is trying to measure? - an ongoing dilemma for all scientists.