PDA

View Full Version : C2 erorrs not detected when using Plextor drives via firewire (Oxford 911 chipset)



boneshaker335
03-20-2008, 07:14 PM
Hi,

I have 4 Plextor drives (755, Premium) in a Mapower firewire case, Chipset: Oxford 911. The ripper doesn't find any C2 errors when using a verified (= it produces c2 errors on other drives) very scratched test disc.

Is there a solution to for this problem?

Best wishes
Peter

LtData
03-20-2008, 07:59 PM
Using C2 over firewire is always dependendant on the bridge chip passing the C2 commands, so....

pls1
03-20-2008, 08:58 PM
I asked in the forum last month for a specific firewire chipset then would work for C2 detection and got no replies. I tried multiple firewire chipsets (including both Oxford options) and could not get any combo to give me C2 detection over firewire.

I gave up and I rebuilt my Plextor drive setup (Premiums, 230s, 755s and 760s) with esata or usb interfaces which give C2 support. You can search for my earlier C2 detection support thread for some other forum members suggestions.

Many other media programs can interfere with C2 support so on one machine I de-installed and in the other case I just did a clean install of XP. One quirk is that it seems that you must install Plextools on the machine to get C2 detection over USB with dbpoweramp.

I could be wrong but after all my hassle I did not want to do a full confirming test.

Phil

bhoar
03-20-2008, 09:27 PM
I could be wrong but after all my hassle I did not want to do a full confirming test.

Yeah, that's quite understandable. If you could, perhaps list the upper filter drivers and lower filter drivers associated with the optical drives on a working setup - might lead us to understand what change, if any, plextools make to get it working.

-brendan

pls1
03-21-2008, 02:13 PM
The PlexTools CD seems to install "PxHelp20" in Class Lower Filters. The Device Upper and lower filters are the standard "redbook" and "imapi". This is on a dedicated desktop where I wiped the disk and reinstalled XP and the dbpoweramp. I seem to recall that USB C2 detection at first did not work after the re-install of XP but then worked after installing PlexTools.

There is a similiar Class Lower Filters entry when installing the Plextor Blu-ray software "ULCDRHlp". This seems to be what enables C2 detection over USB for Plextor drives on my workstation after way to much messing around with uninstalling media software.

I could be wrong about the PlexTools software being necessary for C2 over USB but I am SURE that I'm getting consistent C2 detection over these drives over USB both with dbpoweramp and PlexTools since i test for this at the beginning and end of each days ripping.

Since it took me several weekend of work to build, rebuild, rebuild, etc. and finally get my present setup working (two dedicated desktop machines plus my workstation, each with four different models of drives) I'm not very inclined to mess with it. Music is my hobby and digital audio is not my business.

BTW, C2 can also be detected on a PX-755/760 using an Addonics IDE to SATA adapter and then plugged into an esata card or the internal SATA connector with a 2 meter cable. The XP Device Manager identifies them as SCSI devices. The PX-230 is flaky with the Addonics IDE to SATA adapter.

Hope this is helpful.

Phil

boneshaker335
03-21-2008, 03:59 PM
FYI:

C2 errors work over firewire when connecting the same external case to my MacBook.

It does not work when connecting that case to my PC (whether using a PCI firewire card or the onboard firewire interface).

So the computer side firewire interface seems to be responsible for the problems, not the Oxford chip in the external case.

pls1
03-21-2008, 07:39 PM
Almost all 1394a PC interfaces use the TI chipset so I suspected that it might be a problem. I alsu tried two different 1394b cards and didn't get C2 working on those either and they were two different cards from "other world computing" that were supposed to give full mac-like firewire commands.

Perhaps someone knows which chipset is in the Mac.

Phil

bhoar
03-21-2008, 08:14 PM
Almost all 1394a PC interfaces use the TI chipset so I suspected that it might be a problem. I alsu tried two different 1394b cards and didn't get C2 working on those either and they were two different cards from "other world computing" that were supposed to give full mac-like firewire commands.

Perhaps someone knows which chipset is in the Mac.

