Sony Handycam (DCR-SR45) HDD

[Grinder]

Does anyone have any clues as to how I might be able to recover video
from a DCR-SR45's hard drive?

I have 1.8" drive to USB adapter, that permits me to see the hard drive.
But it's not using an easy file system like FAT32. My next step is to
make a byte-for-byte dump of the drive in an attempt to pick it apart,
but some pointers would likely help.

Thanks for your consideration.

[Gene E. Bloch]

If you had a live Linux CD, you cold boot from it and see if the file
system is readable from Linux.

What I mean by a live CD is a CD that you can boot and it then is
running Linux without making any changes to your computer.

--
Gene E. Bloch (Stumbling Bloch)

[Paul]

http://esupport.sony.com/US/p/model-home.pl?mdl=DCRSR45&LOC=3#/manualsTab

HandyCam Handbook (fourth one down)...

http://www.docs.sony.com/release/DCRSR45_handbook.pdf

2GB max file size. Doesn't say what file system, but it isn't NTFS.
It's probably a FAT family of file system. Since the drive is 30Gb
in size, it would probably be FAT32.

http://en.wikipedia.org/wiki/File_Allocation_Table

I use this utility for "tasting" file systems. It will work
directly with the disk, as in

disktype /dev/sda

if the drive was at that Linux disk address. If I copied the
data off the drive, to the hard drive, like this

dd if=/dev/sda of=/media/somepartition/bigfile.bin bs=512

and waited for it to finish, I could then try

disktype bigfile.bin

and the tool will also work with an "image file".

I would work with a copy of the data, rather than directly
with the tiny drive.

For example, restore the image file to an empty disk.

dd if=/media/somepartition/bigfile.bin of=/dev/sda bs=512

and then the empty disk should behave like the camera disk
would have. You can then try disktype utility again if you
want. Or, you can try TestDisk, as an example of another utility.

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

A hard drive can be prepared with an MBR or without one.
Computers like them to have an MBR, and that is located
at sector zero and has four primary partition entries in
it. But, it's also possible to "lay down" a file system,
which just starts at sector 0. And is more likely to
be the format used by the camera. You might find USB flash
sticks working that way in some cases. I don't know
whether TestDisk appreciates a non-MBR system or not,
because usually you're using TestDisk to verify or
rewrite the MBR.

The above could be done under Linux, but there are
also Windows versions available.

If staying on the Windows side, running CHKDSK on it,
would be way down my list of things to try. Only do that
on a copy of the data, not with your only copy.
It could ruin it.

So my priorities would be:

1) Make a backup copy, and work with the backup to save
wear and tear on the original drive.
2) Try to use disktype (a Linux utility). That's to verify
it is FAT32.

If you use a Linux LiveCD, not every CD will have a copy
of disktype utility. You have to use Synaptic Package
Manager or equivalent, to download a compiled copy of
the utility. I thought by now, that utility would be
more popular, but I'm still not seeing it included on
the latest LiveCDs I tried.

If the disktype utility can give you any info on it,
then you'll have some hint as to what to do next.

According to the handbook, your video will be chopped up
into 2GB pieces. So if you had a 7GB long recording, it
would be stored in four files. So they don't attempt
to store a single 7GB file in the file system, and that
is partially what hints at a FAT family file system.
I think some version of EXT2 might have had a small
limit, and the file system "expands" the first time
you attempt to copy a larger file (if the OS is
capable of handling it). But the odds of them using
a perfectly free file system like EXT2, are slim. Lots
of stuff was built to use FAT instead.

Note also, the file names are 8.3 format, which is
another hint it is FAT and Windows related. A Linux
file system, wouldn't be limited to 8.3 naming.

HTH,
Paul

[j]

Dunno,

But Test Disk is the Mac Daddy, and free:

http://en.wikipedia.org/wiki/TestDisk

Jeff

>
> Thanks for your consideration.

[Paul]

