coricopat
7th February 2024, 22:44
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:
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.
(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.
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.
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:
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.
(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.
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.