This also could be an issue with the microsoft firewire driver set. Remember the debacle with the XP/2003 1394b (800mbit) support?

EDIT: from what I've seen from online forums, some macbooks have TI chipsets, some have Agere chipsets.

-brendan

pls1
03-21-2008, 09:07 PM
One of the PCI firewire cards I used had an Agere chipset (model unknown). I've asked on forums for an example of C2 with Windows and haven't gotten a response so maybe it is the Microsoft drivers and firewire CANNOT give C2 detection on Windows.

The USB interface works fine for me and with a Gefen USB 2 optical extender I can put the dedicated ripping machines in a cabinet and the external drive enclosures with in easy reach of our office chairs.

Phil

bhoar
03-21-2008, 10:38 PM
One of the PCI firewire cards I used had an Agere chipset (model unknown). I've asked on forums for an example of C2 with Windows and haven't gotten a response so maybe it is the Microsoft drivers and firewire CANNOT give C2 detection on Windows.

The USB interface works fine for me and with a Gefen USB 2 optical extender I can put the dedicated ripping machines in a cabinet and the external drive enclosures with in easy reach of our office chairs.

Phil

Dang, the Gefen USB 2.0 optical extenders list at $1600 each. That's a very pricey t.., er, labor saving device!

-brendan

pls1
03-22-2008, 11:05 AM
Street price from the right reseller is significantly less than what it is on the Gefen website. Not even counting the parts, I blew WAY more $$ than that in my own lost client billable time screwing around with multiple failed firewire set-ups.

My wife's office workstation is just on the otherside of the wall from the server closet so esata from the machine to an outboard drive enclosure works fine with a 2 meter cable length.

However, I'm on the other side of the office and partially disabled by pinched nerves in my neck and spine so physical positioning of the drives is a big deal for me. The cheaper extenders were all USB 1.1

Also in terms of cost, multiply 5000 CDs by the average new selling price of the major labels, plus, I'm adding to my collection at about the same average rate over 20 plus years.

BTW what interface are you using for your multi-drive automated ripper builds?

Phil

bhoar
03-22-2008, 11:40 AM
Street price from the right reseller is significantly less than what it is on the Gefen website. Not even counting the parts, I blew WAY more $$ than that in my own lost client billable time screwing around with multiple failed firewire set-ups.
...
BTW what interface are you using for your multi-drive automated ripper builds?

I've been using firewire (on Mediatechnics fusion robots) with the Ripstation software, but I haven't gone down into the nitty gritty of tuning the C2 stuff on the drives yet for use with the dbpa batch ripper. The last time I started playing with it, I ran into issues with parallel ripping causing slowdowns in the batch ripper with more than 2 or 3 drives operating at once. Haven't figure if the problem is with dbpa or elsewhere.

Looks like I have some C2 fun to look forward to even after I resolve that. :) Luckily, I also have SATA<->IDE bridge boards available.

-brendan

pls1
03-22-2008, 12:48 PM
I don't use batch ripper (i use multiple instances of R12 on XP). From "black box" monitoring R12 on my overclocked quadcore workstation, I don't think R12 can make optimum use of an individual interface-to-PCI bus in terms of latency and throughput. Of course, just getting the low-level drive firmware to engage with dbpoweramp must be challenging enough so this is NOT a knock at Spoons.

Just casual observation but multiple cards, each with one drive, give the most consistent high speed (x18-24) on multiple simultaneous drives, while two drives on the same interface aren't consistent even though multiplication of expected through put is below the max of the spec.

For batch ripping I would really recommend the newer Intel CPUs over P4s. Casual observation also indicates the same leverage in performance that the typical video encoding benchmarks showed. The P4s are much less predicable in full CPU loading with multiple drives going. Also total L2 cache seems to make a difference although this seems to be a second order effect.

From my systems engineering experience "kill the problem with hardware" may not be elegant but is usually cheaper and easier from the "outside-in" unless the programmers have and show you secret dials somewhere. At $50-$75 per drive for adapters, interface and cable this seems like a no-brainer for a commercial operation.

Phil