Actually, this is the one you want. Unless you want to examine the
header of the file system with a hex editor, which will also work.
(If you were working with a disk taken from an IBM PC compatible,
you wouldn't bother with this. But we need to know more about it,
if it's extracted from an embedded device.)

http://disktype.sourceforge.net/

The disk might not have an MBR. The camera doesn't "boot", so an MBR
isn't strictly necessary. The camera could have all executable content
on an internal flash, so that the HDD can be removed for maintenance.

Running disktype on it, may help explain later why TestDisk
is not happy.

Only thing missing for disktype - is a Windows port.

Disktype will treat an "image" of a disk, like it treats a disk.
"disktype /dev/sda" would analyse a disk, while "disktype mybigfile.bin"
would do the same thing, if you did a sector by sector copy of /dev/sda
into mybigfile.bin . If all you've got, is an image of a file system,
you can work with that. disktype will even do optical disks for you,
and you get to see that some installer discs, have dual file systems.
"disktype /dev/cdrom" or "disktype /dev/sr0" for opticals.

Paul

[j]

Then the OP may run linux as a windows program.

Wubi:

http://www.ubuntu.com/download/desktop/windows-installer

other options:

http://www.labnol.org/software/run-linux-with-windows/19746/

I hadn't heard of disktype, that I can remember. Fortunately it has been
years since I needed anything like this.

Jeff

[Grinder]

It looks like disktype is included on the Parted Magic livecd, so I'll
give that a look after testdisk finishes its deep analysis. More soon...

[Grinder]

On 10/9/2012 7:43 PM, Paul wrote:
> Grinder wrote:
>> Does anyone have any clues as to how I might be able to recover video
>> from a DCR-SR45's hard drive?
>>
>> I have 1.8" drive to USB adapter, that permits me to see the hard
>> drive. But it's not using an easy file system like FAT32. My next
>> step is to make a byte-for-byte dump of the drive in an attempt to
>> pick it apart, but some pointers would likely help.
>>
>> Thanks for your consideration.
>
> http://esupport.sony.com/US/p/model-home.pl?mdl=DCRSR45&LOC=3#/manualsTab
>
> HandyCam Handbook (fourth one down)...
>
> http://www.docs.sony.com/release/DCRSR45_handbook.pdf
>
> 2GB max file size. Doesn't say what file system, but it isn't NTFS.
> It's probably a FAT family of file system. Since the drive is 30Gb
> in size, it would probably be FAT32.
>
> http://en.wikipedia.org/wiki/File_Allocation_Table
>
> I use this utility for "tasting" file systems. It will work
> directly with the disk, as in
>
> disktype /dev/sda

Here is what I get for the drive from disktype:

--- /dev/sdd
Block device, size 27.95 GiB (30005821440 bytes)
disktype: Data read failed at position 30005817344: Input/output error
DOS/MBR partition map
Partition 1: 27.95 GiB (30005723648 bytes, 58604929 sectors from 62)
Type 0x0C (FAT32 (LBA))
FAT32 file system (hints score 5 of 5)
Volume size 27.94 GiB (29998284800 bytes, 915475 clusters of 32 KiB)

> if the drive was at that Linux disk address. If I copied the
> data off the drive, to the hard drive, like this
>
> dd if=/dev/sda of=/media/somepartition/bigfile.bin bs=512

I'm doing this now.

>
> and waited for it to finish, I could then try
>
> disktype bigfile.bin
>
> and the tool will also work with an "image file".
>
> I would work with a copy of the data, rather than directly
> with the tiny drive.
>
> For example, restore the image file to an empty disk.
>
> dd if=/media/somepartition/bigfile.bin of=/dev/sda bs=512
>
> and then the empty disk should behave like the camera disk
> would have. You can then try disktype utility again if you
> want. Or, you can try TestDisk, as an example of another utility.
>
> http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

TestDisk (Windows) also guessed FAT32, but was unable to list files.

> A hard drive can be prepared with an MBR or without one.
> Computers like them to have an MBR, and that is located
> at sector zero and has four primary partition entries in
> it. But, it's also possible to "lay down" a file system,
> which just starts at sector 0. And is more likely to
> be the format used by the camera. You might find USB flash
> sticks working that way in some cases. I don't know
> whether TestDisk appreciates a non-MBR system or not,
> because usually you're using TestDisk to verify or
> rewrite the MBR.

That's a reasonable speculation. Windows want's to initialize the disk
with an MBR, so I presume that means there is not one. (I've declined
the opportunity.)

> If staying on the Windows side, running CHKDSK on it,
> would be way down my list of things to try. Only do that
> on a copy of the data, not with your only copy.
> It could ruin it.

Absolutely.

> So my priorities would be:
>
> 1) Make a backup copy, and work with the backup to save
> wear and tear on the original drive.

Working on it now.

