Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: EAC and CDex's handling cache (Read 11240 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC and CDex's handling cache

[span style='font-size:8pt;line-height:100%']EDIT : topic split from http://www.hydrogenaudio.org/forums/index....howtopic=16131&[/span]


> To replace EAC ?? Why is this such a matter of principle not to
> use closed source software? Especially if it is freely available.

I just quickly ran through the complete thread and I find this
question truely amazing, so let me explain why I prefer open source
rippers to EAC :

- First, I know exactly what an open source ripper does by simply
reading the code, while with closed sources programs you have to
trust the authors on anything they tell you. For instance, did you
know that EAC secure mode does not always read the sectors twice or
that the reading command you choose is sometimes not the one actually
used ? EAC has hundreds of options, all very lightly documented and
which can produce unwanted behaviour when you choose the wrong
combination, and you will simply never know it.

- Furthermore, closed sources is even more dangerous with EAC since
it is made by a single person who is not even a professional of the
CD/audio industry. Like anyone else Andre is not error prone, so his
bugs get fixed only when he finds, understands and decides to fix
them. For instance, if he had published the source code of his DAE
quality tool from the start, the skip bug would have been found
quickly by code reviews and all results published until now would
not be useless.

- When you have an idea about how to improve EAC, what can you
do ? Send a mail to Andre, cross your fingers and wait until the
next update. With open source code, anyone can easily add his
own improvements and propose them to everyone to try. For instance
everybody seems to wonder at how EAC handles the cache ; well,
sorry to disappoint you, but on this point EAC is actually
inferior to Plextools or even CDParanoia. How long do you think
the FUA bit will take to be implemented in EAC ?

All these problems you get because of lack of documentation, lack of
time, coding mistakes or even plain lies are avoided by open source.
Bugs are found and fixed incredibly sooner and you get a better, more
mature software much faster. Multiple brains work better than a
single one, it's as simple as that.

EAC and CDex's handling cache

Reply #1 –
Quote
- First, I know exactly what an open source ripper does by simply
reading the code, while with closed sources programs you have to
trust the authors on anything they tell you.

Weeee! I'll be able to link to the Ken Thompson article again.

http://www.acm.org/classics/sep95/

BTW: Ken Thompson is one of the creators of Unix and C. No matter what arguments you use - he is right, and you are wrong. 

EAC and CDex's handling cache

Reply #2 –
Quote
For instance
everybody seems to wonder at how EAC handles the cache ; well,
sorry to disappoint you, but on this point EAC is actually
inferior to Plextools or even CDParanoia.

Let me comment some more.

OK, I was a CDex developer, I should know (CDex uses CDparanoia)

CDparanoia is of no use with drives that cache data. Differently from EAC, it doesn't reset cache after each read. So, even if reads the same part 5 times to try to detect an error, the drive will feed the ripper the same data that was first read into the cache 5 consecutive times. And the ripper will think the data is perfect, even if there was a big ugly scratch there.

Regards;

Me.

EAC and CDex's handling cache

Reply #3 –
> Let me comment some more.
>
> OK, I was a CDex developer, I should know (CDex uses CDparanoia)
>
> CDparanoia is of no use with drives that cache data. Differently
> from EAC, it doesn't reset cache after each read.

Great, then check scsi_interface.c in latest cdparanoia source code.
If your drive satisfies the test in check_fua_bit(), the FUA bit is
set for 0x28, 0xA8, 0xD4, 0xD5, and 0xD8 reading methods. And
contrary to the tricks of EAC to force a cache flush (which, by the
way do not occur after each read), the Force Unit Access bit is the
official, hardware supported method to bypass the cache (and the
method used by Plextools too).

EAC and CDex's handling cache

Reply #4 –
Quote
Great, then check scsi_interface.c in latest cdparanoia source code.
If your drive satisfies the test in check_fua_bit(), the FUA bit is
set for 0x28, 0xA8, 0xD4, 0xD5, and 0xD8 reading methods. And
contrary to the tricks of EAC to force a cache flush (which, by the
way do not occur after each read), the Force Unit Access bit is the
official, hardware supported method to bypass the cache (and the
method used by Plextools too).

