New dreamcast dumping program (test please)

[tossEAC]

I tried but it wouldn't rip, just hung half way, then i tried without the fake reads, and it wouldnt even start.

[jamjam]

Come on man. Vague descriptions won't help at all. From that all I can give is vague advice. Problems with starting may well be the same problems that occur with the guide (sometimes you have to try the trap disc multiple times or stop start before it'll take).

What do you mean by hung half way through? An error box popped up? It sat there looking pretty? It started getting read errors all the time?

Please follow this:
Use -df to not delete the .hsh or temp section files.
If any complete sections are saved to hdd, create an md5 file for comparison with the .hsh files
Find the dcd.log so I can see your console output
Send me everything. md5, .hsh, dcd.log, your drive, the game title/region/redump entry
If it hangs, where, what was the last thing it said it was doing
Write down what any error messages say
Less is not more. Send me whatever you have even if you think it's useless. If I have nothing, I can do nothing.

Problems I have found with my own testing:
Some discs have a lot of read errors right from the start of execution, with the odd dump but largely read errors. Exiting and starting the program a few times has got some working. Once they got started they executed ok.

Some discs dump fine and dense.bin is created, but ice.exe shows that the dump has errors. I had hoped that by verifying the dump that most of those errors would go (on the premise that bad dumps due to scratches would rarely match). It seems successful matching reads don't always mean correct reads. Suggestions as to how to reduce this issue? Of course it's possible to detect when ice gives errors and try to rerip, but anything I can do at the ripping stage?

[tossEAC]

It hung halfway meaning it initaial dumped half the disc then hung, as in got no further, and i waited half an hour.

The other try, i couldn't even get the disc to start dumping, with the fake reads disabled.

The first time i tried on my 162c it got loads of matches, but i checked them against previous matches from v0.2  and their were huge differences like half the bytes were completely different, infact their was very little the same. And i first tried on 162d and that got some matches and they were also different to previous matches.

And I couldn't post all this info last night because redump, was not working very well.

[tossEAC]

A new test which I will edit further as it progresses.

TEST:

Disc = Dreamon Vol.17 (undumped this disc) have multiple copies.
Condition = A few light scratches, never been cleaned aggressively, should be good to read.
Drive = SHD-162D

DCdumper 0.2a - used so that I can compare to 0.4a
Faked my own read from 50000 with cdrwin.
Initial Dump = Section 1-49 all ok.
PASS 2 = Section 1 - read error, Section 2 - 49 MATCHES on all. It gave up trying to read setion 1, will start it again and get section 1 to read.

Re-started, fake read with cdrwin, initial dump section 1 ok, pass 2 matched, dense bin created.
Ran ice.exe all tracks ok (75) errors in last data track (in other words) a perfect dump.

No I will remove Section 2,3 & 4, and re run with 0.4a

TEST 0.4a
removed section 2,3,4 in order to force 0.4a to redump these sections only.
PASS 1 - Initial dump. All ok.
PASS 2 - Matces. On all. But guess what md5's differ from first dump with 0.2a, I already know whats going to happen

dense bin created with 0.4a

Extracted with ice, and im expecting some errors in the first track at least.

Wrong it works fine, weird.

The files are not the same though, so it must be some magic going on,

But at least you can relax my tests prove 0.4a works fine, but I don't know why it hang at around section 40.

Will edit to add more as the test completes.

Once I have a good dump with 0.2a Im going to check with ice exe, then im going to manually remove a couple of early bin files, and try to dump it with 0.4a. Hold tight for the results jamjam.

I was busy editting XML monkey files all last night hehe

[tossEAC]

BIG BIT OF WORRYING NEWS.

The dense bin with 0.2 and extraxted with ice.exe, said the usuall, no errors in all tracks except (75) in last data track, Normal.

The dense bin with 0.4a and extracted with ice.exe, also said the usuall, no errors in all tracks except (75) in last data track, Normal.

But and theirs a BIG BUTT, the 0.2a extracted tracks matched the database, BUT the one with 0.4a Track03 was not a match to the database. So definately proving 0.4a produces bad dumps.

But the BIG BUTT is why did ice exe say all was fine. Could this mean dumps we have submitted before are not fine even if ice exe said they was.

Really worrying to see ice.exe say nothing was up when infact their had been major problems. Who knows do we have some bad dreamcast dumps.

