Page 1 of 1

an offtopic question - physical data location on the disc

Posted: Tue Sep 01, 2020 11:46 am
by mike admin
Hi everyone. This is a call for help - hopefully someone, who knows a thing or two about optical media could help me. It turned out that I know very little about the topic, and I don't have a time machine to go back and ask on cdfreaks forum :)

So, if anyone can answer the following question, or knows where to get the answer, this would help a lot:

A regular double-layer BD-ROM disc.
Imagine one wants to figure out physical location of the data, specifically given the user LBA, get the answer - what layer this sector/cluster is located on.
The bounds of the layers, specifically LUA/FUA values can be obtained from the disc structures. However I do not understand how the data is distributed or padded. Let's say that the disc contains two layers, the data zone of each layer is 1000 sectors in size. The total capacity of the disc (as returned by read_capacity) is 1500 sectors. So, how is the data located:
a) 1000 sectors on layer 0, 500 sectors on layer 1
b) 750 sectors on layer 0, 750 sectors on layer 1
c) something else?

Any pointers are very welcome. Thanks!

Re: an offtopic question - physical data location on the disc

Posted: Tue Sep 01, 2020 7:57 pm
by Coopervid
Mike,

I'm not completely sure about BD-ROM but what I know that they harmonized the whole BD-ROM, BD-R and BD-RE spec. BD-R double layer: You can't influence the layer break. The drive just burns to the end of layer 0 and then switches to layer 1. That is also the root cause of many issues at the layer break with cheap discs and bad burning strategies. Especially LG burners are bad. Pioneer burners handle the layer break better. With DVDs you could influence this and avoid the border area where cheap discs failed.

I suggest just ask in the Imgburn forum. LUK = LightningUK is the author of the program and has a very good knowledge about discs, formats etc.

https://forum.imgburn.com/

Re: an offtopic question - physical data location on the disc

Posted: Tue Sep 01, 2020 10:08 pm
by mike admin
Thanks for the link, should have thought about this one...
Coopervid wrote:
Tue Sep 01, 2020 7:57 pm
That is also the root cause of many issues at the layer break with cheap discs and bad burning strategies. Especially LG burners are bad.
Layer break is a source of all sorts of bugs on LG drives, that's for sure. The reason I asked the question in a first place - the next version of MakeMKV will have speed control feature improvement called "low-speed safety zone". When reading a file that spans multiple layers, MakeMKV would slow down to minimal speed around layer break and then speed up again. In my testing that worked quite well to avoid drive firmware bugs caused by LibreDrive unrestricted speed.

I almost got it working, but need more knowledge than I posses...

Re: an offtopic question - physical data location on the disc

Posted: Wed Sep 02, 2020 12:13 am
by SamuriHL
Oh HELL YEA! Cause then we can safely utilize speed control on triple layer discs. SWEET! I hope you get this figured out.

Re: an offtopic question - physical data location on the disc

Posted: Wed Sep 02, 2020 8:50 am
by Billycar11
you could just watch it burn and see when the laser restarts for the new layer and looking how far you are through burning. these drives are very easy to make run open air ⬇
Image

Re: an offtopic question - physical data location on the disc

Posted: Wed Sep 02, 2020 9:45 pm
by Coopervid
Mike,

I saw your chat on Imgburn. LUK's answer was pretty much generic and not very detailed. Maybe you should identify yourself as the author of Makemkv - what you didn't do. My gut feeling is that LUK's answers would be more elaborate then. And since this is not anyway related to copy protections he would have no issue to start an inside conversation. You also don't want to compete with his program regarding disc burning anyway.

Re: an offtopic question - physical data location on the disc

Posted: Sun Sep 06, 2020 2:26 am
by kurayamino
A careful analysis of the ioctl entry point in a drive's firmware might lead to something interesting. Even if this results in a semi-drive-specific solution, programmers are lazy and probably reuse much of the same code between drive generations. You might discover a Renesas or MTK specific ioctl which would work across a wide range of drives.

Perhaps you are approaching the problem from the wrong angle. If the vast majority of users are accessing commercial Blu-Ray discs, the AACS content certificate has embedded layer information. You could use that to form an educated guess, at least at a hundred-kilobyte-ish range.

Re: an offtopic question - physical data location on the disc

Posted: Sun Sep 20, 2020 8:40 am
by RibShark
Is there any particular reason you can't just get the layerbreak LBA from the PIC (Permanent Information & Control data zone), and get the LBA+size of the file you are reading from the filesystem, and see if (lba_of_file <= lba_layerbreak && lba_of_file+size >= lba_layerbreak), and slow the drive down if so once you are reaching within a certain bound of the layerbreak LBA?

Command to do this would be READ DISC STRUCTURE as defined here: https://www.t10.org/ftp/t10/document.05/05-206r0.pdf
AD 01 00 00 00 00 XX 00 10 04 00 00
where XX is the layer you want info for, and "10 04 " is the allocation size (which is always 4100 for Blu-Ray Disc Information).

Structure of the returned data can be found at: https://github.com/aaru-dps/Aaru.Decode ... -ray/DI.cs
You are looking for the first/last AUN of the data zone, to convert this to LBA simply subtract 0x00100000.

Re: an offtopic question - physical data location on the disc

Posted: Mon Sep 21, 2020 5:27 am
by kurayamino
I don't see different AUN start/end values when I specify different layers in the CDB at offset 6. Super hacky POC code attached -- have I done something wrong?

Re: an offtopic question - physical data location on the disc

Posted: Mon Sep 21, 2020 7:53 am
by RibShark
kurayamino wrote:
Mon Sep 21, 2020 5:27 am
I don't see different AUN start/end values when I specify different layers in the CDB at offset 6. Super hacky POC code attached -- have I done something wrong?
Hmm, I'm getting the same results. Doesn't match the documentation I found for sure.