Detect Wii Dual-Layer Discs

[Bombastisch]

I was working on auto-detecting dual-layer wii discs in CleanRip, but my intitial idea to detect this wasn't very clever anyways.

Please take a look: https://github.com/emukidid/cleanrip/pull/73

(I hope this is the correct sub-forum to ask this question.)


AdmiralCurtiss pointed out this idea:
> Can't you instead try to do a read of a sector past the single layer disc limit and see if it succeeds or not?

CleanRip provides this function to read raw bytes:

Code:

/*
DVD_LowRead64(void* dst, unsigned int len, uint64_t offset)
Read Raw, needs to be on sector boundaries
Has 8,796,093,020,160 byte limit (8 TeraBytes)
Synchronous function.
return -1 if offset is out of range
*/
int DVD_LowRead64(void* dst, u32 len, uint64_t offset) {
    if (offset >> 2 > 0xFFFFFFFF)
        return -1;

    if ((((u32) dst) & 0xC0000000) == 0x80000000) // cached?
        dvd[0] = 0x2E;
    dvd[1] = 0;
    dvd[2] = read_cmd;
    dvd[3] = read_cmd == DVDR ? offset >> 11 : offset >> 2;
    dvd[4] = read_cmd == DVDR ? len >> 11 : len;
    dvd[5] = (u32) dst & 0x1FFFFFFF;
    dvd[6] = len;
    dvd[7] = 3; // enable reading!
    DCInvalidateRange(dst, len);
    while (dvd[7] & 1)
        LWP_YieldThread();

    if (dvd[0] & 0x4)
        return 1;
    return 0;
}

But in my tests the function also returned 0, when reading past the size of single-layer disc. It also wrote the same bytes to *dst, when running multiple times, so it wasn't random garbage, but apparently garbage.


So i sporadically looked through Dolphin's code ( https://github.com/dolphin-emu/dolphin/t...ore/DiscIO ), but I did not find any details for dual-layer discs either.
WiiBrew ( https://wiibrew.org/wiki/Wii_Disc ) does also not list any sort of indication in the header of the wii disc, wether it's single or dual-layer.


I am curious if any dolphin dev maybe knows more about dual-layer discs and whats the best way to detect them.
Any help is appreciated! Thanks

[JosJuice]

The approaches I can think of are:

1. Attempt to read past the end of a single layer disc and see if the read succeeds, like you mentioned.
2. Search through the FST of each partition and check if it references any offsets that would be past the end of a single-layer disc. This would probably be the most annoying to code.
3. Supposedly bytes 0x470-0x474 in the decrypted game partition data are 0x7ED40000 for dual-layer discs and zero for single-layer discs. I don't know whether this is reliable. In particular, please check that this works for the earliest released dual-layer game.

I would strongly suggest the first approach if you can get it to work, as it's the only one that's based on whether the disc actually is dual layer as opposed to making assumptions about what the data written to the disc means.

[Bombastisch]

Thank you for your answer.

Turns out I was just a little dumdum and was using the wrong offset. Implementing the first option you listed worked the best.

I have a working solution now ( https://github.com/emukidid/cleanrip/pull/76 )

[DacoTaco]

couldn't stop myself and took a look at the PR
code looks clean, but sadly i don't know enough about the DI (nor cleanrip's code) to know how it would respond to the read on hardware and why the +1 is needed.
if it works, it works *shrug*

a little tip for the future (and that weirdly enough my colleagues at work didn't know either?!) : you don't need to remake a PR if youre changing something in a branch.
git allows to rewrite a branch history/commits with 'git rebase'.
all changes to a branch also instantly change in the PR (new commits, removal or rewritten branch history,... ) !


... god i love git ...