[iR0b0t]

@tossEAC:
ICE creates a correct output thats for sure!
You would not be able to match tosec stuff otherwise also.
There is nothing to worry about 

@jamjam:
tossEAC is right, the newer version (0.41a tested) creates wrong output,
i have not compared what exactly is wrong for now.

here some logs for this dump https://redump.info/disc/17364/
dcdumper_v0.41a

Code: Select all

DCdumper.exe DCdumper h -i170000 -df -p2 

Handle acquired.
Load disc: Done.
Sector map created.

..................:::::::::::::::: PASS 1 ::::::::::::::::..................
Reading section 1: 044990-214989 - Initial dump.
Reading section 2: 214990-384989 - Initial dump.
Reading section 3: 384990-549150 - Initial dump.

..................:::::::::::::::: PASS 2 ::::::::::::::::..................
Reading section 1: 044990-214989 - MATCH: 2e2d69e5e0abe8c85d3849f90da6d9f3
Reading section 2: 214990-384989 - MATCH: 4e1122093a6f200462e3a7e8c38680c5
Reading section 3: 384990-549150 - MATCH: 033d6f70182a6ce063c99f6b7186c5a3
Creating dense.bin: Done. Pass this to ice.exe

hash files contain the same values as above.

would be nice to have no "dcd.log" created if DCdumper is idling or showing the help window only

[iR0b0t]

It seems the drive returns some amount of correct data on each chunk it begins to read (probably the same amount you requested on the first read attempt, i have not looked inside the code now, so just assuming).

The rest of a chunk is most likely generated, as it is created with an ultra speed the real drive would never reach!!!

[jamjam]

Found a problem with the reading, will test before posting a new binary. If the problem is how I think it is, why it doesn't mess up everything is a mystery. For any who still want to test 0.41a, use -i26 as it should bypass the problem I can see.

DeviceIOControl is called to read each section 26 sectors at a time, and you seem correct that it messes up sometime after the first DeviceIOControl call.

Ultra-speed chunk generation sounds very bad, but plausible if windows keeps a record of the last successful read attempt.

Now no log is created unless the arguments are parsed correctly and it will try to dump something.

[jamjam]

Redid a dump that was failing ice on 0.41a, this is the result:

Code: Select all

ice @20090609 / themabus@inbox.lv
---------------------------------
dense.bin
---------------------------------
Accessing                       : ok
Seeking 1st valid Mode1 sector  : ok
 LBA found                      : 44990
 @file offset                   : $0000004C
 Scrambled                      : TRUE
Seeking LBA 45000               : ok
 Combined offset (samples)      : 5899
Parsing IP.BIN                  : ok
 Writting 'ip.txt'              : ok
Parsing TOC                     : ok
 TOC entries                    : 20
 Writting 'redump.cue'          : ok
---------------------------------
03  Mode1   45000  375571  330572 ok
04  Audio  375572  383649    8078 ok
05  Audio  383650  397093   13444 ok
06  Audio  397094  399944    2851 ok
07  Audio  399945  406033    6089 ok
08  Audio  406034  413385    7352 ok
09  Audio  413386  415457    2072 ok
10  Audio  415458  419294    3837 ok
11  Audio  419295  428565    9271 ok
12  Audio  428566  453103   24538 ok
13  Audio  453104  478127   25024 ok
14  Audio  478128  485726    7599 ok
15  Audio  485727  513636   27910 ok
16  Audio  513637  523073    9437 ok
17  Audio  523074  525264    2191 ok
18  Audio  525265  525788     524 ok
19  Mode1  525789  549149   23361 ok (75)
---------------------------------
done

It matches db so great, but will test more and add some functions before new binary. The question is, does every multi-track dump have 75 errors on the last track? Does this number vary at all? Is there any other time ice indicates track errors where the track is actually valid?

[themabus]

ice.exe was made to automate additional steps in DC dumping (unscrambling/track separation)
AFAIR error indication in brackets is based on EDC/ECC check per sector (it determines sector nature: data or audio) and was intendet for gap managment
so there might indeed be cases when indicated number is different from 75 for good image or is 75 for bad image
75 only means that gaps are of common configuration
ice.exe was not meant for image validation
validation is performed by obtaining two matching images, preferably on different drives