Architecture & Internals

This page describes the technical architecture of Open Burning Suite, its layered design, and how the major components interact.

High-Level Architecture

Open Burning Suite follows a clean layered architecture where each layer depends only on the layer below it:

┌──────────────────────────────────────────────────────────────┐
│                       Avalonia UI Views                       │
│  Discover · Copy Disc · Build Image · Burn/Write · Verify    │
│  Advanced · Settings · Help                                   │
│  AudioWizard · VideoWizard · DataWizard · GameWizard          │
│  CopyWizard · BlankWizard                                     │
│  DiscVisualizationControl (SkiaSharp)                        │
├──────────────────────────────────────────────────────────────┤
│                       Services Layer                          │
│  BurnService · ReadService · BuildService · VerifyService    │
│  DiscDiscoveryService · DiscEncryptionService                │
│  GamingDiscService · SettingsService                         │
│  Ps3DiscService · Xbox360StealthService · XisoService        │
├──────────────────────────────────────────────────────────────┤
│                    Native Engine Layer                        │
│  Optical: BurnEngine · ReadEngine · OpticalDrive             │
│  Iso: IsoBuilder · VcdBuilder · ElToritoWriter               │
│       HfsPlusBuilder · RockRidgeExtensions/Reader             │
│       CcdParser/Writer · CdiParser/Writer · MdfParser/Writer  │
│       NrgParser/Writer · ImgParser/Writer                     │
│  Audio: AudioConverter · AudioCdBuilder · CdTextEncoder      │
│         PlaylistParser · AudioReaderFactory                   │
│  Video: BluRayAuthoringBuilder · DvdAuthoringBuilder         │
│         VideoTranscoder (FFmpeg)                              │
│  Toc: TocCueConverter                                        │
├──────────────────────────────────────────────────────────────┤
│                 SCSI / MMC Command Layer                      │
│           MmcCommands · ScsiCommand · ScsiResult              │
├──────────────────────────────────────────────────────────────┤
│              Platform SCSI Transport Layer                    │
│  WindowsScsiTransport (IOCTL_SCSI_PASS_THROUGH_DIRECT)      │
│  LinuxScsiTransport (SG_IO)                                  │
│  MacOsScsiTransport (IOKit SCSITaskLib)                      │
├──────────────────────────────────────────────────────────────┤
│                Platform Utilities Layer                       │
│  NativeDeviceDiscovery · NativeEject · NativePrivilege       │
└──────────────────────────────────────────────────────────────┘

Layer Descriptions

1. UI Layer (Views/)

The presentation layer built with Avalonia UI using the Fluent theme. The main window provides sidebar navigation across multiple views:

2. Services Layer (Services/)

The orchestration layer that coordinates between the UI and native engines. Services handle high-level business logic, progress reporting, and error management.

3. Native Engine Layer (Native/)

The core implementation layer containing the actual disc operation logic, organized into subdirectories:

Optical (Native/Optical/)

ISO / Image Formats (Native/Iso/)

Audio (Native/Audio/)

Video (Native/Video/)

TOC / CUE (Native/Toc/)

Platform Utilities (Native/Platform/)

4. SCSI / MMC Command Layer (Native/Scsi/)

Builds and interprets SCSI Command Descriptor Blocks (CDBs) per the MMC-5 (Multimedia Commands) standard:

5. Platform Transport Layer (Native/Scsi/)

Platform-specific implementations of the IScsiTransport interface:

Key Design Decisions

Native SCSI/MMC Implementation

Why: Traditional disc burning applications rely on external command-line tools (cdrecord, wodim, growisofs, mkisofs). This creates dependency management issues, inconsistent error handling, and platform-specific tool availability problems.

Solution: Open Burning Suite implements all disc operations directly using SCSI/MMC-5 commands sent through platform-specific SCSI passthrough mechanisms. This provides:

• Zero external runtime dependencies
• Consistent behavior across platforms
• Direct hardware error reporting via SCSI sense data
• Fine-grained control over all disc operations

Platform Abstraction via Interface

The IScsiTransport interface defines a single method for executing SCSI commands:

IScsiTransport
├── WindowsScsiTransport  →  IOCTL_SCSI_PASS_THROUGH_DIRECT
├── LinuxScsiTransport    →  SG_IO ioctl
└── MacOsScsiTransport    →  macOS passthrough

ScsiTransportFactory selects the correct implementation at runtime based on the detected platform.

Write Strategy: 16-Sector Chunks

BurnEngine writes data in 16-sector chunks (16 × 2048 = 32,768 bytes per write command). WRITE(10) is used for CD media (16-bit transfer length) and WRITE(12) for DVD/BD media (32-bit transfer length for reduced command overhead). This balances:

• Drive buffer efficiency (large enough to minimize command overhead)
• Progress granularity (small enough for responsive progress updates)
• Compatibility (universally supported transfer size)

Tray Lock Safety

BurnEngine wraps all write operations in a try/finally block to ensure the disc tray is always unlocked (PREVENT/ALLOW MEDIUM REMOVAL) even if an exception occurs. This prevents discs from being permanently locked in the drive after a failed burn.

Sense Data Handling

SCSI sense data is handled in both fixed format (response codes 0x70/0x71) and descriptor format (response codes 0x72/0x73). The sense key, ASC (Additional Sense Code), and ASCQ (Additional Sense Code Qualifier) are extracted at the correct offsets for each format.

Data Models (Models/)

Job Models

Each operation type has a corresponding “job” model that carries all parameters:

Progress Models

Each job type has a progress model for real-time status reporting:

Disc Models

Image Format Models

Application Models

Helpers (Helpers/)

External Dependencies

Note: FFmpeg is an optional runtime dependency — it is required for video authoring features but not for disc burning, reading, building, or verification. It is detected at runtime on the system PATH or common installation locations.

Code Conventions

• Nullable reference types are enabled project-wide (<Nullable>enable</Nullable>)
• Static compiled Regex patterns with RegexOptions.IgnoreCase | RegexOptions.Compiled
• XML doc comments on all public APIs
• Byte-to-uint casting before bit-shifting to prevent signed integer promotion issues
• Path traversal protection — IsoBuilder validates all paths resolve within the source folder
• Process deadlock prevention — stdout/stderr are drained before WaitForExit() on all Process.Start calls

Next: FAQ →