PC3000 DE attr.map to bitmap image

[lcoughey]

Has anyone created or know of a way to translate the sector map file from DE into a nice graphic image showing a clear image of the read patterns for easier explanation to our clients? DeepSpar DRE has it and there are dozens of times a year I wish I could do it with PC3K.

[lcoughey]

Even the zoomed out view of the image map from R-Studio can be screen captured for the client to see.

Attachments

[fzabkar]

Perhaps the easiest approach would be to write a tool to convert a DE map to an R-Studio map.

[lcoughey]

Perhaps the easiest approach would be to write a tool to convert a DE map to an R-Studio map.

Or to a ddrescue map, for that matter.

[fzabkar]

I've already written a couple of map conversion tools. If the DE map file isn't cryptic, I could give it a go.

[Lardman]

If the DE map file isn't cryptic, I could give it a go.

Quick look suggests not. Sample files attached, green = good, black = error, Yellow = skipped. 8GB Flash drive 15633407 total sectors.

Attachments

SAMMPLE_MAP_FILE.zip

(76.46 KiB) Downloaded 18 times

[fzabkar]

I'm embarrassed to admit it, but I can't make sense of the map file.

This is the only number I understand:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  41 43 45 20 4D 61 70 20 46 69 6C 65 00 00 00 00  ACE Map File....
00000010  02 00 FF 8B EE 00 00 00 00 00 EF 00 00 00 00 00
                ^^^^^^^^
           total sectors = 0xee8bff

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030  B4 07 00 00 00 00 00 00 61 00 00 00 00 00 00 00

[Lardman]

That was with the task map type set to "list of ranges" I imagine that's how most of us use it. I've switched it to binary files and it looks straight forward. Not sure what Luke uses as the binary map files produced are considerably larger.

Attachments

sample_map_files_binary.zip

(89.85 KiB) Downloaded 15 times

[fzabkar]

This is how my previous tool converts an MRT Data Explorer map file to a ddrescue map file.

Code:

' ddrescue

'    ?   non-tried block
'    *   failed block non-trimmed
'    /   failed block non-scraped
'    -   failed block bad-sector(s)
'    +   finished block


' MRT

'   x0 = Read Remainder (white)
'   x1 = Read Success (light green)
'   x2 = Read Failed (black)
'   x3 = Skip when reading (yellow)
'   x4 = Read with Error (dark green)
'   x5 = Read without ECC (grey)
'   x6 = Read Timeout (red)

    Select Case sStatus  ' bStatus is MRT hex code
   
     Case "?":  bStatus = 0
     Case "*":  bStatus = 6
     Case "/":  bStatus = 6
     Case "-":  bStatus = 6
     Case "+":  bStatus = 1
     
     Case Else: bStatus = 6
             
    End Select

How do I map PC3K's hex codes to ddrescue's codes?

[Lardman]

10 sectors of each 00 -> 09 and the legend from my version of DE.

Attachments

[Lardman]

You'd think that r-studio would have the option to import the sector map from pc3K natively, would also give us an indication of damaged files. I currently run client report via r-studio but have to give them a damage list from PC3K. Just another example of the lack of joined up thinking in the industry.

It looks like they have their own sector map format too.

[lcoughey]

R-studio map is very similar to ddrescue log, as per my post here
https://www.recoveryforce.com/forums/vi ... .php?t=817

[fzabkar]

I still don't understand these maps. I can see that each byte corresponds to one LBA, and the data within each byte corresponds to a category. Green is 0x01, black is 0x02, yellow is 0x03. What I don't understand is how the same LBA can be both black and green, assuming black is bad and green is good. I assume 0x00 bytes are untried sectors.

1024_green.map

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000002D0  01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01  ................
000002E0  01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01  ................

1024_black.map

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02  ................
00000010  02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02  ................

MRT's map is easy to understand. One byte per LBA, upper nibble = head number, lower nibble = category. The same map handles all categories and all heads.

[Lardman]

Sorry my fault for not making it clearer, each map file is a separate read and after each read I cleared the map in PC3K resetting the file to everything unread (00). Everything 1024_ are all just the first 1024 sectors read in the different states, 1024_last are the last 1024 sectors of the drive also read in those states. It made more sense like that (at least to me) when exporting ranges to look for commonality in the files.