1 Topic by matura713

(4 replies, posted in General discussion)

hi All, I was planning to write this guide, because as a newbie here, i.e. "late to the party", I have faced significant challenges to find working (or at least usable) Plextor in this 2nd half of 2021 - everything on reasonable price is basically with broken laser and it needs repair.

So, while, my guide is not ready yet (I am still testing, experimenting some aspects of the information I am planning to post here), I decided to announce it in advance due to some very recent changes in the Wiki that were made in the last days:

http://wiki.redump.org/index.php?title= … patibility

marking most Plextor drives as "Not recommended, drive is known for having its laser die quickly". That statement is something I disagree with it as it's telling even less than half of the story.

First of all, I made similar comment for the Plextors using Sanyo OPUs here:

http://forum.redump.org/post/95449/#p95449

That I will not attribute to Plextor alone, but to Sanyo OPUs they used, e.g. DB10 in PX708/712 and DS10 in PX755/766. Those were used in NEC drives as well and I have literally pile of NEC drives next to me with dead DB10/DS10 OPUs, exactly like the Plextor.

but what is most important is that those Sanyo OPUs are cheap and abundant - including instead risking and buying Chinese fake, you can take them out of a "donor drive" made by other brands like the NECs, I mentioned above. So, why don't recommend a drive that is having really life-time supply of spare lasers?!

Second, as far as PX-716 is concerned - my dead ones, are really, really low-hour, according to the usage counters that QpxTool shows in Linux. My PX-716 that is working fine is the most heavily used Plextor drive in the past that I own - again, based on QpxTool usage counters and yet it's still working contrary to recommended PX-760, according to the Wiki, which Sanyo laser died in my case for less than 10 time the usage of my working PX-716. Not to mention that PX-716 are cheap, i.e. at least I bought working one cheaper than the cost of replacing the laser in PX-760. So, it seems to me there are batches of PX-716 that die fast, but when they die it's at the very beginning of their life. Also, best about PX-716 is that they don't use Sanyo DB10/DS10 OPUs. Based on my personal experience if PX-716 has many hours of use and its laser is still fine - it will not die and last much longer than any of the other Plextor DVD drive using Sanyo DB10/DS10 OPUs.

So, the above is just few of my point, why I really disagree with the statements made in the Wiki in the last days, as just too general and not even touching the surface of the issue. So, to be continued... I will edit this post with my laser replacement guide, when I am fully ready... BTW, I already posted some small information about laser replacements here:

http://forum.redump.org/post/95373/#p95373

where I installed laser from PX-708A to PX-712 and repair it that way, which has its benefits, but it's the least interesting replacement option, because someone would argue, PX-708 could cost more than working PX-712. Anyway, stay tuned...

Go to forum: General discussion

2 Reply by matura713

(24 replies, posted in General discussion)

a little lucky break with analysis of "CDS200 V4 0.4.4.0.build10b" disc, I found I have later re-release without any protection, but at first glance the data in the tracks were fundamentally different. however, using what I mentioned above that "Plextor PX-5424, was able to read Track05 entirely properly", I found out that the re-release just uses offset of 2472 bytes - enough to make the data look totally different for a naked eye. That finding allowed me to code small tool (a little like what CueTools is doing) that recovers the errors in all tracks from my Plextor PX-5424 dump and reports the number of errors:

track01: 30 wrong bytes
track02: 14 wrong bytes
track03:   4 wrong bytes
track04: 33 wrong bytes
track05:   0 wrong bytes!!
.....................

Doing the same with LG GGW-H20L and NEC ND-3530A gives wrong bytes in thousands.

So, PX-5224 is pretty close to error-free. That's why I am quite confident 20 years ago when the disc has no any aging and the same for PX-5224 it was possible for PX-5224 to do it fully without problems. In any way "CDS200 V4 0.4.4.0.build10b" is different enough from "CDS200.5.11.90 5.10.090" to cause major issues for drives that can do "CDS200.5.11.90 5.10.090" without problems.

Go to forum: General discussion

3 Reply by matura713

(24 replies, posted in General discussion)

bad news again: while "CDS200.5.11.90 5.10.090" is really solved by LG GGW-H20L - extraordinary reliability and performance on reading such discs, I cannot read a single track properly with the drive on "CDS200 V4 0.4.4.0.build10b". It looks like each CDS200 revision is beast of its own and it's a myth that the older it gets the easier to read. The disc I am testing is own by me - I cannot see a single starch on it. Maybe, at play now, is what I was thinking and mentioning in my previous posts - disc aging, because newer the Cactus revision, newer the disc, i.e. this "CDS200 V4 0.4.4.0.build10b" one is 3-4 years older. So, NEC ND-3530A cannot do a single track properly on it - at least it can read all the tracks, which majority of drives cannot do. Plextor PX-5424, was able to read Track05 entirely properly, but that's only 1 track out of 12. So, Cactus is really evil and a nightmare. I guess really nothing better to use than Cactus discs to assess a drive performance on CDs and its C1/C2 error correction capabilities. So, I have a feeling LG GGW-H20L will be OK with all CDS200 V5 discs, but for V4 currently I don't see a solution. I don't have CDS200 V3 discs and I cannot test on that major revision, but I soon I will tests CDS100 - I expects it is absolutely the hardest, because it was immediately abandoned, because of that and that virtually nothing can read it....we will see...

