Something went wrong with my external HD (Ubuntu can't mount it)

Here is my output from the fdisk command:

sudo fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00043809

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   973105151   486551552   83  Linux
/dev/sda2       973107198   976771071     1831937    5  Extended
/dev/sda5       973107200   976771071     1831936   82  Linux swap / Solaris

Disk /dev/sdb: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5387f1b4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   625140399   312569176    7  HPFS/NTFS/exFAT

From my limited knowledge of Ubuntu--I'm guessing my external is being detected by my OS, but it's not being mounted. Backstory: I was trying to use an ISO file that I had on my external using AcetoneISO--then everything froze up. I forced a shut down/reboot, then when I rebooted, my HD wouldn't mount. It didn't even give me an error message, it just didn't work. What's up? Help?

EDIT: @Alaa: I was just about to add this info. I have just tried manually mounting my drive, and this is the output:

$ sudo mkdir /media/TOSHIBA_EXT
$ sudo mount -t ntfs-3g /dev/sdb1 /media/TOSHIBA_EXT
ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read $MFTMirr: Input/output error
Failed to mount '/dev/sdb1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

EDIT 2: This is the result after attempting to run an NTFSFix

$ sudo ntfsfix /dev/sdb1
Mounting volume... ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read $MFTMirr: Input/output error
FAILED
Attempting to correct errors... 
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... ntfs_attr_pread_i: ntfs_pread failed: Input/output error
FAILED
Failed to read $MFTMirr: Input/output error

Hypothesis: Did I short out the drive when I forced a reboot on it? I know it's bad to do that--but I've had to do that before, both on Windows-based systems and since I started using Ubuntu--and this is the first time anything's gone wrong. Just as an FYI to any answerers, my family is going out to eat fairly shortly, so I will be away for the next hour or so. I'm guessing my next logical step is to run a chkdsk in a windows-based environment, so I will attempt that when I get home. Based on the results of that, what do I do next?

EDIT 3: Still waiting on my chance to get onto the windows system (my Dad's laptop and he's busy using it). I have discovered the command fsck--which apparently is roughly equivalent to chkdsk in a Linux environment. This is the result I get:

$ sudo fsck /dev/sdb1
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

I repeated the fsck using e2fsck and the -b 8193 modifier, and got an identical result. Is this information helpful to anyone?

EDIT: I have been unable to use chkdsk on a Windows environment to recover the disk. I did something to it--I'm not sure what. But, the data lost is not life-ending, thankfully. So, I will continue to investigate this issue on my own, and if I come up with a solution I will repost this question, and all relevant information. I thank you all for your help, have a great night! :-)

Solution 1:

fsck is only roughly equivalent to chkdisk. As far as I can tell, it's no good for ntfs (hence ntfsfix). For an NTFS disk, it is always best to do it from windows. In case the disk has some unrecoverable errors with windows, I will guide you on how to use testdisk to a) fix the fs b) recover the data if all else fails

OK, to recover the data, download testdisk and use it:

http://yz.mit.edu/wp/recovering-files-using-testdisk/

(there are screenshots for a similar process -not exactly the one you want, but still helpful: http://www.cgsecurity.org/wiki/Undelete_files_from_NTFS_with_TestDisk)

After you have done that to try recover use of the drive itself (not the data) you can try a destructive badblock test - this will wipe the drive and map out any bad sectors.

https://wiki.archlinux.org/index.php/Badblocks