DiscImageCreator

[sarami]

DVD-R overdump

http://www.mediafire.com/file/eq80y20l9 … st.7z/file
http://www.mediafire.com/file/uw3e03kdk … ar.gz/file
- fixed: FormatCode 10 (ECMA-279 and 359 are used)

If it's supposed to be the "LayerOneSector" number, then 3 of the 4 discs have an odd number. Can this be correct?

4 discs are "Parallel Track Path", not "Opposite Track Path". I think "LayerZeroSector" number is layerbreak.
e.g.

Code: Select all

========== SectorLength ==========
    LayerZeroSector: 1708076 (0x1a102c)
          :
          :
========== SectorLength ==========
    LayerOneSector: 2079572 (0x1fbb54)
    LayerAllSector: 3787648 (0x39cb80)

L0 is 0 - 1708075 (Length is 1708076). L1 is 1708076 - 3787647 (Length is 2079572).

[Jackal]

4 discs are "Parallel Track Path", not "Opposite Track Path". I think "LayerZeroSector" number is layerbreak.
e.g.

Code: Select all

========== SectorLength ==========
    LayerZeroSector: 1708076 (0x1a102c)
          :
          :
========== SectorLength ==========
    LayerOneSector: 2079572 (0x1fbb54)
    LayerAllSector: 3787648 (0x39cb80)

L0 is 0 - 1708075 (Length is 1708076). L1 is 1708076 - 3787647 (Length is 2079572).

Makes sense, thanks for clarifying

[wiggy2k]

Makes sense, thanks for clarifying

I think i speak for 90+% of people here when i say.... "nope. it's still all gobbledegook"

and this is why we arent mods

[user7]

http://www.mediafire.com/file/eq80y20l9 … st.7z/file
http://www.mediafire.com/file/uw3e03kdk … ar.gz/file
- fixed: FormatCode 10 (ECMA-279 and 359 are used)

Still getting overdumps: https://drive.google.com/file/d/12nwgBR … sp=sharing

[sarami]

Still getting overdumps: https://drive.google.com/file/d/12nwgBR … sp=sharing

http://www.mediafire.com/file/eq80y20l9 … st.7z/file
http://www.mediafire.com/file/uw3e03kdk … ar.gz/file
- fixed: FormatCode 0 (ECMA-349 is used for DVD+R)

[pool7]

I dumped and submitted 2 Dreamcast Unlicensed MIL-CD (multisession) yesterday.
No errors during dumping (see logs below); however I now noticed the following:
-The 2 BIN files are 8MB total, while the IMG and SCM files are 34MB each
-If I open the CUE corresponding to the BIN files in IsoBuster and try to read session 2, there's an error "The path table (ISO 9600) couldn't be read properly. Only 0 of 1 blocks could be read. Read error at address: 13855. Device reported error: 05/63/03". The same error appears if I open just Track 2 BIN
-If I open the CUE corresponding to the IMG file in IsoBuster , I can read session 2 just fine, no errors.
-If I open the IMG directly in IsoBuster (without using the corresponding CUE file), it says it can't detect a filesystem.

Is this normal/expected?

Logs:
https://mega.nz/#!q6xQGKTY!bibbH9ssN5Z_ … kNQQp4mJ6E
https://mega.nz/#!iihiSAyC!DUR26IvUie6d … pIzuUhc0mo

[sarami]

-The 2 BIN files are 8MB total, while the IMG and SCM files are 34MB each

Yes. Because IMG and SCM include 11400 sectors (lead-out, lead-in, pregap of 1st track of 2nd session). 11400 sectors = 26812800 bytes.

-If I open the CUE corresponding to the BIN files in IsoBuster...

Because this CUE is the original format of redump'org.

-If I open the CUE corresponding to the IMG file in IsoBuster...

Because this CUE is based on IsoBuster.

-If I open the IMG directly in IsoBuster...

Without CUE, IsoBuster can't recognize what it is.

[pool7]

Got it; thanks for the explanation

[user7]

When dumping a press kit CD-R, it crashes converting from img to bin: https://drive.google.com/file/d/1JOaw_r … sp=sharing

edcchk shows the .img has 0 errors.

isobuster is dumping the disc with consistent hashes, different than dic's .img hashes.

[sarami]

Up http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Test please.