> 2) Try to use disktype (a Linux utility). That's to verify
> it is FAT32.
>
> If you use a Linux LiveCD, not every CD will have a copy
> of disktype utility. You have to use Synaptic Package
> Manager or equivalent, to download a compiled copy of
> the utility. I thought by now, that utility would be
> more popular, but I'm still not seeing it included on
> the latest LiveCDs I tried.
>
> If the disktype utility can give you any info on it,
> then you'll have some hint as to what to do next.

Just for reference, the Parted Magic livecd has disktype included, *and*
it completely loads into RAM. There are other great utilities as well.

> According to the handbook, your video will be chopped up
> into 2GB pieces. So if you had a 7GB long recording, it
> would be stored in four files. So they don't attempt
> to store a single 7GB file in the file system, and that
> is partially what hints at a FAT family file system.
> I think some version of EXT2 might have had a small
> limit, and the file system "expands" the first time
> you attempt to copy a larger file (if the OS is
> capable of handling it). But the odds of them using
> a perfectly free file system like EXT2, are slim. Lots
> of stuff was built to use FAT instead.
>
> Note also, the file names are 8.3 format, which is
> another hint it is FAT and Windows related. A Linux
> file system, wouldn't be limited to 8.3 naming.

Ok, so let's say the volume is an intact FAT32 partition that lacks an
MBR and partition table. Can I just slap one on to the front of that
image file, dd it back to a spare hard drive, and mount that partition?

[Paul]

You could transfer the "raw" partition, to an MBR based disk. For example,
with the successfully obtained image, you could make the FAT32 from
the camera, a FAT32 on a regular computer disk. You make an entry
in the partition table, of the correct size, and then "dd" can
do the actual transfer.

+----+-------------------+----------------------------------------+
|MBR | Regular partition | <----- Make a partition the same ----> |
| | | size as the HDD image |
+----+-------------------+----------------------------------------+

So in this example, the computer hard drive before the operation,
would have one partition, say /dev/sda1. That's the one I call the
regular partition. (I've only included a regular partition, just
to show we can add a partition if we want.)

Then, I'd need to add an entry to the MBR, for the new second partition,
which would be /dev/sda2. Ways to do this would include PTEDIT32 in
Windows, where you can edit the partition table manually. Or, you
can use Disk Management in Windows (and probably get the total
size argument wrong). If you try doing it in Linux, you'd use
"sudo fdisk /dev/sda" and add a partition that way, but the problem with
Linux these days, is "alignment to MB" versus "alignment to cylinder".
So I don't know how difficult it would be, to get a good setup
that way.

Once you're *absolutely sure* the dimensions of the destination
partition are correct, you can dd copy the image file you made.

sudo dd if=bigfile.bin of=/dev/sda2

