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: SATA CD/DVD drive for ripping copy protected CDs (Read 7384 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

SATA CD/DVD drive for ripping copy protected CDs

Can anyone recommend a SATA CD/DVD drive that is good for copying and ripping copy protected CDs, e.g. CDs protected with Cactus Data Shield?

I currently have an Optiarc AD-7203S that cannot copy or rip copy protected CDs properly. There are clicks and other defects in the copied CDs and ripped audio files.

My old IDE NEC CD writer NR-7900A and my old IDE NEC DVD burner ND-3520A can rip most copy protected CDs without problems but I need a SATA drive for my new computer to avoid a cabling mess.

I have tried an LG GH10 drive at work and it seemed to be able to read copy protected CDs without problems. However I cannot find this drive at any retailer. The LG drives I can find, such as LG GH20xxxx and GH22xxxx seem to have problems with copy protected CDs according to some people.

Barbapappa

SATA CD/DVD drive for ripping copy protected CDs

Reply #1
Some remarks about SATA:

SATA was basically intented to replace ATA- (hard disk), but not ATAPI-drives (e.g. CDROM/DVD). Support for the latter was not introduced before Revision 2 (or 2.5) of the SATA specification, and suffers from the "addition effect".
There are many controllers (on-board or pnp) on the market with very different implementations of the SATA-levels and their features. Logically the same is to say about the optical drives herelf.
The most common interface used by ripping software is ASPI, which was originally invented for SCSI, later "ported" for IDE as well. (At the time SATA was still science fiction!)

Very short conclusion:
Depending on controller, device and software (version) someone may succeed in getting a result, but there are many, many reasons to not use SATA for ripping issues.

SATA CD/DVD drive for ripping copy protected CDs

Reply #2
SATA was basically intented to replace ATA- (hard disk), but not ATAPI-drives (e.g. CDROM/DVD). Support for the latter was not introduced before Revision 2 (or 2.5) of the SATA specification, and suffers from the "addition effect".

Do you mean SATA2 when talking about support for ATAPI-drives ? I always think of SATA as just ATA just in another cable, it this wrong thinking of me?
What is "addition effect" ?

The most common interface used by ripping software is ASPI, which was originally invented for SCSI, later "ported" for IDE as well. (At the time SATA was still science fiction!)

Does this mean that SATA support ASPI 100% ?, because SATA was invented after SCSI? I'm not sure what you mean by this.

Very short conclusion:
Depending on controller, device and software (version) someone may succeed in getting a result, but there are many, many reasons to not use SATA for ripping issues.

What's the problem with using SATA for ripping?

SATA CD/DVD drive for ripping copy protected CDs

Reply #3
I am aware that there are some problems with running SATA CD/DVD drives in native SATA mode (AHCI or RAID). Because of this I have connected my DVD burner to a SATA controller that is running in ATA/IDE compatible mode. I have not noticed more issues with SATA CD/DVD drives running in ATA/IDE compatible mode compared to IDE CD/DVD drives.

Surely someone has a SATA CD/DVD drive that is working well for ripping copy protected CDs?

Barbapappa

SATA CD/DVD drive for ripping copy protected CDs

Reply #4
Preliminary:
I kept short in my first post, because the subject is very complex, naturally complicated, and terribly dry at least. To give you fairly an idea of what happens in the background, i only mention that there are "just" six revisions of the ANSI MMC definition (see below), and the last one alone contains more than 700 pages.
On the other side, there are tonnes of rumours, desinformations, and pseudo-scientific articles in so called computer magazines, against which one has to fight like Don Quixote's tilting at windmills.
Finally, i know quite a lot about these things, but i am not a programmer. (Okay, this may be also an advantage...)

So, what can you expect now:
This forum is not the place to go really into details (the moderators would kick me out), also i have not the time to do so. But i'll try to fill the gaps in my first post with more facts.
Please be lenient with me, my native language is not English.

Controllers:
As i mentioned erlier, SATA was not intended for (S)ATAPI-drives. To support the latter, at least a special hardware module ("Port Multiplier") is required, invented first with SATA 2.0.
As a result, former generations of controllers did not benefit from that, despite of their provenance (Intel, Promise, Silicon etc.) If i remember well, the first one with the new feature came from HighPoint. It was a bad laugh though to find a compatible drive...

A negative example of other kind was the SATAII(150) series from Promise. They did not support SATAPI, though the name suggested to do. (To be completely fair: The manuals didn't maintain this. But most people look only at packaging. They don't read, or if at all, they forget to lock the stable door after the horse has bolted...)
By the way, this is not meant as an argument against Promise. I have very good experiences with their hybrid-controllers (IDE/SATA, on-board or pnp), above all in 24/7 operations!

Drives:
Early CD/DVD SATA drives were, without exception, actually ATAPI (IDE) models with a bridge connector/chip. Methods like this cause overhead, which allways reduces performance, and who knows what more.

Of course, things can always change. I am sceptical, however, because the state of the market hardly allows the production of one model in different types, and manufacturers rarely take their trousers down. (I don't claim though that there are no genuine SATA drives at all!)

Standards:

(SCSI) Multi-Media Commands
Published by the American National Standards Institute (ANSI)

This is a definition of a transport independend command set, including SCSI, ATA/ATAPI, SATA, USB and IEEE 1394.

Probably all newer burning software relies on MMC. You can see that on files like mmc.dll in Nero. But in addition, Nero and many others require an ASPI layer, too. However, as well as the term ASPI does not even occur in MMC documents, this is true vice versa. I don't understand this non-relationship, though i have an idea, but that's not enough to write about. Maybe there's a developper here to explain that well...

Advanced SCSI Programming Interface (ASPI)

In contrast to the "public" MMC, the ASPI layer was developped by Adaptec. During the nineties the drivers were limited to computers with a build in SCSI controller (of course from Adaptec). In the mean time however it's not just those are free for everyone, there also exists a technical reference (see sources) for the API.

In 1995, Microsoft bought a license from Adaptec and integrated the driver in all Win9x versions. But between these releases - for saving money, or because of they had no permission to modificate something, or whatever reason else (marketing strategy?) - Microsoft decided to not implement ASPI in Windows NT 4.0 (1996). In place of that a new API was created: SPTI (see below).
By the way, Windows ME got neither ASPI, nor SPTI, but this may hardly be the reason why it became one of the biggest flops Microsoft ever brought out.

SCSI Pass-Through Interface (SPTI)
Microsoft's standard for the NT-platform (WinNT/2000/XP)

Almost nothing is known about, though Microsoft claimed: "The SPT interface is documented in the Windows NT/Windows 2000 DDK documentation." (Q251369, see resources)
I have both DDKs in the MSDN edition. Okay, i'am not a programmer, but i can read. There's a source skeleton (spti.c) without even a description. API documented? Story hour...

Interplay:
There are only few programs which allow (manual) switching between the two interfaces ASPI and SPTI. One of them is fortunately ISOBuster. I had some former issues, when the prog was unable to read certain disks. The problems went after temporarily changing from SPTI (which is the default) to ASPI. Of course, my standard is now set to the ASPI layer.

I cannot seriously say, that Microsoft implemented some hidden "features" into their SPTI. (No conspiracy, please.) But it made me think, that this interface didn't work properly even with drives, which are able to pick out from beer mats!
This happened on two machines with different DVD models from the same manufacturer. The OSes were NT 4.0 and Win2000, but of course identical ISObuster versions as well as ASPI drivers (v4.71a from Adaptec). The disks were approximately to the half copy protected or corrupt/damaged.

Conclusion:
SATA is an issue, particulary with controllers from the lower price ranges, and even more if they have (pseudo) RAID features, they may be activated or not. The old standard (IDE) was much less delicate.

Connecting a CD/DVD-R to a SATA controller has no performance improvements. (Don't believe what manufacturers and magazines maintain.) Such drives are by far not able to use an Ultra ATA-5 controller to full capacity, propper configuration assumed. During my long years in this business i saw a lonely DVD with UDMA-5 (Teac DV-516 D-A95), and a DVD-R with UDMA-4 (Pioneer DVR-109XLA1). Of course, both classifications are pure theory (laboratory measurements). But all others were even then only UDMA-2 models!
Mechanical limits are reached for a long time. So, a new interface alone is not an advantage.

Finally, yet two practical thoughts:
Why occupying a valuable SATA port, if you have three or four unused IDE ports?
Copying files between two different controllers can really improve performance!

Sources:
I have these as local copies, so i can't give URLs extempore. (They change quicker anyway than we can type.)

Serial ATA International Organization (APT/Dell/Intel/Maxtor/Seagate/etc.):

Serial ATA
High Speed Serialized AT Attachment
Revision 1.0a
7.1.2003

Serial ATA
Revision 2.5
27.10.2005

In addition there's a bunch of accompaning documents, published by the same group, respectively by ANSI or others. (This muddle, infiltrated with petty jealousy about competencies, would be stuff alone for snide comments.)

American National Standards Institute (ANSI):

Multi-Media Commands - 6 (MMC-6)
Working Draft
T10 1836D
Revision 0
14.11.2006

From MMC-1 to MMC-4 the title was "SCSI Multimedia Commands". (Sometimes one can get the impression, that they are changing just for fun - or because of the reason to make people much more confused, for being then completely by themselves!)

Adaptec:

Advanced SCSI Programming Interface
ASPI for Win32
Technical Reference
6.11.2001

Microsoft (Knowledge Base):

Info: ASPI on Windows NT Is Not Supported by Microsoft (Q182542)
Info: SCSI Pass Through Functionality and Limitations (Q251369)

SATA CD/DVD drive for ripping copy protected CDs

Reply #5
Thank you for sharing some background information on SATA josefpriko.

Running a DVD drive in native SATA mode (AHCI/RAID/IRRT) in Windows XP/Vista seems to be causing problems for a lot of people. E.g. installing Windows XP from a DVD drive in native SATA mode very often result in a blue screen of death some time during the installation. And a lot of people report about problems with burning DVDs in native SATA mode. Dell switched to native SATA mode for the optical drive for business laptops 2008 and it it causing a lot of problems.

What I don't understand is why it works so much better running a SATA DVD drive in ATA/IDE compatible mode. It is still the same DVD drive using the same cable. What happens when you run it in compatibe mode?

I can't honestly say that I have had any more problems with using a SATA DVD drive in ATA/IDE compatible mode compared to using a IDE DVD drive. So for me SATA DVD in ATA/IDE mode is good since the cable is much easier to use and doesn't restrict the airflow in the chassis as much as an IDE cable.

So far my Samsung SH-S223Q DVD drive has worked flawlessly and I haven't yet run into any CD it cannot rip.

Barbapappa

SATA CD/DVD drive for ripping copy protected CDs

Reply #6
What I don't understand is why it works so much better running a SATA DVD drive in ATA/IDE compatible mode. It is still the same DVD drive using the same cable. What happens when you run it in compatibe mode?

There are no stupid questions, but answers! (german proverb)
Nevertheless, i make a try.

First: What is AHCI?
The Serial ATA Advanced Host Controller Interface is often claimed to be an "open standard". Despite of the questionable term it is simply not true. AHCI was not invented by a public organization or group, but developped by Intel. (Every manufacturer who wants to implement it, needs a license.)

Second: Compatibilty
AHCI does not specify ATA legacy behavior, such as the legacy I/O ranges, or Bus Master IDE. Allowances have been made in AHCI so that an HBA [= Host-Bus-Adapter] may implement these features for backward compatibility with older operating systems ...
(Serial ATA Advanced Host Controller Interface 1.3, June 2008, Intel Corp.)

In other words: Because nothing is specified (What, please, are allowances?), it matters on the particular chipset. Further, probably a lot of the "mystery" is in the motherboard's BIOS, too. So, a serious answer is impossible without knowing many, many details. However, it is not very likely to get these informations... That's business!

Third: So what?
The interplay between chipset and BIOS complemented with drive models and software is the main reason, why so many contradictory reports exist. The success really depends on the actual hardware configuration. Changing only one component may lead to an opposite result. The only choice is: Try and error...

SATA CD/DVD drive for ripping copy protected CDs

Reply #7
Running a DVD drive in native SATA mode (AHCI/RAID/IRRT) in Windows XP/Vista seems to be causing problems for a lot of people. E.g. installing Windows XP from a DVD drive in native SATA mode very often result in a blue screen of death some time during the installation. And a lot of people report about problems with burning DVDs in native SATA mode.

The BIOS is able to read from the drive in AHCI (native SATA) mode and to boot from it, but later (I think after a restart of the system) Windows has to access the drive without the help of the BIOS and that fails due to the lack of an AHCI driver (and results in a blue screen of death).

There are ways to circumvent this:
  • Put an AHCI driver on a floppy disk and make windows use it during the installation process (by pressing I think F6 when prompted to and then selecting the driver on the floppy disk). Unfortunately Windows cannot read it from a USB mass storage device.
  • Create a modified Windows XP installation CD with the driver included (you can also add the latest service pack and patches)
  • Install Windows in IDE mode and install AHCI drivers after the Windows installation, when you can read from USB devices, the optical drive or download it from the internet, then reboot and switch to AHCI mode. I think this should work, I haven’t tried it yet.
Problems with burning are probably due to burning programs which are not prepared to use AHCI. I never had problems, probably because I use only the program which was bundled with my DVD burner.

What I don't understand is why it works so much better running a SATA DVD drive in ATA/IDE compatible mode. It is still the same DVD drive using the same cable. What happens when you run it in compatibe mode?

I think when you set it in the BIOS to IDE compatible mode, the hardware (I think it’s the controller) emulates an IDE drive by hiding the AHCI interface and translating the commands. It is the same cable, but the controller handles the electrical communication and the operating system does not know about it (and doesn’t have to).
FLAC.

SATA CD/DVD drive for ripping copy protected CDs

Reply #8
This discussion began with the unacceptable intent of soliciting help to circumvent copy protection (TOS #9), but thankfully veered off-topic in providing useful information about interfaces.  As such it is staying on the board, but it will be closed to further discussion.