Jump to content
IGNORED

Just the facts: iTunes, lossless, AirTunes and jitter


Recommended Posts

Thankyou for your answers, but I do have some follow up questions and clarifications. Sorry I'm writing on iPhone so can't copy and paste so hope you can follow.

 

I asked what DAC an ADC for various reasons. First a lot of DACs eliminate a lot of jitter errors and from my understanding of how you did the tests, the analogue output stage of the DAC matters. Same for the analogue input stage o the ADC and I would expect a higher end device would be able to reject more external interference.

 

I don't think you answered, but as the test/comparison programme running on a separate PC to the one running XXHighEnd?

 

What I don't understand is how you can say that any variation in the captured data due to the ADC picking up external interference is irrelevant. How do you know that the differences in the recorded signal displayed in the black trace are due to variations in the playback, not variation in the recording? That was my reasoning for running tests multiple times an averaging the results. That's how we always ran tests when I was studying engineering at university.

 

Also, how did you syncronise the beginnings of the waveforms exactly?

 

I asked about similar graphs comparing bit perfect and non bit perfect from iTunes so meetmorrals like me can see what a really bad comparison looks like. Yes it would be "for play" a little but might help less technical members understad what your graphs are showing.

 

The skeptic in me is a little worried about manufacturers who present graphs without allowing access to information on the testing methods used - especially as you said yourself, you created the comparison program. I'm already (see some of my other posts) skeptical - but open minded - that bit perfect software sound different and you did offer the graphs voluntarily so hope you don't mind me analysing the testing methods.

 

Thanks

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

Before I start justifying myself, let me start with asking you whether you asked the test equipment manufacturers how *they* perform their tests. It may cost you 50K and brings nothing but the explicit other way around. I can tell you (without showing it to you yet) that what such a device brings as "distortion" is total complete BS rubbish. I know now ...

 

I asked what DAC an ADC for various reasons. First a lot of DACs eliminate a lot of jitter errors and from my understanding of how you did the tests, the analogue output stage of the DAC matters. Same for the analogue input stage o the ADC and I would expect a higher end device would be able to reject more external interference.

 

This is true. The funny part is, I don't see this. I do see a variable response to e.g. the cursor thing from one DAC to the other, but I do not see this for the same test on the same DAC. This, while this sure is to be expected. Conclusions ? these things are told to be there, but actually they are not or they can't be unveiled by this method of testing OR they are so much repeatable that they come out the same each and every time. For something like jitter this seems odd to me, but on the other hand I have an imagination that this can happen. Anyway, I don't vote for the first option (things are told ...) while for sure this can be the matter just the same.

 

Before judging this, please keep in mind what I found in the first place : one anomaly "spike" we may call jitter, seems to have a way longer effect than that one spike only.

There is not one single bit in me that ever trusts the official measurement, because they perform the exact same loop as I do, but I know I do it right. This means they do it wrong. There is much much more to tell about this, and there is also much more to find out on this subject (I have hardly time for measuring, because still working on the software itself), but think of the example and skepticism you have yourself : do you really think the ADC in measurement equiment will be super outstanding opposed to, say, those for the music producing industry ? of course, they won't be the worse for sure, but EVERYTHING depends on it.

Now, go Google and let me know what you found on this (except possible posts of mine hehe).

 

But let me summarize this part by saying that your doubts on this one are fully recognized by me. Hey, I put a disclaimer right on this under the original post.

 

Two things to settle for I think :

1. This is not important to the relative measurements as how I am doing them, BUT

2. it requires that inherent DAC/ADC jitter doesn't play a too large role.

... with my findings that I don't see anything of that

... which by itself puzzles me.

Overall conclusion on this because I can't do any better, and jitter is assumed to be really there : jitter is completely repeatebla BUT therefore impeeded by the data itself (aha, data jitter).

Also to keep in mind : the clocks of DAC and ADC are connected.

 

I don't think you answered, but as the test/comparison programme running on a separate PC to the one running XXHighEnd?

 

Yes, I see now I forgot that one. The answer is no and I certainly would agree with you if you say it should. And ... I tried, but it can't. Both playback and recording need to be under one control or otherwise the reference can't be set. However, I did all I could to let the recording (aka capturing) not influence the data, at knowing that it will anyway. I don't know how this influence looks like, and I'm afraid we never will (kind of chicken-egg problem). Anyway this is the reason why I had to create this part myself, actually not much different from the "necessity" to do so with XX.

 

What I don't understand is how you can say that any variation in the captured data due to the ADC picking up external interference is irrelevant. How do you know that the differences in the recorded signal displayed in the black trace are due to variations in the playback, not variation in the recording? That was my reasoning for running tests multiple times an averaging the results.

 