Such a command will stop, when either the source is exhausted or
the destination runs out of space. You would verify from the
command results, that the appropriate amount of data got transferred.
Failure to verify, could mean you end up with a (logically) truncated
partition. I do this kind of stuff a lot, and I've made a few
math errors along the way. You have to be careful with the math,
(and also the disk syntax), to avoid ending up with an even
bigger disaster. My record so far, is two partitions irretrievably
damaged by stupid mistakes :-( :-( So be careful!

*******

I predict a more fundamental problem though. By the time you read this,
the "dd" you're running will have failed, because it will not be
able to read "position 30005817344". The regular "dd" command in
Linux, I think if it gets one error, it will stop. So your attempt
to copy the disk is likely to fail. If it doesn't fail, then you're
"ahead of the game". So the following is only necessary, if
my prediction of disk damage down near the end, holds true.

This flavor of command, keeps track of damaged sectors, so
you can do a quick first pass to get most of the partition,
then try to fill in with succeeding passes. As far as I know,
the log file keeps track of what failed. (I can't test that
here, because I've got no disks damaged just the right way
to test with.)

http://www.cgsecurity.org/wiki/Damaged_Hard_Disk

sudo ddrescue -n /dev/old_disk /dev/new_disk rescued.log
sudo ddrescue -r 1 /dev/old_disk /dev/new_disk rescued.log

You download source from download.savannah.gnu.org . You don't
have to use wget to do that. You can use a regular browser. The
latest version is not 1.8. You have to carefully inspect that
download page, to figure out the actual most recent version.

Try this link, and it'll hop to a mirror...

http://download.savannah.gnu.org/releases/ddrescue

ddrescue-1.16.tar.lz 11-Jun-2012 14:15 60K

Just right-click on the revision you want, and save as to
download it. According to this, the .lz extension is LZIP.

http://en.wikipedia.org/wiki/.lz

In Linux, first install LZIP

sudo apt-get install lzip

Then, you can unpack the download

lzip -c -d ddrescue-1.16.tar.lz | tar xvf -

There will be a new directory ddrescue-1.16 . CD to it.

cd ddrescue-1.16

Configure and make. If you do it in two steps, you can note any
errors during configure stage. No need to sudo during configure,
as the files are owned by you. The make install stage, you use
sudo so the executable can be put into the file tree.

./configure
make
sudo make install

which ddrescue

The answer returned by the last line should be "/usr/local/bin/ddrescue".
Now, check that it executes. No sudo needed, as no raw access to
disks is being attempted.

ddrescue --help

Now, it's time to fashion the commands to run the copy attempt.
This would be similar to your previous copy attempt, and use
whatever disk addresses you were using for that. The "old_disk"
and "new_disk" are placeholders, and need to be populated
appropriately. In this example, we would say, transfer a
whole 30GB hard drive, to a second larger hard drive, overwriting
anything that was on the second drive. This is in effect, a clone
attempt.

sudo ddrescue -n /dev/sda /dev/sdb rescued.log
sudo ddrescue -r 1 /dev/sda /dev/sdb rescued.log

According to this page, instead of using the manual installation
method, you can use the one in your distro. So ddrescue appears
to be in package manager as well.

http://ss64.com/bash/ddrescue.html

sudo apt-get install ddrescue

but the version may be slightly older. That article also mentions
it can do

"It copies data from one file or block device (hard disc, cdrom,
etc) to another, trying hard to rescue data in case of read errors."

which implies you could make an image file, instead of a partition
to partition copy. The "-p" option here, claims to support preallocation,
which in your case should be setting the file size of "bigfile.bin"
instantly to 30GB when the command starts. Then it'll fill in the
sectors as it goes. If you did a partition to partition transfer,
as is shown in the command examples, then no pre-allocation would be needed.

sudo ddrescue -n -p /dev/sdb /media/somepartition/bigfile.bin rescued.log
sudo ddrescue -r 1 /dev/sdb /media/somepartition/bigfile.bin rescued.log

If I was doing it partition to partition, I'd do it like this.

(Create a destination for the file. If it was /dev/sdc, I'd zero
out 30 GB of it first. This is 30000 megabytes. Make it a bit
larger, if the destination is a blank disk or whatever. You can
also do this to files. While the preallocation argument could
zero-fill the file first, I don't know if that can be trusted
or not. Another way they could zero-fill, is to use a sparse file,
which is supported on Linux file systems [and on NTFS]. Sectors
which are zero, are not written when created in that case. If
you were copying to a single partition like /dev/sdc2, you'd
precisely work out the necessary block size and count, while for
whole disk transfer, you can zero more space than is needed. Like
set the count to 40000 instead of 30000.)

sudo dd if=/dev/zero of=/dev/sdc bs=1048576 count=30000
sudo ddrescue -n /dev/sdb /dev/sdc rescued.log
sudo ddrescue -r 1 /dev/sdb /dev/sdc rescued.log

If doing it to a file, I might try doing it like this. This
preallocates the file, without using sparse techniques. ddrescue
will come along, and overwrite the initially zeroed sectors, as
it succeeds at reading stuff.

sudo dd if=/dev/zero of=bigfile.bin bs=1048576 count=30000
sudo ddrescue -n /dev/sdb bigfile.bin rescued.log
sudo ddrescue -r 1 /dev/sdb bigfile.bin rescued.log

Anyway, it's a bit crude as a technique. But it you get
stuck, it might work out.

I've done plenty of "dd" type experiments, but I've never
had a disk damaged in just the right way to be able to
use "ddrescue". So I don't have any first hand knowledge
of the details. But it should work in a similar way to "dd".

Paul

[Frank]

On Wed, 10 Oct 2012 14:03:13 -0500, in 'rec.video.desktop',
in article <Re: Sony Handycam (DCR-SR45) HDD>,

If you manage to get everything working but still have a bad sector
problem, Steve Gibson's SpinRite may prove useful.

GRC | Hard drive data recovery software
http://www.grc.com/sr/spinrite.htm

As to chkdsk, please note that chkdsk can do no harm if it's run
without specifying any switches (such as /f, which instructs the
program to fix any errors that it encounters).

However, since chkdsk works at the partition level, and if the drive
currently has no MBR/partition table, then no drive letter will be
assigned (each partition on a physical drive has it own drive letter)
and therefore you would be unable to run chkdsk anyway, so it's a moot
point unless and until you can get the system to recognize a
partition.

Good luck!

--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/
[also covers AVCHD (including AVCCAM & NXCAM) and XDCAM EX].

[Grinder]

> I predict a more fundamental problem though. By the time you read this,
> the "dd" you're running will have failed, because it will not be
> able to read "position 30005817344". The regular "dd" command in
> Linux, I think if it gets one error, it will stop. So your attempt
> to copy the disk is likely to fail. If it doesn't fail, then you're
> "ahead of the game". So the following is only necessary, if
> my prediction of disk damage down near the end, holds true.

dd completed without error. It generated a 30005821440 byte file--which
is exactly the size of the "Block device" identified by disktype.

[Grinder]

The image created by dd is 30005821440 bytes (58605120 x 512 bytes)
long. Here are the first 512 bytes of the disk image:

000 | 0000 ...
1AE | ... 0000
1BE | 00003F000CFEFFFF3E000000813D7E03
1CE | 00000000000000000000000000000000
1DE | 00000000000000000000000000000000
1EE | 00000000000000000000000000000000
1FE | 55AA

That looks looks an MBR. I don't know how much partition entry formats
vary, but the one at 1BE can decode like this:

Status/Flags: none
CHS Start: 0 0 63 (matches testdisk)
Partition Type: 0x0C (FAT32X with LBA)
CHS End: 1023 254 63 (address too large to fit?)
LBA Start: 62 (matches disktype)
Sector Count: 58604929 (matches disktype)

- - - - - - - -

Here's the disktype report again:

--- /dev/sdd
Block device, size 27.95 GiB (30005821440 bytes)
disktype: Data read failed at position 30005817344: Input/output error
DOS/MBR partition map
Partition 1: 27.95 GiB (30005723648 bytes, 58604929 sectors from 62)
Type 0x0C (FAT32 (LBA))
FAT32 file system (hints score 5 of 5)
Volume size 27.94 GiB (29998284800 bytes, 915475 clusters of 32 KiB)

- - - - - - - -

Here is what testdisk reported when I told it it was an Intel type
partition table. (At no point did I give testdisk permission to write
to my drive.)

Disk /dev/sdh - 30 GB / 27 GiB - CHS 3648 255 63
Partition Start END Size in sectors
>* FAT32 LBA 0 0 63 3647 250 58 58604801 [NO NAME]

A deep analysis found "Structure: Ok." Trying to list files, though,
produced "Can't open filesystem. Filesystem seems damaged."

- - - - - - - -

Should I just write that image out to a fresh drive and see if testdisk
can repair it?

[Grinder]

Maybe this is normal, but at the 62nd sector, or (I think) what is the
the first absolute sector in the partition, there appears to be another MBR.

446 bytes of zeros, followed by 4 partition entries and the boot signature:

000002000CFEFFFF01000000013D7E03
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
55AA

This one decodes to:

Status/Flags: none
CHS Start: 0 0 2

Partition Type: 0x0C (FAT32X with LBA)
CHS End: 1023 254 63 (address too large to fit?)

LBA Start: 1
Sector Count: 58604801 (matches testdisk, this time)

The next sector appears to be partition information. It's mostly zeroes
but FAT32 and a partition label is in there. It ends with the "boot
signature."

The next sector after that is sparser. Starts with "RRaA," which I'm
getting some google hits as a "sector signature." This sector also ends
with the boot signature.

After that, there are 4 sectors of fill data--"SW2F" repeats over and over.

Then, another partition information sector. WTF? I guess there could
just be some junk data in here if the partition is actually starting
after this?

[Grinder]

Maybe I have messed something up. I've put the drive back into the
camcorder, and it is now reporting Disk Format Error. I cannot induce
it to format the drive, because the unit's touchscreen is kaput.

Here's what I've done to the drive when it was out:

1) Plugged it into windows with a USB adapter. No partition mounted.
When I went to disk management, it offered to initialize the drive,
giving me the option to use an MBR or GUID table. I declined.

