Ripping games

While many companies discourage making "backups" or "archival" copies, if you want to legally play your games on an emulator, you're going to need to dump them yourself. This guide covers the basics and more well-known methods, so there may be other methods not mentioned here.

Before diving in

• Rip and dump terms are often used interchangeably, the old language specific to DVDs is rip, if you had Windows Media Player back in the Vista days, you might be familiar with the Burn and Rip functions in there, but in most retro game circles you're more likely to see "dump" definition used. e.g. disc ripping and cartridge dumping
• We highly recommend visiting the Save disk space for ISOs, Home media players, Copy protection and List of filetypes pages for information about discs, streamable compressed disc images, copy protection with emulation and other related stuff.
• If you're focusing on preserving the disc, you need to do proper ripping process and use correct image file formats. See #Disc-based section for more information about all of that. In most cases, the MPF software (frontend for various low-level byte-perfect CD dumper utilities) handles the proper disc ripping tasks with ease if you have a compatible optical drive (capable of reading the specific disc), making it the recommended choice for a majority of discs mentioned below. See here.
• See Hardware features sections for each dedicated system on emugen wiki. Some of the emulators supports emulating optical media capability of the systems and if your optical drive has no issues reading the disc, you dont even need to rip your discs to play it. But it wears the disc and the optical drive the longer you use it, hence why it's not recommended.
• You can use FPGA or other boards-based (like Arduino Mega) hardware solutions such as GB Operator, Open Source Cartridge Reader (OSCR) for dumping your cartridges to PC. See here. See #Cartridge-based section and FPGA page for more information.

Digital

Disc-based

For preservation purposes, you should follow the Redump guide and dumping.guide, which emphasizes the use of MPF software (frontend for various low-level byte-perfect CD dumper utilities) as we mentioned above in the "Before Diving In" section, so make sure to read that section first in this page. Using simple tools for ripping process is not a very reliable ripping method, however it may be "good enough" if you just want to play the game. If you really can't follow this guide then you should at least use IsoBuster which is recommended by Redump if you can't follow the guide.

General Tips before we begin

Understanding: We should always understand a disc's characteristics before attempting to preserve it.

Optical drive compatibility and disc image reading capability limitations: The effectiveness of reading and capturing all aspects of the discs can heavily depend on the optical drive's capabilities. Some drives are better at this than others, and you might need to experiment with different drives or adjust settings. Some drives might need specific firmware to do this effectively. See optical disc drive compatibility pages on: redump and RPCS3. But remember, even with a perfect hardware read through your optical media drive, the software layers between the disc and the final image can also introduce errors. Dumping and conversion software tools, virtual optical drive software (e.g., Daemon Tools, Alcohol 120%), hypervisor and/or emulator's disc image reading capability may have bugs, incomplete features, or limitations: see emulation of the drive itself section for more information.

Software Versions: Keep your software updated. Newer versions might include better support or easier access to these settings.

Test with Known Protected Discs: If you're aiming to capture subchannel data for protection emulation, test with discs known to have protections like SecuROM or SafeDisc to confirm your setup works. MPF software provide scanning the discs for example.

Additional Differences or Custom Proprietary Discs: To fully preserve certain systems unique proprietary disc formats or minor differences, extra steps may required, such as including security files for Original Xbox XGD discs, including Disc Manufacturing Information (DMI.bin), Physical Format Information (PFI.bin), and Security Sectors (SS.bin). See System-Specific Discs section of the comparison table or #Specific systems section in this page for more information.

Padding: Padding consists of dummy data used to fill a disc to its maximum physical capacity (e.g., 7.30 GB for XGD2 or 8.14 GB for XGD3), regardless of how small the actual game files are. Removing this padding (Trimming/Truncating) saves significant storage space. A 500 MB game stored in an 8 GB ISO is inefficient for average user. However, for archival purposes, do not remove padding. Altering the file size changes the hash (MD5/SHA-1), making it impossible to verify against databases like Redump. A "trimmed" dump is considered a "bad dump" in the preservation community. If space is a concern, consider using proper compressed but "lossless" formats (Archive-quality dump) which allow you to keep the data intact while reducing the footprint.

Generational loss and derivative converted format: Acquiring a "rip" in a specific format does not guarantee the full preservation of a disc’s original capabilities. Because a file may suffer from generational loss or be a derivative converted from another format lacking essential features (similarly to improper encoding in graphics file formats). To maintain high-fidelity preservation workflows, always create common disc image formats (e.g., ISO, BIN/CUE, MDF/MDS) directly from physical discs or low-level, byte-perfect source files (i.e always generate access copies from the original dump). This ensures the format's full capability for access and emulation.

Scrambled vs. Descrambled Data: On CDs, data is encoded (scrambled) to ensure reliable reading by the drive. Formats like .scm/scram (DiscImageCreator) capture this raw, scrambled data, preserving the exact state of the disc. Standard image formats like BIN/CUE or CCD/IMG/SUB typically contain descrambled data, which is the processed, 'usable' form of the data. While descrambled data is much more compatible with software and emulators, it may not preserve all low-level details needed for certain preservation tasks.

Comparison

