What does jitter sound like?
Sep 15, 2006 at 6:15 PM Post #16 of 39
Quote:

Originally Posted by audioengr
I dont agree. The anecdotal evidence shows the opposite. I performed a jitter demo at CES in January using a track from the CD Nora Jones Come Away with Me - trk 10 "Painters Song". This song has a lot of jitter in the pits on the commercial disk.

First I rewrote the disk using my battery powered disk rewriting system - 100% of listeners could hear the improvement over the commercial disk

Second, I used a modded Transport - 100% of listeners could hear the incremental improvement from (1)

Third, I used a modded DAC - 100% could hear the incremental improvement from (2)

Forth, I played the same track from the computer through an Off-Ramp Turbo - 100% could hear the incremental improvement from (3)

Fifth, I played the same track from the computer through an Off-Ramp I2S - again 100% could hear the incremental improvement from (4)

About 25 different people participated in this demo over three days. This convinces me that the average listener can hear even small differences in jitter. The system must be up to it however.

Steve N.



Did you tell them that the improved component will be put into play, or was it blind?
 
Sep 15, 2006 at 6:19 PM Post #17 of 39
Quote:

Originally Posted by akwok
Did you tell them that the improved component will be put into play, or was it blind?


I told them what I was doing, but not that it would be better or worse.

I know what you are getting at, but theres no way I can fool 10-15 people at a time, and some of these reviewers etc....

STeve N.
 
Sep 15, 2006 at 8:02 PM Post #18 of 39
Quote:

Originally Posted by audioengr
I dont agree. The anecdotal evidence shows the opposite. I performed a jitter demo at CES in January using a track from the CD Nora Jones Come Away with Me - trk 10 "Painters Song". This song has a lot of jitter in the pits on the commercial disk.


Now, not to be a spoil-sport but what exactly is "jitter in the pits"?

A CD is a digital media and each pit is either on or off it can't be somewhat off or somewhat on, each sample consists of 16 pits and there are exactly 44100 of these samples for every second of audio per channel.

There is no information kept in the distances, depths or any other such vague element.

These bits are read of the CD and then sent from the transport to either an internal or external DAC unit clocked by a crystal or similar, just like it would be if you played it off of a harddrive on your computer.

It is true that people have reported hearing differences between original CDs and burned CDs - and the best suggestion as to a cause I have heard (in a thread somewhere on head-fi) was that it was caused by different power loads on the laser causing different effects on the remaning circutry in the CD player.
 
Sep 15, 2006 at 9:02 PM Post #19 of 39
Quote:

Originally Posted by Regus
Now, not to be a spoil-sport but what exactly is "jitter in the pits"?

A CD is a digital media and each pit is either on or off it can't be somewhat off or somewhat on, each sample consists of 16 pits and there are exactly 44100 of these samples for every second of audio per channel.

There is no information kept in the distances, depths or any other such vague element.

These bits are read of the CD and then sent from the transport to either an internal or external DAC unit clocked by a crystal or similar, just like it would be if you played it off of a harddrive on your computer.

It is true that people have reported hearing differences between original CDs and burned CDs - and the best suggestion as to a cause I have heard (in a thread somewhere on head-fi) was that it was caused by different power loads on the laser causing different effects on the remaning circutry in the CD player.



The pits in the CD are spacially located. This is what creates the timing when the disk is spinning. It is NOT like when a hard disk is reading data. This is real-time and the player locks to the bits as they come off the spinning disk. If the spacing between the pits is not very precise or the pits are not precisely defined, then jitter is what results. The CD-R writers that use Superclocks etc.. and special algorithms for writing more precisely defined pits make the resulting CD-R have reduced jitter over the original commercial CD.

Trust me, it is the pit quality and their locations that makes the audible improvement when you write a CD-R copy.

and BTW, when you play "off the hard drive" of your computer, you are actually playing from memory, not the hard drive. Blocks of data are moved from the HD to memory and then spooled from memory to the USB device.

Steve N.
 
Sep 15, 2006 at 9:47 PM Post #20 of 39
Quote:

Originally Posted by audioengr
The pits in the CD are spacially located. This is what creates the timing when the disk is spinning. It is NOT like when a hard disk is reading data. This is real-time and the player locks to the bits as they come off the spinning disk. If the spacing between the pits is not very precise or the pits are not precisely defined, then jitter is what results. The CD-R writers that use Superclocks etc.. and special algorithms for writing more precisely defined pits have reduced jitter over the original commercial CD.

Trust me, it is the pit quality and their locations that makes the audible improvement when you write a CD-R copy.



