Redumper
From Redump Wiki
redumper is an open source optical disc dumping application for Windows and Linux (a macOS version is planned). The application is written by redump moderator superg.
redumper is designed to be very user friendly, a double click of the app will detect the occupied disc drive and account for unique caveat of discs.
redumper is in an experimental stage of support for redump.org contributions.
Contents |
Format Support
- Supported: CD-Rom (most CD-Rom formats are fully supported)
- Not Yet Supported: DVD, HD-DVD, Blu-Ray
Moderator Guidelines
General
Every new disc / verification submitted by the user must include redumper generated LOG file. This file is a main source of all the information needed to validate or discard a dump. Audio CD LOG file example:
=== 2022-12-03 13:22:34 ========================================================
redumper v2022.12.03 [Dec 3 2022, 13:16:43] (print usage: --help,-h))
command: ./redumper --image-path=cc1_audio --image-name=cc1_audio
*** MODE: dump
drive path: /dev/sg6
drive: PLEXTOR - CD-R PX-W5224A (revision level: 1.04, vendor specific: 04/10/06 17:00)
drive configuration: PLEXTOR (read offset: +30, C2 shift: 294, pre-gap start: -75, read method: D8, sector order: DATA_C2_SUB)
image path: cc1_audio
image name: cc1_audio
disc TOC:
disc type: CD-DA / CD-DATA
track 1 { audio }
index 01 { LBA: 0, MSF: 00:02:00 }
track 2 { audio }
index 01 { LBA: 11212, MSF: 02:31:37 }
track 3 { audio }
index 01 { LBA: 23705, MSF: 05:18:05 }
track 4 { audio }
index 01 { LBA: 38455, MSF: 08:34:55 }
track 5 { audio }
index 01 { LBA: 54435, MSF: 12:07:60 }
track A { audio }
index 01 { LBA: 71212, MSF: 15:51:37 }
PLEXTOR: reading lead-in
PLEXTOR: lead-in found (session index: 0, sectors: 3321)
dump started
dump complete (time: 62s)
media errors:
SCSI: 0
C2: 0
Q: 68
*** MODE: protection
scan started
protection: N/A
scan complete (time: 0s)
*** MODE: split
correcting Q... done
final TOC:
disc type: CD-DA / CD-DATA
track 1 { audio }
index 00 { LBA: -150 .. -1, length: 150, MSF: 00:00:00-02:28:74 }
index 01 { LBA: 0 .. 11024, length: 11025, MSF: 00:02:00-02:28:74 }
track 2 { audio }
index 00 { LBA: 11025 .. 11211, length: 187, MSF: 02:29:00-05:15:41 }
index 01 { LBA: 11212 .. 23516, length: 12305, MSF: 02:31:37-05:15:41 }
track 3 { audio }
index 00 { LBA: 23517 .. 23704, length: 188, MSF: 05:15:42-08:32:16 }
index 01 { LBA: 23705 .. 38266, length: 14562, MSF: 05:18:05-08:32:16 }
track 4 { audio }
index 00 { LBA: 38267 .. 38454, length: 188, MSF: 08:32:17-12:05:21 }
index 01 { LBA: 38455 .. 54246, length: 15792, MSF: 08:34:55-12:05:21 }
track 5 { audio }
index 00 { LBA: 54247 .. 54434, length: 188, MSF: 12:05:22-15:51:36 }
index 01 { LBA: 54435 .. 71211, length: 16777, MSF: 12:07:60-15:51:36 }
track A { audio }
index 01 { LBA: 71212 .. 71309, length: 98, MSF: 15:51:37-15:52:59 }
non-zero TOC sample range: [ -88200 .. 41930280]
non-zero data sample range: [ 42352 .. 41864267]
Universal Hash (SHA-1, offset: +42352): 9545d7d9ea95210cac221a8ebaabb8f9d0976534
detecting offset
audio silence detection... done
Perfect Audio Offset (silence level: 0): [-6475 .. +20287]
warning: fallback offset 0 applied
disc write offset: +0
detection complete (time: 43s)
checking tracks
track 1... passed
track 2... passed
track 3... passed
track 4... passed
track 5... passed
track A... passed
check complete (time: 0s)
splitting tracks
writing "cc1_audio (Track 1).bin"
writing "cc1_audio (Track 2).bin"
writing "cc1_audio (Track 3).bin"
writing "cc1_audio (Track 4).bin"
writing "cc1_audio (Track 5).bin"
split complete (time: 3s)
writing CUE-sheet
cc1_audio.cue... done
dat:
<rom name="cc1_audio (Track 1).bin" size="25930800" crc="a332bc5d" md5="aef38166e73b465180de6a7d76af6f49" sha1="675fdac8920c35d2a233db733b072b298c5bb129" />
<rom name="cc1_audio (Track 2).bin" size="29381184" crc="b4979243" md5="2a069dc4b8d380e3b9bd608cc3cf97b7" sha1="d25750df6fd9e261c784af5d6b7680570a8cf217" />
<rom name="cc1_audio (Track 3).bin" size="34692000" crc="adadc51e" md5="12349fd04699688543b9b860c9b1c2fa" sha1="6c50664d3c419d6c3b46997fe55e5f02f13b19c8" />
<rom name="cc1_audio (Track 4).bin" size="37584960" crc="b700d33a" md5="f7dc5bb594112b5c4c6c4de3b4f34fb6" sha1="978ea8a8acd58576ecc85f3e1c27ed761a7f0214" />
<rom name="cc1_audio (Track 5).bin" size="39901680" crc="c3c24318" md5="031b571e4a25c861e22e251612b93552" sha1="dc9df3a8feba5402e5e11921994d4f9cb2992505" />
CUE [cc1_audio.cue]:
FILE "cc1_audio (Track 1).bin" BINARY
TRACK 01 AUDIO
INDEX 01 00:00:00
FILE "cc1_audio (Track 2).bin" BINARY
TRACK 02 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:37
FILE "cc1_audio (Track 3).bin" BINARY
TRACK 03 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:38
FILE "cc1_audio (Track 4).bin" BINARY
TRACK 04 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:38
FILE "cc1_audio (Track 5).bin" BINARY
TRACK 05 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:38
*** MODE: info
The usual workflow would be to open the file with any text editor and search for a "warning" keyword. Each warning represents important information about the dump. Warning messages are pretty self explanatory but some will be explained in a greater detail. Following warnings are considered as show stoppers and new disc submissions with such warnings should be discarded:
warning: drive doesn't support reading of subchannel data warning: drive doesn't support C2 Error pointers warning: unsupported drive read method
Warnings that are safe to ignore:
warning: fake TOC detected, using default 74min disc size (the only known disc that generates such a warning is [PSX] Breaker Pro NTSC PAL)
Output Files
- *.toc: Table of Contents (TOC) in RAW TOC format (legacy command)
- *.fulltoc: Table of Contents (TOC) in RAW FULL_TOC format (multisession supported), might not get generated if drive doesn't support it
- *.subcode: Subchannel dump in RAW format. It is not demultiplexed and thus incompatible with DIC
- *.state: redumper state file which stores the status of dumped data with CD sample (32-bit) granularity. Each byte of this file corresponds to 32-bit value in the .scram file under the same offset
- *.scram: Data channel RAW (scrambled) dump file with extended lead-in / lead-out areas that is drive read offset corrected. This is equivalent to DIC *.scm but incompatible to it as *.scm is combined offset corrected and doesn't carry lead-in / lead-out information.
- *.scrap: *.scram file variation for the dumps with data tracks dumped using BE command. This format variation contains unscrambled data track stored at drive read offset. Such format is used to logically separate dumps created using scrambled mode commands vs generic drive dumps. *.scrap and *.scram are mutually exclusive and only one variation can exist for a named dump
- *.bin: redump.org compatible track split binary files
- *.cue: redump.org compatible CUE-sheet
- *.asus: LG/ASUS/LITE-ON full cache dump that is used to get extra leadout sectors, useful for debug
- *.log: redumper LOG file with all the necessary information needed to validate a submission
