You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
And it has the 'Compact disc Interactive' logo.
Thanks.
Done...
There are some weird points...
1. Track number starts 02, not 01.
2. Index of 1st 75 sectors is 01, not 00.
3. 101 sectors is overdumped.
If you can, please dump it by subdump and upload .sub.
user7 wrote:Jackal said to just go with Fireball's suggestion.
http://forum.redump.org/post/67312/#p67312 or http://forum.redump.org/post/69074/#p69074 ?
Both format is a little different.
I guess the one that F1ReB4LL said, but with an additional session1 line.
REM SESSION 01
...
REM LEAD-OUT 00:03:55
REM SESSION 02
REM LEAD-IN 00:02:00
...REM SESSION 01
...
REM LEAD-OUT 00:03:55
REM SESSION 02
REM LEAD-IN 00:02:00
...
I confirmed that the lead-out of 1st session are 6750 sectors and the lead-in of 2nd session are 4500 sectors.
If both num of sectors are always same, is REM LEAD-OUT and REM LEAD-IN unnecessary? because msf is always same like this.
REM SESSION 01
...
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
...http://forum.redump.org/topic/22034/ata … st-demo-u/ -- the dump is all wrong.
========== FULL TOC ==========
FirstCompleteSession: 1
LastCompleteSession: 2
Session 1, Ctl 0, Adr 1, Point 0xa0, FirstTrack 1, Format: CD-DA or CD-ROM
Session 1, Ctl 0, Adr 1, Point 0xa1, LastTrack 1
Session 1, Ctl 0, Adr 1, Point 0xa2, Lead-out, MSF 01:36:67 (LBA[007267, 0x01c63])
Session 1, Ctl 0, Adr 1, Point 0x01, Track 1, MSF 00:02:00 (LBA[000150, 0x00096])
Session 1, Ctl 0, Adr 5, Point 0xb0, NextSession, MSF 04:06:67 (LBA[018517, 0x04855])
Outermost Lead-out of the disc, MSF 63:05:00 (LBA[283875, 0x454e3])
Num of pointers in Mode 5, 02
Session 1, Ctl 0, Adr 5, Point 0xc0, Optimum recording power, 00
First Lead-in of the disc, MSF 97:47:00 (LBA[440025, 0x6b6d9])
Session 2, Ctl 0, Adr 1, Point 0xa0, FirstTrack 2, Format: CD-DA or CD-ROM
Session 2, Ctl 0, Adr 1, Point 0xa1, LastTrack 4
Session 2, Ctl 0, Adr 1, Point 0xa2, Lead-out, MSF 10:16:25 (LBA[046225, 0x0b491])
Session 2, Ctl 0, Adr 1, Point 0x02, Track 2, MSF 04:08:67 (LBA[018667, 0x048eb])
Session 2, Ctl 0, Adr 1, Point 0x03, Track 3, MSF 04:16:64 (LBA[019264, 0x04b40])
Session 2, Ctl 0, Adr 1, Point 0x04, Track 4, MSF 10:10:28 (LBA[045778, 0x0b2d2])
FILE "myst-demo (Track 1).bin" BINARY
REM SESSION 01
TRACK 01 AUDIO
FLAGS DCP
INDEX 01 00:00:00
FILE "myst-demo (Track 2).bin" BINARY
TRACK 02 AUDIO
FLAGS DCP
INDEX 01 00:00:00
FILE "myst-demo (Track 3).bin" BINARY
TRACK 03 AUDIO
FLAGS DCP
INDEX 00 00:00:00
INDEX 01 00:01:74
FILE "myst-demo (Track 4).bin" BINARY
REM LEAD-OUT 01:34:67
REM SESSION 02
TRACK 04 AUDIO
FLAGS DCP
INDEX 00 00:00:00
INDEX 01 00:01:74
Tracks 2 and 3 belong to the 2nd session and the 1st session's lead-out can't go after them.
There are some weird points...
1. Track number starts 02, not 01.
2. Index of 1st 75 sectors is 01, not 00.
3. 101 sectors is overdumped.If you can, please dump it by subdump and upload .sub.
I tried... but both subdump exes stop after 15sec with empty .sub files and the following log:
Args: -i K: -f test.sub -mode 6 -rereadnum 25 -fix 2
TOC reading...
Find subchannel start sector...
41 01 00 16 42 00 00 00 02 00 18 ef
subStartAddr: 0
subEndAddr: -150
sectorQuantity: -150
Flush...
Sectors with possible errors: 0.
Not corrected sector quantity: 0.
Flush...
Sectors with possible errors: 0.
Not corrected sector quantity: 0.
Flush...
Sectors with possible errors: 0.
Not corrected sector quantity: 0.
Flush...
Sectors with possible errors: 0.
Not corrected sector quantity: 0.
Flush...
Sectors with possible errors: 0.
Not corrected sector quantity: 0.
Pre fix failed sectors quantity: 0.
subchannelsFix started.
Not corrected bytes quantity: 0.
Post correction sectors quantity: 0.
Post correction started.
Pre fix failed sectors quantity: 0.
subchannelsFix started.
Not corrected bytes quantity: 0.Maybe I'm doing something wrong...?
Maybe I'm doing something wrong...?
Something wrong with the TOC.
DiscImageCreator audio K: TOC 4 -5000 -1100Run this command and upload an archive with all the TOC* files here, pls.
And I have a question. Does this disc have the logo of 'compact disc interactive' or 'compact disc digital audio CD-I READY'?
Yes, it's a CD-i Ready title.
Run this command and upload an archive with all the TOC* files here, pls.
Here you are:
https://www.dropbox.com/s/wugb8z3jza35j5g/TOC.7z?dl=0
Yes, it's a CD-i Ready title.
Must be a misprint on the label then... because, yes, there are audio tracks on the disc but the logo on the disc is definately 'compact disc interactive'...
Here, you can see it on the back too: https://i.ebayimg.com/images/g/szIAAOSw … -l1600.jpg
When subQ crc is 0 DIC stops. When I retried it worked. Is is possible to add some more complex restart logic? If crc is 0 go back 100 sectors and retry reading? This crc 0 thing looks quite random...
It should be treated as a read error and reread together with C2 errors. Right now, the DIC's rereading is nearly broken, any read errors stop it with the "Failed to reread because crc16 of subQ is 0" error, earlier versions detect a C2 error there and reread.
sarami, can you add Ctrl+C abort, also can you make it not spit out the usage when the command line is wrong.
Latest test version is working fine on my px-5224a and px-760a , also my lite-on dvd.
sarami, can you add Ctrl+C abort
I think it is supported on the OS level, no?
>Nexy
Long time no see 
Nexy wrote:sarami, can you add Ctrl+C abort
I think it is supported on the OS level, no?
I think so, too.
can you make it not spit out the usage when the command line is wrong.
changed: http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Yes ltns!
Thank you, and yeah I figured out ctrl+c works.
So it runs on XP on PIII-S (surprised VC++ 2015 works) , have you compiled with SSE (1) extensions and optimization? It should help with hashing speed for me.
Also could you detect processor features and make the UI update less frequently (maybe 100 times less) or not at all when on old systems, it really slows things down.
DIC doesn't have any UI. DICUI is by a different person.
The printing the progress to the console, it is slow and takes up processing time. I am specifcally referring to the hash calculation.
+1
It slows the process a lot also on my PC.
I agree that the hashing is really slow and takes a lot of time, but are we sure it's caused by the display of the progress?
have you compiled with SSE (1) extensions and optimization?
No. Because some person use old cpu which doesn't support sse.
The printing the progress to the console, it is slow and takes up processing time.
changed: http://www.mediafire.com/file/eq80y20l9 … st.7z/file
are we sure it's caused by the display of the progress?
If there is the hashing app/library you recommend, tell me plz.
sarami: People are using a Pentium II or AMD with 3Dnow to dump? Even I think that is silly. SSE (1) is introduced with Pentium III. Maybe a command line switch to enable it, hashing is very very slow on such an old processor and a large waste of time.
There's not really any standardized hashing app/library, it depends on what the usage is and most stuff these days is not using md5/sha1 because it's not secure, or is used for low collision hash tables.
Thank you for the update to the hashing, it's much faster now, especially with DVDs.
I really like how it now handles safedisc and securom.
What are your plans for DVD protections, Data Positioning and Starforce/Tages ? Has there been any discussions?
People are using a Pentium II or AMD with 3Dnow to dump? Even I think that is silly.
Pentium III is also very old cpu for me... It was unbelievable that there was the person who used such an old cpu. But PIII user exists, so PII user may exist.
What are your plans for DVD protections, Data Positioning and Starforce/Tages ? Has there been any discussions?
DPM: http://forum.redump.org/topic/17084/ana … l-120-dpm/
It's hard to get the identical values.
Tages: http://redump.org/disc/34669/
Jackal knows it.
Yeah the PIII-S is old, but that machine is IDE (my c2d machine died) and I need that as I cannot find SATA > IDE adapters that work.
I suppose I can just compile it myself in Visual Studio if the project has complete dependencies.
How to continue dumping using the same files? Since I set more than 10000 retries, image files were created but I still need to dump next hard sectors. Tried the same command but it just overwrites existing files. Which command should I use to continue? I use command line.
Would be very nice if DIC would try to read next hard sector if previous one wasn't dumped after all retries. It would help to dump all hard sectors leaving only very hard ones. Is it possible to add this function?
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.
