XXHighEnd

Before you start laughing :)
Please refer to
http://www.digido.com/bob-katz/jitter.html
and read the passage "Can Compact Discs contain jitter?"

Now:
Couple days ago I have burned some audio CDs to listen in the car. I gave up on the CDR audio in general a while ago because it was too jittery for me.
But in the car it the least evil of all (I don't want to play from laptop in the car). So after couple of songs I realized that I feel something familiar in sound signature ( if I may).
And it jumped at me:

I was listening to XX 0.9r while burning audio CD!!!

So here it is Peter, another application for your player. You probably don't suspect how much more there is to your "know how".

So whatever is happening in XX that influences the SQ, the very same thing affects the quality (of jitter) of the audio CD being recorded.
see the link above for details.

Now you can start laughing. :)

Please try it yourselves, when you are done, and share your thoughts

Andrey

PS. that's the way to bring the XX player to your CD player. Just choose version of XX you like, play something with it and burn CD audio in the bacground. and viola XX inside CD player. :)

hehe and I thought I was the voodoo expert here.  Hi andy, not laughing at you laughing with you.  who knows.

Now, Andrey, I have a very open mind and I am not quick to discount anything. And I have heard many "interesting" theories in my time. But I have never heard an idea like this before! Forgive me while I pause to laugh a little . . .

OK, now that I got that out of the way . . . jitter is very easy to measure on CDs. (Mind you, I didn't say it's extremely accurate - just said it's "easy" to measure). You can use Nero CD/DVD Speed with BenQ DVD-Rom Drives and it will chart the amount of jitter on a disc (as a percentage). However, the lowest it will go is 7%. Or if you use certain Plextor drives, you can use a great utility called PxScan:
http://www.alexander-noe.com/cdvd/px/index.php
This utility will chart the jitter as a value (such as 1200). No one really knows what this value correlates to, however we know that a value of 1300 is considered LESS jitter than 1200. So the only thing of value with this test, is to measure a handful of discs, and simply determine which is lowest.

These are two examples of what you can do on a PC. But if you want better accuracy, you can always send your disc to be analyzed by AudioDev CATS CD Analyzer:
http://www.audiodev.com/?id=2088

Could be an interesting experiment. Of course, you know that a Plextor Premium will give you the best results and that the brand/type of CD-R you use will also affect the results.

Unfortunately I don't have such drives to do the testing in numbers.

But isn't it about type of jitter instead of less or more jitter, for XXHighEnd?

Well, some other "jitter" expert can chime in here and add their knowledge. But the way I see it, the playback (as in XXHighEnd) is about the jitter "spectrum" (which I think you are referring to as the "type of jitter"). But what I'm referring to is the physical jitter on the CD, which means the amount of lands and pits that are not the precise length they're supposed to be. The varying lengths cause the timing inaccuracies (jitter).

When you burn CDs with your computer (assuming you use the same drive and same CD-Rs), the only difference is this physical jitter I'm referring to (and also BLER, but that's another story). Not a change in the jitter spectrum. (Which is the effect of your playback chain).

here goes vodoo:

And why this physical jitter recorded during XX playing cannot result in the same jitter spectrum when playing back.
According to the link I provided, Jitter "microcosmically" is transferred through power supply.
So the recorded CDR when played back recreates through power supply the same jitter spectrum as when it was recorded.

Don't have enough technical knowledge here. So I am just speculating.

Andrey - you act like the process of "burning" a CD-R is actually "recording" something and therefore "records" the jitter spectrum of your system onto your CD-R. That's not what is happening. An uncompressed WAV file on your computer does not contain "jitter" information. When you burn that file onto a CD-R, the data is a 100% bit-perfect copy. Jitter is only what happens during playback. Now if you read the file back as a data file and then streamed the audio out of memory (like a "memory player") then the fact that the pits and lands vary in length does not matter, hence it would be like playing music from a computer transport. But conventional CD players stream the audio of the CD in realtime, hence the variations in length of pits and lands will add jitter (in addition to the jitter already inherent with this CD player and the signal it outputs).

Let me also say, there is no CD burner in the world that can burn a CD-R with perfectly shaped pits and lands (zero jitter). (That would be equivalent of playing music from memory or a computer transport). And even if you had a perfect CD (with zero jitter), the playback chain - from the laser to the power supply to the clock/oscillator and all the way through the signal - would still introduce a jitter (spectrum).

