Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 7th February 2024, 22:44   #1  |  Link
coricopat
Registered User
 
Join Date: Jan 2024
Posts: 27
why appear UHD mediums bigger than what one can actually read?

Hey there.

I'm fairly new to making backups of BDs/UHDs. I do everything under Linux.

What I've learned so far is more or less:
  1. DVDs: Easy to backup/decrypt due to CSS being a joke. Some drives (but interestingly not only), do however give "scrambled sector errors" unless one plays back the DVD with e.g. mpv and libdvdcss.
  2. (non-UHD) BDs: Easy to backup, unless they use bus encryption and a bus encryption capable drive is being used. One can just use dd on Linux and create a full dump of the UDF image. Playback then works - unless it uses BD+ or BDJ - with e.g. mpv + libaacs, given the key is already known.
  3. UHD BDs and (bus encryption enabled) (non-UHD) BDs: Mostly the same, but one needs a LibreDrive and MakeMKV to get it into LibreMode. But...

... at least for UHD BDs (well so far I only have two ^^) I noted something odd:

On (non-UHD) BD, dd would just run through and copy as many 2048B sectors as the kernel thinks the medium has. Seems like a perfect backup to me.

On a UHD BD, dd would error out with some unreadable sector errors.
The dumped UDF image seems however to be perfectly valid... comparing all files of the mounted image with the non-decrypted backup create by MakeMKV, they're bitwise identical.

On both UHDs I have, dd read exactly 4GiB (4*1024*1024*1024) less than what the kernel thought the block size would be.

Now using a tool like dvd+rw-mediainfo would show me:
Code:
...
READ DISC INFORMATION:
 Disc status:           complete
 Number of Sessions:    1
 State of Last Session: complete
 Number of Tracks:      1
READ TRACK INFORMATION[#1]:
 Track State:           complete
 Track Start Address:   0*2KB
 Free Blocks:           0*2KB
 Track Size:            42097152*2KB
FABRICATED TOC:
 Track#1  :             14@0
 Track#AA :             14@40000000
 Multi-session Info:    #1@0
READ CAPACITY:          40000000*2048=81920000000
(numbers are made up, but relatively correct to each others)

So the value for the read capacity would be exactly what dd was able to read.

The track size, would be what the kernel though the block size of the medium to be (and what dd tried to read, but then failed).


Long story short:

Does anyone how that discrepancy comes? And why it seems to be always 4GiB (well at least on those 2 mediums I own so far)?

Thanks,
Coricopat.
coricopat is offline   Reply With Quote
Old 15th April 2024, 23:11   #2  |  Link
coricopat
Registered User
 
Join Date: Jan 2024
Posts: 27
FYI: Got another UHD meanwhile, and there the discrepancy ain't 4GiB, but rather some apparently completely random number. Still pretty odd, that then just by chance I had gotten two UHDs where it was exactly 4 GiB.

Still, don't understand why for UHDs there's that discrepancy but not for non-UHDs (if it's the lead out, I'd have expected that both have it).
Also the UDF also seems to somehow know about that (udfinfo lists it as behindblocks=<discreancy in blocks>).
coricopat is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:23.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.