Answer med this:
Why would anyone build a CD player that used the spinning speed of the CD as a clock?

It would be far more expensive and far less accurate than bying a cheap quartz crystal and clocking the data signal with it.

Using the mechanical properties of CD or the reading mechanism as a basis for the audio signal is ludicrous at best:

We are talking digital audio here not some pseudo analogue vinyl look alike - the data on the CD is identical to the data in a normal 16bit 44.1kHz wav file, and every sample represents the voltage level recorded during that 23 us (micro seconds) period - not some times 27 and other times 18 but 23 us for every sample.

Typically one uses a 11.2896 MHz oscillator for CD audio - that is one oscilation for every 89 ns - jitter is when this clock is not accurate, not accurate doesn't mean 10 ms it may mean 91ns or 87ns between some oscillations. The idea that one would be able to even remotely aproach this kind of accuracy using a spinning piece of plastic is quite frankly silly.

Put in other words if the disc were actually being used as a clock you wouldn't be hearing jitter you would be hearing mad LSD trip or just noise whichever CD you put in the player.

Pit quality however might cause errorneous reads or re-reads both of which may affect audio quality the former for obvious reasons the second because it could cause power fluctuations in the circutry - neither has anyhting to do with the phenomenon known as jitter, although the latter may result in jitter through adversly affecting the clock circut causing the inaccuracies but that is speculative.

I'm not trying to rain on your parrade but this notion that the distances, depths or other similar elements constitutes built-in jitter is a myth - I have even seen an article refered to in these forums that claims the sample value is stored in the depth of the pit - all of it is nonsense, a CD may or may not contain errors, it may or may not be easy to read but it does not contain any data beyond what is popularly refered to as 1s and 0s - there is no magic data - jitter or otherwise - included on a CD.

This is not saying that print quality of the CD cannot adversly affect the sound quality through secondary effects (such as power fluctuations) - so you may very well be hearing a difference between the original and your burned copy, but it is not built-in jitter.
 
Sep 16, 2006 at 5:26 AM Post #21 of 39
Quote:

Answer me this:
Why would anyone build a CD player that used the spinning speed of the CD as a clock?


Because that's the way it is done on most players. The crystal is used for servo-control of the drive, but the spin speed (a function of the quartz crystal oscillator and the track being read), creates the bit clock. If the bit clock was not exactly the bit-rate coming off the read-head, at least averaged over very short periods of time, then you would need a very large FIFO or you would have overruns or underruns. Many transports have PLL's that further lock to the bit stream to help smooth out the speed variations, but the jitter on the disk affects these also. The PLL's still jitter when the bitstream jitters.

Steve N.
 
Sep 16, 2006 at 9:51 AM Post #22 of 39
Quote:

Originally Posted by akwok
Am I the only one who can't hear the purported changes in jitter between different computer transports? It all sounds the same to me.

It's also funny to see how according to different people, lower jitter changes different aspects of the sound, not one specific element.



Don't worry, you're not alone. I'm pretty sure the people who actually recorded the music you listen to cared less about "jitter." I figure the music I listen to uses instruments that run through overdrive pedals, tube amps, a board mixer, a few different cards in a Pro Tools system, and a few dozen feet of various wires, passing through who knows how many different circuit boards with who knows how many things inducing "jitter," to a headphone or speaker with a far from flat frequency response. Whatever extra "jitter" I introduce seems negligible.
 
Sep 16, 2006 at 9:57 AM Post #23 of 39
I used to have a friend that swore that when he cleaned his PSX version of Final Fantasy VII, the characters looked less blocky because the "bumps" were clearer or something along those lines. Maybe I should bring him to this forum. He'd fit in perfectly.
 
Sep 16, 2006 at 10:17 AM Post #24 of 39
Quote:

Originally Posted by audioengr
Because that's the way it is done on most players. The crystal is used for servo-control of the drive, but the spin speed (a function of the quartz crystal oscillator and the track being read), creates the bit clock. If the bit clock was not exactly the bit-rate coming off the read-head, at least averaged over very short periods of time, then you would need a very large FIFO or you would have overruns or underruns. Many transports have PLL's that further lock to the bit stream to help smooth out the speed variations, but the jitter on the disk affects these also. The PLL's still jitter when the bitstream jitters.


Well lets see the FIFO buffer would need to last for at least one rotation of the CD in order for you to be able to turn off the reading while the buffer empties out and be back in place before you have an underrun