2) I ran the windows version of testdisk and performed a deep analysis.
It's my understanding that testdisk will not write to the disk unless
you tell it to Write. I did not tell it to write anything.

3) I ran the Linux version of disktype.

4) I copied the disk using dd.

Is it possible that one of these operations went ahead and wrote out a
guess for the MBR, or in some other way molested the drive?

[Grinder]

TestDisk managed to repair the partition table to the point where I
could get 27.2GiB (nearly the entire capacity of the drive) worth of MPG
files off to a backup drive.

Thanks guys for the insights!

[Paul]

Sorry I've been busy this evening...

It looks like you've made some good progress. Especially
if you got that much data off it.

I can't imagine any of the tools writing to the drive.
I haven't checked the code for disktype, but wouldn't
expect it to have any write logic. And TestDisk shouldn't
do anything either, unless you go to the page where your
new MBR is listed, and you explicitly tell it to do the
update.

The "LBA start" of 62, is because CHS alignment would
suggest starting on the next full "track". There are
63 sectors per track, according to the "fake" CHS value.
The CHS value you saw, is a "flag" that says to use LBA.
And then the LBA sizes are used to work things out.
But the starting alignment, is still influenced by
that choice of 63 sectors per track.

Between sector 0 and sector 63, would normally be
empty space. An exception is when one of the two
GRUB bootloaders is present. As then, some sectors below
63 are used for one of the levels of boot loading.
So there can still be some "content" in there, of note.

