cdrom-image file format specifications

[nocash]

specifications of sbi format are given in 'PSEmu Pro CDR plugin interface'
// 1 byte Format: the format can be 1, 2 or 3:

Many thanks! Good to know!

And the https://redump.info/guide/libcrypt/ page says that CRC-16 is also scattered on libcrypt'ed cdrom... but the SBI files don't support that?

...console does not return erroneous subchannel data, in such cases it returns previous frame instead

Ah, okay... then the correct way to support sbi files in my psx emu would be:
Ignore all Q channel data in the sbi file, and replace by Q channel data from previous sector.
Easy to do that. Although it's a bit surreal
Was that sbi format designed specially for psx/libcrypt? Or was it originally for other computers/consoles?

as i remember it this program was updated long ago for a last time
and could be it does not identify every LC pattern as such

Yes, looks so. LC1 and LC2 are fine. But "Other sectors" could either mean LC3 or other/broken/scratched sectors.
NB. the links on the https://redump.info/guide/libcrypt/ page are a all broken/corrupted: The "psxt001z 0.20" links return the .7z as text document instead binary, and the "PSXCPLIST" is completely gone.

Oh, and aside from .sbi, the 'PSEmu Pro CDR plugin interface' source code does also mention .m3s files: containing all subchannel Q data from all sectors with minute=03 (the sectors where normal libcrypt data is found). It doesn't support the backup (on minute=09).
The source code says m3s contain 10 bytes from Q channel plus 6 garbage bytes, but that isn't exactly right: there are 12 bytes (including the crc bytes) plus 4 garbage bytes, as seen in this files: http://www.ngemu.com/forums/showpost.ph … ostcount=8
The 4 garbage bytes seem to be set to 00,00,00,00 or FF,FF,FF,FF (randomly containing either value on this or that sector). The "garbage" doesn't make any sense to me... unless it's meant to contain 32bit timing offset ranging from -1 to +0 or so.

[nocash]

Found out "more" on the m3s files. Well, I am saying "more" - but actually, I do understand the file format less than ever there are at least 3 variants of the format:
1. With CRC, as here: http://www.ngemu.com/forums/showpost.ph … ostcount=8
2. Without CRC, as here: http://chomikuj.pl/DeViS100/PSX/Emulato … 403540.M3S
3. Without anything (mostly zerofilled), as here: http://chomikuj.pl/DeViS100/PSX/Emulato … 403524.M3S
The first variant contains all needed data.
The second lacks the CRC (like SBIs), one could eventually look for uncommon MM:SS:FF addresses, and "assume" a wrong CRC for such entries - nasty patchwork, but seems to be the only way to make sense of the data.
The third variant contains almost nothing. Only the ADR/Control bytes (Q0), and, for a few sectors, also Q1..Q9 bytes. That might be the "bad" libcrypted sectors, although they should be normally located at sector N and sector N+5, which isn't always the case in the m3s file. So I not too sure if the file does contain any intact/useful information at all.

At the moment, I couldn't imagine how to handle m3s files in a reliable way. Are other emulators or other tools able to deal with all that m3s variants?

[nocash]

For .MDS files, this is what I have figured out:

Code: Select all

CDROM Disk Images MDS/MDF (Alcohol 120%)
----------------------------------------

File.MDF - Contains sector data (optionally with sub-channel data)
Contains the sector data, recorded at 800h..930h bytes per sector, optionally
followed by 60h bytes subchannel data (appended at the end of each sector).
The subchannel data (if present) consists of 8 subchannels, stored in 96 bytes
(each byte containing one bit per subchannel).
  Bit7..0 = Subchannel P..W (in that order, eg. Bit6=Subchannel Q)
The 96 bits (per subchannel) can be translated to bytes, as so:
  1st..8th bit  = Bit7..Bit0 of 1st byte (in that order, ie. MSB/Bit7 first)
  9st..16th bit = Bit7..Bit0 of 2nd byte ("")
  17th..        = etc.

File.MDS - Contains disc/lead-in info (in binary format)
An MDS file's structure consists of the following stuff ...
  Header              (58h bytes)
  Session block(s)    (usually one 18h byte entry)
  Data blocks         (N*50h bytes)
  Index blocks        (usually N*8 bytes)
  Filename blocks(s)  (usually one 10h byte entry)
  Filename string(s)  (usually one 6 byte string)

