Burning audio CD while XX playing

[andy74]

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

[PeterSt]

Thanks for the information about 100% bit perfect CDR copy . I have a knowledge.

I'm sorry Andrey, your theory and explanations lost me. I thought I was just helping by adding clarification to the "burning" process.

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

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 .

[edward]

Please don't get annoyed about eachother's means of expressing of what we're all after ... exploring the mysteries of audio.

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

[Chris V]

 Time for a group hug 

[andy74]

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

[andy74]

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

[PeterSt]

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


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

I am scared...

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

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

[PeterSt]

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.

[andy74]

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

[PeterSt]

Are you saying that in the new version the influence on CDRs as I hear it might be gone?

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

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?

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 
 

[PeterSt]

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

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.



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

[PeterSt]

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?

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.

[andy74]

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

[andy74]

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.

[edward]

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.



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

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.