The only thing that's going to change the amount of inaccurately shaped pits and lands on your CD-R is the capability and accuracy of the laser (of your burner) and accuracy of the speed of the spinning disc, and the quality of the blank CD-R. By multi-tasking your burning and playing XXHighEnd, the only impact this will have is on the buffer of the CD burner, which will either result in buffer under/overrun or a more/less accurate speed of the data transfer (in conjunction with the speed of the spinning disc).

So to sum up, I think you are confusing two different culprits of jitter. The only jitter that physically exists on a CD, is the inaccurately shaped pits and lands. The music file itself does not contain jitter information.

I can tell you, your timing was perfect. I read this line, and bursted of laughing.
The tense created by the introduction (I read the link, although I knew it already) perfectly came together with the crux. No jitter there !

But OK, here's my personal problem ... I believe you.
But now, how can it be ?

First of all, we can fairly assume that nobody really knows. Or better : nobody knows what's really happening in these areas of audio. On the other hand, I myself really try to pay attention to all what is happening here at my own place, as well as so called unimportant / small things people report. I all take them into account, and all together they slowly form a picture which in the end will create better audio playback.

That being said, obviously I already know from many things going on, or otherwise XXHighEnd would not be alive. But honestly, it is my feeling that this is 10% only of all there is. But mind you, this first 10% is already unknown generally, and there too you might appraciate that as being voodoo. But it really is not; it is just a matter of recognizing what's going on, and from there on proving it's true. That this still would be far from real science is another matter, but also unimportant (to me anyway).


To the subject, and 100% based on what Andrey found is true (so keep that in mind please), my idea about it would be as follows :

First of all it would be a coincidence (I say this because otherwise my explanation would not stand);
It would be a coincidence to the matter of 0.9r inducing for this, while e.g. 0.9o will not. Otoh, if different sounding versions all induce for the same sound signature on a recorded CDRom (as per the subject), my explanation would even hold better.

The two tasks of audio playback on one side and burning the CD on the other, will interact. They will, say, vibrate, resonate.
Looking at the phenomenon "resonate" you can already feel why I think it is a coincidence; something resonates at certain frequencies only.
Btw, keep in mind that both processes (playback and burning) are 100% time constraint processes. So (persistent throughout) resonating can be there indeed.

Techies/engineers will immediately say "BS", because the CD burner will work with buffers, and whatever is happening software wise, cannot influence the endpoint at the end of that buffer.
Well, that would be true for USB playback just the same. Right ? ... go have a listen ...  :)

I cannot tell for the CD burner and how that could be influenced, but I guess if I'd want to, I could. I could by means of the very same I do it with the DAC.

Oh, it may occur to you that I don't elaborate on "resonance" (what, why etc.). :no:
 :)


Where above is a "far out" explanation, I also like (better) to have this one :

For me, definitely things are going on in our brains when we hear a kind of playback we like, for the coming future;
Once we hear a playback which has something we like, from then on we automatically recognize this for the future. We can't do without that experience anymore. Example in the area of Andrey :
Each and every day I seem to recognize the "quality" of my car radio as a quality which was not there yesterday. I mean, when something better came from XXHighEnd, I tend to recognize the same in the car. Ok, my car equipment may be somewhat better than general, but actually it is just there, and I did not pay attention to it at buying it, and in fact it doesn't even interest me. I listen to it as background data, and things just occur to me ...
What would happen here, is that where I "learned" some good aspects of playback via my home system, some of those aspects can be there in the car equipment, but are recognized by the brain only when they are in the brain first ...
That the total picture keeps on being wrong in car equipment (ok, like mine) is unrelated to that. Good things only jump out when you know them.

Of course, when this would be the explanation of Andrey's experience, now all his self burned (or any) CDs sounds like 0.9r in his car, so this is just a matter of trying that out.


Quite another subject is the jitter being on the CD, with the explanation of the pits being more straight / longer etc.;
Personally I think it is dangerous to call this jitter as such. Indeed, culprits in there only unveil at playback, but then only when reading is not appropriate. It would just be errorneous reading, impeeded by wrong burning. Of course the effect would be the same as time jitter, so for that matter it would be true. Note though that there is a difference between a (44K1) clock pointing at samples and because of deviation a sample is missed or read twice, and a reader which does not read accurately, just reading plain wrong data.