[EDIT] one very interesting "feature" of "CDS200 V4 0.4.4.0.build10b" is that drives like LG GGW-H20L and NEC ND-3530A always read the same Track with the same Hash - that leads to believe it was properly read and even databases like AccurateRip are "infected" with wrong hashes, because of that. it's a stark difference with "CDS200.5.11.90 5.10.090" when you can get 2 times the same hash only when the track is read properly. So, it's like "CDS200 V4 0.4.4.0.build10b" is corrupted in a way that is harder to properly error-correct, but at the same time, more often error correct attempt results in the same (wrong) data and hence more often you get the 2 times the same hash even the track is not read (entirely) properly.

[EDIT2] I further analyze manually in a hex-editor, for example on Track01 of  "CDS200 V4 0.4.4.0.build10b" disc, PX-5224 made number of errors that you can count even manually, i.e. they were less than 30 bytes for the whole track, but LG GGW-H20L made thousands of wrong bytes, even it fools you the track is read properly giving everytime the same "Test CRC" in ExactAudioCopy - that is AccurateRip (and CueTools) database were "infected" with wrong data for the tracks on those Cactus CDs.

Go to forum: General discussion

4 Reply by matura713

(24 replies, posted in General discussion)

we have a winner and that is LG GGW-H20L, my gut feeling was correct:

http://forum.redump.org/post/95536/#p95536

that installing it to my system somehow messed up my ExactAudioCopy installation - after full uninstall and install of ExactAudioCopy LG GGW-H20L not only works with my "CDS200.5.11.90 5.10.090" test CD, but it made PX-5224 to look stupid, because it reached speed of 39X on the last track and average of 30X for the whole CD - absolutely mind-blowing performance. And on that speed it achieved perfect copy, because it has LeadOut capability as well.

LG GGW-H20L is HD-DVD drive and that format was very short-lived. So, I wonder, it demonstrates such unbelievable performance, because its laser is in like new condition or the laser they use in that HD-DVD drive is that good. After all modern and brand new Asus BW-16D1HT is pathetic on the same CD - about 0.3X read speed and it cannot do a single track.

I don't know, but at least for "CDS200.5.11.90 5.10.090", there is nothing that can even come close to LG GGW-H20L!

Go to forum: General discussion

5 Reply by matura713

(24 replies, posted in General discussion)

PX-755A is not working either - same behavior as PX-716A. so, it's obvious now what to expect from PX-760A....

Go to forum: General discussion

6 Reply by matura713

(3,497 replies, posted in General discussion)

sarami wrote:

Do you have any video game discs?

I understand and so the case is closed. I do have and I submitted some dumps:

http://forum.redump.org/topic/39914/xbo … s-revenge/
http://forum.redump.org/topic/39912/xbo … spiderman/
http://forum.redump.org/topic/39911/xbo … iderman-2/
http://forum.redump.org/topic/39909/xbo … n-legends/
http://forum.redump.org/topic/39311/xbo … deception/

for verification, because I still haven't found something that I have and it's not already in the database.

Go to forum: General discussion

7 Reply by matura713

(24 replies, posted in General discussion)

PX-716A is not working either - in fact I see no any difference in its behavior and performance compared to my previous tests with PX-712A. if I didn't know it's 716, I would think it's 712.

So, currently, PX-708, 712 and 716 confirmed - as not capable to deal with Cactus.

Only 2 are left: 755 and 760. I already bought cheap 755 and it's on its way to me - I hope it has working, laser because otherwise the test will take more time until I find spare laser for it.

Go to forum: General discussion

8 Reply by matura713

(24 replies, posted in General discussion)

Another not working drive:

* LG GGW-H20L

and this one is really bad - with it, even ExactAudioCopy cannot see the Audio Tracks, let alone try to copy it. So, this is worst drive of all tested so far!

[EDIT] I need to investigate further, because ExactAudioCopy now even stopped to work with Plextor. Maybe, something messed up in my installation...

Go to forum: General discussion

9 Reply by matura713

(3,497 replies, posted in General discussion)

sarami wrote:

No...
Btw, what title do you want to dump?

I have several titles with Cactus, released in 2001 to 2004 period. The one I posted 2 posts ago, that is using "CDS200.5.11.90 5.10.090" has barcode 724386620323. I used that for all tests here:

http://forum.redump.org/topic/39497/i-a … ted-discs/

because it's using one of the latest CDS200 revisions and thus is hardest for a drive to read. BTW, CDS300 has nothing to do with CDS200 and CDS100, as I pointed out here:

http://forum.redump.org/post/95412/#p95412

So, CDS300 is no problem, the issue at hand are CDS100 and CDS200.

[EDIT] for barcode 724386620323: attaching screenshot of the correct CRC hashes for each track - only possible to get with PX-5224 and NEC ND-3530A, but of course the NEC cannot do the last track with the same checksum, because it has no LeadOut capabilities.
[EDIT2] one correlation that starts to emerge is that all NECs and all Plextors that don't work use Sanyo DB-10 and DS-11 Optical pickups (OPU). ND-3530A is the only one in the whole 35xx and 45xx series that uses Sony OPU, in fact that is consistent with my PS3 BD drive test - another Sony OPU and both drives work. PX-5224 is neither Sony OPU, nor Sanyo, but the point is that it's not with Sanyo.

