I have a failing HD and was following the instructions posted here in LinuxQuestion about using ddrescue. Except I did something silly.

I did this:
ddrescue -n /dev/sdc1 /dev/sdb rescued.log

instead of this:
ddrescue -n /dev/sdc /dev/sdb rescued.log

I don't really want to try ddrescue on the damaged drive again as it takes days and the drive is failing.

Is it possible to use dd (rescue or otherwise) to fix this issue? sdb is one of a pair of new drives I intend to set up as a Raid 1. Can I do something to move sdb to sdX1? Is it as simple as partitioning the new drive correctly (and what does that mean exactly) and then :
dd /dev/sdb /dev/sdX1

Thanks!

You've copied a partition directly onto the target device. That's not a huge problem; the data are there, just in the wrong place. Just make sure you don't edit the partition table on the new drive, as sector 0 (where the partition table normally lives) now contains the boot block from your old drive.

The data will have to be moved from sector 0 to the starting sector of what is to become the first partition, typically sector 2048 (assuming a sector size of 512 bytes). The problem is that the move operation must start with the last sector to avoid overwriting existing data. I'm not aware of any tool capable of moving a range of sectors to a new location on the same disk, starting with the last block, when no partitions are (or can be) defined.

What you could do, is create a partition and then move the data with a suitable tool. As I mentioned, creating a partition would overwrite the first sector of the drive, so you'd have to create a small backup first. Here's what I'd suggest:

1. Use dd to save the first 2048 blocks to a file (dd if=/dev/sdb of=file.bin bs=1024 count=1)
2. Create a partition (/dev/sdb1) starting at block 2048 and covering the remaining data (get the partition size from the old drive and subtract 2048 sectors)
3. Use a partitioning tool like gparted to move the partition 2048 blocks (1 Mb) towards the end of the disk so it starts at sector 4096 (gparted is smart enough to realize it has to start the move operation at the end of the partition)
4. Delete and recreate /dev/sdb1 so it once again starts at sector 2048 (but ends where where it did after gparted had moved the data)
5. Copy back the missing first 2048 sectors (dd if=file.bin of=/dev/sdb1)

Not exactly pretty, but it'll work.

Important: If either drive has 4k sectors, the numbers will have to be adjusted accordingly.

What you forgot was to post details about the old disk. We don't know what you intend to do (or destroy ;-p). But if the old disk was a DOS (not GPT) type and only held one partition then couldn't you just edit the Partition Table of the new disk?

I am not sure what information is important. The failing drive was the only drive in a Windows 7 box. It is a 1TB Western Digital ATA WDC WD1002FAEX-00Z3A0. It is a NTFS file system. My goal is to copy the data over to a new drive, and use the new drive as part of a pair in a Raid 1 setup in my Windows 7 box.

My next step in the process was to use ddrutility to identify which files where damaged.

If this is not possible, then I will reinstall Win 7 on a clean drive and copy over undamaged files that I want to keep.

If I had not made my mistake of running ddrescue on a partition instead of the whole drive, I would have simply put the new drive back in the windows box and booted from it.

I don't know if just editing the partition table of the new drive will work. I am thinking the new drive does not have a partition table since I performed ddrescue on a partition and not the whole drive, but I don't know enough about partitions to say. That is why I am asking for help before continuing.

How do I determine this?

Last time I checked all consumer 4K HDDs had 512 byte emulation, none are actually natively 4K, so I don't think it would matter.
http://en.wikipedia.org/wiki/4K_native#4K_native