Well, I remember that André and you didn't have that much of a good start (I remember one unlucky debate on the EAC board at digital-inn) but why don't you share your knowledge in a more productive way (no offense here) by giving Andre a few hints about the facts you consider as flaws (from your more professional point of view) ? ... if you do it on the board and adress him directly, he won't ignore that ...

Andre is a student of mathematics and computer science and worked for VOB in development of their ASAPI layer so I think he is somewhat skillful in programming ... but he is not an engineer in electronics.

That way, we could all benefit from improvements ... and I don't think that Andre would be that kind of egoistic to disrespect some constructive criticism ...

Just my 0,02€

Sven
The name was Plex The Ripper, not Jack The Ripper

EAC and CDex's handling cache

Reply #6 –
Quote
> Let me comment some more.
>
> OK, I was a CDex developer, I should know (CDex uses CDparanoia)
>
> CDparanoia is of no use with drives that cache data. Differently
> from EAC, it doesn't reset cache after each read.

Great, then check scsi_interface.c in latest cdparanoia source code.
If your drive satisfies the test in check_fua_bit(), the FUA bit is
set for 0x28, 0xA8, 0xD4, 0xD5, and 0xD8 reading methods. And
contrary to the tricks of EAC to force a cache flush (which, by the
way do not occur after each read), the Force Unit Access bit is the
official, hardware supported method to bypass the cache (and the
method used by Plextools too).

But how well does this check for the FUA bit work in practice (i.e. with the current drives) ?

Case has already mentioned several times that CDEx doesn't detect errors on his drive that caches audio.

And what about Pio2001's threads about EAC vs CDEx ?
http://www.hydrogenaudio.org/forums/index....showtopic=2803&
http://www.hydrogenaudio.org/forums/index....=ST&f=20&t=3164

I'll quote the conclusion from the second thread:
Quote
With the Memorex DVD-Maxx 1648 drive, CDex is of no use compared to EAC, it returns files full of errors and audible clicks claiming zero errors occured even in full paranoia mode.
Though the C2 error detection is currently very criticized, it is still, at least for this drive, infinitely more accurate (9462 times more accurate, according to Feurio ) than CDex full paranoia mode, and as accurate as the reading twice method in EAC, while much faster.


I would assume that CDEx uses the cdparanoia library with the FUA bit check included. If it does, how do you explain this behaviour ?

Don't get me wrong, I would love to see cdparanoia perform as well as EAC. I was very disappointed when I started reading about those CDEx issues with drives that cache audio. It's in everyone's best interest to have those issues resolved.
Over thinking, over analyzing separates the body from the mind.

EAC and CDex's handling cache

Reply #7 –
That's interesting. The question is: Did the change in CDParanoia take place before or after the comparisons where done?
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

EAC and CDex's handling cache

Reply #8 –
Quote
That's interesting. The question is: Did the change in CDParanoia take place before or after the comparisons where done?

It's worth mentioning that it's been more than 2 years since CDparanoia was updated in the CDex source tree (with some small changes that happened about an year ago)

But then again, to the best of my knowledge, CDparanoia didn't underwent much development during this time - if it was developed at all.

EAC and CDex's handling cache

Reply #9 –
@JeanLuc:

> Well, I remember that André and you didn't have that much of a good
> start (I remember one unlucky debate on the EAC board at digital-inn)

Indeed, about CIRC and C2 accuracy. If you remember well I asked him
many times to elaborate on his claim that all drives were C2 inaccurate,
and he always ignored my posts. Now few weeks ago Pio found a bug in the
C2 analysing tool which shows that all these accuracy percentage figures
are actually unreliable.

> but why don't you share your knowledge in a more productive way
> (no offense here) by giving Andre a few hints about the facts you
> consider as flaws (from your more professional point of view) ?
> ... if you do it on the board and adress him directly, he won't
> ignore that ...

Well, as I just said I offered to review the methodology of his C2
accuracy test several times, on his board, addressing him directly,
and he just ignored me. When I work on a project open-source code is
very nice to have, but open-minded people is a requirement. Anyway,
this is history so I propose we come back to the topic.


@PoisonDan:

> But how well does this check for the FUA bit work in practice
> (i.e. with the current drives) ?