Header (58h bytes)
  00h 16  File ID ("MEDIA DESCRIPTOR")
  10h 2   Unknown (01h,03h or 01h,04h or 01h,05h) (Fileformat version?)
  12h 2   Media Type (0=CD-ROM, 1=CD-R, 2=CD-RW, 10h=DVD-ROM, 12h=DCD-R)
  14h 2   Number of sessions (usually 1)
  16h 4   Unknown (02h,00h,00h,00h)
  1Ah 2   Zero (for DVD: Length of BCA data)
  1Ch 8   Zero
  24h 4   Zero (for DVD: Offset to BCA data)
  28h 18h Zero
  40h 4   Zero (for DVD: Offset to Disc Structures)   (from begin of .MDS file)
  44h 0Ch Zero
  50h 4   Offset to First Session-Block (usually 58h) (from begin of .MDS file)
  54h 4   Zero (for DVD?: Offset to DPM data blocks)  (from begin of .MDS file)

Session-Blocks (18h bytes)
  00h 4   Pregap correction. ALBA. (0=TAO, FFFFFF6Ah=-150=DAO)
  04h 4   Total number of sectors (in Pregap, plus in .MDF file)
  08h 2   Session number (starting at 1)
  0Ah 1   Number of Data Blocks with any Point value (Total Data Blocks)
  0Bh 1   Number of Data Blocks with Point>=A0h      (Special Lead-In info)
  0Ch 2   First Track ? Unknown (01h) (total number of sessions in image?)
  0Eh 2   Last Track ? Number of Data Blocks with Point<A0h (Normal Track info)
  10h 4   Zero
  14h 4   Offset to First Data-Block (usually 70h) (from begin of .MDS file)