bhoar
03-22-2008, 01:02 PM
From my systems engineering experience "kill the problem with hardware" may not be elegant but is usually cheaper and easier from the "outside-in" unless the programmers have and show you secret dials somewhere. At $50-$75 per drive for adapters, interface and cable this seems like a no-brainer for a commercial operation.

I was hoping the "throw as much hardware at it" approach would work, which is why I was surprised.

FWIW, the experiments I was talking about with more than 2 or 3 drives causing all drives to slow down was with each drive on a separate channel (tried all Firewire, then all USB, then all SATA) using the "Test" codec that throws the data away and doesn't write to the hard drive, on a core 2 quad CPU with 8GB of RAM on Win 2003 Server EE. The problem continued to exist if I mixed and matched interfaces (one on USB, two on SATA, one on firewire, for example). My gut feeling is that it is a DMA or interrupt issue of some sort in Windows. I'm going to try a few different windows installations to see if I can get the problem to go away.

Of course, now I'm going off topic, sorry.

-brendan

pls1
03-22-2008, 02:59 PM
Try to not use USB/Firewire at the same time as SATA. Then use only two drives per sata PCI card (or MOBO SATA interface). Better yet one interface per drive sending each ripping stream to a fast HD that is different from your systems disc using a quadcore processor.

My MOBO uses the nvidia chipset since there is an elusive bug in the intel chip that slows the fastest discs in RAID zero like configs. I can get four drives going with four separate R12 instances at X22+. Also make sure that the SATA card can handle the full 3 gbs. Many cards really don't.

This is only partially OT since I have lost C2 detection due to overloading the interfaces on my P4 machine.

I'll bet you will run into all sorts off hardware/interface quirks with multi-drive batch rippers.

I hope Spoons is not as touchy as the TOS enforcers over at HA.

Phil

boneshaker335
03-22-2008, 03:09 PM
I made another test:

Exact Audio Copy (current version) is able to detect C2 errors with the same exact PC/external case firewire setup that dbpoweramp fails to detect any C2 errors.

So the hardware seems to work.

pls1
03-22-2008, 03:19 PM
That's great news since this means it is a bug that is "fixable". Multiple firewire ports will be much more palatable to folks than multiple esata or expensive USB interfaces.

Thanks for the persistence.

Phil

bhoar
03-22-2008, 04:55 PM
I can get four drives going with four separate R12 instances at X22+.
...
I'll bet you will run into all sorts off hardware/interface quirks with multi-drive batch rippers.

One thing I want to clarify for you about how the batch ripper works is that it basically does the same thing you do with R12. The batch ripper launches a separate instance of the dbpa cd ripper process for each drive. Normally they are hidden, but you can always unhide them and bring them to the front if you think there is an issue. Any problems seen with the batch ripper would therefore be seen with the standard R13 ripper (and vice versa) under this architecture.

If you look in the task manager, you'll see one process for the batch ripper, one process per drive for each instance of the cd ripper and then, of course, a bunch of encoding processes, one or more per track currently being encoded.

-brendan

Spoon
03-22-2008, 06:10 PM
There are instances where c2 will not work in EAC but will in dBpoweramp (atleast on our systems), so it is half a dozen of one, half a dozen of another...

I recently built a system - quad core, 4 drives on PCI IDE cards (darn SATA MB's), on that system you could rip all 4 drives at x40 ripping speed (at the end of a disc) with less than 5% CPU usage (when using test conversion). Using Firewire, or USB you will quickly fill the systems bus allocation for these when using multiple drives.

bhoar
03-22-2008, 06:23 PM
There are instances where c2 will not work in EAC but will in dBpoweramp (atleast on our systems), so it is half a dozen of one, half a dozen of another...

Yes, but asking "why" here is an important thing to do to reduce the headaches that a lot of users go through trying to get this right. If you (spoon) finally know why this happens, perhaps you can tweak the code so that it always works for dbpoweramp in both the current positive circumstances as well as when it has only historically worked for EAC.

It might be as simple as the buffer sizes used at some point in the chain, which might be too small for certain drive data to be reported back correctly or too large for certain interfaces/drivers to handle correctly.

So much hardware and so many drivers out there are supposed to follow the T10 recommendations and just get it completely wrong. :)


