why appear UHD mediums bigger than what one can actually read? [solved]

[coricopat]

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:

...
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]

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]

Just for the records:

A very knowledgeable user here on the forum mentioned in some private conversation that this discrepancy is actually a bug in Pioneer devices (not really sure whether all Pioneer devices/firmwares are affected, but at least it seems all of the different ones that I have).

With a non-Pioneer device, the Linux kernel shows the same value for track size and read capacities (respectively the device reports the same values for both to the kernel).