Reading the source code, both the test and the actual use of the
FUA bit should work nicely on any drive which supports one of the
5 reading methods I mentioned (that's a lot). However, it seems FUA
is not the preferred method to handle the cache, so it is very
likely that cdparanoia will not test or use the FUA bit even if
your drive supports it.

Indeed, according to the author cdparanoia implements similar
tricks as EAC to avoid multiple reads from the cache, see
http://groups.google.com/groups?hl=en&lr=&...dfellow.MIT.EDU
I've not reviewed this part of code so I don't know how well
it works.

Regarding CDEX, I have never used it and and I don't know what's
in its code, so for now I assume it's not the same program as
cdparanoia and I will not try to explain any behaviour it might
show.

EAC and CDex's handling cache

Reply #10 –
Quote
Reading the source code, both the test and the actual use of the
FUA bit should work nicely on any drive which supports one of the
5 reading methods I mentioned (that's a lot). However, it seems FUA
is not the preferred method to handle the cache, so it is very
likely that cdparanoia will not test or use the FUA bit even if
your drive supports it.

Hey spath, thanks for answering

One question  ... is the read command "MMC-1" (In EAC terminology) one of the 5 read modes you mentioned ? I could only identify D5 and D8 (latter is, AFAIK, used by Plextor, Yamaha and on most other SCSI devices) ...

A little offtopic ... I've been using EAC's C2 (or better: CU) ever since and did some personal tests on my own by using damaged discs from my collection ... My Plex drives (as well as my LiteOn's) never gave me a real hint of faulty C2/CU reporting since the extraction results from different drives were always the same (and the CD's I used had some real errors on them like scratches in the reflective layer and so on) and matched the ones obtained with Plextools as well.

The only drive not being able to reproduce matching results was my Toshiba DVD-ROM 1612 which failed with and without C2/CU usage (so I simply assume that this drive cannot handle overall DAE very well - although it's abilities on yellow book CD's and DVD's are good, though) ...

Anyway, I posted something on the EAC board, referring to your statements about the FUA bit and cache handling during DAE ... maybe (and hopefully) Andre will make a statement about that issue.
The name was Plex The Ripper, not Jack The Ripper

EAC and CDex's handling cache

Reply #11 –
> One question ... is the read command "MMC-1" (In EAC terminology)
> one of the 5 read modes you mentioned ?

No, MMC-1 in EAC corresponds to READ_CD (0xBE) command.

> Anyway, I posted something on the EAC board, referring to your
> statements about the FUA bit and cache handling during DAE ...
> maybe (and hopefully) Andre will make a statement about that issue.

See my point about open-mindedness ?  Once again when his code is
questioned Andre gets offended, posts parts of his resume (?) and
just breaks the discussion. Well, I just wish the best to his future
colleagues the day he gets a job and starts working on a project in
a team

More seriously, regarding FUA : it's nice to get 5 years old emails,
but what's the point ? To show that in 1998 implementations of the
FUA bit were broken ? It could very well be the case, but if most
modern drives correctly support FUA, it seems fair to me to say that
this feature is lacking in EAC. And since Andre avoided this part
of your question, I'll say it again : a good hint that modern drives
correctly support FUA bit is that Plextools uses it.

EAC and CDex's handling cache

Reply #12 –
I rip a lot of scratched CD's & I have had some random CRC mismatches in EAC the problem with Plextools is it doesn't have the test & copy feature as EAC so it's hard to know if the Plextools algorithm failed in general ripping.

EAC and CDex's handling cache

Reply #13 –
Quote
I'll say it again : a good hint that modern drives correctly support FUA bit is that Plextools uses it.

Hrm... that's actually a good hint the Plextor drives support FUA bit, since Plextools was specifically written for Plextor drives.

EAC and CDex's handling cache

Reply #14 –
Quote
No, MMC-1 in EAC corresponds to READ_CD (0xBE) command.

Well, I just wish the best to his future
colleagues the day he gets a job and starts working on a project in
a team

Hi spath,

Does that mean that the FUA bit is not fully implemented into READ_CD ? I'm asking because (roundabout) with 95% of all ATAPI drives using READ_CD and again 95% of all ATAPI CDRW drives using their internal buffer during DAE, things might get a little complicated when it comes to drive cache questions ...

And be assured, I was a student at at german university not too long ago ... you won't get anywhere near a successful end with being some "lone ranger" ...
The name was Plex The Ripper, not Jack The Ripper

EAC and CDex's handling cache

Reply #15 –
Quote
Indeed, according to the author cdparanoia implements similar
tricks as EAC to avoid multiple reads from the cache, see
http://groups.google.com/groups?hl=en&lr=&...dfellow.MIT.EDU
I've not reviewed this part of code so I don't know how well
it works.

You haven't reviewed the code, but does the method Monty describes (backtracking 32 sectors/read-ahead 150 sectors) seem sufficient to you on current drives ? I don't know enough about the subject, so I'd like someone more knowledgeable to confirm this.

Quote
Regarding CDEX, I have never used it and and I don't know what's
in its code, so for now I assume it's not the same program as
cdparanoia and I will not try to explain any behaviour it might
show.

Interesting assumption. I always thought it would simply contain the latest cdparanoia library, so I assumed any test results from CDEx would probably also apply to other implementations of cdparanoia. But I don't think this has been verified.

It would be valuable if somebody could repeat the tests from Pio2001 and Case on another cdparanoia implementation (maybe simply using the standalone cdparanoia binary in Linux?).

If the results are similar to Pio2001's results, then it would strongly suggest a flaw in the algorithm cdparanoia uses.

If the results are different (i.e. it turns out to be more reliable than CDEx), then the CDEx developers should have a look at it. Maybe they're not using the latest library (although this seems improbable to me), or maybe they're not using it correctly. Since CDEx is used quite widely (AFAIK) fixing this would benefit many people.
Over thinking, over analyzing separates the body from the mind.

EAC and CDex's handling cache

Reply #16 –
@JeanLuc :

> Does that mean that the FUA bit is not fully implemented into READ_CD ?
> I'm asking because (roundabout) with 95% of all ATAPI drives using READ_CD
> and again 95% of all ATAPI CDRW drives using their internal buffer during
> DAE, things might get a little complicated when it comes to drive cache
> questions ...

As described in the MMC spec (http://www.t10.org/ftp/t10/drafts/mmc4/mmc4r02f.pdf),
READ_CD does not allow any FUA bit at all, so if this reading method is chosen then
flushing tricks are needed. However, other MMC commands like READ10 (0x28) and
READ12 (0xA8) support the FUA bit.


@PoisonDan :

> You haven't reviewed the code, but does the method Monty describes (backtracking
> 32 sectors/read-ahead 150 sectors) seem sufficient to you on current drives ?

It should work, although I think EAC's method is more secure.

> Interesting assumption. I always thought it would simply contain the latest
> cdparanoia library, so I assumed any test results from CDEx would probably
> also apply to other implementations of cdparanoia. But I don't think this
> has been verified.

Just had a quick look at CDEX 1.40 source code and it seems that the FUA
handling part has disappeared when the interface layer has been rewritten
(now AspiCD.cpp). Can a CDEX developer confirm this ? Have the original
cdpranoia cache flushing tricks also been modified/removed ?

EAC and CDex's handling cache

Reply #17 –
> Can a CDEX developer confirm this ? Have the original
> cdpranoia cache flushing tricks also been modified/removed ?

rjamorin, now is the perfect time to post something starting with
"I was a CDex developer, I should know "...

EAC and CDex's handling cache

Reply #18 –
After having tested three methods to set the FUA bit without success, Andre Wiethoff is going to test Plextool's way of clearing cache ( http://www.digital-inn.de/showthread.php?t...33&page=2&pp=15 )

He needs experts in DAE to test his new routines. People who are interested are welcome to send him a mail (see his website, or use the EAC forum's "send mail" option).

Quote
>So everybody who want to participate, please send me a private mail (only expert users, please!)

EAC and CDex's handling cache

Reply #19 –
> After having tested three methods to set the FUA bit without success,
> Andre Wiethoff is going to test Plextool's way of clearing cache

And of course he doesn't mention which drive or plextools version he
tried, or what this 'Plextools way' would be  Anyway Plextools Pro 2.08
indeed uses the FUA bit on my Plex2410, but not in any of the 3 methods
he tried. So Plextor owners should stick to Plextools for optimal cache
handling.

Regarding CDEX and cdparanoia, they don't use the same recovery and
cache handling methods and contrary to cdparanoia, CDEX shows no sign
of FUA bit handling. So when testing CDEX and cdparanoia should not be
considered as two equivalent rippers.