Go to forum: General discussion

10 Reply by matura713

(3 replies, posted in General discussion)

scsi_wuzzy wrote:

$20 (including shipping)

I've just checked and shipping from my location to NA is over $20. yeah, it's not feasible to buy from EU.

Go to forum: General discussion

11 Reply by matura713

(3,497 replies, posted in General discussion)

sarami wrote:

Why are you particular about using DIC?

What is ReDump standard for dumping Cactus CDs? If I use IsoBuster then if ReDump will accept my dump information? How is supposed to dump Cactus CDs compatible with ReDump standards based on available hardware software and their respective limitations? that's what I don't get. sorry, I am newbie here and maybe I am missing some point... thank you!

Go to forum: General discussion

12 Reply by matura713

(33 replies, posted in General discussion)

scsi_wuzzy wrote:

the FW 3.02 on my BW-16D1HT (the one recommended by the Wiki). Sarami is using 3.10. It seems unlikely this explains the different behavior, right? I feel it's more likely the disc, but we are running different FW revisions

I don't know, if you know, but it's now possible to go from 3.02 to 3.10 and back safely - before it was very hard (and risky) to downgrade as the downgrade is not allowed with those drives, because of their UHD/BD support - it requires manual patching of the firmware and easy to brick the drive. So, the new way for downgrade is a lot like PS3 downgrade, if you're familiar with PS3 HFW (Hybrid Firmware) downgrade procedure. It has additional advantage that contrary to the previous methods, this one keeps the individual calibration data of your particular drive - it's done entirely in software. So, from your 3.02 you can update to 3.10, then to go back, you need to flash it to another firmware 3.10DE, i.e. 3.10 Downgrade-Enabled firmware and then flash it to 3.02. I can give you better details, but I did it over few months ago and I am searching for my notes - I recall write down small txt file for myself...

[EDIT] I cannot find the notes I had in mind, but found another notes that say:

1. Update BW-16D1HT FW3.02 to 3.10 using the official updater
2. then if you what to go back to 3.02
2.1. use "ASUS_ODD_FW_Changer_(Modified) (24.08.2019)" and update with file "ASUS-BW-16D1HT-3.10-WM01601-211901041014.bin", that enables 3.10 drive to be downgraded
2.2. use again "ASUS_ODD_FW_Changer_(Modified) (24.08.2019)" with "DE_ASUS_BW-16D1HT_3.02.bin" to update it

I am giving those just as clues, maybe there are now newer vesions of the above files and they are no longer the latest.

[EDIT2] I found the note I made to myself 4 months ago, literally it says:

3.10 can be flashed to 3.10MK for downgrade
3.10MK can be flashed with any DE firmware.

So, it seems it works a little like PS3 HFW:

OFW --> HFW
HFW --> Downgrade

In my maybe:

3.10 --> 3.10MK
3.10MK --> 3.02DE

Also, that note is my "ASUS_ODD_FW_Changer_(Modified) (24.08.2019)" and so that tool was used. I think "MK" comes from Mike the guy that make 3.10 downgrade firmware and "DE" is stands for Downgrade-Enabler or something like that...So, yeah, it seems the files in my other note match perfectly this one.

Go to forum: General discussion

13 Reply by matura713

(3,497 replies, posted in General discussion)

sarami wrote:

See https://github.com/saramibreak/DiscImag … /issues/41

yes, I understand, why Multi-Session support was removed with Plextor CD drives in the General case, but why remove it in case of Cactus protected CD, when the only confirmed Plextor drive (so far) that can do it is PX-5224? just ignore the 2nd session do not dump it - it's garbage data. It's very easy to detect, at least Cactus CDS200 V5, please, read my details below:

Maybe my main point was missed in the conversation - the 2nd session is just there as part of the protection, i.e. to even further confuse the drive on top of the C1/C2 errors pressed on the discs at the factory.

So, the 2nd session is additional lawyer of protection similar to how Key2Audio protection uses fake sessions, etc. Isn't then the logical thing to do - check for Cactus and if yes then ignore the 2nd session and dump only of the 1st session (if necessary, I am not familiar and knowledgeable about image formats, fix the dumped image to indicate only one session or if that's hard, not possible or not preferred, fill with 0x55 or 0x00 or something like that for all data in the 2nd session - do not care to read that garbage from the disc).

* How to detect Cactus:

- at least Cactus V5 is ultra simple to detect, because there is file:

"F:\player\version.txt"