Ah. Ok. My before answer to this was hidden in the "more tests needed" vs. "once you know a property" (similar). So, back to the example of the cursor, it is not difficult to prove that the excursions you see come from that cursor, once you know it is there, and it is not there in the other "file". So, this one is easy : the flat one is the reference here. But is it ? not sec, because the file with the cursor also has become a reference *for such things !*. As I wrote on my own forum (by I think you have been there by now), it may take days to find real decent reliable references working this way. That is why I created the absolute measurement afterwards (at earlier thinking it wouldn't be possible), because that is obviously the way to do it. Yea, weren't it that now all *is* depended on the ADC.

Another, hopefully more direct answer to your question, depending on relative measurement : easy, have a take from XX, have a take from Foobar, have one from XMPlay, and this comes out by itself. You have three runs now, and any anomaly occurring in one only, will fall out. The fun is, if the anomaly is in the DAC or anywhere (including the original file !) except the playback, this does NOT show because it is repeatable. Ain't that great ...

 

Also, how did you syncronise the beginnings of the waveforms exactly?

 

Very good question. And assuming that you're not in doubt I can, this is irrelevant.

And a secret. :-)

 

I asked about similar graphs comparing bit perfect and non bit perfect from iTunes so meetmorrals like me can see what a really bad comparison looks like. Yes it would be "for play" a little but might help less technical members understad what your graphs are showing.

 

Ok, Good. But I think you may make the same mistake as Mat and the "big perfect soap", or otherwise allow me to say the question is wrongish; What you should have asked is a comparison between both iTunes and Amarra (e.g. of course) because only that can tell something. So, I keep on having the standpoint that what you literally ask for cannot exist, although this depends on the application a bit, and for iTunes it can't. I feel no need to explain further, but can always direct you to the more useful comparisons.

Btw, despite what I just said, comparing "volume results" will (I think) not be reliable in any case. For now you have to trust me that I can't explain what's in my mind on this, but in the mean time I have another kind of example which shows it also :

 