I recently built a system - quad core, 4 drives on PCI IDE cards (darn SATA MB's), on that system you could rip all 4 drives at x40 ripping speed (at the end of a disc) with less than 5% CPU usage (when using test conversion). Using Firewire, or USB you will quickly fill the systems bus allocation for these when using multiple drives.

That still doesn't explain why I see the problem with any mix of the following: on-board SATA, on-board firewire, PCI firewire, on-board USB. If the problem had ever gone away in any circumstance, I could understand, but surely the situation with all on-board SATA (tried in both native and emulation modes) parallels your all PCI IDE cards well enough. I don't think that's the explanation for what I was seeing, but I do need to start from scratch with experiments on that hardware again.

-brendan

pls1
03-22-2008, 07:11 PM
brendan:
Most common (current) RAID oriented SATA MOBOs will not give dbpoweramp C2 detection off their on-board connectors. I don't know why but I spent enough weekend time convincing myself to just give up on certain machines.

Multiple PCI IDE cards (one card-to-one-drive) always work fine for me on any of my machines. Some eSATA PCI card combos work with the PX-755/760 and Samsungs but some don't. One USB plus multiple PCI IDE cards work fine on my quad core workstation with very highspeed ripping and low CPU utilization.

Every other attempted combo has either plain not worked or can't reliably deliver high speed ripping with consistent C2 detection over eight different other (MOBO) machines.

After Spoons' recent post I'm going to sell the Firewire enclosures, cards and cables on ebay.

Phil

bhoar
03-22-2008, 07:24 PM
Yeah. Ok. But the fact that on-board SATA connections aren't working makes me believe this is a software issue of some sort.

-brendan

pls1
03-23-2008, 12:35 AM
Some on-MOBO SATA connections work and some do not. On board RAID MOBOs, at least versions i have, do not.

Not all PCI SATA cards work and not all drives work via SATA. It was a very frustrating and rather expensive month to get my set ups working . Beats me as to what is going on.

Perhaps we can put together a consolidated list of combos that someone has gotten to work as a FAQ

Phil

bhoar
03-25-2008, 02:42 PM
One of the other things I've considered is playing around with alternate firewire and ATA drivers under windows, to work around the 800mbit issue and the PIO issue, respectively:

http://www.unibrain.com/Products/DriverAPI/ubcore.html
http://alter.org.ua/en/soft/win/uni_ata/

Once I get ULCLI up to the release v1.00, I'll return to experimenting with drive, IO rates and feature support.

-brendan

computer-girl
12-09-2008, 07:28 PM
There are instances where c2 will not work in EAC but will in dBpoweramp (atleast on our systems), so it is half a dozen of one, half a dozen of another...

I recently built a system - quad core, 4 drives on PCI IDE cards (darn SATA MB's), on that system you could rip all 4 drives at x40 ripping speed (at the end of a disc) with less than 5% CPU usage (when using test conversion). Using Firewire, or USB you will quickly fill the systems bus allocation for these when using multiple drives.


Spoon,

How many PCI IDE cards, which manufacturer and model number, and which drives did you use for this setup?

computer-girl
12-09-2008, 07:31 PM
There are instances where c2 will not work in EAC but will in dBpoweramp (atleast on our systems), so it is half a dozen of one, half a dozen of another...

I recently built a system - quad core, 4 drives on PCI IDE cards (darn SATA MB's), on that system you could rip all 4 drives at x40 ripping speed (at the end of a disc) with less than 5% CPU usage (when using test conversion). Using Firewire, or USB you will quickly fill the systems bus allocation for these when using multiple drives.

I have my eye on the following drives


Plextor PX-230a
Plextor PX-708a
Plextor PX-760A

Can I assume that these will work with the configuration above?

computer-girl

Spoon
12-10-2008, 04:41 AM
>Can I assume that these will work with the configuration above?

No, each PCI card might be different. I cannot remember the names of the cards I used.