that in case of the latest revision (at least known to me, it's also the hardest protection for a drive to overcome) and on which I am testing contains:

CDS200.5.11.90
5.10.090

What do you all think about the following ReDump/DiscImageCreator Standard for Cactus discs:

* add check to DiscImageCreator about "\player\version.txt" file on the CD, if it's there, read and report the Cactus version back to the user, in such case allow use of PX-5224 (even better inform the user he/she needs PX-5224 and quit otherwise). Dump only the 1st session, discard the 2nd session as it's just garbage data. Preferably, even add command line-switch to DiscImageCreator for the user to select it's Cactus disc manually, if for some reason the Cactus cannot be detected - I am suggesting such option, because on some discs both "A-Ray Scanner" and "ClonyXXL" tools fail to detect the Cactus, because there is no "\player\version.txt" file, which is very rare case (I have only one such CD). You can see all Cactus versions I listed in a table here:

http://forum.redump.org/topic/40001/int … otections/

BTW, Sony seems to do exactly what I am suggesting above in the firmware of their PS3 BD Drive - I tested it today connected to PC - for Cactus disc it doesn't even need authentication to read it, but it hides the 2nd session makes the disc look as single session to the computer. Also, interesting fact that I found - it seems Sony process the Cactus disc entirely in PS3 BD firmware, because the drive rips all tracks correctly, but with +2305 offset, no matter what offset is set in ExactAudioCopy. So, PS3 BD drive also is capable to fully overcome Cactus like PX-5224, but it seems in a different way - hides the 2nd session and adds that weird +2305 sample offset to each track. However, PS3 BD drive is amazing - rips Cactus 2 times faster than PX-5224 without any single error - all bytes are correct - compared in Hex-editor, just  that 2305 samples offset is added to the beginning of each track. So, PS3 BD C1/C2 error correction is out of this world - to fix 8000 such errors on such high read speed - I tested over 30 other drives on Cactus so far and PS3 BD drive blows my mind (KEM-450 drive from a slim console), really unbelievable and amazing! Especially, when drives like Asus  BW-16D1HT fail so spectacularly on Cactus disc and go to 0.3X speed, struggling and struggling.

[EDIT] even in cases when  both "A-Ray Scanner" and "ClonyXXL" tools fail to detect the Cactus, it's still very easy to detect it, because there is "CACTUSPJ.EXE" file in those cases. So, based on that I guess the correct detection algorithm (at least for the time being) is: check for "player\version.txt" file and if there is proper "CDS200" string  inside it with version report it, if no then check for  "CACTUSPJ.EXE" and report some unknown exact version of CDS200 V3/V4 detected. I have no V5 discs without "player\version.txt". So, those without it are CDS200 V3/V4 for sure, they are also released 2-3 years before discs with CDS200 V5.

Go to forum: General discussion

14 Reply by matura713

(3,497 replies, posted in General discussion)

bikerspade wrote:

I own at least three audio CDs where dumping with my BW-16D1HT and the /mr flag is always unable to proceed with dumping the disc (Cache is short), even with 999 retries.

you're not alone:

http://forum.redump.org/post/95220/#p95220
http://forum.redump.org/post/95227/#p95227

I guess it's just  BW-16D1HT limitation and nothing can be done in software, i.e. in DiscImageCreator.

Go to forum: General discussion

15 Reply by matura713

(24 replies, posted in General discussion)

scsi_wuzzy wrote:

Having since acquired some Plextor equipment, I feel like it's....not that great.(It was essentially tied with another Plextor drive, the PX-W4824A, for last place.)

I totally agree with you and I am one miserable original owner of PX-W4824A - in fact it's the only Plextor that I purchased until few weeks ago when I joined here. It stayed for 20 years in the drawer, because was total disappointment. So, at least those 2nd hand Plextors I bought recently for testing purposes, they were all sold as faulty (and were in fact faulty, except 708A I bought), etc and that's why sold cheap, not like my PX-W4824A, which buying it as new cost me a lot of money.

scsi_wuzzy wrote:

the same review acknowledges the Plextor as a good audio reader. In fact, the review claims that the Premium can read CDS200-protected discs. However, I'm not sure they actually test such a disc in the review.

I don't believe it, those reviews are all fake - I mean I already proved that cannot be for 4 reviews:

* NEC ND-4550A: https://www.cdrinfo.com/d7/content/nec-nd-4550a?page=4
* PX-708A: https://www.cdrinfo.com/d7/content/plex … 08a?page=6
* PX-712A: https://www.cdrinfo.com/d7/content/plex … 12a?page=5

and my favorite fake review of:

* AOpen CRW2440A:

https://www.cdrinfo.com/Sections/Review … cleId=5095

because they praised it as most capable to read Cactus (it failed only on 2 tracks on the disc) from a long list of drives including Plextors and Yamahas of that time. So, all those reviews are fake, there is really no other explanation.


scsi_wuzzy wrote:

it sounds like PX-716s were dropping dead shortly after they were made too.

That I will not attribute to Plextor alone, but to Sanyo OPUs they used, e.g. DB10 in PX708/712 and DS10 in PX755/766. Those were used in NEC drives as well and I have literally pile of NEC drives next to me with dead DB10/DS10 OPUs, exactly like the Plextor. the OPU in PX-716 is the only one that no one was able to identify, but I guess is again some re-branded Sanyo.

scsi_wuzzy wrote:

Anyway, my apologies that this rant isn't directly on topic...

actually, it's all on topic from my perspective. And speaking about things not directly on topic and ranting, I want to say that I understand I am new here, but I am already very confused by some of the directions taken by the community here and lack of common standard, when exactly otherwise is claimed. So, for example, when make DiscImageCreator dump of Wii disc - it's decrypted, i.e. all protections are stripped down and thus the dumped image is not anything close to the source, i.e. it's not byte-by-byte identical to the source data - it couldn't be even, the source and the dump data, to be more different, in fact. However, at the same time, when Cactus disc is dumped, not only its 2nd session is not stripped (which is only there as part of the protection), but DiscImageCreator even refused to start dumping with capable PX-5224 drive, because of that 2nd session instead remove it:

http://forum.redump.org/post/95385/#p95385

So, where is the common standard?! I mean, if that is the standard for Cactus discs, then why not leave the Wii image encrypted and that way list it in the ReDump database? So, if we use the DiscImageCreator own standard for making Wii dumps, i.e. strip its protections, then what make sense is to do the same for Cactus 2nd session - ignore it and do not dump it, because it's garbage data - everything on the disc is in the 1st session. Anyway...

scsi_wuzzy wrote:

I think I might hunt around some at a local shop and see if I can spot any CDS discs.

IMHO, it's very good to have, especially if you find one that is with no any heavy scratches, i.e. even more C2 errors and using Cactus from 2003/2004, i.e. with latest heaviest versions. So, it's excellent for testing real drive performance for correcting errors, because it has like 5000-8000 C2 errors pressed at factory as part of the protection. So, it really gives you idea about the drive performance like nothing else.

reentrant wrote:

True. All my Plextors: 2x760, 716, 4012 are not that great at reading scratched discs. Other drives perform much better.

Cactus protection is like scratches on steroids, I mean I haven't seen yet, a scratched CD that can go into thousands of C2 errors...

Go to forum: General discussion

16 Topic by matura713

(0 replies, posted in General discussion)

While researching Cactus copy protection, more specifically CDS200 (Cactus Data Shield 200):

http://forum.redump.org/topic/39497/i-a … ted-discs/

I read there are 7 major revisions of it. So, I started building a list based on what I can find on the web and looking the files on my own CDs, at the end my list looked like:

CDS200.0.4 3.0 build 12b
CDS200.0.4 3.0 build 16a
CDS200.0.4 4.0 build 10b

5.00.151
5.00.160
5.10.090
5.11.090

However, searching further on the web, I stubble upon document in German (it's not free, but Google Cache can open it) that is specifications for a car CD-player - I presume maybe for one of the big German car makers, where they provided long list of CD Audio Copy protections that the car CD-drive has to be capable to play. So, here is that list:

Key2AudioXS V1, Sony DADC
Key2AudioXS V2, Sony DADC
Key2AudioXS V3, Sony DADC

Cactus Data Shield CDS-100, Macrovision

Cactus Data Shield CDS-200 V3 0.4.3.0.build16a, Macrovision
Cactus Data Shield CDS-200 V3 0.4.3.0.build16c, Macrovision
Cactus Data Shield CDS-200 V4 0.4.4.0.build10b, Macrovision
Cactus Data Shield CDS-200 V5 5.0.150 5.00.160, Macrovision
Cactus Data Shield CDS-200 V5 5.0.151 5.00.160, Macrovision
Cactus Data Shield CDS-200 V5.1 5.1.90 5.10.090, Macrovision
Cactus Data Shield CDS-200 V5.1 5.1.91 5.10.090, Macrovision

Cactus Data Shield CDS-300, Macrovision

Extended Copy Protection (XCP) 1.9
Doc.loc V1
Doc.loc V2
Doc.loc V2
Copy-x, Optimal Media
MediaMax, SunnCom
Alpha Audio S-Type, Settec
Alpha Audio M-Type, Settec

So, some of the protections I've never heard, other like Key2Audio V1, I don't even know they existed and BTW they call Key2Audio "Key2AudioXS" (which I guess is the correct name, just we outsiders didn't know). I only have discs with Key2Audio V2 and V3 - I thought V1 was something like internal release and never used.

if you wonder, Macrovision acquired Cactus, that's why they are listed as the company that makes the CDS protection.

Also, I think they have some typos in the table, I mean why they have entries like "5.1.90 5.10.090" and "5.1.91 5.10.090" and later in the document they listed "5.11.90", which matches an entry in the table I build using my own discs and web searches.

So, that's why I think from V5 series of CDS200, there are actually 5.00.150, 5.00.151, 5.00.160, 5.10.090 and 5.11.090 (which they mistype as "5.1.91" in their table).

Another oddity is that they missed "CDS200.0.4 3.0 build 12b", which is popular on commercial discs, but they have "V3 0.4.3.0.build16c" that is totally missing from my list and I've never seen anywhere else except in their table. So, I think neither mine, nor their list is perfect and free of mistakes, but it gives an idea. In fact if we join mine and their list and assume the information there are 7 revisions of CDS200 is true, I believe the real list for CDS200 has to be:

V3 0.4 3.0.build12b
V3 0.4.3.0.build16a

V4 0.4.4.0.build10b

V5 5.00.150
V5 5.00.151
V5 5.00.160
V5 5.10.090
V5 5.11.090

Go to forum: General discussion

17 Reply by matura713

(24 replies, posted in General discussion)

Wow, I've just spotted album from 2003 reissued in 2008 and the reissued disc in 2008 still has the Cactus logo on it - that is really unbelievable, because I was thinking by 2005 no more such discs were made, because I have album from 2004 (and that is using the latest revision of Cactus, at least the latest one that I know of, who knows what is the wild), which when was reissued in 2005 they dropped the protection, i.e. only 1 year later, but this one 5 years later reissued and still with Cactus. Now, I wonder do they use the same revision of Cactus or 5 years later use even newer and harder revision of the protection? I guess with second hand prices like 1-2 bucks shipped, that's an easy thing to answer, i.e. if they use same revision, but unfortunately, if the disc is scratched we cannot judge if a drive can rip it or not with that particular Cactus revision and make a conclusion... it's still interesting if in 2008 they still used the same Cactus revision from 2003, though.

[EDIT]
OK, it seems some re-branding was going on around 2005-2006, after Macromedia acquired Cactus. So, CDS300 has nothing to do with CDS200, but they continued to use same/similar logo and it's just using fake TOC and session to confuse the CD drive, but not C1/C2 errors like the previous very hard and evil CDS200 and CDS100. Basically, CDS300 is from technical point of view completely unrelated to CDS100 and CDS200. Now, from what I read, CDS100 could be even more secure than CDS200, because reportedly after first revision of CDS100 it was abandoned due to even home and car equipment refusing to play the CD. I know only one CDS100 disc - if I find and buy it, then I will test and tell more. Anyway, allegedly there is one revision of CDS100 and 7 revision of CDS200 - last CDS200 ones are 5.10.90 and 5.11.90. My test CD, based on which all above posts are made is 5.10.90 and that is the, again allegedly, the strongest among CDS200 - in 5.11.90 they supposed to relax it a little bit again to avoid too many home and car equipment completely not working. I cannot confirmed any of those statements right now, just making summary of my research so far. BTW, I made another post about list of some Audio CD copy protections with some Cactus information there as well:

http://forum.redump.org/topic/40001/int … otections/

in any way, as far as I can tell from forum posts all over the web and all over the years, people seems happy when they were able to read the disc and think that they cannot get perfect copy anyway - something that I proved is wrong - PX-5224 and NEC ND-3530A can get perfect copies, i.e. tracks are byte by byte identical with later re-releases of some of those Cactus CDs without or with weaker protections. So, I am glad my efforts so far, were not pointless, but bring new information and results.

Go to forum: General discussion

18 Reply by matura713

(3,497 replies, posted in General discussion)

Unfortunately, today I am really out of any luck and I came across another problem - this time with Key2Audio protection. So, here are my steps to confirm something is not right:

1. Rip the disc with ExactAudioCopy using physical Plextor DVD drive
2. Dump the disc with DiscImageCreator using physical Plextor DVD drive
3. load the image from step2 in virtual drive
4. Rip the disc with ExactAudioCopy using the virtual drive with DiscImageCreator image in it from step3

So, with all other discs ExactAudioCopy "TestCRC" Hashes match those from step1 and step4, i.e. ripping from the DiscImageCreator image in virtual drive is absolutely equivalent to ripping from the original physical media.

However, with my Key2Audio protected CD, ExactAudioCopy "TestCRC" Hashes from step1 and step4 are different. It's open question to me if ExactAudioCopy is correct or DiscImageCreator is correct, but it's the very first time I see difference between the the 2 applications and one of them must be wrong...

[EDIT] Decided to try with my Asus BW-16D1HT drive, this time:

* DiscImageCreator completely failed:

[INFO] This disc is Multi-Session. /ms is set.
Checking SubRtoW (Track) 18/18
Set OpCode: 0xbe, SubCode: 1(Raw)
Checking SubQ ctl (Track) 18/18
LBA[000001, 0x00001]: [F:ProcessReadCD][L:318]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
LBA[000001, 0x00001]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
End of readable sector

then it stop accessing the disc, creating for several minutes ".scmtmp" file, then more errors:

LBA[337562, 0x5269a]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337563, 0x5269b]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337564, 0x5269c]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337565, 0x5269d]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337566, 0x5269e]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337567, 0x5269f]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337568, 0x526a0]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337569, 0x526a1]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[337570, 0x526a2]: [F:ProcessReadCD][L:288]
        Opcode: 0xbe