Do note that wrong data in these terms is bout reading a 0 where it whould be a 1 (or the other way around) which can happen anywhere in the byte, and if this is near a most siginicant byte ... call Houston (and assuming this is not captured by CRC checks, or can't be re-read within the expected time).
Time jitter as what we speek of generally, is about missing / re-providing a SAMPLE. Btw note that IMO this can be proved by recapturing the data at the end of your SPDIF etc., and that there is no way wrong data comes from it. This means the individual bits stay as ok as they were and nobody is going to tell me that the bits get mangled inside of the (bit shift registers of the) DAC afterall.

Wrong data read from a CD therefore is a zillion times worse than missing/repeating samples in the DAC (which by itself is a zillion times worse than the DAC not being accurate in providing the proper analogue voltage, but that's another matter again).


From above follows that real jitter on a burned CD would be about repeating samples (I don't think that missing samples can occur here), of which I actually don't know whether they can happen during the process of burning. Otoh, it is 100% sure this happens at ripping, actually caused by processes not being able to keep up and therefore buffers keep on having the same data, and since burning is very similar to reading, why not (in the early days of burning you were not even allowed to touch the PC because of buffers running empty, the process not being able to cope / capture that).


All together, and no matter my first explanation above, I tend to say "Busted !".
There would be, however, not much distance to "Plausible", when all is taken into account.

What remains is that I sure do believe Andrey in what he perceived.

The two tasks of audio playback on one side and burning the CD on the other, will interact. They will, say, vibrate, resonate.
Looking at the phenomenon "resonate" you can already feel why I think it is a coincidence; something resonates at certain frequencies only.
Btw, keep in mind that both processes (playback and burning) are 100% time constraint processes. So (persistent throughout) resonating can be there indeed.

There is an analogy in Chemistry. :grin:

Most pharmaceutical drugs are isolated through a process called crystallisation. Any one chemical can crystallise in a number of forms (polymorphs). Some of those forms have desirable characteristics such as enhance solubility and can be patented in their own right.

So workers throughout the world have often raced against each other to crystallise a particular polymorph and many workers dedicate years of research to the process.

There are a number of cases in history where a worker has crystallised a difficult, wanted form, in one Continent only for the same form to be isolated almost at the same time in a different Continent.

The phenomenon is known as morphic resonance where the blueprint for the crystal form somehow finds its way around the world instantly. Like the effect with the CD it cannot be proven or disproven at present. :dntknw:

Hi Edward,

Thanks for the information about 100% bit perfect CDR copy :(. I have a knowledge.
And clarifying things about CDR recording process.
I never said that the music file contains jitter. Why are saying this? :(
And I don't confuse anything.
I may sound vodoo, but I understand what's going on. at least everything you said I agree with.
But why are saying for?

Andrey

It does not record jitter spectrum on CDR. It record its usual physical pits and lands jitter but in some manner affected by what's going on in the system, including spectrum created by XX.

And somehow this physical pits and lands jitter reminds me of this jitter spectrum when played plack. And I am saying that it probably recreates si,ilar "picture" on the power supply. Vodoo.

I'm sorry Andrey, your theory and explanations lost me. I thought I was just helping by adding clarification to the "burning" process. Oh well, I guess you already know everything and there's nothing else I can contribute to this topic.

Good luck with your voodoo.

Fascinating discussion. Andrey, what software were you using to burn the CDR while you were playing XX?

A very professional one: Roxio Creator Plus!
:)

I am thinking about removing this complete topic :(

Please don't. Trust your ears! Just extend your experiment a little.

For comparison, have you burnt a CDR of the same track without XXHighEnd engaged (or different version of XXhighEnd loaded) to compare for any difference in sound against the CDR you already have?

I remember being scoffed at 20 years ago when I suggested tonearm height movements of +/- 2/1000ths of an inch around the "correct" VTA alignment could be easily heard by anyone. Had to demonstrate it to 40 members of the audio club before 36 of them agreed they could easily hear the differences.

Frank

Hi Frank,

The first thing I did when noticed this was making a copy of the same tracks without XX playing.
When I tried both of them in my car. The difference was "obviouos" to me, no blind test for now, but I feel pretty confident.
I am planning to do more testing (may be even blind, if my pals won't giggle) with two different versions of XX r and pd and without XX and see what I get.
ran out of CDRs now :)

Andrey

Hi guys,

Please don't get annoyed about eachother's means of expressing of what we're all after ... exploring the mysteries of audio. I don't think neither of you deserves any bad treatment by the other (or another) and IMHO only because we all are free to express our ideas about things, we proceed with better playback (in fact, that happened again today, but that's for another story :teasing:).

I am glad that people are allowed to say what they think, and so far I did not see anything on this forum that would be beyond the limits of reality, or worse, just blabbering about something which was copied from someone else without actually knowing. If anything, *that* would be useless.

Andrey, from the same distance as you look, I don't see anything wrong with Edward's view on things, and what I myself did not agree with I wrote about (and nobody says I'm right);
Edward, again from the same distance, I think there is not much wrong with what you said as quoted above in a response to a maybe clumsey saying of Andrey. What I did not quote, however, maybe was not necessary.

I think both of you are as valuable to me and everyone just because of the knowledge *you* have, with the sidenote of me having just that tad more experience with either of you because of a load of PMs. And think back, both of you started with, say, shouting on this forum. You both are unique to that respect. ;)

Best would be if *I* appologised for my before post in this thread, just in case you both read things in there of disagreement by me.
But hey, this is not about disrespect, but about working out things for the better. You may not believe it, but I operate with your data only. From all of you. Your data creates your player :yes:.

Wow Peter, I think you read way too much into that (and perhaps too much inbetween the lines). I was not annoyed nor offended and most certainly meant no disrepect to Andrey. I was trying to add a scientific complement to what Andrey was saying, but I suppose in the end maybe something came out wrong. That is the price we pay for text messages. :( There's no substitute for HEARING someone speak and WATCHING his manner and expressions. It's a good thing I didn't become a literary writer (with this much misinterpretation going on).

 Time for a group hug  :friends: :friends: :friends::friends:

Oh yes. And the context matters very much. doesn't it?
:)

Ok Now, here is some results.

I recorded 3 CDRs with Nero
1 with XX r playing
2 with XX pd playing
3 with no XX playing

First I tried them with XMplay and through laptop speakers. But was a short one and I thought I could tell the difference, but decided to wait and try it in my earplugs later.

Then I listened them on windows media player :) just to make sure I can hear anything and I actually I could.
Then I asked a friend to shuffle the 3 CDRs and put them one at a time in my CD-ROM.

The first one he put happenned to be XXr and I recognized very quickly no mistake.
The other two was not so obvious so I asked him to changed twice to make sure. But after 2nd change I was able to tell which is which with no mistake.

So I guessed not only that they were different. but even the exact version of XX, which was playing while recorded.
:) :) :)
And this all is with WMP and cheap laptop soundcard. hahaha

I am scared... :)

Andrey

Well, at least I want to think this over.  I don't know what it takes to find out what's happening ... could need a lot of :party:
:yes:

Now, if you could tell us what to do during ripping ... jiiihaaaaaaa


I think you should be ... yes.

..................

Ok, I allowed myself not to press "Post" immediately, and this is what I come up with :

As we know by know, the "Controlling section" of the player influences the SQ of Engine#3 (largely), the latter being a separate program, trying its best to produce good sound;
What happened in the upcoming 0.9s-0 (that presenting a completely wild difference with previous versions), is that I set down to eliminate the influence of the controlling section. Now, whether that worked out for better or for worse is up to you out there actually, but fact is : all sounds completely different now (The end of XXHighEnd ? (http://www.phasure.com/index.php?topic=266.0)).

What it comes down to, is that a 100% separate process (the controlling section) is influencing ... well, say jitter (actually I don't know, because what happens is really out of my control). Jitter or not, it influences sound (hugely) ... which is what I proved with 0.9s-0.

If it influences Engine#3, why would it not influence something else. Btw, forget about the PSU, because there's no logic in that (not to me).

Of course this is only half of the explanation, because the other half is about how to get this to the pits on the CDR. But apparantly this just happens anyway ...

It might be interesting to bit-compare the various burned versions. I don't know how yet, but it just might.
If you don't know what to do with them, you can PM them to me (shorter tracks).

It is the most interesting anyway ...

Btw, not to be too much confusing or vague :

Note that this Controlling Section is what you actually use for Engine#1/#2 (XP), and that then it includes the producing of the sound.
Not important for the matter by itself, but just for better understanding / thinking.

I am not sure I understood about controlling section.
Are you saying that in the new version the influence on CDRs as I hear it might be gone?

I am using XP and all my observations and tests were on XP.
I just ripped couple of tracks (beginning and middle of CDR) from 2 CDRs with XX and no XX and the files are identical. Actually this was no question to me? :)

ripping and comparing was done in EAC

Once you listen (play during burning) to Vista/Engine#3 ... yes.
No practice for you, but still ...


When things are really about jitter, of course.
But now you proved that the jitter on the burned CDR really would be normal jitter. For now this is beyond my comprehension.
So now  :party: :party: :party:
 :)

Edward ...

Looking at my previous post too, would you care to explain *your* explanation of time jitter (I know, I named it like that) as how it would be on the burned CDR ? Apparantly I miss something.

:scratching:

Fot arguments sake, let's assume that Andrey's observations are correct ...

Now I think of it ... EAC would read back too well ...
So any induced jitter from "a not so good" burned CDR wouldn't come forward by means of (EAC) ripping.

Hi Peter,

I would advise to reread the link I provided, May be new details will come forward.

In order to cause reading ripping errors from CDRs the [edit]distance[/edit] jitter of pits and lands should very very high.
So no matter how good or bad EAC does its job ripping. It would read the CDR all the same unless it is scratched too much.

I remeber ripping two CDs one was Original and other a licensed, the latter being very jittery. even my friends were able to hear it.
Guess what. they contained the same data, after ripping.

I even revived one CD for a friend. He complained that it sounded bad for him. I made a CDR copy, And he agreed that the sound did improve.
He is very suspisios about my theories however.

So the jitter in distance between pits and lands, causes laser, motor or whatever act with irregualarites. which result [edit](through PSU)[/edit] in time jitter of the 0 and 1 appearing on the circuit.

but spectrum of the distance jitter of pits and lands may not coinside with spectrum of time jitter of 1 and 0 (or the samples), but they certainly related: one is a function of another.

Andrey

About the PSU phenomenon.

It's all about the threshold crossing in the right moment of time.
So to generate 1 an 0 by crossing some threshold without timing errors (jitter)we need a perfectly clean power.
But if there is some irregularities in power consumption by say CD reading circuit in case of jittery CDR, these irregularities affect the power fed to other circuits too.

I hope I didn't stray too far in a fantasy with the above.

OK . . . if we look at a CD from the side (like a cross section) you would see the grooves (which might remind you of vinyl) which are the pits and lands and the shape would be raised rectangles. When a CD is read, it's not as simple as a pit=1 and land=0. In actuality it is all about the transitions. So a transition from land-to-pit or pit-to-land represents a binary "1" and all other surfaces (land or pit bottom) represent binary "0". If you read the CD as data (or rip a music CD) all that matters is that you can read the transitions. You may have a very poorly formed pit, but as long as the laser can tell it is a pit, then it is captured bit-perfect. If it can't tell if it is a pit or land then the CIRC error correction is engaged and if it doesn't work, then that is when you will get wrong data (a "0" instead of a "1"). Now, when a CD is streamed as music (as in a conventional CD player) then not only does it have to capture the 1s and 0s, it also has to apply a clock to it. And this all happens in real time. It's First In First Out and the speed of the spinning CD and the laser capturing the bits have to be precise. The speed (or clock) is fixed and based on the specification of exactly how long pits and lands are supposed to be. So let's use the example of the poorly formed pit that looks more like a triangle than a rectangle. The laser will recognize it as a pit, so there won't be any error correction needed, but the transition between that pit and the next land will occur at the wrong time (because the pit is the wrong length), thus creating jitter. Peter, you were correct in saying "Indeed, culprits in there only unveil at playback..."

So this is why many generations of burns/rips will continue to be bit-perfect identical to the original. There is no clock applied when ripping and it doesn't care how long the pits and lands are. So "jitter" does not exist in the music (or WAV files) itself, per se.

I think I did not make clear enough what my "problem" is ...

Disclaimer : all is my very own interpratation of things, based on experience and knowledge where possible.
What mr. Katz says I all agee with, BUT, what he leaves out (explicitly or implicitly) is just what it is about here.

In fact it's IMHO the same with you (Andrey and Edward) above, and it makes explanations (if any) too simple, or fail;
In my earlier long post, I tried to explain the difference between errorneous reading, and normal time jitter. You don't go into that (oh, not that you really should have, but it is important for what is happening IMO).

I say : at the DAC level samples are missed out completely. Look at the picture below; from left to right is the time domain, and the height represents the voltage level (= volume). Now, one sideways step as you can recognize in the picture, represent one sample. Mind you, this comprises of two bytes per channel (for 16 bit audio).
One sample (just made up) for two respective channels may look like :
00010101 11001000  (left)
00100011 01011100  (right)
(big endian notation, which is not even true, but never mind)

Look at the picture again. The topmost part (left channel) presents a value-change at 36.4 (never mind the meaning of that number) and a next step presents 37.6.
Now, time jitter in the DAC might just point at the 37.6 sample, while actually 36.4 should be pointed at. See this as an arrow poining from above donwards pointing at the samples, the time running by at crazy speed, and the pointer should just stop once per 0.00002 seconds (44K1 sample rate) and pick the sample, while the pointer pointing is directed by a clock (in the DAC), and the samples running by is directed by another clock (!) (in the PC).

Sidenote : the thing about the clocks is a tad more complex, because in either case it would be the DAC impeeding for the samples arriving (and the PC just causing the samples to be ready in a buffer, this already working differently for SPDIF and USB).


This explanation of time jitter as how I (!) see it, as happening in the DAC, is different from errorneous reading :

Below is the sample of the left channel again, but now underneath is what was read (at either place where reading can go wrong) :

00010101 11001000  (left original)
01010101 11001000  (left read)

The above is what everybody is talking about (you both, mr. Katz), and (big endian read and unacording plus or minus voltage) this an error of 32768 upon the original data in the 8192 range. Note that this implies a voltage spike of 4 times (12 dB) the original level, and which happens at one sample.
Do note : this is perceived as inaudible (because it lasts too short), but is dead wrong anyway.

In the DAC, these kind of errors can happen only because of a poor TTL levels (TTL : the standard voltage for 0 and 1). Thus, when a rised voltage is below the offical minimum level, the 1 can be read as 0.
Poor TTL levels can be caused by cabling and many more things (PSU, etc.).

Again different would be "time jitter" in reading out a (double) byte;
Note that it is this what you talk about with the CDR as point of view, but of which I personally do not believe it will happen in other hardware.
Thus, think of the time-pointer again as explained above, and now you imply that the individual bits are read wrongly.
NOTE : with the poor TTL levels it still can, but that aside ... no. BUT ... on the other hand, it would still be subjective to time jitter, because TTL voltage ups and lows have a rise and fall time, and it would still depend on where the "pointer" drops in (looks).

To put the above in another perspective, also look at this :
No matter what I do to influence the DAC (because that's what XX does in each of their sound engines), when the data is read back from the digital out of the soundcard (or even DAC when possible), it would read back the original data. Do note that at least *I* test this with real reading back, and not with stupid tests like DTS signals at te receiver (which would not even prove anything in Vista (!)) or do or not being able to influence digital volume level.
What does this tell ?
It tells that everything up to the input of the DAC was ok for TTL levels, so *IF* the DAC would read errorneously, then suddenly there all wouldn't cope ??
No ... (of course it could, but I just don't believe that).
Also note that if TTL levels (or better, the resulting voltage ups and lows) were not okay, there would be no way of error checking that (I think). And if it were, the DAC could cope with it just the same ... (per implementation).


As a sidestep, we now go to the CD(R);
Your (and everybody's) story about the pits and lands and the *there* impeeded time jitter ... true IMO. But mind you, this is at the bit level ! (compareable to the TTL level thing from above). So, when jitter is induced from reading the CD, we'd get

00010101 11001000  (left original)
01010101 11001000  (left read)

this again. And this would just be truely happening.
Now remember, when I state (haha) that it is not this what is happening inside the DAC, and instead there complete samples are missed (and repeated), this has a very different outcome soundwise. The errors would be outrageously more less.
Look at the picture again; When the pointer would read the 36.4 again instead of the 37.6, this is an actual difference (error) of decimal 1.2, which is quite different from 32768 ...
Note that it is nature which causes the difference to be so small, because nature dynamics can't be that large.


It is not for nothing that I always express "a zillion things are wrong at audio playback", because to me it is obvious that the misread of 32768 is just happening in a normal CDP. The better the box the less it will be, but still.
Also, I know how sound is perceived to stay the same, when I inject wrong samples on purpose. You just won't hear it. Or ...
... In the end, obviously yes, and it is this what it all is about.
If you hear the upcoming 0.9s-0 you might wonder : were 80% of before samples read wrongly, or is it now for 80% wrong ? So huge is the difference ...
Never mind bits (!) are read wrong from the CD all over the place. At the other end things are 10 times worse ... (mind you, that's my perception, and by each improvement of XX this is just proved true).


So where do we stand according to the subject of mapping the jitter (?) as produced by XXHighEnd onto a burned CDR ?
I don't know. :)

The most logical base for it to happen must be the PSU indeed. But, if that were true, there's so much more to make consistent;
When XX asks PSU power via the processor asking for it, and that tiny levels would influence the laser capacity ... beyond my comprehension.
When XX asks PSU power via the processor asking for it, and that influencing rise and fall times of TTL levels ... yes. The smallest difference would be enough to make a difference. How this is consistent with reading back the data bit perfectly ... probably my error in thinking that this proves something.

How a 1:1 map can emerge from supposedly jitter signatures, XX playing at 100% speed, the burning process burning at, say, 1200 % speed ... could be, but then by "resonance" only.

The only real explanation might be that so many things are going wrong, that the going wrong at XX playback is so persistant, that it infuences all. But mind you, this then must be about something we don't know yet (by far).
I'd like to think in the area of of synchroneous processes which are time constraint at the same time, thus leaving things out. This can't be it, because then the data on the various burned versions should be different.

This is crazy ...

Btw, before someone else comes up with it :

IIRC, on a (red book) CD the bits are not organized in a normal fashion, but merely like this :

00010101 11001000 (original data)
00000011 11100010 (as on the CD)

and the (smart) organization is such that as few as possible transients from 0 to 1 and back have to be met.
I recall that it even might be so that towards the most significant bits this is stronger, so if errors are read, they are read in the, say, 64 area (instead of the 32768 area from the earlier example).

All is fed by large tables (by convention) as how which original value should be transferred to the value for the CD (and back).

Edit : I think it was this one : http://www.physics.udel.edu/~watson/scen103/efm.html
... but maybe this is an idea only (I don't feel like working this out right now).

Hi, I am Carlos Rodríguez, this is my first post on this forum (sorry for my bad english).

I believe what Andrey says and agree as well with Edward as the theory always differs from practice.

I have been burning a CD without and with Foobar + modified ASIO playing (what XX vesion do you recommend me to do the test? with WAV or FLAC?) and I´d say that even this burning process influences the sound as well... as Peter said, interactions. It makes sound a bit more balanced though (I think more in the begining of the burning) with more of that "microdistortion", but burning a CD every time I want to listen more balanced music is not a solution.

I used for the test PlexTools cause it is wider and far more transparent than Nero 6.6 in my old Plextor 1x burner and in my recent Plextor 4x burner (the one I use now, I prefer 1x but the new burner has less distortion). Though I have not tried Roxio, any recommended version Andrey?

After listening 2 tracks on both CDs, it seems the one with Foobar is more detailed, wider, less plastic and have more soundstage. But it is only a first listening. I will play the full CDs to get more perspective. For sure the begining of the CD has always longer-length jitter than the end, so I will have that into account (I guess we all can notice the difference in jitter between the begining and the end of the CD).

I always get surprised. Recently I upgraded emule (which runs in the background "almost" always) and noticed an improvement in distortion and bandwidth (on the interface as well!, I mean smoother mouse movements and clicks). Jitter is amazing, but well, I dream listening music without audible jitter some day...

PS: I never compared two different pressed CDs, but it would be a beautiful test.

Hi Carlos ! very nice to see you here !!


Hahahaha, not me. Uhhm ... so far.
And I just thought I got rid of such beginning vs. end distortions since I stopped with vinyl ...  :)
Oh my ...

Hi Peter, very nice project.

Well I think begining vs. end differences are far more subtle than the typical jitter, and IIRC I noticed it for the first time this year.

Ahh, I´m stupid... forget the FLAC/WAV question.

I will do the test with XX 0.9r.

Hi Carlos,

It is nice to hear from you.

I used Roxio just because it was the only program I had on the PC at that time. :)
I wanted to show that this effect we are talking about here doesn't depend on the software or CD writer we use too much.
And I agree that any background activity influences the SQ of the CDR being recorded.
Also I said in the first post, that you can take your favorite version of XX and play it while burning CDR, and you will have CDR with the SQ signature of your XX version.

IMHO XX r I like best for now (in XP) and it is the most easily to tell it on the CDR.
And I could tell XXpd version from no XX running, though it was not so obvious for me.

Please note that all tests I did on XP. could not find how to burn CDRs on Vista (was too lazy to google :))

Hi Peter,

Sorry I always have trouble reading your posts. they always confuse me. My bad English probably. :(

So you saying that we get the wrong samples because time jitter is so big that it even points to the wrong sample.
No I don't think so.
And the bit stream is not changed and arrives at DAC the same from CDR.

The samples are points interpolating the analog wave. In theory these points should be at exactly the same distance fro each other to reproduce the right wave. If the distance has jitter, points moved a tiny bit to the side, we will get slightly different wave, but enough to be audible.

All those errors with missing samples are very very seldom, the data are the same and not corrupted. it all about when the samples appear on the time line. And this time jitter cannot lead to reading the next sample instead of current. Jitter is to small for this.

0.00002 seconds does not compare to the jitter values.

the jitter is in 10 to 500 picoseconds not milliseconds, refer to stereophile for measurments examples..

And also DAC clock is tied to the incoming form PC clock by means of PLL, in case of nos DAC.
And they cannot stray too far from each other by design. especially to read the next sample.

all the errorneaous reading as you say it and I understand it,
Is corrected by the means of the error correction mechanism in CDROM or in the SPDIF or USB interface.
Even if by wrong levels some of the 0 become 1s the algorithm has enough extra data to correct it. RedBook has two level of error correction.

inside the DAC this misinterpreatation is impossible. or again error corrected.
So the misinterpretations of 1 and 0 are not of the importance anymore. The data is not changed.

As I said before it is about samples apearing on the time line at a slightly different moment. Not enough to shift the sample to the next position a lot less than that, but enough to recreate (from interpolation) a slightly different waveform to be audible.

In the case of badly recorded CDR the data is still the same right?
But in this case the error correction processes come into play. Say they affect PSU power cleanness in away.

It will be my english Andrey, sorry !

I agree with all you say, and of course the jitter we measure at the DAC is too small to incur for the jitter I implied (and I think I put a "(?)" behind that somewhere). Also, there is more too it than an already too large post can describe, e.g. my presentation of a "computer clock" which in fact is totally unrelated (so that was for visualization). And btw, also note that somewhere else (at AA I think) I pointed out that the jitter we generally talk about is to be measured at the analogue side ... (just your story). :)

IMO it is too complex to just write ahead (and brainstorm), because remember the subject : XX playing and influencing the pits on the burned CD. So I am (or was) just trying to find reasons for that, which all didn't hold. Note that the normal jitter (occurring at the analogue side) could NO WAY influence your burning process, unless it's the soundwaves in air doing it. Hahahaha.

Maybe we should stick to that ... it can be tested easily (by guys like you).

Well, after being tested the 3 CDs I conclude:
- The CD recorded with XXHE playing sounded a bit emphazised in the mid-bass and mid-highs.
- The CD recorded with my Foobar running (consumes 20% CPU) sounded clearly different from the other two, a lot more transparent, but less balanced and with more "holes".

I prefer the CD recorded with no software playing in the background, it is cleaner and more balanced.

PlexTools reported that all the 3 CDs were recorded successfully. After the listening I ripped the 3 CDs to the harddisk again and WaveLab 4 reported that they were exactly equal.

It seems that something related to CPU time consumption has to do with how the CD is recorded. Being the differences so big when using the CPU at 20% I´d say that the key is the power quality to the burner, cause the burner buffer is too long to be influenced by the CPU quantum.

Important:
Some time ago I discovered that every windows CD player (old fashion Win95) sounded different as well. I used the SPDIF-out connector from the drive.

I believe that process is independent of the software used (the CD drive works even when you close the CD player software). So this leaves the power as the only connection between them.