If you knew the camera could format the drive again,
you could zero out the drive and put it in the camera.
Then ask the camera to format it, pull the drive,
and see what sectors got overwritten (with non-zero
data).

But seeing as you've got the files, I expect you're
done with the thing. With no working LCD, it's going
to be a bit difficult to use.

Paul

[Frank]

On Wed, 10 Oct 2012 23:39:03 -0500, in 'rec.video.desktop',
in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,

Grinder <gri...@no.spam.maam.com> wrote:

>TestDisk managed to repair the partition table to the point where I
>could get 27.2GiB (nearly the entire capacity of the drive) worth of MPG
>files off to a backup drive.

Excellent work, excellent!

By the way, along with the 30 GB DCR-SR45 that you've got there, Sony
also offered a 40 GB model known as the DCR-SR46. According to the
service manual, both of these two camcorders, along with some other
models in the DCR-SR series as well, all used the same 40 GB HDD (Sony
Part Number 1-797-998-21), so what you have, per Sony's documentation,
is actually a 40 GB drive that contains a 30 GB partition and 10 GB of
unused space.

[Grinder]

On 10/11/2012 1:39 AM, Frank wrote:
> On Wed, 10 Oct 2012 23:39:03 -0500, in 'rec.video.desktop',
> in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
> Grinder <gri...@no.spam.maam.com> wrote:
>
>> TestDisk managed to repair the partition table to the point where I
>> could get 27.2GiB (nearly the entire capacity of the drive) worth of MPG
>> files off to a backup drive.
>
> Excellent work, excellent!
>
> By the way, along with the 30 GB DCR-SR45 that you've got there, Sony
> also offered a 40 GB model known as the DCR-SR46. According to the
> service manual, both of these two camcorders, along with some other
> models in the DCR-SR series as well, all used the same 40 GB HDD (Sony
> Part Number 1-797-998-21), so what you have, per Sony's documentation,
> is actually a 40 GB drive that contains a 30 GB partition and 10 GB of
> unused space.
>

The Toshiba model number and on label specs says that it is a 30GB
drive. I've looked at the drive with a partition editor, and it seems
convinced it's a 30GB drive as well.

[Frank]

On Thu, 11 Oct 2012 01:58:37 -0500, in 'rec.video.desktop',

Interesting. That's proof that Sony service manuals should not be
trusted. Thank you for letting me know.

Try http://www.scribd.com/doc/93867668/DCRSR45 (page 5-2), "Note 1",
where it states "30GB model and 40GB model use the same parts.".

I've suspected the existence of various errors in Sony service manuals
in the past, which is why I qualified what I wrote in my post by using
the phraseology "per Sony's documentation".

They seem to make changes in production which aren't always reflected
in the service manuals, such as in the case where I was working on an
old U-matic deck one day and the service manual kept referring to a
non-existent circuit board where I was supposed to be making
adjustments, although I finally got my hands on a service manual
"supplement" that indicated some units didn't contain that particular
board. Of course, the supplement merely said "some units", rather than
"all units after serial number such-and-such".

Anyway, I hope that all of the files that you recovered were intact
and playable and if for some reason you'd like a complete set of
DCR-SR45 documentation (totaling about 28 MB), including all four
service manuals, just let me know and I'll make them available to you.

Regards,

[Grinder]

Yes, I would. This was a recovery attempt for a client, and I suspect
that I might end up with the unit after delivering the files. The
touchscreen lights up, but is uninterested in responding to button
presses. It might just be a bad ribbon cable or something, so I'll
likely tear it apart. If I have the manuals there is a 10% less chance
I will destroy the unit in the process.