Suppose you have two calibrated volumes (meaning : both have the exact same attennuation which is problem #1 because how to prove that for two players of which you don't know the internals, ok ?). Anyway, supposing this. Now, one of them will represent the red line, and the other one, Amarra of which we know it dithers, the black. For understandings : you may just as well switch both, as long as you know which is which. So what will you see ? a one bit variation without pattern. Uhm ... if the dithering is applied correctly (and *that* you can see, thus). But there isn't anything else to see.

Don't forget, if you're looking at stuff like an FFT, you can look at this as aggregated data, which is the exact reason you'll never see something as from my picture in an FFT (or waterfall etc.). The other way around, discovering undithered data will be a no go via my method, because I'm working with music data in the first place. Oh, you can play back sines and all just the same, but now the next part comes into play : what does your DAC make of that sine in the first place.

 

Although I'm trying to keep it understandable, here I'm going to get stuck on that, because now you need a few "references" in order to understand, and it is on to the NOS/Filtering etc. thing which will make all uninterpretable to start with, while I wanted to see a discrete dither which is mangled along with everything. Use an OS DAC, and this is a 100% show stopper, because nothing can be recognized from it, and thus dither cannot be either. The detail you're looking at is too high. An FFT does better on this.

 

Addendum after reading back : I only now see that your before question (at least that's how I have it in mind) about volume-iTunes vs volume-Amarra wasn't put at all like that in your latest post :

 

I asked about similar graphs comparing bit perfect and non bit perfect from iTunes

 

So, if I have to take this literally, this sure is a valid question, but again I can predict an "impossible" again, but now for another reason;

 

There's two kinds of "not bit perfect" : the one that has dither applied as a bug, like Windows XP does, and the one that resamples (and dithers) like Windows Vista does.

Now, the dither thing will have the same result as I explained before. The resample thing tough, may vary so much that nothing can be made of it. You could say it keeps on being the right part of the before shown picture all over, and it only tells you that everything is wrong. Wrong opposed to the original file.

 

This latter fact falls apart in two subjects : upsampling (from Vista) and oversampling (from a DAC).

I am sure the first (Vista) will show some correlated data, and I know (!) that the second will not. This is the story about the squares becoming sines (OS DAC) and sines becoming squares (NOS DAC).

May you have followed that (if not, sorry, but I can't keep on repeating it), we can now extend this little story :

a. squares becoming sines : this happens within the DAC.

b. sines becoming squares : this happened at the recording -> CD process (not enough resolution).

 

Ad a

Makes measuring IMPOSSIBLE (but hey, 50K equipment tells it can !!)

Oh excuse me, I can measure that too, but somehow the results say 100% distortion compared to the original file.

 

Ad b.

Measurement is just possible.

 

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Peter, as always thanks for your time in responding.

 

I'm not sure I'm much further forward understanding your testing methods: I'm not able to read your response except on iPhone and that makes it difficult for me to follow your langague at times (I assume English is your second language?).

 

Anyway I'm not sure this is adding to the original thread I'm just trying to understand. I'm not doubtingthe validity of the results, just sometimes it's diffiult to understand why you ignore what I feel are valid (potential) external influences. As I said before I'm a natural sceptic about software sounding different.

 

Thanks for your time by I feel it's best to leave it at this point, especially on this thread. Maybe when I have more time I'll be able to think more and return to your original thread.

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

 

Peter,

 

Don't take this post the wrong way, I'm just attempting to discuss further, not moan or doubt what you're doing. I'm chatting away elsewhere on this very subject too..

 

You have demonstrated that your GUI causes what we see in the graph, so could possibly be an artefact caused by your own code.

 

The point halfway along the trace looks like a filter transient response which means the loop has gone out of lock, possibly caused by some interrupt in your GUI, the lock is then reaquired, producing a transient. So, with the GUI running, it's not bit perfect as the graph shows.

 

My understanding is that John Atkinson of Stereophile verified this does not happen with Itunes working with the Airport Express.

 

Since I'm interested in testing myself, I'm going borrow a computer and attempt to do some recording and analysis myself. I find this stuff very interesting...

 

 

Matt.

 

 

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment

I've got a week off purgatory coming up in June and this was also on my agenda! I don't think we can do the CSI level stuff Peter is over-dosing on but I'm sure we can have a good crack at a sensible set of outcomes.

 

The big one, for checking between different software, will be volume matching but if everything is at max then nothing should be happening. At the very least we might be able to say that even though volumes are at max, something is still happening! And then there is always the Peak Gain tool in Wavelab. My first project will be wav and flac versions of the same file, through the same software. I swear to god flac sounds inferior, so at the least I should be able to prove myself either correct or stoopid!

 

I can handle both. :)

 

I plan on recording everything from the Dac output, that way I'm going to be looking at the signal that hits my amp - which is the one that matters most to me! I'm sure all this will be very unscientific and prone to all sorts of extra-terrestrial influences but if I get the same, repeatable, results from a half-dozen different tracks then I shall be happy.

 

Happy daze!

 

Link to comment

BEEMB, I don't quite understand what you're saying, but if I get the meaning properly, I don't think this is the explanation.

 

If you're referring to a typical PLL implementation completely losing sync, all DACs that I'm aware of will completely mute the audio. You might, instead, be referring to the PLL in the DAC adjusting it's frequency in a large discrete step to prevent buffer underrun/overrun. It does not seem likely that such adjustments would be correlated so perfectly and repeatably to the screen refresh, unless the buffer is extremely small. BTW, that kind of PLL adjustment can and will occur in any system that uses an external DAC without a separate clock sync to the source. Also as an aside, keep in mind that Peter's system uses a Firewire digital interface, so the original source clock is not located in the PC.

 

I would not put excessive stock in Stereophile's measurements. I'm glad they do them, but what a digital audio device does with a steady state signal, when fed by laboratory-grade power, may or may not correlate well to the way it performs with musical signals and dirty power.

 

Doing recording and analysis of the kind Peter is doing is not trivial. Most analysis tools are designed to extract a particular abstraction from a single signal (a spectrum analysis, or THD, or A-weighted noise, for instance). What Peter is doing is comparing two signals recorded at different points in time. There are reasons this isn't usually done, and reasons that Peter has had to write quite a bit of code to make it happen. But it is the most legitimate way to look at the system as a system, instead of as a collection of idealized black boxes.

 

 

 

 

Link to comment

The point halfway along the trace looks like a filter transient response which means the loop has gone out of lock, possibly caused by some interrupt in your GUI, the lock is then reaquired, producing a transient. So, with the GUI running, it's not bit perfect as the graph shows.

 

Try not to put things upside down Matt !

The base of this all is that it *is* bit perfect. Otherwise this all makes no sense.

And so it is. And therewith all bugs in code etc. are out of the equation.

 

Keep in mind that I only showed this as an explainable example. I also can show Foobar-XX or whatever you want comparisons. All show differences, all 100% repeatable, but not all explainable.

Remember the Q1 slider in XX ? there are some pictures of some settings on phasure, and it just does what it intends to : change sound. And ... still bit perfect.

 

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

just sometimes it's diffiult to understand why you ignore what I feel are valid (potential) external influences.

 

Eloise, this is not my intention. But please keep in mind that if I - for example - refer to irrelevance, you can't ask me to explain something which just is not there. The only thing I could do is explain why it is not there. So, I thought my posts where long enough already and that you could trust me on "irrelevance" if I say so.

 

Might you refer to me not wanting to answer a question like how to get the stuff aligned ... think twice in that case. Only if you think I make errors on proper aligning - that is relevant. But as I started the last post, I am not here to justify myself. I hope that is okay with you and everyone.

This is different from faking or telling stories of course. So on that matter I should be explaining sufficiently enough. Well, I hope.

 

Thanks (and sorry for that english),

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...