Where (as opposed to "how") to rip - does it matter?

My digital strategy has had me not power on my cd player for well over 2 years.  It seems to be working

At the fringes of my memory and knowledge . . . some rippers check for certain parameters of the cd drive being used ("offset??")....does this imply that they factor in something about the drive iteself when they rip? Reading the dbPoweramp pages probably would answer this for me!

Playback quality might potentially be degraded by electrical and mechanical noise from a CD mechanism, what with all those motors, servos, bearings and speed changes. This was put to me at the launch of the HDX as a possible advantage to ripping accurately just the once and subsequently playing back by streaming. The proof of the pudding turned out to be in the listening, although it took me a year after getting the HDX to finally let my CDX2 go. 

This is the only valid (for the individual) way of answering such a question. Try it and go by what your ears tell you. If others disagree with you that's fine. They don't listen with your ears. For my own subjective part, I have used a variety of computers and two iterations of HDX to rip accurately (or so I'm told) and I can not distinguish between them. Ditto streaming from NAS compared to HDX internal storage. Ditto type of HDD and NAS. But I do hear differences in Ethernet leads, digital interconnects and file formats. I prefer WAV. It don't matter if you do or don't. It's what works for you that counts. How can somebody else tell you what you are hearing? Or you them?

Hi DrPo, essentially if a CD-ROM is tracking correctly, the data recovered will be completely correct. If it's not it will trip the checksums on the CD-ROM data structure and the CD-ROM will try and re read the suspect data. 

Now what can happen is the offset settings are not correctly set for a ripper and a particular CD-ROM drive. This can result with the first few millisecond or even tenth of a second at the start of a track not being ripped. ITunes used to suffer with this on Windows machines.. Not sure if they have now resolved this.

Several years ago on this forum when the ripper wars raged, a few of us ripped and compared WAV files from different rippers, and no differences what soever were detected (apart from the iTunes offset issue described above). I am sure these posts can still be searched.

Simon

Thanks all for the good points raised; I am going to spend some effort on this issue as I would indeed like to formulate my own opinion, what I heard yesterday was for me (and to the chagrin of my friends) rather inconclusive and possibly biased (I want to hear no difference as I don't own a player and they do the opposite - being streaming skeptics).

@Harry, that could also be directly tested on an HDX with (a) a CD playback, (b) the WAV / FLAC of the same CD ripped by th HDX and (c) a rip of the same CD on a laptop/PC.

I did do some CD playback versus ripped on the HDX and found the HDX to be not as focuesd/detailed as the CDX2. So our CDX2 carried on with CD playback duty until we realised that nobody had used it for months. Rips always sounded better to us.  

Some drives also cache audio data. So tracking and offsets aside, this can be a problem. Software like EAC tests for this and also whether audio caching can be turned off.

Assuming you are getting the right checksums, then any two rips with the same checksum will be identical.

Simon's point is particular important. The offset of some drives appears to be documented for a particular batch which then changes. I have had problems with drives that, when tested had very different offsets from the one stored in the database.

As for drives, if you are planning on actual disc-based playback such as building a HTPC, Pioneer do some fantastic drives. But if the intent is for ripping, I would not spend the money unless my rips were constantly failing checksums and reporting errors. This was indeed a problem I had between two different LG drives where both were new and worked fine as a system drive but for ripping in secure mode, one consistently gave poor results.

Indeed Mr Zen, most ripping software will  let you undertake some calibration tests to determine the CD-ROM drive offsets.

i would recommend a quality drive for ripping however.. and if you google these can be found .. and it does tend to be laptop or attachable drives that can be the weak link.

the reason I say a good drive is preferable is that it will be better able to cope with off centre CDs and also extended length CDs which are outside the Redbook spec... the latter appears quite common now. A lesser quality drive might error on the last track of a long play CD, and be exacerbated if slightly off centre.

finally rips are one things.. But playing the rips out whether from USB stick to UPnP introduces many variables that in my experience do affect SQ or at sound character. 

Simon

Yes, I suppose it is the last statement above that worries me (namely rips being OK but other factors affecting SQ). 

DrPo posted:

Yes, I suppose it is the last statement above that worries me (namely rips being OK but other factors affecting SQ). 

The only way to make a fair comparison is by using the same playback chain - exactly the same playback chain just different files held on the same device.

In regard to rips being different, the accumulation of data from the interleaved frame checksums will tell you that.  If the accumulated checksum data are the same the chance of the music data being anything different is minuscule.

If you want to know how it works, that's given here
CD Reed-Solomon encoding

So errors of up to 1.84ms (3500 bits total) can be fully corrected in the CD drive itself.  Errors beyond this length cannot be handled internally and should be reported by the drive in 'C2' error structures (but not all drives do this) for the application software to handle.  Only if C2 errors occur should there be any difference in the data extracted from the CD by whatever drive, and hence only then should there be any difference in the rips of the CD.  Other than this, the data in the rips should be identical and they should sound identical.

thanks Huge, my driver (an external SAMSUNG one) supports C2 and the setting is activated in dBpoweramp. Thanks for the link i will have a look!

Hi DrPo,

Just one point; the C2 Error structure isn't directly used to fix errors, but it does give a more precise location for them so that DBPoweramp only has to re-read the critical areas rather than a whole bunch of sectors.  This means that it's possible to set DBPoweramp to do a larger number of recovery passes at different speeds and hence increase the likely hood of it getting closer to the true data.

Thanks Huge, understood.

DrPo posted:

My question is: is there any consensus as to whether the CD drive from which a dBpowermap accurate rip is made makes a differnce in the sound? In theory there shouldn't, especially if the rip is accurate, but is there a chance that the quality / suspension of the drive itself or some noise induced by the cables might degrade the rip quality? I cannot think how but then why would a rip sound flat versus the same CD on the same machine?

At the end of the day, if you are using AccurateRip you are comparing your rip to multiple other rips.  If the same information is got off the CD, then it doesn't matter (to your computer) how it got there.  There is no (known) method for a computer to store any noise created by different CD drives in ripping a CD; there is no (known) method for a computer to know if the rip was done at 1x or 32x speed.  With a CD, there IS a "perfect" rip; and if your drive creates a perfect rip it is the same as every other perfect rip as far as the computer is concerned.  

In essence while there *may* be different levels of noise from different drives, different suspension of the drive, etc. there is no (known) method by which that noise can be stored, read back by the computer or transferred from one copy of a file to another.

This is a completely different issue than rip vs CD played direct as in one situation (when doing the rip) can be read multiple times to get an accurate read where as real time playback has to be read in ... well real time.  There is also the issue of different levels of jitter and other potential sources of interference in playing a CD vs playing a ripped file - playing a file is easy, but the complication comes from interfacing the computer to the rest of the HiFi.

Eloise

The other difference between streaming and playing a CD is there's no moving parts in a streamer and moving parts add noise and vibration, no matter how small that is, it's measurable and it's there.  There's also the power usage on the power supply to take into consideration.  This is far greater in a CD player than a streamer because, again, there are no moving parts to power in a streamer. Naim suggest in the streamer white paper that transcoding before entering the streamer may increase sound quality (and many people believe they hear this improvement) because the processor in the streamer will use less power meaning the power supply is working less and affecting sound quality less.

It follows that a CD player which is powering a rotating spindle, a tracking arm, error correction whatnots that this power usage is far greater than a streamer would use.  It's even far greater power usage than transcoding would take up.  Transcoding requires pretty miniscule effort for a CPU.

So all things being equal, same dac etc a streamer has these advantages.

Jota posted:

The other difference between streaming and playing a CD is there's no moving parts in a streamer and moving parts add noise and vibration, no matter how small that is, it's measurable and it's there.  There's also the power usage on the power supply to take into consideration.  This is far greater in a CD player than a streamer because, again, there are no moving parts to power in a streamer. Naim suggest in the streamer white paper that transcoding before entering the streamer may increase sound quality (and many people believe they hear this improvement) because the processor in the streamer will use less power meaning the power supply is working less and affecting sound quality less.

It follows that a CD player which is powering a rotating spindle, a tracking arm, error correction whatnots that this power usage is far greater than a streamer would use.  It's even far greater power usage than transcoding would take up.  Transcoding requires pretty miniscule effort for a CPU.

So all things being equal, same dac etc a streamer has these advantages.

On the other hand, a CD doesn't need so much computing power.

Power consumption:
My streamer:                     60VA
My CD player:                    25VA
My Computer CD Drive:  <11W DC

The moving parts / vibration argument is valid though!

But anyway this is thread is about the quality of the signal in a datafile ripped from a CD, played back at a later date via a streamer; so all these other factors in real-time CD replay are irrelevant, as they don't cause any variance in the resultant datafile produced by the ripping process.

Jota, Eloise,

I am fully with you in terms of "what is logical" and it was arguments such as these that led me to opt for a "streaming" rather than "CD" based digital source. It is precisely for this reason that finding a CD replay sounding superior to ripped playback on the same machine seems weird... i can think of only four possible explanations:

1. the rip i used was inaccurate
2. the rip was accurate but not all accurate rips are equal in SQ, the ripping medium playing a role (the topic of this thread)
3. all accurate rips are equal in SQ but ripping is inferior to CD replay (on the same equipment)
4. accurate rips are at least equal to CD in quality -all other components in the test being equal-, but we did not do double blind testing and the test is not trustworthy

Regarding those options:

[1] I will verify as the rip was from a brand new CD without any difficulty in reading and anyway I did a second secure rip which at some point I  will compare with the first one (the device is unfortunately not anymore available so as to compare playback of the two rips directly)

[2] is most likely ruled out as the consensus in this post is that for accurate and secure rips there is no room for SQ differences all other things being equal.

[3] seems illogical (transport mechanism noise, real time reading, all the good arguments made above by all of you)

[4] is the one i am inclined to find as the most logical explanation :-)

P.S. Huge just saw your post after compiling this...

Hi DrPo,

+1, totally agree!

Seems our posts crossed over twice, does that make it a double cross?  

Or "Double vision" ��