My email is grinder, then there's a 2112, followed by an @ and the ever
familiar gmail.com

Thanks.

[Frank]

On Thu, 11 Oct 2012 13:05:10 -0500, in 'rec.video.desktop',

An e-mail message has been sent. It didn't bounce, so it should be in
your Inbox.

>Thanks.

You're very welcome.

[Grinder]

On 10/11/2012 2:57 PM, Frank wrote:
> On Thu, 11 Oct 2012 13:05:10 -0500, in 'rec.video.desktop',
> in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
> Grinder <gri...@no.spam.maam.com> wrote:
>
>> On 10/11/2012 11:06 AM, Frank wrote:
>>> On Thu, 11 Oct 2012 01:58:37 -0500, in 'rec.video.desktop',
>>> in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
>>> Grinder <gri...@no.spam.maam.com> wrote:
>>>
>>> Anyway, I hope that all of the files that you recovered were intact
>>> and playable and if for some reason you'd like a complete set of
>>> DCR-SR45 documentation (totaling about 28 MB), including all four
>>> service manuals, just let me know and I'll make them available to you.
>>
>> Yes, I would. This was a recovery attempt for a client, and I suspect
>> that I might end up with the unit after delivering the files. The
>> touchscreen lights up, but is uninterested in responding to button
>> presses. It might just be a bad ribbon cable or something, so I'll
>> likely tear it apart. If I have the manuals there is a 10% less chance
>> I will destroy the unit in the process.
>>
>> My email is grinder, then there's a 2112, followed by an @ and the ever
>> familiar gmail.com
>
> An e-mail message has been sent. It didn't bounce, so it should be in
> your Inbox.
>
>> Thanks.
>
> You're very welcome.
>

I have yet to see anything. I'm not sure what gmail's attachment limit
it is, but you might try sending just service manual as a bit of a test.

[Grinder]

> I have yet to see anything. I'm not sure what gmail's attachment limit
> it is, but you might try sending just service manual as a bit of a test.

Ooops, sorry. I see it in my spam folder. Thanks.

[Frank]

On Fri, 12 Oct 2012 07:52:00 -0500, in 'rec.video.desktop',

in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
Grinder <gri...@no.spam.maam.com> wrote:

>

>> I have yet to see anything. I'm not sure what gmail's attachment limit
>> it is, but you might try sending just service manual as a bit of a test.

As you'll see when you read my message, it was not sent as an e-mail
attachment, but rather as a link to a Web download.

>Ooops, sorry. I see it in my spam folder.

Strange that gmail would consider it to be spam. I wonder why.

>Thanks.

You haven't downloaded the file yet. Is everything okay?

[Grinder]

>
> You haven't downloaded the file yet. Is everything okay?

Got it -- thanks.

[Frank]

On Fri, 12 Oct 2012 16:48:20 -0500, in 'rec.video.desktop',

in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
Grinder <gri...@no.spam.maam.com> wrote:

>
>>

>> You haven't downloaded the file yet. Is everything okay?
>
>Got it -- thanks.

Yes, just saw your visit in the log -- you're welcome. Hope that it
proves useful.

Regards,

[Grinder]

On 10/11/2012 1:39 AM, Frank wrote:

> On Wed, 10 Oct 2012 23:39:03 -0500, in 'rec.video.desktop',
> in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
> Grinder <gri...@no.spam.maam.com> wrote:
>
>> TestDisk managed to repair the partition table to the point where I
>> could get 27.2GiB (nearly the entire capacity of the drive) worth of MPG
>> files off to a backup drive.
>
> Excellent work, excellent!
>
> By the way, along with the 30 GB DCR-SR45 that you've got there, Sony
> also offered a 40 GB model known as the DCR-SR46. According to the
> service manual, both of these two camcorders, along with some other
> models in the DCR-SR series as well, all used the same 40 GB HDD (Sony
> Part Number 1-797-998-21), so what you have, per Sony's documentation,
> is actually a 40 GB drive that contains a 30 GB partition and 10 GB of
> unused space.

In spite of my earlier, confident pronouncements, it does appear that
you (and the service manual) are correct here. I'm not sure how I
overlooked it, but the drive plainly has "40GB" printed on it. Earlier
I had looked up the model number and found specs indicating it was, in
fact, a 30GB drive--but I can no longer find that reference. All that I
see now is this:

http://storage.toshiba.eu/cms/en/hdd/consumer_electronics/product_detail.jsp?productid=257

That indicates it is a 60GB drive. Any sort of partition editor I use
sees it as a 30GB drive, and has difficulty writing an new partition
table and formatting the new partition. It will immediately kick an I/O
error on most attempts. I wonder if these problems and the truncated
disk size are related?

Also, if this drive does, in fact, have a 1KB sector size, would that
cause problems with all of these tools that are expecting a 512B sector?
I've download Toshiba's Paragon Alignment Tool to see what it might
tell me.

http://storage.toshiba.eu/cms/en/support_services/advanced_format.html

Of course, it might be a bad drive, or the cheapish LIF-to-USB adapter I
bought might provide an incomplete interface.

[Grinder]

I guess I'm going to start a new thread onthis in alt.comp.hardware.

[Paul]

It occurs to me, that the 1KB sector size may be an issue. Windows
is used to 512 byte sectors. With the new 4KB sectors being something
that only the latest OSes support properly. I don't know where that
leaves a 1KB sector...

Using a recent Linux CD, try "sudo fdisk /dev/sda" type command, and
it should report both the physical and virtual sector size (in case
the drive has some kind of emulation feature). If the Toshiba page you
found is accurate, then fdisk should be able to report that weird 1KB
sector size.

The I/O error might be because some math was done somewhere, assuming
a 512 byte sector. Purely a guess.

Paul

[Frank]

On Mon, 15 Oct 2012 09:24:46 -0500, in 'rec.video.desktop',

in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
Grinder <gri...@no.spam.maam.com> wrote:

>On 10/11/2012 1:39 AM, Frank wrote:
>> On Wed, 10 Oct 2012 23:39:03 -0500, in 'rec.video.desktop',
>> in article <Re: Sony Handycam (DCR-SR45) HDD [Got It!]>,
>> Grinder <gri...@no.spam.maam.com> wrote:
>>
>>> TestDisk managed to repair the partition table to the point where I
>>> could get 27.2GiB (nearly the entire capacity of the drive) worth of MPG
>>> files off to a backup drive.
>>
>> Excellent work, excellent!
>>
>> By the way, along with the 30 GB DCR-SR45 that you've got there, Sony
>> also offered a 40 GB model known as the DCR-SR46. According to the
>> service manual, both of these two camcorders, along with some other
>> models in the DCR-SR series as well, all used the same 40 GB HDD (Sony
>> Part Number 1-797-998-21), so what you have, per Sony's documentation,
>> is actually a 40 GB drive that contains a 30 GB partition and 10 GB of
>> unused space.
>
>In spite of my earlier, confident pronouncements, it does appear that
>you (and the service manual) are correct here.

Okay.

>I'm not sure how I
>overlooked it, but the drive plainly has "40GB" printed on it.

No problem.

>Earlier
>I had looked up the model number and found specs indicating it was, in
>fact, a 30GB drive--but I can no longer find that reference. All that I
>see now is this:
>
>http://storage.toshiba.eu/cms/en/hdd/consumer_electronics/product_detail.jsp?productid=257
>
>That indicates it is a 60GB drive.

Well, according to the official Sony doc, some camcorder models in the
series used a 40 GB drive and some used a 60 GB drive.

>Any sort of partition editor I use
>sees it as a 30GB drive, and has difficulty writing an new partition
>table and formatting the new partition. It will immediately kick an I/O
>error on most attempts. I wonder if these problems and the truncated
>disk size are related?

Interesting, don't know.

>Also, if this drive does, in fact, have a 1KB sector size, would that
>cause problems with all of these tools that are expecting a 512B sector?

Good question, and I must say that I am more than a bit surprised that
the drive uses a 1 KB sector. Very surprised, but then again, I've
almost never worked on a drive from a portable device, aside from
standard notebook computers.

I'm not sure why I say this, but I think that it would have been nice
if the Sony doc mentioned the 1 KB sector size. :)

> I've download Toshiba's Paragon Alignment Tool to see what it might
>tell me.
>
>http://storage.toshiba.eu/cms/en/support_services/advanced_format.html
>
>Of course, it might be a bad drive, or the cheapish LIF-to-USB adapter I
>bought might provide an incomplete interface.

Yes, both of those would seem to be possible. Also, we don't know how
the Sony firmware in the camcorder is managing the drive. It might be
treating it in very strange and unnatural ways for all that we know.