Unsupported format -- Blu-ray

[CaMiX]

AnyDVD is good for bad sector based protections and other protection stuff etc., but I'm not sure about normal unreadable sectors,
based on bad fabrication or scratches causing this.

Still AnyDVD is needed later after the ddrescue process to decrypt the image, for playing or by reripping
The problem is, those programs can't resume if interrupted, if you want to procede the copy/rescue process in another optical drive, which might be able to read out further problematic blocks, which the other drive couldn't.
Also you've to click through error messages about bad sector readings all the time etc.
takes more time etc.
So normal ripping programs are not specialized for Blu-rays and DVDs and CDs on normal unreadable sectors, (not based on a copy protection).

Though "ddrescue" (gddrescue) is bad for Blu-ray discs which ask for bus encryption (only in a capable drive),
and ddrescue is not recommended to be used on bad sectors discs (based on a bad sector copy protection)
But the AnyDVD status window in his logfile does show, "bad sector protection not found".
Also hisc Star Wars discs do not ask for bus encryption so it doesn't matter with his discs that his LG BH16NS40 supports it, the mods/dev explained to me.

So ddrescue could be a first option in this case.

https://en.wikipedia.org/wiki/Ddrescue

ddrescue is included in Knoppix Live Linux System (DVD)
In Debian and Ubuntu the package is called "gddrescue", the cosole program name though is called "ddrescue", not to confuse with "dd_rescue" which is another program.

What he could try to do first is:
Booting Knoppix from DVD or USB flash drive. Then mount his NTFS partition. Run ddrescue from his desired location on his NTSC volume.

Open console/bash/shell/terminal -window
1st step with ddrescue: ddrescue will first rescue only the easily recoverable (relatively quickly readable) data:

ddrescue --idirect --sector-size=2048 -n -v -v /dev/srX ddrescue_Star_Wars_Attack_Of_The_Clones.iso mapfile_ddrescue_Star_Wars_Attack_Of_The_Clones.log

--idirect: Direct access from the input device (source), not using internal RAM/kernel buffers
but this option can also be left out, not so important, but doesn't harm.
All my drives (LG BH16NS40, Pioneer BDR-205, LiteON iHOS-104) seem to provide raw access.

--sector-size=2048: for the Block size, on DVD and Blu-ray UDF block/sector size is 2048 Bytes
-n: skip the scraping phase: not easily and not quickly reable sectors are "ignored" and jumped across until next readable sectors reached. Avoids spending a lot of time trying to rescue the most difficult parts of the file/(or disc).
-v: verbose: printing more precise info how it's progressing. WHen more specified it's more detailed.
/dev/srX : Blu-ray source drive
ddrescue_Star_Wars_Attack_Of_The_Clones.iso : image_file_to save rescued data to
mapfile_ddrescue_Star_Wars_Attack_Of_The_Clones.log : name for map file ,(only) all failed blocks are marked and listed. Needed for proceeding from last point.

So the mapfile name is important, so that ddrescue can resume further, you don't need to restart the process from the beginning, especially useful if it takes several hours
You can "abort" the process with STRG+C (CTRL+C) at any time and procede when the mapping logfile is specified.
You can take any map file name and image file name, but should not rename them for further rescue attempts!!

2nd step, leaving out "-n" option, for trimming and scraping retrying the failed bad blocks.
ddrescue --idirect --sector-size=2048 -v -v --retry-passes=2 /dev/srX ddrescue_Star_Wars_Attack_Of_The_Clones.iso mapfile_ddrescue_Star_Wars_Attack_Of_The_Clones.log

The failed blocks are filled with zeros in the ddrescue iso-image file and listed in the log file. If more sectors gets rescued, their entries are deleted within the map logfile, so it does not need to retry those, because already recovered.

The LG BH16NS40 lists the correct sector count on Blu-ray discs, though my LiteON iHOS104 doesn't!
Here the "--complete-only" option is helpful.
If you had such drive, the iso could get corrupt if you left out the option "--complete-only"
I had to rerun ddrescue deleting the old iso because I forgot, that my Liteon iHOS104 reports higher sector count than actaully is. The iso was 2 Gigabytes bigger suddenly when changing the disc into the Liteon to procede further to recover more sectors.
Additionally with --complete-only option the iso with the same size is in my Pioneer
and BH16NS40.
It's always useful to have one or two backups of the different ddrescue steps.

