Search options (Page 1 of 2)

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?

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

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.

About reverse engineering, I'm not sure that the alcohol application is the best candidate to start from. I've only recently discovered that the old .bwa file format used by Blindwrite back in 2002 was in fact storing DPM information the exact same way than the very latest Alcohol 120% version released in 2023.

The thing is that those .bwa files were created by a much smaller dedicated stand-alone program called BWA builder. Since smaller probably also means it's simpler, it might be more interesting to analyze it with Bus Hound, or even to decompile it.

The DPM sample itself I guess.

DPM sample     value     timing

1C 05 00 00    1308
38 0A 00 00    2616      1308
53 0F 00 00    3923      1307
6E 14 00 00    5230      1307
88 19 00 00    6536      1306
A2 1E 00 00    7842      1306
BB 23 00 00    9147      1305
D4 28 00 00    10452     1305
ED 2D 00 00    11757     1305
05 33 00 00    13061     1304
1D 38 00 00    14365     1304

sarami,
If I rely on the values you were getting in 2020, the sampling seems to be wrong in the first place :

value ?        timing ?

154.500100
154.566300     0,0662
154.758100     0,1918
154.850500     0,0924
154.853000     0,0025
155.114800     0,2618
155.013000     −0,1018
155.249500     0,2365
155.350000     0,1005
155.493100     0,1431
155.512100     0,019
155.672400     0,1603
155.690200     0,0178
155.774200     0,084
156.011200     0,237
156.051600     0,0404
156.179200     0,1276
156.326700     0,1475
156.385200     0,0585
156.486800     0,1016

These timings look inconsistent. I would be curious to see if they also vary across multiple dumps though (same disc, same drive, same settings).

Thank you for sharing that code reentrant.

That's indeed the core logic involving the use of thresholds, obviously due to the analog nature of DPM. Even as is, it already worked quite well with DVDs because what you called 'readingTimeDifference' was spread across significantly less sectors than the length in sectors that's used for sampling (corresponding to the 'resolution') which made the detection of a 'range' in the same pass way more feasible. For CDs however, 2 to 3 samples are actually needed to describe that timing difference...

I will, thank you Deterous.

Data sectors, as opposed to audio sectors, are all structured this way: sync, addr, mode, +/-subh, data, +/-edc, +/-null, +/-ecc.
The mode consists of one single byte located at the 16th position of every sector and can easily be checked with an hex editor.

Some examples:
- a mode 0 sector
00 FF FF FF FF FF FF FF FF FF FF 00 25 59 34 00
- a mode 1 sector
00 FF FF FF FF FF FF FF FF FF FF 00 10 38 72 01
- a mode 2 sector
00 FF FF FF FF FF FF FF FF FF FF 00 54 17 36 02

If you are a Windows user, I would suggest to use HxD to open your disc image.

Alright... f*** consistency then

0xbe can be trusted to retrieve correct information from perfectly standard non-protected single-session single-track mode 1 CD-ROMs with no mastering error only, problem is you just can not guess, and that's part of the reason why it will never be "enough" for building a database. From personal experience, 0xbe drives gave matching results for more than 90% of PC games, including mode 1 + audio discs with the help of EAC.

Anyway, this is an awesome feature, well done sarami!

Maybe we should start a dedicated thread so that everybody can post their widest range with BadSectorCnt=0, identical hash, drive info, for every Tages disc...