and at the end it reported something about "failed to analyze subchannel" - sorry but by accident I deleted the log, but bottom line is no any image was produced. I am even lost, which logs are beneficial to provide.

At the same time Asus BW-16D1HT with ExactAudioCopy produces the same Track hashes as Plextor with ExactAudioCopy. So, on this Key2Audio disc both Asus BW-16D1HT and Plextor PX-712A produce the exact same rips using ExactAudioCopy, i.e. the 2 drives are equivalent there.

[EDIT2] looking in hex-editor the differences, it seems some chunks of data are positioned at different addresses, for example on the attached screenshot what EAC put at 0x1ffffd0, DIC put at 0x2000000...

Go to forum: General discussion

19 Reply by matura713

(3,497 replies, posted in General discussion)

@sarami

just to let you know that "px_d8" from the links here:

http://wiki.redump.org/index.php?title= … isc._Tools

more specifically this one:

http://www.mediafire.com/file/khnzcxdae … 8.zip/file

works with my Yamaha CDR200t drive, i.e. it returns the exact same data for each LBA read on Plextor and Yamaha CDR200t on the same disc. yet, as I reported, it fails with DiscImageCreator:

http://forum.redump.org/post/94975/#p94975

So, I don't know exactly why it fails, but it seems to me Yamaha D8 is fully compatible with Plextor D8 command, if "px_d8" works with my Yamaha CDR200t.