Image Formats Capabilities
CDs BIN/CUE is widely supported, making it popular for users, while CCD/IMG/SUB or MDF/MDS are preferred for discs that requires even more precise preservation of subchannels, multi-session data or physical structures.
Disc Aspect	CDFS/ISO 9660 FS type .iso	CDRWin BIN/CUE	CloneCD CCD/IMG/SUB	Alcohol 120% MDF/MDS	Low-level byte-perfect (e.g., .scm/scram, .aaruf)
Main Data	✓	✓	✓	✓	✓
File System	~ (Captures ISO 9660 for data CDs. Cannot capture copy protection, or low-level features like subchannels or physical structures, Red Book audio, Green Book CD-i, mixed-mode or subchannel data.)	✓ (Capable of capturing ISO 9660, Red Book, Green Book CD-i, and subchannel data.)	✓ (Capable of capturing ISO 9660, Red Book, Green Book CD-i, and subchannel data.)	✓ (Capable of capturing ISO 9660, Red Book, Green Book CD-i, and subchannel data.)	✓ (Capable of capturing any file system, multi-session, and subchannel data.)
Pregap Data	✗	~ (described in CUE)	✓	✓	✓
Multi-Session	~	~	✓	✓	✓
Disc Mode (Mode 1, Mode 2, Mixed Mode)	✗	✓	✓	✓	✓
Sector-level error detection/correction	✗	~ (EDC/ECC only in 2352 rips; no CIRC)	✓ (Full sector EDC/ECC; no CIRC)	✓ (Full sector EDC/ECC; no CIRC)	✓
Jitter and Timing	✗ CD image formats do not preserve low-level analog characteristics like jitter and timing. Solution: Use hardware like Domesday Duplicator or MISRC/CX Cards to capture raw RF signals, processed by CD-Decode software.
Physical Metadata (UPC/EAN Barcode, Matrix and SID codes)	✗ Cannot be digitally captured to image data formats. See this guide for scanning this. You can also fill the redump's submitting dump info for these after the ripping process done using MPF frontend software.
Digital Integrity Verification (AccurateRip/CTDB)	✗	✓ (Industry standard for BIN/CUE; uses CRC checksums to compare audio data against a global database of known clean dumps.)	✓ (Supports verification, though not a substitute for full-disc cryptographic hashes.)	✓ (Supports verification, though not a substitute for full-disc cryptographic hashes.)	✓ (Essential for low-level formats; preservation workflows additionally require external cryptographic hashes (e.g., SHA-256) to detect file-level corruption over time.)
Error Mapping (C1/C2/CU)	✗	✗	~ (CloneCD can skip errors, but doesn't log precise C1/C2 counts for health analysis.)	~ (Alcohol 120% can bypass/emulate bad sectors for copy protection, but does not store an internal "health map" of the physical substrate.)	✓ (Tools like DiscImageCreator or Aaru generate detailed logs of hardware-level error correction attempts.)
Drive Read Offset Correction	✗	~ (Requires software such as Exact Audio Copy or DiscImageCreator to apply a drive-specific correction value; otherwise, data may be shifted. Offset correction aligns data but does not validate correctness by itself.)	~ (CloneCD can apply user-defined drive offsets during ripping, but relies on correct manual configuration and lacks database-backed verification.)	~ (Supports drive offset correction when properly configured.)	✓ (Low-level tools account for the drive’s +/– offset to align the resulting image to the true sector 0.)
Main Channel (Sector) Data	✗	~	✓ (in SUB)	✓ (in MDF)	✓
Lead-in / TOC (digital metadata, CD-Text)	✗	~ (Described in CUE)	✓ (Metadata in .CCD)	✓ (Metadata in .MDS)	✓
Physical End-of-Disc Structure (Lead-out Area)	✗	✗ (Not preserved. Burning software generates a compliant lead-out during disc writing.)	✗ (Not preserved; typically recreated by burning software. Some tools may overread into the lead-out, but this is not standardized or reliably stored.)	✗ (Not preserved; typically recreated during writing. Limited overread support may detect the transition but does not ensure archival capture.)	~ (May capture the transition into the lead-out depending on hardware and dumping method, but full physical characteristics require RF-level capture.)
Subchannel Data (ISRC, MCN/UPC, CD-Text, CD+G, CD+MIDI, Timing/Indices, Pre-Emphasis, copy protection)	✗	~	✓ (in SUB)	✓ (in MDF)	✓
ATIP / Media ID	✗	✗	✓ (Can store ATIP/Media ID in CCD if the hardware supports reading the disc "wobble" (primarily for CD-R/RW).	✓ (Can store ATIP/Media ID in MDS if the hardware supports reading the disc "wobble" (primarily for CD-R/RW)	✓ (Captures ATIP on recordable media or manufacturing SID/Matrix info via low-level hardware analysis.)
DVDs, UMDs, HD-DVDs and BDs For DVDs and UMDs, UDF ISO (ISO/IEC 13346) is fine. However, for more complex DVD discs, particularly discs with copy protection, MDF/MDS or a low-level byte-perfect format is highly recommended. These formats are designed to capture the disc's entire physical structure, including aspects that UDF alone does not. Also see Home media players#Media player software section.
Disc Aspect	UDF FS type .iso		Alcohol 120% MDF/MDS		Low-level byte-perfect (e.g., .aaruf)
Main Data	✓		✓		✓
File System	✓ (Captures UDF file systems, including UDF 1.02 for DVDs; VIDEO_TS for DVD-Video, AUDIO_TS for DVD-Audio. UDF 2.5 for HD-DVDs. UDF 2.5/2.6 for Blu-ray; BDMV for BD-Video and BD-Audio)		✓ (Captures original file system, e.g., UDF, ISO 9660 with extensions like Joliet or Rock Ridge)		✓ (Captures the original file system as part of the raw data)
Sector Information including Error Correction	~ (Captures user data and some metadata, but typically excludes raw ECC data which is part of the physical sector structure)		✓		✓ (Captures all sector data, including Error Correction Code (ECC) and Error Detection Code (EDC), crucial for exact duplicates)
Physical Structure including Lead-in/Lead-out	~ (Captures logical structure but may not perfectly replicate all physical layer details like lead-in/lead-out if not part of the file system data area)		✓ (Captures essential physical layout and session information)		✓ (Captures the entire physical layout of the disc, including lead-in, lead-out, and session gaps, essential for disc cloning)
Multi-Session	✓		✓		✓
Layer Break Information (for dual-layer discs)	✗ (Does not capture physical layer break information)		✓ (Captures layer break as part of physical structure)		✓ (Captures exact layer break as part of byte-perfect replication)
Region Coding	✓		✓		✓
Copy Protection mechanisms	✗ (Cannot capture copy protection as it operates at a lower physical level than the file system. A UDF .iso only contains the logical file structure.)[5]		~ (Designed to capture low-level disc structures. Some protections (e.g., CSS) may be preserved structurally, but modern schemes such as AACS rely on drive authentication and cannot be fully reproduced by standard imaging alone.)[6]		✓ (It replicates the disc bit-for-bit, including scrambled sectors, managed copy flags, and other obfuscation)
Metadata/Menus and Navigation (e.g., DVD-Video, HD-DVD Advanced Content, BD-J)	✓		✓		✓
Physical metadata (UPC/EAN Barcode, Matrix and SID codes)	✗ Cannot be digitally captured to image data formats. See this guide for scanning this. You can also fill the redump's submitting dump info for these after the ripping process done using MPF frontend software.
Subtitles and Audio Streams	✓		✓		✓
Media Identification Code (MID) / Media Type	✓		✓		✓
System-Specific Discs While standard formats like BIN/CUE or ISO are used for the majority of optical media, certain consoles and operating systems utilize proprietary physical structures or encryption that standard imaging tools cannot properly interpret. These system-specific formats are often "wrappers" or raw containers designed to bypass those limitations or to provide emulators with the specific metadata (like security sectors or high-density track info) required to boot the software.
Aspect	.xiso	.wud	.bin or .raw/.gdi	.dmg
Primary System(s)	Xbox, Xbox 360	Wii U	Dreamcast	macOS X
Preservation Role & Characteristics	Designed for XGD, XGD2 and XGD3 disc structures.[7] Those discs uses ISO 9660 for Video Partition, and XDVDFS for Data Partition. On the Xbox 360, XGD3 discs use this same file system but maximize usable space (approx. 8.13 GB) by reducing the outer lead-out and video partitions. XISO image format captures those specific partitioning and data layouts used by Microsoft's proprietary media.	A 25GB uncompressed raw dump of a Wii U optical disc. Captures the encrypted state of the disc bit-for-bit.	Designed for GD-ROM (Gigabyte Disc) technology. Manages 1.2 GB high-density tracks that are physically different from standard CDs.	Apple Disk Image; a proprietary format for the Macintosh ecosystem. Captures HFS/HFS+ file system metadata more reliably than other formats.
Key Considerations	Essential for preserving OG Xbox and Xbox 360 discs. Includes additional security files (SS, DMI, PFI) for 1:1 "stealth" verification. Because it utilizes XDVDFS, standard OS mounting tools cannot read the contents without specialized drivers or extraction utilities (like xdvdfs or extract-xiso for OG Xbox, exiso for Xbox 360).	Requires "Common Keys" for decryption and use in emulators. Can be converted to compressed .WUX format to save storage space.	Industry standard for Dreamcast preservation.	Preferred over the older .toast (Roxio) format. Primarily used for software archival within Apple-specific workflows.

While there are other disc image formats that could be mentioned but they are either less relevant to preservation workflows or redundant given the existing selection.

• .nrg (Nero Burning ROM): Used by Nero software, this format can store multi-session data and copy protection. However, its popularity has waned, and its features overlap with formats like MDF/MDS.
• .isz (UltraISO): A compressed ISO variant focused on data discs, lacking support for complex features like audio tracks or copy protection.

Preservation Priority (Recommended Workflow)

Best practice is to maintain two distinct image types:

• Preservation Master
  • Low-level or raw structured formats
  • Should never be regenerated from lossy or derivative formats or modified
  • Must be accompanied by dumping logs and cryptographic checksums (e.g., SHA-256)
  • Used only for verification or regeneration

• Access Copy
  • Standard raw formats or Filesystem-only images
  • Used for emulation, playback, or quick user access
  • Can be regenerated from the preservation master

Not all disc image formats are equal for preservation. For long-term archival accuracy, disc image formats should be treated as belonging to different preservation tiers:

1. RF-level capture (ultimate preservation)
   • Examples: Domesday Duplicator + CD-Decode
   • Captures raw analog RF signal, preserving jitter, timing, and physical defects
   • Impractical for most users, but represents the theoretical preservation limit
2. Low-level byte-perfect images (preservation master)
   • Examples: .aaru, .scm/.scram
   • Captures scrambled data, subchannels, ECC, session structure, and drive behavior
   • Recommended preservation baseline when RF capture is unavailable
3. Structured raw formats (preservation-compatible)
   • Examples: CloneCD CCD/IMG/SUB (for CDs), Alcohol 120% MDF/MDS (for CDs and DVDs)
   • Preserve subchannels, sessions, TOC, and some physical metadata
   • Acceptable when low-level formats are not possible
4. Standard raw images (situational preservation)
   • Examples: BIN/CUE (for CDs)
   • Highly compatible and popular but may lose subchannel or session fidelity
   • Acceptable for many preservation workflows when ripped in RAW mode with proper verification and settings, but not "ideal" as a long-term preservation master
5. Filesystem-only images (access only)
   • Examples: .iso
   • Discards audio, subchannels, copy protection, and disc structure
   • Never suitable for preservation

Tutorials

• Using MPF software

Drive Selection: MPF should detect your DVD drive automatically. If it doesn't, you might need to manually select the drive from the dropdown or input the drive letter.

Dumping Program: We will choose Aaru for this tutorial.

Image Format: Use the default option. If you're using Aaru for dumping program, make sure to read this for CSS protected DVD discs (MPF using "--title-keys false" as default option). MPF will create .scram or .aaruf (depends on which dumping program choosed) which contains 99% of the disc's information (the rest may be stored with additional associated metadata files like .subcode, .state, .toc, .fulltoc, depends on the format) generated by the dumping program; which you can convert these to popular formats using CLI commands using the same dumping program (e.g., aaru image convert --force image.aaruf image.mds OR others such as .ccd, .cue, .iso)[8], but remember the original dump format (.scram or .aaruf) contains even more data than what those popular formats allows.[9][10] On top of that, there could be bugs or unimplemented features on the dumping and converting tool.[11][12][13][14][15][16][17][18] So, if your aim is long time preservation instead of constant usage, it is recommended to keep the original dump format instead. You can use RedBookPlayer for in order to play Audio CDs from Aaru Format Images.[19]

Protection Scanning: Under Tools > Options > Dumping > Protection, you can configure how MPF handles copy protection. Enable options like "Scan for protection" if you want to identify or deal with protections.

Choose System/Media: MPF will analyze the disc type and then set the correct format for media type, depending on what you're backing up. Ensure the correct system and settings selected and match the content of your disc though.

Output Path: Click "Browse" to choose where you want to save the image. Name it appropriately; MPF will generate output files automatically.

Dump: Click the "Dump" button. MPF will analyze and then dump the disc. This process can take time depending on the size and condition of the disc. Watch the progress bar and any messages for errors. MPF will show you details like sector reading speed, errors encountered, and whether protection is detected.

Verification (Optional but Recommended): After dumping, MPF can verify the image. This step ensures the integrity of your backup. Go back to the main interface, select your dumped image, and choose "Verify".

Redump Compatibility: If you're part of the Redump preservation project, MPF's output is tailored for their standards. Remember to submit your dumps if you're contributing.

• Using Alcohol 120%

This is the primary software for creating MDF/MDS images. Ensure you have a version that supports DVD handling.

Choose Image Format: Select MDF/MDS as your image format. This is crucial for capturing all necessary data, including potential protection mechanisms.

Configure Image Settings: Reading Speed: Set to a moderate speed to minimize errors. Too fast might skip problematic areas.

Error Handling: Choose robust error handling options. Alcohol 120% allows you to set how it deals with read errors, which can be critical for copy-protected discs. Options like "Read Sub-Channel Data" or "Detect Unreadable Sectors" can help in maintaining disc integrity.

Protection Handling: If your DVD has copy protection, ensure that the software is configured to deal with it. Alcohol 120% has options to auto-detect and handle various protections, but you might need to manually adjust settings for complex protections.

File System: Make sure to select or let the software auto-detect the DVD's file system (like UDF for DVDs).

Choose Destination: Select where you want to save the MDF/MDS files. Remember, these files will be named similarly (e.g., MovieName.mdf and MovieName.mds).

Verification (Optional but Recommended): Once the image is created, Alcohol 120% might offer to verify the image. This step checks if the image matches the original DVD, ensuring data integrity.

• Using CloneCD

Drive Selection: Launch CloneCD, and it will typically auto-detect your CD/DVD drive. If multiple drives are present or auto-detection fails, select the appropriate drive from the dropdown menu in the main interface.

Profile Selection: Choose a profile suited for the disc type. For most CDs, select the "CD" profile or a specific profile like "Protected PC Game" or "Audio CD" if applicable. These profiles configure settings to handle copy protection mechanisms like SafeDisc or SecuROM. You can customize profiles in the "Options" menu if needed.

Image Format: CloneCD creates images in its proprietary format, consisting of a .ccd (control file with track and header data), .img (main disc data), and .sub (subchannel data). These files are generated automatically with the same filename prefix. The .ccd format is essential for preserving all disc data, including subchannels critical for copy-protected discs.

Protection Handling: In the "Read" settings, enable "Read Subchannel Data" to capture subchannel information, which is necessary for discs with copy protection or mixed-mode CDs (containing both audio and data tracks). For protected discs, ensure "Amplify Weak Sectors" is enabled to improve reading accuracy for problematic sectors.

Output Path: Click the "Browse" button to specify the directory where the .ccd, .img, and .sub files will be saved. Ensure sufficient disk space, as the .img file can be large (up to 700 MB for a standard CD).

Read Process: Click the "Read to Image File" button (represented by a CD-to-hard-drive icon). CloneCD will begin reading the CD, capturing all data, including subchannel and control information. A progress bar will display the status, and the process may take several minutes depending on the disc and drive speed.

Verification (Optional but Recommended): After the image is created, use CloneCD’s "Compare" feature to verify the image against the original CD. Select the generated .ccd file and the source drive, then click "Compare" to ensure the image is an accurate copy.

Burning or Mounting: The resulting .ccd/.img/.sub files can be burned back to a CD using CloneCD’s "Write from Image File" option or mounted using virtual drive software like Virtual CloneDrive or Daemon Tools. Note that converting to .iso format (e.g., using ccd2iso) may strip subchannel data, making it unsuitable for discs requiring exact replication.

Preservation Notes: The CloneCD format (IMG/SUB/CCD) is ideal for long-term preservation of CDs, especially those with copy protection, as it retains subchannel data that other formats like may discard. For preservation projects, keep all three files (.ccd, .img, .sub) to ensure complete disc fidelity.

• Using Exact Audio Copy (EAC)

Subchannel Reading: Ensure that your CD drive supports reading subchannel data. In EAC, go to EAC -> Drive Options -> Additional Parameters and check if there's an option to read subchannel data. Not all drives support this, but many do with the right software.

Secure Mode: Enable secure mode for ripping, which will attempt to read subchannel data as part of the error correction process. Go to EAC -> EAC Options -> Extraction and make sure "Secure Mode" is checked.

Generate SBI File: If you're dealing with protected audio CDs, EAC can generate an SBI file which can be crucial for handling subchannel errors or protections. After ripping, you can find this option under EAC -> Create CUE Sheet -> Create CUE File With Gaps (Noncompliant) and then select to create an SBI file.

• Using ImgBurn

Advanced Read Mode: When setting up to read a disc, switch to "Advanced" in the "Read Mode" settings. Here, you can enable options like "Read Subchannel Data" if available.

Subchannel Settings: Look for settings related to subchannel data reading. Not all versions of ImgBurn might explicitly allow for this, but if available, check options like "Read P-W Subchannel Data" or similar.

• Using CDRDAO

--read-subchan: When using CDRDAO from the command line to create a BIN/CUE, use the --read-subchan option to ensure subchannel data is captured. For example:

 cdrdao read-cd --read-subchan --device /dev/cdrom --datafile disc.bin disc.toc

Specific systems

As noted in the General Tips section, some systems used custom proprietary discs or had minor variations. Preserving these unique disc formats or differences may require additional steps. Let’s explore specific systems and their detailed requirements;

CD-i

For CD-i CDs, see #Comparison section. DVC placeholder text

Neo-Geo CD

For Neo-Geo CD discs, see #Comparison section. placeholder text

Amiga CD32 and Amiga CDTV

For CDs for these systems, see #Comparison section.

Sharp X68000, FM Towns, NEC PC-9800 series, Classic Mac OS, IBM-PC

For CDs for these systems, see #Comparison section.

3DO Interactive Multiplayer

For 3DO CDs, see #Comparison section. The 3DO Interactive Multiplayer uses standard Yellow Book CD-ROM media, but does not implement the ISO 9660 filesystem. Instead, it uses a proprietary filesystem known as Opera FS. While the physical disc format is readable by most CD drives, the filesystem is not natively supported by common operating systems. As a result, discs may appear as empty, partially readable, or with unrecognized data when inserted into a PC.

Disc Structure and Format

3DO discs typically consist of:

• A single data track (commonly Mode 1, though Mode 2 variants exist)
• In some cases, mixed-mode layouts with additional Red Book audio tracks

Unlike systems such as the PlayStation, the 3DO does not rely on subchannel-based copy protection or special wobble data. However, correct sector layout and track structure are still important for compatibility. The Opera filesystem contains all game data and is accessed directly by the console without ISO 9660 translation layers.

With a PC's optical drive

Because the discs follow standard CD physical formats, they can be read by most PC optical drives.

However:

• The filesystem will not mount correctly on most systems
• File browsing is unreliable and should not be used for preservation purposes

• Recommended Format: Use .bin/.cue to create a raw dump of the disc. This preserves:
  • Full 2352-byte sectors
  • Track layout (including mixed-mode discs)
  • Any non-standard sector usage

• Dumping Tools:
  • Media Preservation Frontend (MPF)
  • DiscImageCreator

These tools ensure accurate dumping of all sectors and proper handling of track boundaries.

• Verification:

Always verify dumps against the Redump database. While 3DO discs are generally easier to read than more exotic formats, verification ensures that no read errors or inconsistencies are present.

Data Integrity Considerations

Although 3DO discs use standard CD-ROM encoding with built-in physical error correction (CIRC), they typically rely on Mode 1 or Mode 2 sector formats for data storage. Unlike Mode 1 CD-ROMs, which include additional error detection and correction at the data layer, Mode 2 formats may provide reduced redundancy. This makes accurate dumping and verification important, especially for discs that are scratched or degraded.

Additionally:

• Some titles rely on exact sector alignment or track layout
• Converting to ISO format may discard structural information and lead to incompatibility

For these reasons, raw dumps are strongly preferred over extracted or converted formats.

Burning and Real Hardware

The 3DO platform does not implement robust copy protection, and many systems are capable of reading CD-R media.

To maximize compatibility:

• Burn using DAO (Disc At Once) mode
• Avoid software that modifies sector format or "repairs" the image
• Use high-quality CD-R media

While the system is generally tolerant, poor-quality burns or incorrect track layouts may result in loading issues or audio playback errors.

Jaguar CD

For Jag CDs, see #Comparison section.

Unlike most 5th-generation consoles, the Jaguar CD does not use the standard Yellow Book (CD-ROM) data format. Instead, Jaguar CD uses a proprietary data format that does not follow standard Yellow Book CD-ROM conventions (proprietary data format with a non-standard sector layout and no ISO 9660 filesystem). By treating the entire disc as an audio-like stream, it uses a non-standard sector layout that differs from typical Mode 1 CD-ROM data, which can complicate dumping and interpretation to increase storage capacity from the typical 700MB up to approximately 790MB.

With a PC's optical drive

Because Jaguar CDs use standard physical pit density, they can be read by almost any functional PC optical drive. However, because they lack a standard ISO 9660 file system, Windows or macOS will typically see the disc as "Empty" or as a "Music CD" with one or more tracks.

• Recommended Format: Use .bin/.cue. A raw sector dump (.bin) is required to capture the full 2,352 bytes per sector, as this includes the data that would normally be reserved for error correction on a standard CD-ROM.
• Dumping Tools: It is highly recommended to use Media Preservation Frontend (MPF) or DiscImageCreator. These tools ensure the "pre-gap" and sub-channel data are preserved, which is vital for Jaguar CD boot consistency.
• Verification: Always verify your dump against the Redump Jaguar CD database. Due to the lack of standard CD-ROM data-layer error correction and filesystem structures, "silent" read errors may go unnoticed without verification. A hash match is the only way to ensure your rip is 100% accurate.

Burning and Real Hardware

If you intend to burn a rip back to a CD-R to play on real hardware:

• The Jaguar CD hardware does not have a robust "copy protection" check (like the PS1's wobble groove), but it is extremely sensitive to media quality.
• You must burn in DAO (Disc At Once) mode. If the burning software attempts to "fix" the sectors to standard Mode 1 CD-ROM data specs, the Jaguar will not recognize the disc.
• High-quality CD-Rs are recommended to avoid the "Red Screen of Death," as the console has no way to recover from even minor read offsets or bit-rot.

PlayStation and PlayStation 2

With a PC's optical drive

For DVDs and CDs (PS1/PS2 blue disc games), see #Comparison and #Tutorials sections. For more information such as .sbi situation for emulators, see PlayStation emulators#CD player section. Also see PCSX2's official docs for ripping/dumping. While you can play PS1/PS2 discs directly from your PC's optical drive in some emulators (see hardware features section of the systems in emugen wiki) it wears the disc and the optical drive the longer you use it, hence why it's not recommended. Once you have ripped the game, you should check the hashes against the Redump database to make sure the rip is good.

With a PlayStation 3 with CFW and title manager

Dumping PS1/2 titles with a title manager like Multiman is quite easy on PS3 with CFW.

1. Put the PS1/PS2 disc into the disc drive.
2. Open the title manager e.g. Multiman/Irisman and move the cursor to the game you just inserted.
3. Open the menu and select "create ISO" or similar option.
4. Choose where to store the ISO file. It's recommended to insert a USB drive and save it there so it could be easily moved away from the PS3.
5. Then you'll get the ISO dump at the specified location.

Ripping from emulated releases

Sony made the hard part of game ripping already for you, so why not go for those instead to dump your game images from?

PS Classics (PS1C PSP, PS1C PS3, PS2C PS3)

Sony also has a digital distribution service for their old PS1 and PS2 games. The selection is limited considering Sony prohibits any kind of modification to the ISO data compared

For PS1 Classics on PSP: Rip the EBOOT.PBP file. It can be directly opened in some emulators like PCSX-R. Its ISO can also be extracted with other tools.

See #PlayStation Portable section for Eboots.

PlayStation 3

PlayStation 3 titles on blu-ray discs could be dumped with either a PS3 with CFW or a computer with a compatible Blu-ray drive, while titles downloaded from PS Store has to be dumped from a PS3 with CFW or HEN. RPCS3 Wiki has a detailed article for dumping PS3 titles.

See PlayStation 3 emulators#Blu-ray player section for supported file formats for RPCS3 emulator.

Sega CD / Saturn / Dreamcast

For the Sega CD and Sega Saturn tutorial, see #Comparison and #Tutorials sections due to reasons mentioned in the PlayStation section (similar process).

Sega Dreamcast game ripping can be done in several ways. Also see: Aaru has disc image creation tool designed to dump GD-ROM discs using a real Dreamcast unit.

Dreamshell GD ripper DreamShell's built-in GD ripper

1. Launched directly from menu

Note: The existent SD card formats are: SD 1.0 (8MB to 2GB), SD 1.1 (128MB to 4GB), SDHC (4GB to 32GB), SDXC (64GB to 2TB), SDUC (2TB to 128TB). DreamShell 4.0.0 used to officially support up to 32GB SDHC cards, it's not known if the most recent version (currently 4.0.3) supports anything beyond, feel free to test out and edit the section. DreamShell also supports CF cards (no idea if size limit exists either).

Dreamshell SD card reader dumping with a dedicated tool

1. Connect a Dreamcast SD adapter (buy online or make one yourself)
2. Boot the Dreamcast SD Rip disc
3. Swap in the disc you want to dump
4. Select GD-ROM <bin> all track

LAN/BBA dumping with a network-connected Dreamcast

1. Assign a static IP to your adapter using a web browser like XDP or Broadband Passport
2. Burn the image you can grab here to a disc and boot the Dreamcast. Alternatively, boot the Dreamcast using KallistiOS' dcload-ip or its enhanced version (experimental) and load the elf file with dc-tool:

dc-tool -t <dreamcast ip> -n -x httpd-ack.elf

1. On a PC connected to the same network as the Dreamcast, load a browser and enter the Dreamcast IP in the URL bar. A menu interface will appear that will allow you to dump tracks from the GD-ROM by clicking a track to "download" it via your browser. See the parameters' description to manipulate the dumping process.

Note: It's a slow process, around 40KB/s. There're also scripts in case you want an easy way.

TODO: Obsolete dumping methods and GD-R dumping

Serial cable/Coder's cable dumping

Compatible PC optical drive dumping

Parallel printer port cable dumping

GameCube/Wii

With a PC's optical drive

Only some out-of-print models of DVD drives may read GC and Wii discs, mainly from LG (compatibility list here). Even then, Windows won't recognize the disc as valid. You'll need a tool like Rawdump or Friidump to dump it. Make sure you convert the dump to ISO format.

With homebrew

For the GC and Wii, use CleanRip.

You'll need a Wii with homebrew channel installed, so if you don't have homebrew already, go here check which homebrew installation method works for what System Version you have ETC. Now that you have Homebrew Channel and CleanRip installed here are instructions.

1. Make sure a GameCube controller is plugged into your Wii.
2. Insert your Wii or GameCube disc and your SD card or USB stick into the Wii.
3. Choose what device you're using, USB or SD using the GameCube buttons
4. Choose which file format your SD or USB stick is. (Must be FAT32 or NTFS, if not you'll need to format it, read down below for instructions)
5. If it asks you download Redump.org bat files. Press no.
6. Press A on your GameCube controller and it will start the ripping process, wait for it to finish and when its done the ISO file will be on your SD card or USB stick.

Instructions for formatting SD card/USB stick: If your SD card or USB stick is not FAT32 or NTFS here's how to format on a Windows computer.

1. Plug your SD card or USB stick into your computer.
2. Click on Start Menu, click on computer.
3. Right click on your SD card Or USB card.
4. Press Format, and choose FAT32 or NTFS (Make sure you backup files if there's any on there, as the formatting process will delete everything)

Wii U

Wii U discs have rounded edges making it impossible to read on Blu-Ray drives for PC the same way, though early dumping groups made a non-public physical modification to the Wii U to dump the data directly from its optical drive. If your console can run homebrew, however, you can dump your Wii U discs with Dumpiine, Wudump or disc2app. Only Wudump produces a lossless dump, the others extract the bare code and data for the game in either RPX/RPL (Dumpiine) or WUPInstaller (disc2app) format.

PlayStation Portable

Using PSP with homebrew

To extract the ISO game image from a physical PSP UMD disc, you simply need a 6.60 CFW PSP, its USB connection cable, and a PC.

On the main menu, press the Select button to bring the PRO VSH menu with the neat overclocking options. You'll need to change UMD ISO MODE from "Memory Stick" to "UMD Disk" (don't forget to revert this after you're done).

Now, if you "Initialize USB Connection" with your computer, what will appear under the freshly mounted drive in Windows isn't your memory stick, but a drive with a neat ISO file ripe for copying to your computer, which you can emulate or load in a CFW enabled PSP.

Converting PS1 ISOs to PSP Eboots

Main article: PSP Eboots

Convert your own PS1 ISOs into Eboots using PSX2PSP.

Popsloader

If you are having some trouble with converted Eboots, be sure to download Popsloader v4i. Most of the games will work without it nowadays, but for those that don't, you'll need this. See popsloader compatibility list.

Microsoft Xbox

Use this guide for dumping your OG Xbox XGD discs. Also see xboxdevwiki's XDVDFS (XISO) disc images and Xemu Docs: Disc Images pages. There is also a dedicated guide page on redump for Microsoft Xbox and Xbox 360 dumping.

Archival Dumping (Redump Standard)

For a "perfect" archival rip (XGD1/XGD2), extracting the security and topology metadata is required. While simple XISO (XDVDFS-only) images are popular for emulation and HDD-loading, they lack the physical structure needed for disc authentication. A complete, verified dump using tools like DiscImageCreator or CloneCD (with 0800 firmware) will produce:

• DMI.bin (Disc Manufacturing Information):

A 2048-byte file[20] containing the unique manufacturing stamp and lead-in data of the specific pressing.

• PFI.bin (Physical Format Information):

A 2048-byte file[21] containing the disc's physical characteristics, such as the number of layers and the Data Zone boundaries.

• SS.bin (Security Sector):

A 2048-byte file[22] containing the "Challenge-Response" data. On the Original Xbox, this allows the DVD drive's firmware to authenticate the disc as an original retail copy.

XGD1 vs. XGD2

• XGD1: Used primarily for early OG Xbox titles. These are Single Layer (DVD-5) discs.
• XGD2: Used for later OG Xbox titles and early Xbox 360 titles. These are Dual Layer (DVD-9) discs and include a "Video Partition" (ISO 9660) and a "Game Partition" (XDVDFS).

Microsoft Xbox 360

• free60: Xbox 360 DVD Drive
• consolemods: XGD3 games
• redump: Microsoft Xbox and Xbox 360 Dumping Guide.
• Xenia Quickstart: How to rip games

Disc Structure & Security

A standard Xbox 360 dump is a raw sector-by-sector image. It consists of specific regions that the console's firmware validates before execution:

1. Physical Format Information (PFI): Contains the disc's physical characteristics (book type, layers).
2. Disc Manufacturing Information (DMI): Unique identifier for the disc's pressing origin.
3. Security Sector (SS): Contains the keys and "drive response" data used for the initial handshake.
4. Video Partition: An ISO 9660 filesystem containing the "Play this in an Xbox 360" video.
5. Game Partition: The actual game data formatted in XDVDFS (Xbox DVD File System).
6. System/Padding Area: Includes the Layer Break and transition regions.

XGD3

XGD3 discs increased the usable density by moving the Lead-Out further toward the edge. Key additions include:

• Extra Outer Area: Adds approx. 1GB of extra data (totaling ~7.8GB usable).
• CIV (Content Integrity Verification): Silent, real-time checks that verify data hashes at random intervals during gameplay.
• Topology Data: A physical "map" of the disc's surface used for AP2.5 (Anti-Piracy 2.5) challenge-response checks.

Verification & Stealth

Because topology data and security sectors are not part of the standard filesystem, they must exist as specific sectors within the image. Verification tools like abgx360 use:

• Topology Injection: Writing the `.bin` data into the ISO's system area.
• CRC Matching: Ensuring the sectors match a verified "Golden Dump" from the database.

A modern Stealth ISO (Kreon/0800 era) is a verified dump containing all security sectors, correct padding, correct layer break, and the full video partition, making it indistinguishable from an original disc to the console's firmware.

VideoNow XP

See Aaru.VideoNow tool.

Diskette-based

Floppies

The primary difference between between "regular" floppy disc dumps and the lower-level captures that devices like Applesauce or Greaseweasel produce; regular dumps just have the data that you would obtain when copying the disk on a computer using the OS. Lower-level dumps go down to the magnetic flux changes on the disk and are able to reproduce complex copy protection schemes.

Floppy Disk Image Formats Comparison
Standard sector-based formats typically preserve only decoded sector data and do not retain the low-level physical characteristics of a floppy disk. Many historical copy-protection schemes relied on physical disk properties such as non-standard track layouts, deliberate CRC errors, weak bits, long tracks, or precise timing behavior. High-fidelity archival preservation therefore requires flux-level captures that record magnetic transition timing rather than only decoded bitstreams.
Archiving extracted files or sector images into compressed containers (e.g., ZIP, 7z using LZMA2) does not constitute full preservation of the original disk. Such containers store logical files or "cooked" sector data only, discarding physical metadata including flux timings, track gaps, weak regions, and intentional structural anomalies. Proper archival preservation requires a low-level disk image (surface or flux-level), which may then be compressed losslessly for storage.

Aspect	Sector Image (.IMG / .IMA)	Structured / Geometry-Aware (.IMD / .TD0 / .FDI / .JSON)	Surface / Bitstream (.MFM / .86F)	System-Specific	Emulator / Reconstruction (.HFE / .IPF)	Flux-Level (.SCP / KryoFlux .RAW / .Z00)
Main Sector Data	✓	✓	✓	✓	✓	✓
File System Integrity	✓ Standard DOS/Windows FAT or equivalent.	✓ Preserves non-standard sector interleave and geometry.	✓	✓ Varies by platform (e.g., Amiga OFS/FFS, C64 GCR).	✓	✓
Track Geometry & Encoding Metadata	✗ Assumes fixed geometry.	✓ Stores bitrate, encoding (FM/MFM), sector sizes, layout.	✓ Captures full decoded track bitstream including gaps and CRC status.	~ Varies significantly by format and platform.	✓ Encodes analyzed track structure for emulation.	✓
Copy Protection Preservation	✗	~ Supports structural protections (sector size/layout tricks); insufficient for protections relying on precise timing or analog behavior.	~ Preserves many structural protections (weak bits, long tracks, CRC anomalies), but does not capture raw analog flux timing.	~ Platform-dependent; some formats (e.g., G64) preserve more low-level behavior than others (e.g., ADF).	✓ Implements protection behavior through analyzed reconstruction models.	✓ Preserves raw magnetic transition timing (hardware-dependent resolution).
Magnetic Flux Timing	✗	✗	✗ Decoded bitstream only.	✗	✗	✓ Captures magnetic transition intervals directly from hardware.

---

When dealing with flux-level image sets, images are categorized by verification status. A flux dump is only as reliable as its independent validation against other physical samples and consistent capture methodology.

• Verified [!]: Two or more independent dumps from separate physical disks produce matching structural and timing characteristics across tracks. Minor variations caused by intentional weak bits or analog instability must be documented. Capture hardware, firmware, and software versions (e.g., KryoFlux or SuperCard Pro logs) should be recorded.
• Modified [M]: Image contains post-production alterations such as user files, installer artifacts, filesystem metadata updates, or operating system writes occurring after original manufacture.
• Fixed / Restored [F]: Image has been modified to remove post-production alterations and approximate original factory structure. All restoration actions must be documented transparently.
• Copy Protected [cp]: Software employs physical, structural, or timing-based copy protection. Sector images (.IMG) generally require cracking to function if protection relies on non-standard disk behavior. Original protection mechanisms are most accurately preserved in Surface (bitstream) or Flux-level formats

Cartridge-based

Games on Nintendo's NES, SNES, GB and N64, Sega's Master System and Mega Drive (aka Genesis), NEC's PC-Engine (aka TG-16), and other systems from the same era were stored on special cartridges to be read with a very particular pin layout only found on their intended hardware.

General tips before we begin

With special hardware

Special hardware dumping the cartridge contents to a more digital-friendly binary form has been made for older consoles (as we mentioned in "Before diving in" section). However, these pieces of hardware have been going out of print recently.

• Kazzo: for the NES.
• INLRetro: From the same person as Kazzo, but able to dump NES, SNES, N64, Sega Genesis, Famicom, GB, and GBA.
• Retrode: for the SNES and Sega Mega Drive/Genesis. Third-party physical plug-ins add more systems, including the GB, GBA, N64, VB; Sega's Master System, Pico; NEC's PC-Engine; Atari 2600 and more. An NES add-on was said to be under development.

Bear in mind that when trying to dump cartridge games, there's a significant risk of having corrupt sectors in the resulting dump. If you're using your DIY adapters but don't know what you are doing, there's a risk of damaging the original cartridge due to out-of-spec voltages.

Newer systems using game cards such as the DS and 3DS have other solutions relying either on recent dedicated hardware, or homebrew under a compromised system.

Ripping from emulated releases

Sometimes the companies re-release the games digitally, as a wrapper containing an emulator and the ROM. Depending on the company, the ROM may or may not be directly playable in regular emulators. You can extract those ROMs and play them without having to go to shady sites nor tracking expensive cartridges and potentially breaking them in the ripping process. And you get to support the company who made the stuff you love, instead of resellers hoarding second-hand game copies or random, less-reputable ROM sites other than those trusted by the community. That being said, emulated re-releases may contain changes due to licensing or censorship issues amongst other things.

Virtual Console (Wii, Wii U, 3DS)

The Wii VC releases are most of the time ready to work in emulators. In fact, Nintendo was so kind they even included the iNES headers in NES ROMs (16 bytes at the beginning of the ROM that are not part of the original cart data yet the emulator needs them to know which mapper it is and run the game at all). You can even replace the ROM with one from the same system from your choice, and get it to run if Nintendo's emulators are compatible. The discovery of iNES headers in VC releases led to a rumour wherein Nintendo, or at least those whom Nintendo subcontracted for the re-releases, merely downloaded their own games off a ROM site, though while both the VC release of Super Mario Bros. and pirated copies of it do share the same checksum (and are thus identical), it might be just a coincidence, and knowing Nintendo they will certainly deny any such accusations of pirating their own games.

Some Virtual Console versions have been enhanced or modified compared to the original release.

While some just modify the ROM directly (like Monster World IV's English translation), other modifications rely on real-time patching by patch files included with the ROM (like Romancing SaGa 2's extra dungeons). The anti-seizure effects and texture enhancements are most of the time tied to the VC emulator.

Also, Super Nintendo ROMs have their SPC sound data blanked in the ROM and stored in a separate file, meaning the ROM dump is incomplete for these. And you might need a byte swapper tool for N64 games.

For Wii VC:

• Get ShowMiiWads.exe and select "I accept and take the risk of WAD editing features". Go to Tools/Create Common-Key and type in the text it asks you for.
• You need a wad file of the VC app.
• If you don't have a wad file yet, you can get it from a NAND dump extracted off your Wii with dedicated homebrew apps (changing it and reinserting it in the Wii could be dangerous if you don't know what are you doing, that was what the disclaimer was for, it's not relevant here though). In ShowMiiWads, click Options/Change NAND Backup Path, then click View/ShowMiiNand, and then on the file with the name of the game right-click and click Pack Wad. Then click View/ShowMiiNand again.
• Now that you have the wad file, go to File/Open Folder and where the wad file is.
• Right-click, Extract/To Folder.
• You go to the newly created folder, and you'll find lots of files. Chances are the biggest "app" file has the emulator and ROM data. It's usually "00000005.app" for MSX/GEN/N64 roms. In the utility, load it and click Tools/Unpack U8 Archive.

Congrats! You should have the ROM somewhere in there. Check the file sizes and name for hints and find out which one it is, it's part of the fun.

However! Some post-2010 ROMs give inside another compressed "romc" file. That's the ROM, but compressed. You'll need the romc command-line decompression tool, following the commands:
cd C:/romfolder/
romc d C:/romfolder/romc C:/extractionfolder/customromname.extension

Here is how to dump GBA images off Wii U's VC and unscramble the resulting ROM images to something playable on emulators.

Various compilations

• Sega Ages - MD
• Sega Mega Collection (multiple systems) - MD
• Sega I Love Mickey Mouse (Saturn) - MD - ROM divided
• Animal Crossing GC - NES/SNES
• Zelda Collector Disk GC - NES/N64 (includes 60Hz PAL OoT/MQ/MM versions)
• Konami Twinbee Collection - SNES - ROM divided
• Rare Replay

Nintendo Game Boy Advance

With a Flashcart (On DS)

• GodMode9i

GBA Link Cable (GCN and Wii)

• GBA Link Cable Dumper - Slow transfer speeds, can dump BIOS also. Cannot be used to dump GB(C) sadly.

Nintendo DS / 3DS

With a Flashcart (On DS / DSi / 3DS)

• Wood Dumper Uses FTP to send ROM and save file over wifi. Only for DS ROMs.

With Custom Firmware (On DSi)

• GodMode9i - Only works if run off of SD card, not on flashcart.

With Custom Firmware (On 3DS)

To hack your 3DS, refer to 3ds.hacks.guide.

DS and 3DS cartridges can be dumped using GodMode9. This works for both the old and new models, as well as variations like the 2DS.

3DS dumping formats. See this page for more information.

Extension	Full name / Official term	Container type	Primary purpose / Usage	Contains executable code?	Relation to NCSD / NCCH	Notes / Common context
.3ds	(Unofficial) 3DS ROM dump	NCSD (CCI variant)	Dumping / emulation of physical Game Cards (cartridges)	No (container)	Identical structure to .cci (NCSD container holding NCCH partitions, typically 0.cxi + CFAs)	Very common in emulation (Citra) and community dumps; unofficial extension for .cci files
.cci	CTR Card Image / Citrus Card Image	NCSD	Official format for 3DS Game Card (cartridge) dumps	No (container)	NCSD container; holds up to 8 NCCH partitions (usually partition 0 = CXI, others = CFA)	Official Nintendo term; exact same format as most .3ds files
.csu	CTR System Update / Citrus System Update	NCSD	System/firmware update packages	No (container)	NCSD format, similar to CCI but used for updates; contains NCCH (usually CFA-type) partitions	Same underlying structure as .3ds/.cci, but for system updates
.cxi	Citrus eXecutable Image / CTR eXecutable Image	NCCH (executable variant)	Main game/application executable code	Yes	NCCH container with ExeFS (includes ARM11 .code) + RomFS; wrapped in NCSD (.cci/.3ds/.csu) or CIA	Core executable part of a title; can be extracted from cartridges or installable packages
.app	(Application)	NCCH (usually CXI)	Alternative name for the main executable content file	Usually yes	Typically synonymous with .cxi; seen in title directories or unpacked formats	Often just a renamed .cxi; used internally by Nintendo tools/system
.cfa	Citrus File Archive / CTR File Archive	NCCH (non-executable variant)	Non-executable data: manuals, additional assets, Download Play child, updates	No	NCCH container with RomFS (and sometimes minimal ExeFS without code); no ARM11 executable	Commonly found as secondary partitions in NCSD (e.g. manual in partition 1, updates in others)
.cia	CTR Installable Archive / Citrus Installable Archive	CIA (separate format)	Installable packages for digital titles, updates, DLC, homebrew	No (container)	Contains one or more encrypted NCCH files (CXI + CFAs), ticket, TMD, certificates	Installed to NAND/SD via FBI/GodMode9 etc.; appears on HOME Menu; not directly runnable like .3ds

Sony PlayStation Vita

With a PS Vita with HEN and NoNpDrm plugin

Notice: dumping titles via Vitamin/MaidumpTools has been considered outdated methods as they are slow and always generate problematic or even upright broken dumps.

Use NoNpDrm plugin and VitaShell to dump titles and DLCs. Notice that the data dumped in this way are still packed in PFS encryption. If you need to modify game content, then you need to decrypt the title by FAGDec presented in PSVita-RE-tools.

Nintendo Switch

With a Nintendo Switch console with CFW

Both cartridge and digital games, and related DLCs and updates could be easily dumped with nxdumptool.

Notice that you are very likely to be using emuNand in order to prevent from damaging the system software stored in the actual built-in storage and/or getting banned from eShop and other online services by Nintendo. If that is the case, you will have to create a new emuNand as the image of the built-in storage in order to dump game titles installed from eShop in actual built-in storage.

Extension	Full name / Official term	Container type	Primary purpose / Usage	Contains executable code?	Relation to NCA / other formats	Notes / Common context
.xci	NX Card Image	HFS0 partitions (secure RomArea + non-secure NormalArea)	Dumping / emulation of physical Game Cards (cartridges)	No (container)	Top-level container holding multiple NCAs (Program + Control + Meta + optional update/DLC partitions); GameCard distribution type	Precise 1:1 dump of the cartridge including all empty space and padding (fixed cartridge sizes: 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB); often pre-patched with updates/DLC in the scene; uses hardware authentication (CardKey / certificates)
.nsp	Nintendo Submission Package	PFS0 (Partition File System 0) superblock	Installable packages for digital titles, updates, DLC (eShop / digital distribution format)	No (container)	Packs one or more NCAs + Ticket (.tik) + Content Meta (.cnmt) + Certificates + Rights IDs; Download distribution type	One-to-one copy of the eShop/digital version; usually contains only the base game (updates and DLC are separate NSP files); no cartridge padding → smaller file size; can be split into multi-part files (e.g. .00, .01); installed to NAND or SD card
.nca	Nintendo Content Archive	NCA (encrypted archive with sections: Header + FsSections)	Modular content units: program code, metadata, control data, manuals, additional assets, etc.	Varies by content type (Program NCAs contain executable code)	Core building blocks extracted from .xci or .nsp files; types include: Program (00), Meta (01), Control (02), Manual (03), Data (04), PublicData (05); contains ExeFS (PFS0 with .npdm, .code, etc.) + RomFS (assets/data)	Always encrypted and signed; RomFS can be patched for updates; Program NCAs hold the main executable code (.code) and launch metadata (.npdm); rarely used directly by end-users

Arcade hardware

PC-based

Despite the very kernel of them being just PCs, customized hardware and software copy protection made dumping arcade titles a very complex procedure that's not one-for-all.

Generally speaking, after disabling protocol level security (ATA password, etc.), the hard drive that contains the operating system and game data could be plugged into a computer running Linux and a raw dump could be generated by dd command, which would serve the purpose as the backup for a specific cab: a specific board + hard disk + security measure (dongles, etc.) combination.

However, if the purpose of dumping is running the game in other hard disks/boards/cabs, or on regular PCs via compatibility layers e.g. TeknoParrot then a series of complex operations including decrypting data, fetching license from security measures, unpacking executive files, etc. would be involved which is way beyond the scope of this article or even the entire wiki.

Here is an example of what it takes to dump and optionally change the games running in SEGA Ring series PC-based arcade hardware.

Analog

Comparisons

Analog Media File Format Comparison This table compares the two primary methods for digitally preserving analog media like LaserDisc and VHS: the high-fidelity Domesday Duplicator method (raw RF signal capture) and the more common Playback Capture method (standard video/audio file capture). The choice of file format is directly tied to the capture method, determining the level of detail and data retained for future-proofing and accurate emulation.
Aspect	Domesday Duplicator Method (Raw Capture) .ldf, .vhs, .lds, .rf, .mmi	Playback Capture Method (Standard Capture) .mp4, .avi, .mkv, .mpg
Core Principle & Workflow	Captures the raw, unprocessed RF signal from the player's internal electronics. Decoding is done later in software, allowing for maximum data recovery.	Captures the decoded and processed video and audio output from a player. The signal has already passed through the player's internal TBC and decoders.
Video Quality	Highest Potential: Bypasses the player's internal decoders. Quality depends on the decoding software, which can be improved over time. Software-defined noise reduction and advanced deinterlacing are possible.	Limited by Hardware: Quality is limited by the specific player's components (e.g., TBC, comb filter) and the capture card. Subsequent improvements in decoding are not possible. Artifacts and generational loss from compression are unavoidable, the choice of codec (e.g., Lossy codecs like H.264 or MPEG-2, Lossless codecs like FFV1) and its settings (e.g., bitrate, GOP structure) also determines the amount of data loss.
Audio Preservation	Comprehensive: Captures all audio tracks, including analog FM, digital PCM (for LaserDisc), Hi-Fi stereo (for VHS), and multi-channel formats like Dolby Digital and DTS. HiFi-Decode is used for Hi-Fi tracks.	Limited: Typically only captures the final stereo or mono audio output. Digital tracks and Hi-Fi RF tracks are often lost, The quality is limited by the hardware as the capture card only processes the final analog or digital audio signal. The quality is also limited by the software, codec (e.g., Lossy codecs like AAC, MP3 or Opus, Lossless codecs like FLAC) and audio settings. Lossy audio codecs are often chosen during the single-step capture and encoding process, causing further degradation.
Data & Interactivity	Complete: The only method that preserves low-level data streams, control codes, and frame-by-frame timing information. Essential for emulating interactive media (e.g., BBC Domesday Project) and arcade games (e.g., Dragon's Lair).	Lost: All low-level data and control codes are discarded by the player's internal decoders. This makes accurate emulation of interactive features and timing-sensitive content impossible.
Data Recovery	Stacking: Allows for "stacking" multiple captures of the same media to recover lost data and correct dropouts from physical wear. This can produce a composite file with better quality than any single disc.	None: Data is lost once the signal is decoded and captured. There is no mechanism for comparing multiple playback captures to improve quality or recover data.
Future-Proofing	Highly Future-Proof: Since the raw signal is preserved, future software can be developed to decode the data with new, improved algorithms, potentially revealing more detail than the original hardware could.	Not Future-Proof: The video and audio are "baked in" to a final format. Even with lossless codecs with proper settings, the quality is permanently capped at the level of the original capture hardware and software, and all low-level data and interactivity information are still lost.
Emulation Support	Supported by MAME for some specific LaserDisc arcade games, allowing for accurate emulation. Ares and Domesday86 communities have made serious progress in Pioneer LaserActive emulation. .mmi (Mixed Media Image) file format, which contains the full analog audio, video, and digital content in a single file, can be loaded directly into Ares.	Widely used by arcade LaserDisc emulators like Daphne, Hypseus Singe, which were built around this method. Emulation is based on timed commands and video files, focusing mimicking and simulation of the original behaviour, fundamentally limiting accuracy and interactive features compared to the raw capture method. Raw captures can be converted to playback formats for other emulators (e.g., Hypseus-Singe) using ffmpeg to get the best visual quality. See Hypseus: Utilizing DomesDay86/Radio Frequency captures
Optimal File Size	Very Large: Raw captures can be massive (e.g., ~41 GiB per LaserDisc side). File sizes can be reduced significantly (~40-60%) using FLAC compression.	Manageable: File sizes are much smaller, as the video is already compressed by the capture software (e.g., into MPEG-2 or H.264).
Hardware Required	Requires dedicated, open-source hardware like the Domesday Duplicator or a CX Card, which is more complex and expensive than a standard capture card.	Requires a readily available video capture card (e.g., Elgato, Hauppauge) and a working analog player.

Tutorials

For .ldf (LaserDisc RF Captures)

These are raw RF samples from LaserDisc players captured via hardware like the Domesday Duplicator.

• Decoding Process: Use ld-decode (a Python-based tool) to convert .ldf files into time-base corrected (TBC) files. From there, tools like tbc-video-export can generate playable files such as lossless FFV1 in .mkv format.[23]
• No Direct Playback: The raw files cannot be opened or viewed without decoding; there's no software for on-the-fly playback of stored .ldf files.
• Tools Required: ld-decode and its utilities (available on GitHub with CLI/GUI options like ld-analyse for inspection). Dependencies include Python, NumPy, and FFmpeg.

For .lds (LaserDisc Sample Files)

These appear to be sample or cut segments from raw LaserDisc RF captures, often used for testing or issue reporting in decoding workflows.

• Decoding Process: Treat them similarly to .ldf files using ld-decode tools like ld-cut for extraction, followed by full decoding to TBC and export to video.
• No Direct Playback: Like other raw RF formats, they require processing; no direct viewing tools are present.
• Tools Required: Same as ld-decode ecosystem.

For .vhs or .rf (VHS RF Captures)

These store raw FM RF signals from VHS tapes, often captured with similar hardware. .rf is a generic extension for uncompressed raw data, while .vhs may indicate FLAC-compressed versions.

• Decoding Process: Run vhs-decode (a fork of ld-decode) on the files to produce TBC files (luminance and chrominance separated). Then, use tbc-video-export to create video files, such as 10-bit 4:2:2 FFV1 .mkv (70-100 Mbps, lossless) or ProRes .mov. Audio (e.g., Hi-Fi tracks) is handled separately with hifi-decode, outputting FLAC files that can be muxed in.[24]
• No Direct Playback: Raw .vhs or .rf files cannot be played without decoding, as they need software demodulation and correction. However, live "on-the-fly" decoding is possible during capture with certain setups (e.g., RTLSDR and GNURadio), but not for pre-captured files.
• Tools Required: vhs-decode and companions (CLI-focused, with some GUI like ld-analyse; supports Windows, Linux, macOS). Requires Python 3.8+, SciPy, Qt5, and FFmpeg.

For .mmi format

Recently, the Ares and Domesday86 communities have made serious progress in Pioneer LaserActive emulation. For instance, games are stored in a new .mmi (Mixed Media Image) file format, which contains the full analog audio, video, and digital content in a single file. This can be loaded directly into Ares. The MMI format has internal compression support, do not compress it.

Note about .CHD format

The primary reason that emulation of LaserActive games does not use the Compressed Hunks of Data (CHD) format is a combination of the format's technical limitations and the demanding performance requirements of the LaserActive system. The developer who created the alternative .mmi format for emulation has publicly explained this decision.

While the CHD format is used for some laserdisc-based arcade games, such as Dragon's Lair, its support is limited and does not cover the full range of features present on LaserActive discs. The format does not currently support:

• PAL format: CHD is restricted to NTSC.
• Digital audio
• Dual-sided discs and CLV (Constant Linear Velocity)
• Video lines: CHD can cause slight corruption to the original vertical blanking interval (VBI) lines.
• Resolution and cropping: The horizontal resolution is limited and the image is cropped to the "visible region" of the screen.

The MAME development community acknowledges that a significant revision of the CHD format is needed to properly support LaserActive games. However, since this work is not scheduled, the developer chose to create a new format rather than delay the release of LaserActive emulation.

The LaserActive is a significantly more advanced machine than early 1980s laserdisc arcade games. The CHD format was designed for those older systems, which had slow, infrequent seek times. In contrast, the LaserActive's control system allows for rapid and precise playback, including:

• Instant seeking
• "Trick play" by fixed frame intervals
• Reverse playback
• Seamless looping
• Interleaved video streams where frames are skipped or fields are selected on the fly

To achieve the performance required for emulation, the `.mmi` format was created to store video in a way that allows for extremely fast decoding—approximately 2ms per frame. This is critical to maintain the target 60fps framerate.

Emulating the LaserActive is a complex task, as it involves running a full Mega Drive and Mega CD alongside the laserdisc playback. The system includes multiple CPUs, sound sources, and a complex graphics chip. It also performs sophisticated video mixing, which requires the emulator to pull specific lines from a decoded frame and mix them with the Mega Drive's graphics output. A traditional video codec used by CHD cannot handle these demanding, real-time operations.

The `.mmi` format was designed as an open and simple alternative. It is a ZIP file in "store" mode, with a JSON metadata file, raw PCM for analog audio, and a custom video format called QON. This design enables:

• Fast decoding: Frames can be decoded directly from the disc into memory as needed.
• Transparency: The format is easy to inspect and can be unpacked into a folder of PNG images.
• Flexibility: The `.mmi` format can support any storage medium and has potential for use in future emulation projects.

Disc-based

LaserDisc

Main article: #The Domesday Duplicator Project Method

Main article: #Playback Capture Method

Main article: LaserDisc

The preservation and emulation of systems and games that utilized LaserDisc technology have evolved significantly over time. A core distinction lies in the method of capturing content from the discs: whether it's a simple playback capture or a deep, low-level digital archive of the raw signal.

Tape/casette-based

VHS

Main article: #The Domesday Duplicator Project Method

Main article: #Playback Capture Method

You can follow this guide.

Compact Cassette

See this guide.

The Domesday Duplicator Project Method

The Domesday Duplicator is a dedicated, open-source hardware and software project designed by the Domesday86 community to create the most accurate possible digital archives of LaserDiscs and other analog media.[25][26] It relies on a principle of low-level RF signal capture, which is detailed in the Signal Sampling wiki. The project takes its name from the BBC Domesday Project of the mid-1980s, an ambitious multi-media census of the UK stored on specialized LaserDiscs. The Duplicator was initially created to preserve these culturally significant discs, which were at high risk of being lost to time due to the obsolescence of the original playback hardware. The project is built on the philosophy of open-source and open-hardware, with all schematics, board designs, and software freely available. This community-driven approach ensures that the methods for preserving these formats are accessible and can be improved over time. It operates on a principle similar to "low-level" floppy disk imaging, which captures the raw magnetic flux changes on a disk rather than just the file data a computer's operating system would see.

Core Principles and Technology

• Raw RF Signal Capture: Unlike a standard video capture card, this method involves tapping into the analog RF signal *before* the player's internal electronics decode it into video, audio, and data. The hardware consists of a device using an Analog-to-Digital Converter (ADC) that samples the RF signal at a very high rate (e.g., 35.5 MSPS for PAL), an FPGA for buffering, and a Cypress FX3 board for high-speed USB 3.0 data transfer to a computer. The hardware can be a Domesday Duplicator or a more cost-effective CX Card. The RF Capture Hardware wiki has more information.

• Software-Defined Decoding: Since the raw RF data is captured, a suite of open-source software is used to perform all decoding in a software-defined manner. This is a key advantage, as it allows for:
  • Maximizing Video Quality: bypassing a player's internal Time Base Corrector (TBC) and analog-to-digital converters allows the signal to be decoded in software. This enables the use of advanced deinterlacing and noise reduction algorithms that can be improved over time, potentially producing a cleaner image than the original player could.
  • Capturing All Audio: the capture includes all audio tracks, both analog (often with CX noise reduction) and digital (CD-quality PCM, Dolby Digital, or DTS), ensuring nothing is lost. For tape formats, this includes the HiFi FM tracks.
  • Data and Interactivity: for discs containing interactive content (such as the BBC Domesday System) or other digital data streams, the raw RF capture is the only way to preserve the control codes and data packets necessary for emulators to accurately replicate the original experience. This is particularly important for both Constant Angular Velocity (CAV) and Constant Linear Velocity (CLV) disc formats. CAV discs, which spin at a constant speed, allowed for features like perfect freeze-frame and frame-by-frame playback, often used for special features and interactive content.
• "Stacking" for Data Recovery: A unique feature of the Domesday Duplicator software is its "stacking" capability. By capturing multiple copies of the same disc, the software can use algorithms to compare them and correct for "drop-outs" (physical damage or defects on one disc). This process can create a near-perfect composite from the best data of each capture, a method invaluable for preserving rare or heavily used media. The successful preservation of the arcade game Dragon's Lair required stacking captures from seven different discs due to wear and tear.[27][28]

The Software Stack and Broader Applications

The hardware is only half the story. The Domesday Duplicator relies on a suite of open-source software to make the captured data useful:

• LD-Decode: This is the primary software for converting the raw RF data from LaserDiscs into usable video and audio files. It performs the complex decoding, time base correction, and noise reduction in a software-defined manner, which is a key advantage over a player's fixed internal electronics.
• VHS-Decode: Demonstrating the versatility of the capture hardware, this is a separate software project that uses the Domesday Duplicator to archive and decode other analog video formats like VHS, S-VHS, and Betamax by capturing their respective raw RF signals. It supports a wide variety of formats, as listed in the Supported Tape Formats wiki.
• CVBS-Decode: This experimental decoder shares code with `ld-decode` and `vhs-decode` to decode basic RAW digitized NTSC and PAL composite video, leveraging the powerful TBC code and chroma-decoders of the ld-tools suite.
• HiFi-Decode: Provides decoding support for (S)VHS & Video8/Hi8 HiFi FM tracks from uncompressed or FLAC compressed RF captures, outputting standard 24-bit stereo audio files.

Impact and File Sizes

The Domesday Duplicator method has been a game-changer for preserving LaserDisc-based arcade games and other interactive media, allowing for more faithful and future-proof emulation than was previously possible. The scale of this preservation effort is significant; raw RF captures from a single LaserDisc can be around 41 GiB, and the stacking process for a single game can require hundreds of gigabytes of data. The resulting compressed files used in emulators like MAME, however, are much more manageable, typically ranging from 10 to 20 GiB. The use of FLAC compression can reduce raw RF file sizes by 40-60%.

Playback Capture Method

This method typically use video and audio files (e.g., MPEG-2, MP4) that have been captured by playing a LaserDisc/VHS on a player and feeding its video output into a standard video capture device (like an Elgato). The resulting files are already processed, decoded, and encoded by the capture hardware and software. Arcade LaserDisc emulators like Daphne, HYPSEUS-SINGE, and DirkSimple are widely used this method for playing LaserDisc arcade games which is fundamentally different from the Domesday Duplicator's approach. You can follow this guide. This method has several inherent limitations;

• Signal Degradation: the capture reflects the quality of the specific LaserDisc/VHS player and capture card used, including any signal noise, decoding errors, or compression artifacts introduced during the process.
• Loss of Raw Data: crucial raw RF data, control codes, and frame-by-frame timing information are not preserved, making it impossible to perform advanced software-based corrections or to emulate interactive data.
• Lack of Future-Proofing: Since the captured files are already processed, they cannot benefit from future improvements in software decoding algorithms, unlike the raw RF captures from the Domesday Duplicator. While historically these emulators relied on playback capture, Hypseus-Singe can now enjoy the superior clarity of the Domesday86 rips by converting the raw captures to a compatible format with ffmpeg.[29]

See also

• Copy protection
• Sites for determining good dumps (CRC's, MD5's, etc.)
• Save disk space for ISOs
• Literature
• Home media players

External links

• Redump Dumping Guides
• No-Intro Dumping Guides
• dumping.guide
• RED Project - Information on extracting ROMs from a variety of products such as game compilation and mini consoles (still a work in progress)
• bitsgalore: Preserving optical media from the command-line
• Aaru changelog, DiscImageCreator changelog, Redumper changelog.
• GerbilSoft: ROM Properties Page shell extension