26 Reply by sarami 2025-03-11 17:52:59

  • 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

27 Reply by Nemok 2025-03-15 04:16:30

  • Registered: 2023-03-03
  • Posts: 124

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.

28 Reply by Nemok 2025-04-04 15:06:19

  • Registered: 2023-03-03
  • Posts: 124

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.

29 Reply by Nemok 2025-04-15 17:45:06

  • Registered: 2023-03-03
  • Posts: 124

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

30 Reply by reentrant 2025-04-15 22:26:05

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

Looks nice, could you write something more?

31 Reply by Nemok 2025-04-17 09:44:58

  • Registered: 2023-03-03
  • Posts: 124

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 2025-04-22 01:23:25 (edited by HeroponRikiBestest 2025-04-22 01:24:07)

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

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.