ddrescue --idirect --sector-size=2048 -v -v --complete-only --retry-passes=2 /dev/srX ddrescue_Star_Wars_Attack_Of_The_Clones.iso mapfile_ddrescue_Star_Wars_Attack_Of_The_Clones.log

https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

3rd step rerun the process: with two addional parameters: --retrim --try-again
ddrescue --idirect --sector-size=2048 -v -v --complete-only --retrim --try-again --retry-passes=2 /dev/srX ddrescue_Star_Wars_Attack_Of_The_Clones.iso mapfile_ddrescue_Star_Wars_Attack_Of_The_Clones.log

Addiobaly if you have a spare disc, even if dfective, but mayba at other sectors, or the bad sectors are problematic but more easily to recover, you can rerun with:
ddrescue --idirect --sector-size=2048 -v -v --complete-only --retrim --try-again --retry-passes=2 /dev/srX ddrescue_Star_Wars_Attack_Of_The_Clones.iso mapfile_ddrescue_Star_Wars_Attack_Of_The_Clones.log

in another optical drive, didn't he buy a spare drive? Same model? And maybe he has a friend with snother Blu-ray drive model, he can borrow, where he can resume further the process!
And maybe he has spare discs with identical data, it's a further chance to recover rest failing blocks.

After 100 percent is recovered he can mount the ddrescue iso in Virtual Clone Drive and decrypt it normally with AnyDVD.
It's also working with not fully rescued images, but some of the data then is wrong (those filled with zeros from the missing failed blocks)
Handbrake transcoder might make problems perhaps if not fully recovered, (but maybe I'm wrong)

How do you know what the sector count is for each drive? Separate command?

 

[theosch]

I guess there is no such command to get to know the correct sector count, if you use an optical drive which reports the wrong sector count.

You need to have two other optical drive models which report the same sector count each other, to know who's the culprit.
So you need to put the disc into another " good" optical drive and read out the sector count value from there.
But don't worry most drives report the correct sector count.
I wrote this addiotnal info just to make sure, that s.o. using ddrescue not gets a "wrong" image if he had such a drive (LiteOn iHOS-104) like me.
But I guess I have rather confused the people.

See below"Update", at the bottom of this post what you can do if you had been using a "bad" drive for ddrescue at the beginning point. I've run several tests, so there's a solution, but you still need other "good" optical drives which reports the correct sector count.

When you insert a Blu-ray disc into an optical drive and it has initialized the disc after half a minute:

The command to see the size of the disc (is in KibiBytes=1024 Bytes) reporting of block device such as (BLu-ray) is as follows, in a console/bash/shell/terminal: type in:
cat /proc/partitions

It will list something like that:
8 0 1953514584 sda
8 2 14651248 sda2
8 3 14651280 sda3
8 4 1924209472 sda4
8 16 1953514584 sdb
8 17 2548 sdb1
8 18 14651252 sdb2
8 19 14651280 sdb3
8 20 1924209472 sdb4
" "_" " 48828125 sr0

Example:
It would look like this if an ODD was connencted with a Blu-ray with exact 50 GigaBytes used space (50* 1000*1000*1000 Bytes)
(This is an example how it would look with a 50 Gigabyte disc, when one ODD connected to the computer)
The sizes above are in KibiBytes =>48828125 KibiBytes =48828125 *1024Bytes = 50,000,000,000 Bytes (50 GigaBytes)

If there are two ODDs connected, there cat /proc/partitions will list two lines.
Example:
{......................}
" "_" " 48828125 sr0
" "_" " 44040372 sr1

If you want to know the sector count used on your Blu-ray, read the value on what "/cat/proc/partitions" lists within the line next to sr0.
Then multiply that with 1024 and divide that with 2048. (Or devide this with 2)
If converted this way with a calculator, you'll see it will match with AnyDVD status window and ImgBurn etc. If you multiply that with just 1024, youl see also it will match with the file size (in bytes) from the iso file.


UPDATE:

I now had problems ripping another Blu-ray disc from Star Trek Enterprise (also sector reading issues).

I wanted to know if ddrescue has done its job really 100% correctly, because a different Blu-ray disc which I had recovered 100% previously with ddrescue, had some picture artefacts.
Those artefact can also be a result from a bad video recording or bad video mastering.
Still that made me a bit "unsure" about ddrescue so I wanted to check ddrescue.

So I've run a few more easy tests between ddrescue and ImgBurn (AnyDVD off) with another disc which also has bad sector issues (a few smaller areas of a bit problematic sectors).

To do that you can make two (2) image files from the same disc, one image from ImgBurn (AnyDVD disabled) and one image with ddrescue.
Then making checksums of both images and comparing, and hoping it won't differ.

Fortunately with one drive model (LiteOn) it seemed possible reading all sector for ImgBurn without swapping drive+resuming, because ImgBurn doesn't support swapping and resuming in another drive.
Still I wasn't so clear to me according to the ImgBurn-Log-Window that ImgBurn rescued all.

Then I tried ddrescue, also with ddrescue of course the LiteOn seems to read all problematic sectors, too, with some restoring attempts.

The problem is, that my LiteOn often reports a wrong sector count (higher) and the imaging file from ddrescue can get bigger than from all other optical drives which report the accurate sector count.
This could "falsify" the checksum result of ddrescue.
Fortunately creating images with ImgBurn creates correct sized images, even though LiteOn drive reports higher block count.
(But in ddrescue it does)

So I had to start ddrescue at first in my Pioneer drive or LG BH16NS40, to prevent that, which are reporting the correct same sector count.
And if needed, proceeding ddrescue in my LiteOn, without chnging image size with: --complete-only
(Starting ddrescue at first in the LiteOn, with --complete-only -option, gives only an error message and ddrescue won't start at all)

But ddrescue didn't go any fast ahead and it took endless long between the PIoneer BDR-205 and LG-BH16NS40.
So I proceeded the disc in the LiteOn with --complete-only and rescueing the rest got done within minutes

Then I compared those encrypted images from ImgBurn (AnyDVD was off) and "ddrescue". The checksums of both files are identical.
--------------

The next thing I tested: I wanted to know if making a decypted image (AnyDVD ON) of the 100%-recoverd-ddrescue-image would differ from the decrypted+recovered-image, which was made directly from the BD-ROM, (AnyDVD ON) with letting ImgBurn do the recovering.
This is interesting also, to see if s.th. would get decrypted in another way when recovering+decrypting in one procesc with ImgBurn+AnyDVD on from the original disc (direct method) than if you did with the 2-step-method with ddrescue and decrypting afterwards with ImgBurn+AnyDVD).

But the checksums differed.

Fortunately this is just a falsified result,
because I used my LiteOn (AnyDVD on), and AnyDVD alaways creates a disc.inf file when decrypting file, in the root directory of the dcrypted image.
In the disc.inf file is some text, which differed from the decrypted image, made from the ddrescue image in the second step with ImgBurn+AnyDVD on. The difference is only in the sector count number text within disc.inf between the LiteOn drive and Pioneer+LG.

First I was wondered that both images differed, I wanted to know what the difference is, and hoped it's not in the video files.
So I mounted the decrypted 100%-recovered-ddrescue-image and the decrypted+hopefully-100%-recovered-image from ImgBurn.
Than I ran "diff -r" command of the root directory and all sub-directories between both images and the result was, and "diff -r" showed the difference, and that was only within the .inf file (sector count number)
---------------------------------------------------------
Interestingly ImgBurn does not create a bigger image, neither at copying to encrypted image nor to decrypted image, as ddrescue would do.
------------

(If you make an encrypted image of the disc (AnyDVD off) with ImgBurn, no disc.inf is created, and the original disc doesn't have one.)
So it's not so strange that the 100%_-recovered-ddrescue-image and the 100%-recovered-ImgBurn-image without decryption (AnyDVD OFF) are identical (because both checksum identical)

--

The next thing I tested:
I started ddrescue at first with the LiteOn drive only, creating another iso-image, which of course, creates a bigger image, due to higher sector count reporting.
It ran through 100%, too, took some minutes rescueing the problematic sectors areas.

Then I cut off the file difference, the file-size-difference, so what's too big compared to the other ddrescue-image which has the correct sector count, because NOT started in the LiteOn drive at first.

Then I ran a file compare check between the truncated-100%recoverd-ddrescue-LiteeOn-image (which now has the same correct size) and from the image from the other drives at start.
The file checksums are identical.

I've also checked before the too big image with hexedit, so it looks like that there are just zeros added at the overhanging part.

But I should remember not to create a decrypted image with my Liteon drive (AnyDVD on). Because AnyDVD understandibly writes the wrong too high sector count into the disc.inf file.
If I do, I'll need to do some changes in the iso file with UltraISO for example afterwards.
First reading the sector count which the Pioneer/LG driver reports and edit the number within the disc.inf.