[EDIT] or maybe it's because Yamaha CDR200t is doing just main plus sub-channel and not main plus sub-channel plus c2?

Go to forum: General discussion

20 Reply by matura713

(3,497 replies, posted in General discussion)

superg wrote:

Did you try to dump with /sf?

thanks, I did try it, "DiscImageCreator.exe cd f AUDIOCD 8 /sf /c2 /d8" - no difference, except this time DiscImageCreator says it cannot detect the protection and will ignore the "/sf" switch. it proceeds from there with no any difference

Go to forum: General discussion

21 Reply by matura713

(3,497 replies, posted in General discussion)

sarami wrote:

Yes. I think it's impossible to get the consistent hash. If the disc you want to dump is released as CDDA, I recommend you get it.

PX-5224 is capable to bypass the protection - I definitively proved that, if you read all the details in my other thread - exactly, because 1 of my CDS200 discs, I own re-issued release of it without a protection, i.e. release of it as CDDA disc and that is how I know the correct hash of each track. So, that allowed me to prove PX-5224, not only can read CDS200 discs, but read the tracks from them with 100% correct hashes and no any C2 errors. Plextor DVD drives at the same time are terrible to correct such errors.

So, the issue is on CDS200 discs 'DiscImageCreator' says to me "Plextor CD drives are not supported for Multi-Session discs" (or something like that, I don't recall the exact error message), that's why I cannot dump it with PX-5224 and with Plextor DVD drives (at least 708 and 712) it's all thousands of errors.

What makes sense to me is some "combination" of PX-5224 (for all data in the 1st session) and PX-712 for the 2nd session and Multi-Session information.

[EDIT] OK, below are:

* Logs from recent version of DiscImageCreator - it quits with PX-5224, saying "This program doesn't support to dump the multi-session disc by the plextor CD Drive"

* Logs from older version - that shows PX-5224 is capable to read the data properly without any C2 errors (and I confirmed the same with EAC that all track hashes are correct), but it's stuck on the 2nd session.

* And of course the log from my previous post is showing PX-712 making several thousand C2 errors.

So, why not option just to stop DiscImageCreator on 2nd session with  PX-5224 or something like that when CDS200 is in use? Obviously older DiscImageCreator can read the important data on the disc, while newer version of DiscImageCreator refuse to do anything altogether?!

newer DIC version wrote:

DiscImageCreator.exe cd f AudioCD 8 /c2 /d8
AppVersion
        x86, AnsiBuild, 20210701T212154
/c2 val1 was omitted. set [4000]
/c2 val2 was omitted. set [0]
valid extension was omitted. -> set .bin
CurrentDirectory
        G:\dicnew
WorkingPath
         Argument: AudioCD.bin
         FullPath: G:\dicnew\AudioCD.bin
            Drive: G:
        Directory: \dicnew\
         Filename: AudioCD
        Extension: .bin
StartTime: 2021-09-22T17:13:45+0100
Set the drive speed: 1411KB/sec
This drive supports [OpCode: 0xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking reading lead-out -> OK
Checking SubQ adr (Track) 16/16
[INFO] This disc is Multi-Session. /ms is set.
[ERROR] This program doesn't support to dump the multi-session disc by the plextor CD Drive
EndTime: 2021-09-22T17:15:53+0100

older DIC version, all important data read without a single C2 contrary to PX DVD drives with thousands of errors! wrote:

DiscImageCreator.exe cd f AudioCD 8 /c2 /d8
AppVersion
        x86, AnsiBuild, 20201101T114333
/c2 val1 was omitted. set [4000]
/c2 val2 was omitted. set [0]
valid extension was omitted. -> set .bin
CurrentDirectory
        G:\dicold
WorkingPath
         Argument: AudioCD.bin
         FullPath: G:\dicold\AudioCD.bin
            Drive: G:
        Directory: \dicold\
         Filename: AudioCD
        Extension: .bin
StartTime: 2021-09-22T17:18:17+0100
Set the drive speed: 1411KB/sec
This drive supports [OpCode: 0xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking reading lead-out -> OK
Checking SubQ adr (Track) 16/16
[INFO] This disc is Multi-Session. /ms is set.
Checking SubRtoW (Track) 16/16
Reading DirectoryRecord    4/   4
Set OpCode: 0xd8, SubCode: 8(Raw)
Checking SubQ ctl (Track) 16/16
Creating .scm (LBA)   6753/352351 End of readable sector
Creating .scm (LBA) 330755/352351 Lead-in length of 2nd session: 330756
Creating .scm (LBA) 330756/352351 Lead-in length of 2nd session: 330757
..........................

So, I guess, what I am asking is why not check 2nd session contains the useless CDS200 data and in such cases cut the process at LBA 330755 (or 330754, I am not sure what is the correct number) and proceed from there?

Go to forum: General discussion

22 Reply by matura713

(3,497 replies, posted in General discussion)

@sarami

please, advice me - is it possible somehow to do like 2-pass dump with 'DiscImageCreator' for Multi-Session CDs in order to dump them with Plextor CD-drive(more specifically PX-5224) using information about the Multi-Session from a previous dump made with Plextor DVD-drive? Here is what I mean by 2-pass and why I want to do that in more details:

- the discs I mean are CDS200-protected, I posted details here:

http://forum.redump.org/post/95373/#p95373

So, the whole issue is, in their 1st session, they have so many C2 errors pressed at factory as part of the protection that Plextor DVD-drives just cannot handle them, but those DVD drives can handle the Multi-Session part, as well read properly the 2nd session.

What I mean by 2-pass:

1st pass) make dump without "/c2" with  Plextor DVD-drive to get Multi-Session information:

Creating .scm (LBA) 330753/352351 Lead-out length of 1st session: 6750
LBA[330758, 0x50c06]: [F:ProcessReadCD][L:288]
        Opcode: 0xd8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-8d = MEDIUM_ERROR - VENDOR UNIQUE ERROR
End of readable sector
Lead-in length of 2nd session: 4500
Creating .scm (LBA) 335403/352351 Pregap length of 1st track of 2nd session: 150

Creating .scm (LBA) 352351/352351
Copying .scm to .img
Descrambling data sector of img: 335253/335253
Descrambling data sector of img: 352350/352350
Exec ""G:\dic\EccEdc.exe" check "G:\dic\px712cds\AUDIOCD.img""
FILE: G:\dic\px712cds\AUDIOCD.img
Checking sectors: 352350/352350
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC:
4497
Total errors: 4497
Total warnings: 0
Creating cue and ccd (Track) 16/16

2nd pass) provide some of the numbers above from PX-712A dump to 'DiscImageCreator' to make it able to dump at least the 1st session properly, but this time using Plextor PX-5224, which can handle those "C2" errors with no problem. the 2nd session - we don't need it at all - it contains executable of the player - what is needed is perfect 1st session. Now, if based on the above numbers from PX-712A dump, PX-5224 can be made to dump both 2 session - that is a bonus, most important is perfect copy or the 1st session. Or since PX-712A can dump the 2nd session as there is  no protection, i.e. no C2 errors there, as part of the 2nd pass combine it to 1st session dumped with PX-5224.

After all based on the available drives capabilities and what is important on those CDs we need to set some acceptable ReDump standards what proper dump for those CDS200 CD means. Any opinions on that are welcomed.

Go to forum: General discussion

23 Reply by matura713

(24 replies, posted in General discussion)

Bad news - chances for a possibility of 'DiscImageCreator' dumps for Cactus CDs are getting slimmer and slimmer.

So, finally, I found cheap PX-708A and got it - that one contrary to my previous cheap buys of PX-712A and PX-716A is with working laser on CDs - it also has its original laser, i.e. warranty seals is unbroken. Unfortunately, It fails miserably on Cactus:

* PX-708A : really struggles, speed goes down to under 1X, i.e. 0.8X-0.9X, at the end it fails to even rip my test track (if i recall correctly "lost sync" or something like that was the exact EAC error in such case). Performance reminds that of Asus BW-16D1HT, which goes to even slower speeds...

I read in other forum that Laser OPU from PX-708A is compatible with PX-712A and now I personally confirmed that - I took the laser from that PX-708A unit and installed it in my PX-712A unit with broken laser - it immediately came back to live, in fact PX-708A laser in PX-712A is beneficial, because the performance on Cactus CDs of PX-712A (even with PX-708A laser) is much better than PX-708A itself. That shows the laser is not of primary importance. So, to put  PX-712A Cactus performance in few lines:

* PX-712A : it doesn't struggle, reads the tracks with speed 2 to 4 times faster than PX-708A and basically reaches the speed of NEC ND-3530A, but unfortunately all the track hashes are totally wrong, i.e. it just gives the illusion it works fine, but it's not

BTW, another 2 totally fake cdrinfo dot com reviews, because they said, both PX-708A and PX-712A, are "OK" for Cactus:

https://www.cdrinfo.com/d7/content/plex … 08a?page=6

https://www.cdrinfo.com/d7/content/plex … 12a?page=5

I am interested to hear their exact definition of "OK" for CDS200 protected disc! I mean be able to read, doesn't mean what you read is correct. So, what I see from PX-712A: it can read the disc - many of the drives I listed here are not even able to do that, but what it reads it's not 100% correct data, which after all is the goal. PX-708A is much worse than PX-712A in that regards and it's very good comparison as for both I used the exact same laser that came from my PX-708A unit.

Go to forum: General discussion

24 Reply by matura713

(2 replies, posted in General discussion)

actually, i now believe the main reason it will not work is because the Laser optical pickup unit between the 2 drives is very different in any way, PX-4824 is really disappointing drive compared to PX-5224, when it comes to CDs with a lot of C1/C2 like those Cactus protected ones.

Go to forum: General discussion

25 Reply by matura713

(24 replies, posted in General discussion)

scsi_wuzzy wrote:

Most of my discs are North American releases, and I think that's why I've unwittingly avoided CDS. From reading about it, it sounds like it was more common in Europe compared to the Americas or Asia.

yes, indeed, and in Asia, more specifically Japan, they used some special "builds" of Cactus. however, in Europe, a lot of discs released in Germany and especially in the UK use it, that applies for CDs in the period 2001 to 2004.

scsi_wuzzy wrote:

Do you know if there's a comprehensive list of CDS discs anywhere

I don't know any available lists, but such discs have the Cactus logo on the back cover. In any way, it's a lot more than 8 discs. I've just check that site MusicBrainz and I noticed they seems to use the term "Enhanced CD" for some Cactus titles I know. So, that seems like a code word.

Go to forum: General discussion