• Registered: 2011-02-20
  • Posts: 1,771

reentrant wrote:

ULONGLONG performanceFrequency = 0;
ULONGLONG performanceCounter = KeQueryPerformanceCounter(&performanceFrequency);
ULONGLONG ticksMicroSeconds = 1000000 * performanceCounter / performanceFrequency;

I implemented the following in a test version(http://forum.redump.org/post/78821/#p78821).

    LARGE_INTEGER freq = {}, current = {}, end = {};
    QueryPerformanceFrequency(&freq);
    double time = 0;

    QueryPerformanceCounter(&current);
    (Read the CD multiple times)
    QueryPerformanceCounter(&end);
    time = static_cast<double>(end.QuadPart - current.QuadPart) * 1000 / static_cast<double>(freq.QuadPart);
DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2023-03-03
  • Posts: 129

Wish I could help you, but for now that's beyond my understanding.

All I know is that BWA builder had an alleged precision of about 6 µs.

  • Registered: 2023-03-03
  • Posts: 129

I did a bit of testing with different time stamp functions. It seems that after simply iterating a printf in a for loop, clock(), QueryPerformanceCounter() in Windows, and clock_gettime() in Linux give extremely close results when CLOCK_PROCESS_CPUTIME_ID is used.

If that behavior is consistent in any situation, which needs to be checked, I find it even harder to understand how one would achieve the task of measuring DPM with these functions, unless the I/O latency is deduced, because they try to assess the same thing, that is the CPU time spent on a process, while the time NOT spent by the CPU is required for DPM (as I see it).

I wonder if calculating the difference between clock_gettime(CLOCK_MONOTONIC) and clock_gettime(CLOCK_PROCESS_CPUTIME_ID) is enough to approximate the drive's latency variations.

  • Registered: 2023-03-03
  • Posts: 129

I have added a graphical representation of the timings in DPM SCN. Simply drag and drop a mds file on 'scan' and press Escape key to close the window. A corresponding .bmp file will be created, along with a .log file that contains the stats and all DPM values in a human readable format.

Linux : https://github.com/jonblau/dpmscn/relea … _64.tar.gz
Windows : https://github.com/jonblau/dpmscn/relea … x86_64.zip

For example, a SecuROM 7 disc (http://redump.org/disc/105429/) :
- timings in red
- timing variations in blue

https://i.postimg.cc/SX7CYMsJ/dmc.png

  • Registered: 2014-10-06
  • Posts: 732

Looks nice, could you write something more?

  • Registered: 2023-03-03
  • Posts: 129

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

32 Reply by HeroponRikiBestest (edited by HeroponRikiBestest 2025-04-22 01:24:07)

  • Registered: 2019-12-25
  • Posts: 444

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.

  • Registered: 2023-03-03
  • Posts: 129

HeroponRikiBestest wrote:

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?

HeroponRikiBestest wrote:

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

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

HeroponRikiBestest wrote:

I can send my awful python scripts here.

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

  • Registered: 2023-03-03
  • Posts: 129

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
https://i.postimg.cc/hht9B3sv/securom-cav-24x-success.png

CLV
https://i.postimg.cc/8f4KjF3v/securom-clv-8x-failure.png


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

35 Reply by HeroponRikiBestest (edited by HeroponRikiBestest 2025-05-31 23:05:11)

  • Registered: 2019-12-25
  • Posts: 444

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.

  • Registered: 2023-03-03
  • Posts: 129

HeroponRikiBestest wrote:

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.

HeroponRikiBestest wrote:

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.