IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3 >  
Reply to this topicStart new topic
The ONLY way to be guaranteed correct ripping?, EAC, secure + fast rip
DrDoogie
post May 15 2003, 17:32
Post #26





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE (liekloo @ May 10 2003 - 11:41 AM)
Well... no more news from Dr.Doogie?  huh.gif

Duh... about what?

Currently I've been busy ripping all my CD's, with the following procedure:

* Read with EAC (Accurate stream, Caching [disabled], reports C2, adjust drive speed) at speed 8CLV.
* If an error lights up, put that CD away and look at it later.

I decided to do 8CLV since my drive (plextor 1210A) had a "perfect" error reporting at this speed (compared with other speeds as set by plextools).
I can post the graphs illustrating this (by DAEQuality's c2extract+analyse) sometime soon by flogging up a pitiful webpage somewhere, or is there some central repository where we can post such data?

To summarize, I do not trust EAC's error <insert despising sneer here>"correction" facilities one bit, jolt, or - or - or something vastly smaller than some other really small thing.

I've seen - and can repeat, methinks - results where two identical CD's are being read, one CD having errors and the other not, and EAC fails to give an Exact result.

"Exact Audio Copy" my #!*.

But perhaps it's just my grapes. Would be good if Andre decided either to open source it or put in some effort into it.
Go to the top of the page
+Quote Post
ancl
post May 15 2003, 18:05
Post #27





Group: Members (Donating)
Posts: 185
Joined: 29-September 01
Member No.: 54



QUOTE (DrDoogie @ May 15 2003 - 06:32 PM)
* Read with EAC (Accurate stream, Caching [disabled], reports C2, adjust drive speed) at speed 8CLV.

Just to be sure: What do you mean with "Caching [disabled]".
Is the option checked or not?

If you don't check that option, that means that EAC will asume that your drive is not caching, and this may lead to that errors are being missed if your drive do cache.

The safe way is to check that option. The only negative thing with that is that the ripping speed may be lower.
Go to the top of the page
+Quote Post
liekloo
post May 15 2003, 20:10
Post #28





Group: Members
Posts: 456
Joined: 22-March 02
From: Belgium
Member No.: 1596



QUOTE (DrDoogie @ May 15 2003 - 05:32 PM)
I've seen - and can repeat, methinks - results where two identical CD's are being read, one CD having errors and the other not, and EAC fails to give an Exact result.
"Exact Audio Copy" my #!*.
But perhaps it's just my grapes. Would be good if Andre decided either to open source it or put in some effort into it.

ohmy.gif
WTF... I am speechless...


--------------------
"E S S E N T I A L" Guide for E A C :

http://users.fulladsl.be/spb2267/
Go to the top of the page
+Quote Post
Pio2001
post May 15 2003, 21:20
Post #29


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



QUOTE (DrDoogie @ May 15 2003 - 07:32 PM)
I can post the graphs illustrating this (by DAEQuality's c2extract+analyse) sometime soon by flogging up a pitiful webpage somewhere, or is there some central repository where we can post such data?

You can start a thread here, or in the EAC forum.
Go to the top of the page
+Quote Post
westgroveg
post May 15 2003, 21:27
Post #30





Group: Members
Posts: 1235
Joined: 5-October 01
Member No.: 220



QUOTE
Would be good if Andre decided either to open source it or put in some effort into it.

I think he means lately & I agree.

QUOTE
* Read with EAC (Accurate stream, Caching [disabled], reports C2, adjust drive speed) at speed 8CLV.

If you encounter an undetected error (#/CRC mismatch) please try without C2 enabled & report your drive, results. If you rip all your CD's without C2 the same thing may happen possibly on different CD's.

This post has been edited by westgroveg: May 16 2003, 10:52
Go to the top of the page
+Quote Post
DrDoogie
post May 16 2003, 14:06
Post #31





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE (liekloo @ May 15 2003 - 11:10 AM)
QUOTE (DrDoogie @ May 15 2003 - 05:32 PM)
I've seen - and can repeat, methinks - results where two identical CD's are being read, one CD having errors and the other not, and EAC fails to give an Exact result.
"Exact Audio Copy" my #!*.
But perhaps it's just my grapes. Would be good if Andre decided either to open source it or put in some effort into it.

ohmy.gif
WTF... I am speechless...

By my arrogance or by my claim that the first letter in EAC is misleading?

The first I am reluctant to do anything about in this situation ("...y'all need a li'l con-tro-ver-sy...", etc.), the other I will post on later.
Go to the top of the page
+Quote Post
DrDoogie
post May 16 2003, 14:11
Post #32





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE
QUOTE
Would be good if Andre decided either to open source it or put in some effort into it.

I think he means lately & I agree.


Yes, *snigger*, exactly.

Sorry for mnot making that clear. My position is that you can't both spank your little ego by keeping your intellectual property underdeveloped 'cause you want to reap all the praise for it yourself, and at the same time claim that you want to code a good product for the community.

Don' get me wrong tho', ain't nuthin' wrong with a little ego-spanking, but let's all recognise what motivates people. Altruism ain't it.
Go to the top of the page
+Quote Post
Daybreak
post Jun 1 2003, 06:54
Post #33





Group: Members
Posts: 104
Joined: 22-July 02
Member No.: 2722



Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option?

Since there isn't really a Test & Copy sort of thing ( which is largely what I've been using till recently ), do we have to do the comparision manually? Have EAC rip twice ( manually ) and then md5sum of diff the two resultant waves for differences before compressing?

Or is there any other better automated method?
Go to the top of the page
+Quote Post
_Shorty
post Jun 1 2003, 09:59
Post #34





Group: Banned
Posts: 694
Joined: 19-April 02
Member No.: 1820



well, it gives you a crc after the rip is finished already
Go to the top of the page
+Quote Post
zack
post Jun 1 2003, 15:05
Post #35





Group: Members
Posts: 26
Joined: 16-February 02
Member No.: 1336



One can conclude that CD's were not meant for accurate data transport. They were meant for end user playback. If you take two different drives, both rips will be different as far as CRC goes , even with offset correction. However I've found that the actual sound is 99.9% the same on a non scratched CD. With a brand new CD, I actually just use fast or burst mode. I get the same results as with secure mode. I only use secure mode with my older CD's that might have scratches. I don't own any copy protected CD's, so I don't know about them. If I have a CD that's more than lightly scratched, and I have been ripping for 12 hours and it's only into the 2nd minute on track 1, I'll try to use fast mode and if I notice a bunch of clicks, i'll just mark the folder as errored and get a new CD sometime in the future. Either that or I'll attempt to use scratch removal then do another secure rip. If it's still taking 120 hours and it's a CD that will be expensive to replace, and won't even play back on a regular CD player, I'll take more extreme measures, i.e. very high grit (1500-2500+) emery cloth. Luckily haven't had to use this method yet.

This post has been edited by zack: Jun 1 2003, 15:16
Go to the top of the page
+Quote Post
liekloo
post Jun 1 2003, 16:27
Post #36





Group: Members
Posts: 456
Joined: 22-March 02
From: Belgium
Member No.: 1596



QUOTE (Daybreak @ Jun 1 2003 - 06:54 AM)
Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option?

Since there isn't really a Test & Copy sort of thing ( which is largely what I've been using till recently ), do we have to do the comparision manually? Have EAC rip twice ( manually ) and then md5sum of diff the two resultant waves for differences before compressing?

Or is there any other better automated method?

No, there isn't.

The reason is quite simple: EAC should (in theory) give a perfect rip in mere 'copy' mode (no test & copy needed).
Those who use Test & Copy (for separate tracks) will know that every now and then, the rip is not always perfect (sometimes CRC mismatch...).

But that's it. I think (or better: we know) EAC is very good, even without Test & copy.
The claims made in this thread (also the post preceeding this one) are mere claims, without decent argumentation or testing mad.gif


--------------------
"E S S E N T I A L" Guide for E A C :

http://users.fulladsl.be/spb2267/
Go to the top of the page
+Quote Post
DrDoogie
post Jun 3 2003, 13:39
Post #37





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE (liekloo @ Jun 1 2003 - 07:27 AM)
QUOTE (Daybreak @ Jun 1 2003 - 06:54 AM)
Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option? ...

Or is there any other better automated method?


No, there isn't.
...
The claims made in this thread (also the post preceeding this one) are mere claims, without decent argumentation or testing mad.gif

Um, was that aimed for me?
If so, yes I haven't bothered putting up my results anywhere... would you like me to mail them to you?

Anyway, my claims are:

1. My drive, a plextor1210 with firmware 1.10, detects errors most accurately when reading at a speed setting of 8CLV.
I can document this if desired, bu sending the *.bmp (well, gif'ed) and *c2.dat (zip'ed) files to whom may be interested.
2. Having ripped some 100 cd's in various states of deterioration with both EAC and plextools, I currently have the (approximate) results of:
20% have detectable errors
30% are in disagreement when using EAC to compare the two rips
50% (duh!) are in full agreement between EAC and plextools.

I have a hard time seeing how the 50% can possibly be wrong, so I will be sharing those.
The 20% I will not bother ripping, and the 30% I will not share even though I cannot hear anything wrong with them.

This way I believe I am doing my part for the great and just cause of accurate ripping and reaming the music companies. If you pardon my american. tongue.gif

This post has been edited by DrDoogie: Jun 3 2003, 13:41
Go to the top of the page
+Quote Post
liekloo
post Jun 3 2003, 13:55
Post #38





Group: Members
Posts: 456
Joined: 22-March 02
From: Belgium
Member No.: 1596



QUOTE (DrDoogie @ Jun 3 2003 - 01:39 PM)
Um, was that aimed for me?

Zack not to forget wink.gif

A lot of people work hard to test EAC thoroughly, that's why people with a different opinion could do a little more than just boasting with controversal claims (or rather: fragments of claims) without argumentation or even complete background.
It seems I'll have to take my words back though, since you (DrDoogie) started to be more concrete.
Actually, it does hardly matter who will turn out to be right about EAC, and who will be wrong... We'll try to get to a 'consensus' and hopefully this will be interesting for a lot of ppl.
CODE
If so, yes I haven't bothered putting up my results anywhere... would you like me to mail them to you?

Feel free to post them here smile.gif
EDIT: we can add images (a link to them) to posts etc...
EDIT: Although this is getting more & more interesting, I'll be a bit 'slow' to follow the discussions on the forum - sorry in advance (lack of time, exams)

This post has been edited by liekloo: Jun 3 2003, 13:59


--------------------
"E S S E N T I A L" Guide for E A C :

http://users.fulladsl.be/spb2267/
Go to the top of the page
+Quote Post
tigre
post Jun 3 2003, 14:04
Post #39


Moderator


Group: Members
Posts: 1434
Joined: 26-November 02
Member No.: 3890



QUOTE (DrDoogie @ Jun 3 2003 - 04:39 AM)
2. Having ripped some 100 cd's in various states of deterioration with both EAC and plextools, I currently have the (approximate) results of:
20% have detectable errors
30% are in disagreement when using EAC to compare the two rips
50% (duh!) are in full agreement between EAC and plextools.

Interesting. What (secure mode) settings have you used when getting these results? (C2, Caching)

What's the condition of your CDs?

I haven't tested with 100 cds (rather ~10 - the scratchiest I had) but I get > 90% (I can't tell exactly but I'd say >99%) full agreement between EAC and plextools - AND between plextor 121032A and lg DRD8120B.

Do you check "disagreemen when using EAC to compare the two rips" comparing CRCs or using compare WAVs?

Your numbers sound to me like your drive has ripped some CDs too much, your settings are not optimal (Drive caches audio data unchecked) or there's a hardware problem like bad RAM that causes data corruption.


--------------------
Let's suppose that rain washes out a picnic. Who is feeling negative? The rain? Or YOU? What's causing the negative feeling? The rain or your reaction? - Anthony De Mello
Go to the top of the page
+Quote Post
DrDoogie
post Jun 4 2003, 13:36
Post #40





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE (liekloo @ Jun 3 2003 - 04:55 AM)
QUOTE (DrDoogie @ Jun 3 2003 - 01:39 PM)
Um, was that aimed for me?

Zack not to forget wink.gif

A lot of people work hard to test EAC thoroughly, that's why people with a different opinion could do a little more than just boasting with controversal claims (or rather: fragments of claims) without argumentation or even complete background.
It seems I'll have to take my words back though, since you (DrDoogie) started to be more concrete.
Actually, it does hardly matter who will turn out to be right about EAC, and who will be wrong... We'll try to get to a 'consensus' and hopefully this will be interesting for a lot of ppl.
CODE
If so, yes I haven't bothered putting up my results anywhere... would you like me to mail them to you?

Feel free to post them here smile.gif
EDIT: we can add images (a link to them) to posts etc...
EDIT: Although this is getting more & more interesting, I'll be a bit 'slow' to follow the discussions on the forum - sorry in advance (lack of time, exams)

QUOTE (lieklo)
A lot of people work hard to test EAC thoroughly, that's why people with a different opinion could do a little more than just boasting with controversal claims (or rather: fragments of claims) without argumentation or even complete background.


True.

QUOTE
Actually, it does hardly matter who will turn out to be right about EAC, and who will be wrong... We'll try to get to a 'consensus' and hopefully this will be interesting for a lot of ppl.


Word.

QUOTE
...
Feel free to post them here smile.gif
EDIT: we can add images (a link to them) to posts etc...


Eh. Link to images I haven't bothered putting up anywhere?

QUOTE (tigre)
Interesting. What (secure mode) settings have you used when getting these results? (C2, Caching)


EAC: constant speed of 8, disable audio caching, use accurate stream feature and C2 error reporting feature, abort on read/sync errors
plextools: constant speed of 8C[doh!]LV, report errors only, abort on lowest number of errors (some 100+ I think)

QUOTE
What's the condition of your CDs?


From extremely poor (10 years old, played 100's of times and mishandled) to very good (less than a year old, hardly been handled, can shave yourself in 'em).

QUOTE
Do you check "disagreemen when using EAC to compare the two rips" comparing CRCs or using compare WAVs?


I don't trust EAC's CRC handling. So I compare the wavs.

QUOTE
Your numbers sound to me like your drive has ripped some CDs too much, your settings are not optimal (Drive caches audio data unchecked) or there's a hardware problem like bad RAM that causes data corruption.


"Bad RAM that causes data corruption". That's a good one. laugh.gif
You realize that there's CRC in RAM as well, of course?

But no, the drive is fine - or at least so I think, based on testing with daequality twice at a speed of 8 and getting 99.9% and 100.0% accurate error reporting. I jot the 0.01% down to sync / too high burst error count introduced to one of the test cd's during scratching.

The CD's are to blame, methinks. We're talking scratch'o'rama here.
Go to the top of the page
+Quote Post
JeanLuc
post Jun 4 2003, 14:48
Post #41





Group: Members
Posts: 1311
Joined: 4-June 02
From: Cologne, Germany
Member No.: 2213



@Doogie ...

You are right about RAM ... bad RAM will most likely cause a whole system crash with a nice and blue screen ...


--------------------
The name was Plex The Ripper, not Jack The Ripper
Go to the top of the page
+Quote Post
PoisonDan
post Jun 4 2003, 14:50
Post #42





Group: Members (Donating)
Posts: 678
Joined: 10-December 01
From: Belgium
Member No.: 622



QUOTE (DrDoogie)
EAC: constant speed of 8, disable audio caching, use accurate stream feature and C2 error reporting feature, abort on read/sync errors.


DrDoogie, according to this table, your drive (with your reported firmware version) caches audio. Therefor, you MUST enable caching in EAC, otherwise you will get unreliable results.

Also, as westgroveg mentioned before, to be safe you should also disable C2 reporting.

Please don't diss EAC like that when you haven't even configured EAC properly in the first place.

QUOTE
"Bad RAM that causes data corruption". That's a good one.  laugh.gif
You realize that there's CRC in RAM as well, of course?

So according to you the CRC in RAM is the "magical" solution to all RAM problems. If only that were true... (there wouldn't be any bad RAM anymore, would there ?)

Believe me, bad RAM CAN cause data corruption (if the RAM is bad, how do you know the CRC calculation is correct ?).

Don't diss tigre's comments if you don't really know what you're talking about yourself.


--------------------
Over thinking, over analyzing separates the body from the mind.
Go to the top of the page
+Quote Post
kdo
post Jun 4 2003, 17:02
Post #43





Group: Members (Donating)
Posts: 304
Joined: 18-April 02
From: Russia
Member No.: 1812



QUOTE
DrDoogie, according to this table, your drive (with your reported firmware version) caches audio. Therefor, you MUST enable caching in EAC, otherwise you will get unreliable results.


Although I can barely understand what exaclty are the DrDoogie's claims in this thread, I think I can understand that his "caching" setting is ok.
(Of course, one can in fact neither disable nor enable drive cache.) So I understand his words "disable audio caching" as that he has the option "Drive caches audio data" checked, which is the correct setting for his drive.

@DrDoogie:

please let us know if that is indeed what you mean!

We would also be very grateful, if you could make some tests with EAC but this time not using the C2-report feature, i.e. with the first C2 checkbox unchecked.
Edit: and this is what Tigre suggested you to do nearly a month ago, in the beginning of this thread! But you have chosen to ignore it...

This post has been edited by kdo: Jun 4 2003, 17:15
Go to the top of the page
+Quote Post
Pio2001
post Jun 4 2003, 18:39
Post #44


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



QUOTE (JeanLuc @ Jun 4 2003 - 04:48 PM)
@Doogie ...

You are right about RAM ... bad RAM will most likely cause a whole system crash with a nice and blue screen ...

'Bout RAM

Nope,
Defective RAM can very well introduce errors in wav files. The size of a wav file from a CD being 100 to 10,000 times bigger than an exe, it can introduce errors into any CD you rip without affecting much the system stability.
It occured to me twice already. The first time, it took me two monthes to realize that the RAM was responsible for corrupted VOB files ripped from DVD (I checked everything else, posted the problem to doom9.net forum without sucess...). The second time, I got a wav file that was read differently in SoundForge and in Samplitude. It was a CD image. There was only one different sample in the whole wav, always the same, and the values returned by Samplitude and SoundForge were both consistent. I suspected the RAM, and let things rest for a while (the computer running well), until I wanted in upgrade to Windows XP, which turned out impossible (errors, data corruption, process aborted etc), until I had the RAM changed.

However, if the CDs are scratched, and if you get a full error recovery in EAC (with the red lights never reaching the end), getting different wavs with no error occured is common (it's the fact itself of getting a whole wav with constant error correction and no error occured, that is very rare).
Go to the top of the page
+Quote Post
Daybreak
post Jun 4 2003, 19:44
Post #45





Group: Members
Posts: 104
Joined: 22-July 02
Member No.: 2722



QUOTE (liekloo @ Jun 1 2003 - 11:27 PM)
QUOTE (Daybreak @ Jun 1 2003 - 06:54 AM)
Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option?

Since there isn't really a Test & Copy sort of thing ( which is largely what I've been using till recently ), do we have to do the comparision manually? Have EAC rip twice ( manually ) and then md5sum of diff the two resultant waves for differences before compressing?

Or is there any other better automated method?

No, there isn't.

The reason is quite simple: EAC should (in theory) give a perfect rip in mere 'copy' mode (no test & copy needed).
Those who use Test & Copy (for separate tracks) will know that every now and then, the rip is not always perfect (sometimes CRC mismatch...).

But that's it. I think (or better: we know) EAC is very good, even without Test & copy.
The claims made in this thread (also the post preceeding this one) are mere claims, without decent argumentation or testing mad.gif

Well.. for one, the CD I was ripping was a copy-protected CD. Despite having only given it a spin in my iRiver once, and being absolutely scratch-free, EAC reported a quality of ~ 97% ( can't remember the figure off the top of my head ) after taking like 3 hours to do the rip.

What would you do in such a case?

Naturally, I get concerned and wonder whether any errors were introduced during the ripping. So far, listening through, I didn't detect any, but I'm using a below-average soundcard ( SBLive ) and a crappy pair of headphones ( Philips SBC HP840. Anyone heard of this model before? ). Hence the question about whether a Test&Copy exists for image rips.

A suggestion/question though. There should be some of option in EAC that dumps a DETAILED logfile. By detailed, that means the approximate time/duration at which a read error occurred and re-reads were necessary. That would allow the user to quickly zoom in on trouble spots to listen for flaws.
Go to the top of the page
+Quote Post
DrDoogie
post Jun 5 2003, 13:39
Post #46





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE ("Rock Oooooonnnnhng Dude")
DrDoogie, according to this table, your drive (with your reported firmware version) caches audio. Therefor, you MUST enable caching in EAC, otherwise you will get unreliable results.


No.
I must enable disabling of the audio cache.
I'm sure you will agree, having thought about it a bit.

QUOTE
Also, as westgroveg mentioned before, to be safe you should also disable C2 reporting.


I don't really think so.
Please bear with me as I try to explain why.
If there is an unrecoverable, uncorrectable error(C2), the drive does two things, as I understand it (corrections to this understanding are welcome).
1. It reports the error.
2. It hiddes the error by pretending to perform a valid correction (muting, extrapolation etc.)

Not all drives report all errors, especially at high speeds and lots of errors (in my impression), which means that EAC can only (in my guess) compare results by reading several times, and assume that the result that rears its ugly head most often is most likely correct.
But there is, I believe the very real chance that the result will be "bogus-corrected" the same way lotsa times.
More to the point, when you have a C2 error you no longer have any way of finding out whether your result is correct or not ('cept by comparing with a known good rip, which I did for some CD's [and found that EAC can't do nuthin' 'bout the fact that there are errors encountered when reading: [i]This is a claim which I will not bother documenting. I have experienced it, good enough for me.])

QUOTE
Please don't diss EAC like that when you haven't even configured EAC properly in the first place.

I have no interest in dissing EAC, as such. Please excuse me if my frustration got vented a bit too much. On the other hand, please don't post out of a fanboy-ish attitude.

QUOTE
So according to you the CRC in RAM is the "magical" solution to all RAM problems. If only that were true... (there wouldn't be any bad RAM anymore, would there ?)


I do not believe I was quite that general... but to answer so that you can understand, bad RAM does not just affect ripping. Furthermore, EAC uses some 4MB when running, which according to the other programs you run, can be physically located anywhere on the ram-stick. Having ripped 100 (well, 250) cd's almost twice, I do not think that... oh, toss it.

QUOTE
Don't diss tigre's comments if you don't really know what you're talking about yourself


Pooh-poo on your comments.
Go to the top of the page
+Quote Post
DrDoogie
post Jun 5 2003, 14:32
Post #47





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE (kdo)
We would also be very grateful, if you could make some tests with EAC but this time not using the C2-report feature, i.e. with the first C2 checkbox unchecked.
Edit: and this is what Tigre suggested you to do nearly a month ago, in the beginning of this thread! But you have chosen to ignore it...


Um, chosen? No, I've been busy and forgot.
"Never attribute to malice what simple stupidity alone can explain".

But YOU want ME to "test" something for you, on the grounds of, as you say, "I do not think I understand...".

How 'bout YOU test what you want to test instead. It's YOUR hardware you're going to be using, after all, and you shouldn't trust anything I say just because I seem to have convinced myself of the validity of my views.

QUOTE (Pio2001)
Defective RAM can very well introduce errors in wav files.


Yes, well, I could always test my ram again, seeing as that 30% of my rips are in disagreement between EAC and PlexTools. If I find any errors, I'll amend that to this post.
Go to the top of the page
+Quote Post
kdo
post Jun 5 2003, 17:25
Post #48





Group: Members (Donating)
Posts: 304
Joined: 18-April 02
From: Russia
Member No.: 1812



QUOTE (DrDoogie)
Um, chosen? No, I've been busy and forgot.

I am very glad it is just a misunderstanding.
I have to say it did indeed look a bit strange to me that you were intensively testing EAC/C2 etc, but not even once tested it with the different C2 option. That would be the first thing I would do even if I didn't suspected anything wrong with that option. Just for the sake of it.
Hence, a bit exclamatory tone of that comment - Sorry about that.

QUOTE
How 'bout YOU test what you want to test instead. It's YOUR hardware you're going to be using

Yet again, this would be the first thing I would do - if I had a drive that reports C2.
By the way, I did make some (humble) testing with my drive, but the results were in accord with what was commonly known.

QUOTE
But YOU want ME to "test" something for you, on the grounds of, as you say, "I do not think I understand...".

Heh... Someone here had a signature "everything you say will be mis-quoted and used against you".

ahh, it's just hopeless...

P.S.
Indeed, sometimes people are having very peculiar problems with hardware, like this one, for instnace. Better double-check everything.
Go to the top of the page
+Quote Post
Pio2001
post Jun 5 2003, 20:13
Post #49


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



QUOTE
"Never attribute to malice what simple stupidity alone can explain".


So true ! I know some people in real life who should think about it rolleyes.gif

QUOTE
Yes, well, I could always test my ram again, seeing as that 30% of my rips are in disagreement between EAC and PlexTools. If I find any errors, I'll amend that to this post.


Personally, I never said that your results came from a defective RAM, I just said that errors in CD ripping is often the only visible manifestation of a defective RAM, the BSOD being mistaken for Microsoft Windows ones.
Anyway, this is easy to check. Target one wav file, about 100 to 200 MB, in the explorer. Make a copy of it (drag+drop+ctrl, or ctrl-C+ctrl-V, or what you want). Erase the copy, and copy again, repeat two or three times, until the copying is very fast (file cached in the RAM).
Then compare the two files. With a defective RAM, you'll get differences for sure.
Go to the top of the page
+Quote Post
DrDoogie
post Jun 6 2003, 12:48
Post #50





Group: Members
Posts: 81
Joined: 17-April 03
Member No.: 6024



QUOTE
Personally, I never said that your results came from a defective RAM, I just said that errors in CD ripping is often the only visible manifestation of a defective RAM...


Mm.
I think we will have to agree to disagree on that one.

Having used memcheck 3.0 with all the simple tests (1.5 hours) last night, I am firm in my belief that discrepancies between extractions wit plextools and EAC cannot be blamed on any "boogy-men" in the ram.
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd July 2014 - 07:42