lets say the CD rotates at 1000 rpm equal to 0.06s per rotation meaning 32 * 44100 * 60 / 0.06 = 10584 bytes - lets say we need twice that to be sure, then we reach 21168 bytes or a little less than 21kB, not really an eartshaking size for a FIFO buffer, even ten times that wouldn't cost any noticable amount of money - my first portable CD player had a full 10s antishock buffer in it and it wasn't particularly expensive, so i can't really see the problem with simply buffering and clocking which would obviously be a far superior design.
 
Sep 16, 2006 at 10:26 AM Post #25 of 39
Hey Regus,
I don't know how CD players are really done, but that approach is what I'd do if I was to design one.. Using a buffer to remove jitter.

Similarly if I was to build a DAC, I would also use a buffer to remove the jitter from the source/cable etc... However I suggested that on another thread and ppl thought my idea was crap/ridiculous. Jitter/jitter reduction doesn't seem like a big problem to me at all.
 
Sep 16, 2006 at 11:33 AM Post #26 of 39
Quote:

Originally Posted by theexec
Similarly if I was to build a DAC, I would also use a buffer to remove the jitter from the source/cable etc... However I suggested that on another thread and ppl thought my idea was crap/ridiculous. Jitter/jitter reduction doesn't seem like a big problem to me at all.


I can see some problems with designing a DAC that way:
If your clock is even marginally slower that the clock in the device sending you the data you will have a buffer overflow sooner or later, meaning your buffer will need to be rather large for this not to become a seriously anoying issue - without doing the math i would guess well into the MB range. Conversely if your clock is faster you will have nothing but underrun.
And whatever you do you will need a clock that is slower than the input in order to ever fill up your buffer, or you will have a significant delay from you start sending data to the DAC before you hear any sound.

The problem is significantly different in CD player where you can control your input media (The reading of the CD) - if you make a design that is slightly faster than 1x and allows for pausing you will have an easy time keeping a reasonably sized buffer full at all times.
 
Sep 16, 2006 at 3:43 PM Post #27 of 39
Quote:

Because that's the way it is done on most players. The crystal is used for servo-control of the drive, but the spin speed (a function of the quartz crystal oscillator and the track being read), creates the bit clock. If the bit clock was not exactly the bit-rate coming off the read-head, at least averaged over very short periods of time, then you would need a very large FIFO or you would have overruns or underruns. Many transports have PLL's that further lock to the bit stream to help smooth out the speed variations, but the jitter on the disk affects these also. The PLL's still jitter when the bitstream jitters.


Are you sure that this is still true. I agree this used to be method how players were build 15-20 years ago but after the integrated chipsets for car players came along this was no longer true.

For contemporary players that are not following some ill conceived ideas of a turntable the clock comes from a crystal and the speed of the disc is regulated by the chipset to get enough data off the disc. These chips even support re-reads in case you drive over a bump or race around a corner.

This is one of the advantages of the conversion stage in a player. They don't need to recover or follow any clock but can drive their conversion directly from fixed frequency crystal.

Cheers

Thomas
 
Sep 16, 2006 at 4:14 PM Post #28 of 39
Quote:

Originally Posted by akwok
Am I the only one who can't hear the purported changes in jitter between different computer transports? It all sounds the same to me.

It's also funny to see how according to different people, lower jitter changes different aspects of the sound, not one specific element.



I'm in your camp. I've never heard jitter.

I have absolute pitch and very good ears, but I don't fool myself into thinking I can hear things that I really can't. Jitter is certainly real, given that it can be objectively measured using instruments, but the fact that something can be measured doesn't necessarily mean it will have any kind of audible impact. Just because can measure a noise at 100,000Hz, doesn't mean I'm going to hear it, in fact I have no chance of hearing that.

That all being said, I've never sat down and objectively compared "regular" jitter prone equipment to jitter free I2S or synched clock equipment; maybe if I actually sat down and did a direct comparison I would notice. However, I have listened to "low jitter" sources, and I don't notice anything that sticks out as "ah, that's what I was missing".

I've heard some people describe jitter as somethin you only notice once it's removed, not when it's present. I think that the fact that no one has a concrete description for what jitter actually sounds like is enough to bring its audible legitimacy into question.
 
Sep 17, 2006 at 3:47 PM Post #29 of 39
Quote:

Originally Posted by LeChuck
I think that the fact that no one has a concrete description for what jitter actually sounds like is enough to bring its audible legitimacy into question.



Well said.


Regards,

L.
 
Sep 17, 2006 at 3:54 PM Post #30 of 39
From the prespective of another uninformed data point, me.

What I have read about this subject suggests that jitter relates to the overall FM distortion level. The higher the jitter the higher the distortion in the output. Distortion varies over the frequency and jitter itself is very frequency dependent.
 

Users who are viewing this thread

Back
Top