Analyzing Alcohol 120% DPM

[Nemok]

The two curves at the top allow to have a quick look at the whole disc.
The two curves at the bottom focus on the first 750 samples to zoom in on the first region's pattern found in SecuROM 4.8+ discs.

This pattern is identical for all regions, and highly specific. It is not 100% specific to one disc in particular, as two different games from the same publisher might use the same pattern, nethertheless, as far as I know, one particular game is always associated with the same pattern.
On that matter, it would be possible to obtain a reproducible characteristic for DPM, as opposed to hashes, by using the pattern more or less like a barcode, translated to a series of numbers.

In the log, the two most important things are :
- the layout : unreliable (bad dump), regions x spikes per region count (SecuROM dump), normal (non-SecuROM dump).
- the curve % : a "smoothness" score (the closer to 100%, the cleaner in terms of analog noise).

[HeroponRikiBestest]

I only just saw this thread today. I had already been working on something that can read mds DPM, do curve smoothing, attempt to convert the securom spikes and a second smooth curve, and write back to an MDS file. Two things

- Have you still not figured out how to read the 4 byte DPM values from .mds files? They're pretty simple, and they've already been documented at both aaru and cdemu. I figured you have by now given it's well documented, but I just wanted to make sure.

- If I'm reading this all correctly; is there currently a way to get timing values with DIC, and an equation to convert those timing values to angles or rotations per sector or anything like that?

Those were the 2 major pieces I've been missing. I can send my awful python scripts here, but I want to know both of those things first. They're pretty haphazard and I'd need to clean them up before sending them here.

[Nemok]

Have you still not figured out how to read the 4 byte DPM values?

How would any program using DPM work without being able to read it?

Is there currently a way to get timing values with DIC?

Not really, DIC test build gives incorrect values and the reason is unclear.

I can send my awful python scripts here.

If you think it might be useful, don't hesitate.

[Nemok]

One thing about dumping DPM timings that should be mentioned explicitly, is that a constant angular velocity reading seems mandatory.

Obviously, the shape of the timings curve strongly suggests that, but the best argument is in fact the inner/outer edge timings ratio : it equals 2.4 for a CD with around 333 000 sectors, which is EXACTLY the theoretical bitrate increase ratio in CAV mode.

Transfer rates analysis with either constant linear velocity (CLV) or constant angular velocity (CAV) also proves that density variations in SecuROM discs can be detected using CAV, but not with CLV.

CAV


CLV



@sarami @reentrant
Do you know how to force CAV mode?

[HeroponRikiBestest]

How would any program using DPM work without being able to read it?

I apologize if I was unclear; I don't understand how that response relates to the question I asked. As far as I saw from reading this thread, you were unable to read DPM from the .mds format, and switched to using a different format instead. Is that correct?

Anyhow; rereading my previous message, I was really vague about what my roadblock still was. The one thing I'm missing is getting the correct value for microseconds per rotation. I understand that the way you're supposed to do this is by using Force Unit Access (on a drive that obeys, this, anyways) and constantly re-reading the same sector; the time it takes to re-read it each time should be the amount of time it takes to read 360 degrees, since the drive needs to make a full rotation to re-read the same sector. Once you have that, the rest of the math necessary is pretty trivial. My problem is, the values I get from trying to do this just don't seem to make sense. I don't know if I'm supposed to be compensating for scsi latency somehow, or if I need to compensate for rotational latency, or what.

Tl;dr: if someone can figure out how to get (micro)seconds per rotation, which is supposed to be done via repeatedly re-reading the same sector, that would be pretty much everything I need to make proper DPM/MDS dumps.

[Nemok]

As far as I saw from reading this thread, you were unable to read DPM from the .mds format, and switched to using a different format instead. Is that correct?

No. There's probably just a confusion between reading and creating DPM. Reading from files is easy. Creating values from the disc is not.

re-reading the same sector; the time it takes to re-read it each time should be the amount of time it takes to read 360 degrees

Alcohol does not do that. It would add a variable and unpredictable amount of mechanical delay due to the non-continuous read.

[MrPepka]

If anyone is still working on MDS, a decryptor for MDSv2 and MDX files has appeared online. I don't know if it has any use for DPM, but it's worth checking out.
https://github.com/Marisa-Chan/mdsx/