Full Version: Is it safe to use the CPU normally while ripping?
Or is it likely to "screw up" the work that EAC/LAME do? Can it cause errors in the ripping/encoding process?
If you rip in secure mode there should be no problems. If you rip in burst mode while there's a heavy system load, there may be some glitches.
edit: grammar
edit: grammar
QUOTE(rutra80 @ Feb 22 2006, 05:29 PM)
If you rip in secure mode there should be no problems. If you rip in burst mode while there's a heavy system load, they may be some glitches.
Any proof of this? What if one uses Test & Copy in Burst mode and gets matching CRC's while producing load, any concern with that? That's how i'm typically ripping.
Well, this should be easy to test. I'm going to try ripping in burst mode while defragging and playing World of Warcraft tomorrow (too late right now).
QUOTE(Daffy @ Feb 23 2006, 01:45 AM)
QUOTE(rutra80 @ Feb 22 2006, 05:29 PM)
If you rip in secure mode there should be no problems. If you rip in burst mode while there's a heavy system load, they may be some glitches.
Any proof of this? What if one uses Test & Copy in Burst mode and gets matching CRC's while producing load, any concern with that? That's how i'm typically ripping.
If CRCs match, all went fine.
As for a proof, there were some posts about it, so doing a search should bring some proofs.
QUOTE(Daffy @ Feb 22 2006, 11:45 PM)
QUOTE(rutra80 @ Feb 22 2006, 05:29 PM)
If you rip in secure mode there should be no problems. If you rip in burst mode while there's a heavy system load, they may be some glitches.
Any proof of this? What if one uses Test & Copy in Burst mode and gets matching CRC's while producing load, any concern with that? That's how i'm typically ripping.
Good question. I often wondered if system load influences ripping quality during burst mode extraction.
So, I tried to rip a CD in burst mode with Test & Copy, while defragging and playing World of Warcraft, and the CRCs checked out fine.
QUOTE(JensRex @ Feb 23 2006, 05:28 PM)
So, I tried to rip a CD in burst mode with Test & Copy, while defragging and playing World of Warcraft, and the CRCs checked out fine.
You probably didn't produce enough load
I'd expect problems on lock-alike load, when 3DMark2006 is scanning system configuration for example.
It should be easier to test on slow computer.
rutra80, you're missing the point completely. It shouldn't be tested on a slow computer. The point isn't to make the burst copy fail. The point is to test if it will succeed. Defrag + WoW is as stressed as a system is likely to be during normal usage (and then some), and under these circumstances, the burst copy completed successfully, which sufficiently proves that system load does not break your burst copy.
To me it seems like you're not getting the point - the point is to see if heavy system load can introduce quirks while ripping in burst mode. It's easier to produce heavy load on slow computer than on the fast one. What you prooved so far is that there were no quirks on your single rip on a fast computer with moderate load (of HDD & GPU 
).
I'll try to find old threads about that issue when I have time.
).I'll try to find old threads about that issue when I have time.
OK, I made a test too - I launched cpub4gx with high priority while doing Test & Copy in Burst mode with EAC being on normal priority, and CRCs did not match. I repeated the test without cpu4gx, in both burst & secure modes, and then CRCs did match.
It was a quick test so anyone is welcome to re-test, just make sure that you produce such a load that there is noticable slow down in ripping (mine went down under 1x).
It was a quick test so anyone is welcome to re-test, just make sure that you produce such a load that there is noticable slow down in ripping (mine went down under 1x).
QUOTE(rutra80 @ Feb 23 2006, 07:44 PM)
To me it seems like you're not getting the point - the point is to see if heavy system load can introduce quirks while ripping in burst mode.
Was this not exactly what I tested?QUOTE(rutra80 @ Feb 23 2006, 07:44 PM)
It's easier to produce heavy load on slow computer than on the fast one.
How does that make any sense? When I run a game, my CPU and GPU render frames as fast as they can. When I defrag or move files around on my HDD, it's doing it as fast as it can. Thus, by running these applications, my system is by definition under heavy load. 100% load in fact.QUOTE(rutra80 @ Feb 23 2006, 07:44 PM)
What you prooved so far is that there were no quirks on your single rip on a fast computer with moderate load (of HDD & GPU ).
That depends on whether you want to call a 1.5 GHz machine "fast". Anyway, what I proved so far is that there are no errors during burst copy on my machine under 100% load. ).This entire topic is highly uninteresting.
Here's a fun test.
Start lame.exe with time critical priority and have it encode a 1 TB wave file. Now you can't do anything. Amazing.
Start lame.exe with time critical priority and have it encode a 1 TB wave file. Now you can't do anything. Amazing.
QUOTE(JensRex @ Feb 23 2006, 08:41 PM)
QUOTE(rutra80 @ Feb 23 2006, 07:44 PM)
It's easier to produce heavy load on slow computer than on the fast one.
How does that make any sense? When I run a game, my CPU and GPU render frames as fast as they can. When I defrag or move files around on my HDD, it's doing it as fast as it can. Thus, by running these applications, my system is by definition under heavy load. 100% load in fact.QUOTE(rutra80 @ Feb 23 2006, 07:44 PM)
What you prooved so far is that there were no quirks on your single rip on a fast computer with moderate load (of HDD & GPU ).
That depends on whether you want to call a 1.5 GHz machine "fast". Anyway, what I proved so far is that there are no errors during burst copy on my machine under 100% load. ).1. If you ran the game with VSync on, your GPU wasn't rendering as fast as it can, but as fast as your screen's refresh rate is.
2. You want to produce load on CPU, not GPU.
3. Producing load on IDE bus is a good idea, but they are fast enough to handle both HDD & CD drives at once. And there's still an issue of priorities - defrag could pause in favor of what EAC has to write onto HDD at the moment.
4. 100% load isn't equal to 100% load - you want to give most of these 100% to the application which produces load, not EAC.
QUOTE(rutra80 @ Feb 23 2006, 08:53 PM)
1. If you ran the game with VSync on, your GPU wasn't rendering as fast as it can, but as fast as your screen's refresh rate is.
My game isn't hitting the Vsync barrier.QUOTE(rutra80 @ Feb 23 2006, 08:53 PM)
2. You want to produce load on CPU, not GPU.
Yea, you try running a heavy 3D game and take a look at your CPU usage. Back to school.QUOTE(rutra80 @ Feb 23 2006, 08:53 PM)
3. Producing load on IDE bus is a good idea, but they are fast enough to handle both HDD & CD drives at once.
You fail again, because with the HDD taxed with defragging, EAC is competing for I/O bandwidth on the HDD (and not the bus), since it has to dump its data to HDD since I'm not ripping to /dev/null.QUOTE(rutra80 @ Feb 23 2006, 08:53 PM)
And there's still an issue of priorities - defrag could pause in favor of what EAC has to write onto HDD at the moment.
Yea, but it doesn't.QUOTE(rutra80 @ Feb 23 2006, 08:53 PM)
4. 100% load isn't equal to 100% load - you want to give most of these 100% to the application which produces load, not EAC.
No, that is exactly what you don't want to do. If you deny EAC processing or I/O time, you are forcing it to fail. This isn't the point of the test. The point of the test is to see if EAC fails during a normal usage scenario. Playing WoW is a very normal scenario. Running specially crafted stress tests at elevated priority is not.I'm done with this topic.
I personally don't understand why a system under heavy load would impact upon the quality of an extraction.
rutra80, could you please run your test a number of times to see if your results are consistent.
And guys enough of the condescending snipes.
rutra80, could you please run your test a number of times to see if your results are consistent.
And guys enough of the condescending snipes.
QUOTE(JensRex @ Feb 23 2006, 08:41 PM)
Anyway, what I proved so far is that there are no errors during burst copy on my machine under 100% load.
No, you have only proven that in a single heavy load case, not every possible case, no errors happened. You cannot take this as an universal proof.
QUOTE(JensRex @ Feb 23 2006, 08:41 PM)
This entire topic is highly uninteresting.
Yeah, it was already proven in a previous topic; it is kinda useless.
[edit:]spelling
QUOTE(JensRex @ Feb 23 2006, 09:45 PM)
QUOTE(rutra80 @ Feb 23 2006, 08:53 PM)
And there's still an issue of priorities - defrag could pause in favor of what EAC has to write onto HDD at the moment.
Yea, but it doesn't.If it were as you think, you wouldn't rip a thing until defrag finishes.
QUOTE
QUOTE(rutra80 @ Feb 23 2006, 08:53 PM)
4. 100% load isn't equal to 100% load - you want to give most of these 100% to the application which produces load, not EAC.
No, that is exactly what you don't want to do. If you deny EAC processing or I/O time, you are forcing it to fail. This isn't the point of the test. The point of the test is to see if EAC fails during a normal usage scenario. Playing WoW is a very normal scenario. Running specially crafted stress tests at elevated priority is not.Seems we have different points, you seem to try to show that with "normal" load it is possible that there won't be any quirks, I showed that heavy load introduces quirks.
Note that:
1. Not everyone is running EAC with High priority.
2. Not everyone makes sure that there are no tasks running with priority higher than EAC.
3. There are constatnly running some system services with priorities set to at least High (WINLOGON, CSRSS, SMSS), and you can't be sure that they won't produce heavy load at least for a while.
QUOTE(evereux @ Feb 23 2006, 10:23 PM)
rutra80, could you please run your test a number of times to see if your results are consistent.
Yeah, just ran them once again and it seems to be perfectly reproductable, here are the logs:
Heavy load:
CODE
EAC extraction logfile from 23. February 2006, 22:00 for CD
Unknown Artist / Unknown Title
Used drive : SONY DVD-ROM DDU1621 Adapter: 0 ID: 1
Read mode : Burst
Read offset correction : 12
Overread into Lead-In and Lead-Out : No
Used output format : Internal WAV Routines
44.100 Hz; 16 Bit; Stereo
Other options :
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Native Win32 interface for Win NT & 2000
Track 18
Filename C:\Documents and Settings\artur\Moje dokumenty\test\18 - Track18.wav
Timing problem 0:01:10
Timing problem 0:01:13 - 0:01:14
Timing problem 0:02:27 - 0:02:28
Timing problem 0:02:31 - 0:02:35
Peak level 96.6 %
Test CRC 48086B7D
Copy CRC 76500580
Copy finished
No errors occured
End of status report
"Normal" load:
CODE
EAC extraction logfile from 23. February 2006, 22:06 for CD
Unknown Artist / Unknown Title
Used drive : SONY DVD-ROM DDU1621 Adapter: 0 ID: 1
Read mode : Burst
Read offset correction : 12
Overread into Lead-In and Lead-Out : No
Used output format : Internal WAV Routines
44.100 Hz; 16 Bit; Stereo
Other options :
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Native Win32 interface for Win NT & 2000
Track 18
Filename C:\Documents and Settings\artur\Moje dokumenty\test\18 - Track18.wav
Peak level 96.6 %
Test CRC FAFB655A
Copy CRC FAFB655A
Copy OK
No errors occured
End of status report
QUOTE(rutra80 @ Feb 23 2006, 10:18 PM)
Seems we have different points, you seem to try to show that with "normal" load it is possible that there won't be any quirks, I showed that heavy load introduces quirks.
Not to butt in unneccessarily, but
QUOTE(thread title)
Is it safe to use the CPU normally while ripping?
Ya but the guys wanted proof for:
QUOTE(rutra80 @ Feb 23 2006, 12:29 AM)
If you rip in burst mode while there's a heavy system load, there may be some glitches.
QUOTE(tgoose @ Feb 24 2006, 03:18 PM)
Not to butt in unneccessarily, but
QUOTE(thread title)
Is it safe to use the CPU normally while ripping?
The point is that problems may happen. "normally" does not mean much as there are always huge variations in CPU% when using a computer, such as peaks when starting applications. We cannot say he will never encounter problem. I have already ripped many discs (probably more than 50) with heavy memory and cpu loads but never had any bad-sounding rip issue. So it is probably some kind of one-man-and-one-computer problem.
Still, I do not think a bad rip is a critically issue if you own the disc. You can rerip it later. So he should do whatever pleases his mind. There is no definitive answer because it is not absolutely safe, but I assume it is safe enough. He should probably test himself, though.
Long story short:
System load has influence on ripping in burst mode - if you got mismatched CRCs, it doesn't neccessarily mean that the disc is damaged, it could as well be that due to heavy load EAC got denied I/O operations and encountered a timing problem.
Is it a serious issue? No, because if you use Test & Copy you always know if things went well (CRCs match) or not-so-well (CRCs don't match).
This also applies to secure mode (after all it consists of bursts), but in case of problems secure mode will automatically recover (in opposition to burst mode which goes ahead whatever happened).
System load has influence on ripping in burst mode - if you got mismatched CRCs, it doesn't neccessarily mean that the disc is damaged, it could as well be that due to heavy load EAC got denied I/O operations and encountered a timing problem.
Is it a serious issue? No, because if you use Test & Copy you always know if things went well (CRCs match) or not-so-well (CRCs don't match).
This also applies to secure mode (after all it consists of bursts), but in case of problems secure mode will automatically recover (in opposition to burst mode which goes ahead whatever happened).
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.