Data-Blocks (50h bytes)
Block 0..2 are usually containing Point A0h..A2h info. Block 3..N are usually
TOC info for Track 1 and up.
  00h 1   Track mode (see below for details)
  01h 1   Number of subchannels in .MDF file (0=None, 8=Sector has +60h bytes)
  02h 1   ADR/Control (but with upper/lower 4bit swapped, ie. MSBs=ADR!)    Q0
  03h 1   Zero (probably Track, which is alwas 0 in Lead-in)               Q1?
  04h 1   Point (BCD? Track, or A0h and up=Lead-in)                         Q2
  05h 4   Zero (probably dummy MSF and reserved byte from Q channel)   Q3..Q6?
  09h 1   Minute (Non-BCD!) (if track >= 0xA0 -> info about track ###)      Q7
                            (if track = 0xA2 -> min. @ lead-out)
  0Ah 1   Second (Non-BCD!) (if track = 0xA2 -> sec. @ lead-out)            Q8
  0Bh 1   Frame  (Non-BCD!) (if track = 0xA2 -> frame @ lead-out)           Q9
For Point>=A0h, below 44h bytes at [0Ch..4Fh] are zero-filled
  0Ch 4   Offset to Index-block for this track    (from begin of .MDS file)
  10h 2   Sector size (800h..930h) (or 860h..990h if with subchannels)
  12h 1   Unknown (02h) (maybe number of indices?)
  13h 11h Zero
  24h 4   Track start sector, PLBA (00000000h=00:00:00)
  28h 8   Track start offset                      (from begin of .MDF file)
  30h 4   Number of Filenames for this track (usually 1)
  34h 4   Offset to Filename Block for this track (from begin of .MDS file)
  38h 18h Zero
Trackmode:
  (upper 4bit seem to be meaningless?)
  00h=None (used for entries with Point=A0h..FF)
  A9h=AUDIO       ;sector size = 2352    930h  ;bytes 000h..92Fh
  AAh=MODE1       ;sector size = 2048    800h  ;bytes 010h..80Fh
  ABh=MODE2       ;sector size = 2336    920h  ;bytes 010h..92Fh
  ACh=MODE2_FORM1 ;sector size = 2048    800h  ;bytes 018h..817h (incomplete!)
  ADh=MODE2_FORM2 ;sector size = 2324+0? 914h  ;bytes 018h..91Bh (incomplete!)
  ADh=MODE2_FORM2 ;sector size = 2324+4? 918h  ;bytes ??..?? (contains what?)
  ECh=MODE2       ;sector size = 2448    990h  ;(930h+60h) (with subchannels)

Index Blocks (usually 8 bytes per track)
  00h 4  Number of sectors with Index 0 (usually 96h or zero)
  04h 4  Number of sectors with Index 1 (usually size of main-track area)
Index blocks are usually 8 bytes in size (two indices per track). The MDS file
does usually contain Index blocks for <all> Data Blocks (ie. including unused
dummy Index Blocks for Data Blocks with Point>=A0h).

Filename Blocks (10h bytes)
  00h 4  Offset to Filename (from begin of .MDS file)
  04h 1  Filename format (0=8bit, 1=16bit characters)
  05h 11 Zero
Normally all tracks are sharing the same filename block (although theoretically
the tracks could use separate filename blocks; with different filenames).

Filename Strings (usually 6 bytes)
  00h 6  Filename, terminated by zero (usually "*.mdf",00h)
Contains the filename of the of the sector data (usually "*.mdf", indicating to
use the same name as for the .mds file, but with .mdf extension).

Missing
Unknown if/how this format supports EAN-13, ISRC, CD-TEXT.
Unknown if Track/Point/Index are BCD or non-BCD.

For the "Missing" parts, it would be interesting how they do work. For audio discs & games with more than 9 tracks it'd be absolutely important to know if Tracks are BCD or non-BCD... or if the file format does support than many tracks at all
But I am giving up there for now, I've asked in this forum, and in another forum, but finding somebody who has some .MDS files for examing them seems to be pretty impossible.

[nocash]

About the 2nd and 3rd variant of M3S files... I think they are just nonsense.
For example, for the SLUS-010.51.M3S file, according to https://redump.info/disc/259/ the SLUS-01051 disc doesn't have any libcrypt protection at all.
Same for the "zero-filled" SCES_028.73.M3S file, see https://redump.info/disc/17774/
Looks as if somebody tried to create (corrupt) m3s files for games that don't need them at all.

So far one could just ignore those files - only problem is how to separate between 'real' and 'nonsense' m3s files, ie. how to know when to ignore them... The corrupt "zero-filled" files are easy to detect (and easy to ignore)...
The files without CRC entry are more difficult, unlike SBIs, they do contain ALL sectors on Track 3 (not only the libcrypt'ed sectors), so one can't just assume assume ALL sectors in the file to have wrong CRCs.

Maybe this m3s interpretation could work:
If CRC is nonzero --> accept the whole m3s entry.
If CRC is zero, and Q1..Q9 are zerofilled --> completely ignore the m3s entry.
If CRC is zero, and Q1..Q9 contain "normal" values --> calculate normal CRC value.
If CRC is zero, and Q1..Q9 contain SOME wrong bits --> calculate wrong CRC value (eg. normal value XORed by 0080h).

[Nexy]

Also for ECM encoded images, they are meant to be decoded back into a .bin/.img/.mdf image before use.

DPM measurement is used for a lot of things, SecuROM, Starforce, Tages, both CD and DVD.

Multi-session you want some Dreamcast ones I think? I'm not sure entirely, I'm a PC guy.

iirc Alcohol mdf which are 2448 also store the subchannels scrambled in the image. Where as .sub files from CloneCD are unscrambled. However 2448 images can have the subs either way...

I also think MDS files can contain additional data from a disc, such as ATIP info.

[nocash]

Rok (the libmirage guy) has tested .mds files with more than 9 tracks some days ago. The track numbers are non-BCD (which solving my main question about the format).

He has also made some .mds/.ccd sample images with ean/catalog, isrc, cdtext, more than 2 indices and multiple sessions (which is interesting, although not so important to me; for my psx emulator).

According to Rok's tests, Alcohol .mds images don't have any support for EAN (catalog), ISRC, and CD-TEXT. The html manual on the Alcohol webpage doesn't mention that features either. So far it looks as if they unsupported - although that's hard to believe.
The thing that Rok has tested was: Creating a CD-image as .toc/.bin files, mounting it as virtual cdrom-drive, and then recording it via CloneCD and Alcohol. The resulting .ccd image did have the EAN/ISRC/CD-TEXT stuff. But the .mds image didn't.

> I also think MDS files can contain additional data from a disc, such as ATIP info.
Then it'd be even stranger if it really doesn't support basic features like ISRC... maybe things like ISRC do work too, but need to be enabled via special options.
Seeing a .MDS file with ATIP info would be interesting. Even if it's only to resolve some of the "unknown" MDS file entries; libmirage/mds source code doesn't seem to handle ATIP.

> DPM measurement is used for a lot of things, SecuROM,
> Starforce, Tages, both CD and DVD.
I really hope that I won't need DPM for my PSX emulation! At least, I've never heard about PSX games using DPM.
And for DPM in general, there seems to be a lot of confusion, at least, on wikipedia
For example, http://en.wikipedia.org/wiki/Data_position_measurement claims that SecuROM uses DPM, but in the same sentence, they are referencing to http://www.encrypt.ro/cd-encryption/cd- … curom.html which tells that it uses Data Density (not Position) Measurement.

> iirc Alcohol mdf which are 2448 also store the subchannels
> scrambled in the image. Where as .sub files from CloneCD
> are unscrambled. However 2448 images can have the
> subs either way...
In the formats that I've looked at yet, I've seen the unscrambled variant only in .SUB files. All other formats (with 930h+60h bytes per sector) seem to use scrambled subchannels. But I guess, sooner or later, I'll come across a format that does it the other way.

> Also for ECM encoded images, they are meant to be decoded back
> into a .bin/.img/.mdf image before use.
Yes, seems to be the only way to deal with them. I've added a ECM "decompression" function doing that in no$psx v1.1 (released yesterday) bundled with some cautions about typical ECM-related problems (like .BIN.ECM files without .CUE files).

Oh, and my http://nocash.emubase.de/psx-spx.htm#cdromdrive specs have been updated yesterday, too. The new chapters contain info on .CCD, .CDI, .MDS, .ECM, .SBI, .M3S. The CDI format contains a lot of useless garbage entries (apparently filled with meaningless constant values), but it's easy to implement when ignoring that garbage.

I've also had brief look at mame/mess source code, hoping to find out more about compressed .CHD images... the "chdman" source code looked like a good place to start with... but, after reading it, I didn't learn anything about the file-structure, compression-filters, and compression-algorithm :-/ maybe I didn't study it carefully enough, or the relevant info hides in other libraries/include files.

[F1ReB4LL]

Maybe you will include the support for Redump images, since you are on Redump forum? Just tried them on no$psx 1.1 and they still won't load.

[nocash]

What is a redump image? Another file format?

[F1ReB4LL]

For example:
https://redump.info/disc/19655/

FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 01).bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 02).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 03).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 04).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 05).bin" BINARY
  TRACK 05 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 06).bin" BINARY
  TRACK 06 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 07).bin" BINARY
  TRACK 07 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 08).bin" BINARY
  TRACK 08 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 09).bin" BINARY
  TRACK 09 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 10).bin" BINARY
  TRACK 10 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 11).bin" BINARY
  TRACK 11 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 12).bin" BINARY
  TRACK 12 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 13).bin" BINARY
  TRACK 13 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 14).bin" BINARY
  TRACK 14 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 15).bin" BINARY
  TRACK 15 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 16).bin" BINARY
  TRACK 16 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Agent Armstrong (Europe) (En,Fr,De,Es) (Track 17).bin" BINARY
  TRACK 17 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

So it's each track in a standalone file and audiotracks are without .wav headers.

[Nexy]

Alcohol supports ISRC, this stuff is encoded in sub channels in mode 0 sub channel entries (normal ones are mode 1). So basically any image with valid sub channels can have ISRC codes. So do, some don't, depends on the mastering.

Redump images are multi-file cue/bin's, they conform to bin/cue specs. As F1ReB4LL said, the audio tracks are raw PCM , which is how audio is stored on the actual disc. There is no .wav header on them, unless the disc was mastered badly, in which case they can have them, but only if they are actually on the disc that way.

You may want to make sure your emulator can also unscramble scrambled data sectors, sometimes due to bad mastering, there can be scrambled data sectors in audio pre-gaps.