[BigCabDaddy]

I inherited an older, probably cheap to start with, Celeron base PC. It does have a DVD player however. Does the PC used for ripping CDs make any difference?

 

[PleasantSounds]

If your concern is the quality of the ripped file then rest assured: the content should be identical to the latest state of the art machine, provided that the DVD player is still fully operational.
The only penalty you will pay is the time it takes to convert the ripped wav file to your target format.

 

[Slogra]

Audio difference: none
Speed difference: encoding can be a lot slower, depending on codec and encoder. Actual read speed wil depend mostly on the drive itself. Older drives are probably better/faster than new bluray drives!

I'd say drive quality is the most important aspect (edit: and the rip software and settings).

 

[Octagon]

Hi BigCabDaddy,

I did some research in diffent environments, if the main environment has been choosen carefully you should be able to have no difference.

You might find my experience in more detail helpful. Following resulst I published elsewhere earlier this year. I apologize for the pictures added as links only, did not manage to get them in this post, need to learn that for future

Ripping – Are There Any Differences Based On OS Environment
 
Some comments made me curious to check if there is a difference from a ripping processes in different environment. If so, the files would need to be different. Maybe not from the perspective of a binary difference, but from one in the frequency spectrum. As I was already looking for a methodology to understand the results of rewriting mechanism used in Bug Head Emperor (BHE) or MQn I took this thesis as an example to check my ideas. I would think that rewriting benefits from storage handling and electrically smoothed processes, not from changes in the files itself. But let’s take it step by step:
 
To start with the result: There is no difference in the files whether they are ripped on different OS, OS environment or different hardware as long as the whole process has a secure setup. You will find differences in the offset, the beginning of the data stored as well as in the speed of the ripping process. Needless to say, that all remarks are based on my system and the following test environment. Let’s dive into more details:
 
OS:            W7; R2 GUI, R2 Minimal Server, R2 Core Mode each booted normally and as RAMOS; all R2 fully optimized with AO1.41
Drives:      Plextor PX880SA via SATA fix within W7 PC; Samsung BD SE-506 USB2.0 via USB3.0
Software:  EAC 1.1, highest quality setup, offset set per drive (both +6), save mode, audiobuffer of Samsung drive off, wav 44,1kHz 16bit; NWDiff 1.0 for
                  checking binary data; Adobe Audition 3.0 for checking of frequency spectrum
Test data:  3 audiofiles und 1 minute logsweep build with Acourate, everything 44,1kHz 16bit wav burned Audio CD with Imgburn 2.5.8.0
 
Ripped files have always different starting points due to the different start up of the CD drive and the ripping itself. To avoid differences I build a biunique starting sequence in Audition with 3 times a 1 second(sec) MFV tone A and 1 sec break in between resulting in a 6 sec starting sequence. In addition I changed a single sample 5 sec after the begin and 5 sec before the end of each test file to -10db. Every one of the four test files has been prepared like this before burned as a single AudioCD.
 
The resulting AudiCD has been ripped by EAC in different combinations:
* W7, Plextor // W7 Samsung
* R2 GUI, Samsung // R2 Minimal Server, Samsung // R2 Core, Samsung
* R2 GUI RAMOS Samsung // R2 Minimal Server RAMOS, Samsung // R2 Core RAMOS, Samsung
 
There was a recognizable time difference in ripping between the different scenarios. R2 has mainly been slower, but that might be due to the Samsung BlueRay drive. The first bits of the ripping files are different, as expected, sometimes the end of the files as well. In the next step I cut the parts outside my sample marks and stored the files for comparison.
 
The binary check with NWDIFF resulted in prove that the files are bit identical, you can see that in the graphical part of the interface very nicely: Both upper windows show the same sequence of each file, down left would show differences as coloured – black means identical; down to the right shows yellow all identical bits, differences would be shown in green for file 1 and red for file 2. In this example I show you Tin Pan Alley from W7 Plextor vs R2 Core RAMOS with Samsung:
 
[img=http://abload.de/img/01nwdifftinpanw7vsr2c22sy4.jpg]
 
Recognizing no differences does not have too much meaning for our topic. For better understanding, please take a look at the following picture. It shows the same files without the corrections using the sample marks. You can see clear differences, one could even say not so much compliance but you will not hear these differences:

 [img=http://abload.de/img/02nwdifftinpanw7vsr2cv8sbf.jpg]
 
So let’s take a look with Audition on these files. If the content is identical we will be able to prove that on this level as well. I inverted the file which resulted from ripping and cutting within the sample marks. With Audition I summed(mixed) the inverted file with the original file. If identical the result must be 0.
 
Following the original file and the inverted ripped file of Tin Pan Alley:
 
[img=http://abload.de/img/01auditiontinpanw7vsrwojn1.jpg]
 
Next the addition/mix of both files:
 
[img=http://abload.de/img/02auditiontinpanw7vsrurb5i.jpg]
 
And finally all of the free together, the third one showing the result of  the mix=0
 
[img=http://abload.de/img/03auditiontinpanw7vsr95z4u.jpg]
 
I could verify this result for each of the mentioned combinations. But measurement is not everything, how does it sound: I was not able to find any difference between the different ripps. Good news, we don’t have the need to start ripping our thousands of CD’s again as long as we have taken a serious quality based approach to ripping from the beginning. And we will always be able to verify this quality.
 
 So, why did some of us recognize differences? One reason maybe, that ripping with dbPoweramp might include upsampling by some users. Upsampling is a totally different beast and might explain recognizing benefits from a perfectly smoothed system like R2 with AO. Another reason might be that there is electrical noise left in the files which we can't measure this way. Anyway, that is why I trust my ears at the end of the day which support my measured results.
 
Enjoy the music
Thomas

 

[serman005]

That is a fascinating explanation--thank you for laying that out for us.