cdrom-image file format specifications (Page 1 of 2)

Yes, it's constant.

Only NRG allows to store the first 150 sectors and a very small amount of drives can dump these (and only via the tricks, not directly).

CloneCD dumps always contain the .SUB file, .CCD file contains only the TOC, the index stuff is inside the .SUB.

CDI? CHD?

As for the MDS files, they are way more complex, than you think. Try to find some from StarForce-protected MDF-MDS images with DPM measured and examine them.

Yes, the no$emus, that was me. Newest one is no$psx (which got me into dealing with cdrom formats).

Yup, I've found that, too. It really contains some useful info. For MDS, it says that DPM is used only for DVDs... so, for the PSX/PSone, I hope that I can ignore that part.
Best would be comparing the libmirage source code with real MDS binaries. Anyone having some MDS files around? (I don't want to spend hours on downloading whole CDROM-images, specially if I don't even know if the ZIP contains an MDS or something else).

Good to know that MDS [EDIT: oops, I meant CCD, not MDS] sector size and pregap are constant. Haven't yet come across CDI or CHD files (but I'll keep them in mind).

The one thing that appears to be also popular appears to be .BIN.ECM, which is a nice idea (to remove error correction info when it isn't needed), but the way how is implemented in the ECM format is, well... it's somehow inviting to write a book about "what is wrong this file format", the biggest mistake is that it doesn't allow random access without scanning ALL preceeding sectors.
I guess the only way to "support" in an emulator would be to offer an option to convert it back into a regular .BIN file.
Or, another solution would be to scan the ECM file once, and store the missing sector look-up table in a separate .BIN.ECM.TAB file. Or is there already such a workaround-solution? When using RLU-like compression, the table could be quite small (first N sectors with size X, next N sectors with size Y, and so on). Though that might make the mess of numerous file formats even bigger, and I think ECM isn't really worth support.

EDIT: The look-up table idea wouldn't work too well: The ECM type 0 chunks could be, for example, 940h bytes in size (one 930h-byte sector, plus 10h bytes from next sector), so the chunks aren't guaranteed to be located on sector boundaries, supporting that special cases in a look-up file would be almost equally bizarre as the ECM format as such :-/

One thing that I'd prefer would be a good compressed-cdrom format. Is there already such a thing?
Some years ago I came across .CDZ, which didn't compress too well, mostly because it didn't support removing error correction before compression. At least back then, some years it didn't support that.

Oh, and .SBI files. From what I can see, the format is as so (sorry if that was a well kept secret):

 53 42 49 00      <----------------------------- ID "SBI",00h
 03 08 05 01 41 01 01 07 06 05 00 23 08 05
 03 18 49 01 41 01 01 03 1E 49 00 03 08 49
 .. .. .. .. .. .. .. .. .. .. .. .. .. ..
 09 46 13 01 41 01 01 09 44 1B 00 09 46 03
 09 48 59 01 41 01 01 09 44 59 00 09 08 59
 |______| |  |______| |______| |  |______| |___|
        | |         |        | |         |     \___ missing CRC ??? (Q10,Q11)
        | |         |        | |          \__ MSF (Q7,Q8,Q9)
        | |         |        |  \__ Reserved Zero Byte (Q6)
        | |         |         \____ MSF (Q3,Q4,Q5)
        | |          \_____________ ADR/Control, Track, Index (Q0,Q1,Q2)
        |  \_______________________ Unknown 01h
         \_________________________ Real MSF

The things that I don't understand are:
What is the "Unknown 01h" byte for? Disc number? Subchannel number? Patch type/version? Number of following 10-byte pairs? I have no clue.
And the http://redump.org/guide/libcrypt/ page says that CRC-16 is also scattered on libcrypt'ed cdrom... but the SBI files don't support that?
And the tool for generating LOGs for generating SBIs does throw out something like:
Original sectors: 48
LC1 sectors:      0
LC2 sectors:      0
Other sectors:    16
What does that mean? Does it mean that there are 64 sectors being common candidates to contain protection info on PSX discs? And this case, 16 of them actually containing that info? And what is LC1, LC2, and is it PSX related, too? (Asking because I'd like to support SBI's in my emu.)

lol? MDF (MDS is a descriptor, not image) sector size is exactly NOT constant, can be 2048, 2048+96, 2352, 2352+96, dunno about 2336 and 2336+96, but I guess it's possible.

Wrong, it is used for CDs as well. And again: look for images of StarForce-protected CDs. IIRC there were even sites with MDS collections for such titles (in case your drive can't measure DPM).

CDZ and CHD are containers and aren't really image formats. CHD is from MAME/MESS, so it's easy to find out all the needed sources. CDZ is from pSX emulator.

Is it possible that "LC1" and "LC2" and "Other" sectors just refer to some sort of "libcrypt version"?
The "Unknown 01h" byte seems to be always 01h though, no matter of the version.

hi nocash

this byte defines format of following bytes
specifications of sbi format are given in 'PSEmu Pro CDR plugin interface'

yes, it's a pity
for exact data can not be reproduced from .sbi files
though it's enought to fool protection algorithm
as console does not return erroneous subchannel data, in such cases it returns previous frame instead
so .sbi basically just stores information where error occured and that's enough to bypass LC

LC1 and LC2 are LibCrypt patterns from a viewpoint of data not code
i.e. if you'll look for documents on LibCrypt, they'll reference changes that took place in code
and variations noted in those guides will not correspond to LCx generations in this DB

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
might be some would just be reported as odd sectors
also not everything reported as odd means it's LC

generally LC always has those pairs
and backup copy of pattern further on CD, if data track is large enough
this backup though seems to never get actually used by algorithm
...many strange things with LC, it's as if it was rushed

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?

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 http://redump.org/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 http://redump.org/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).

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.

What is a redump image? Another file format?

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.

Yes, that would work. But only if the .MDF files does contain subchannel data (which is optional, it could also contain raw sector data). And it won't work for stuff located in lead-in (namely CD-TEXT) (and I think EAN and maybe even ISRC could be also stored in lead-in, although the typical PC cdrom drives may be unable to extract that data).

Yeah, guess I should support that, too. It isn't my first choice though - I'd much prefer fileformats where all data is stored in one file. And the required filenames are looking quite fragile to me (like: somebody renames the files, but doesn't edit the names in the .CUE accordingly).
At the moment I am completely ignoring the filename(s) inside of the .CUE (and just expect file.CUE to refer to file.BIN with same name).

Okay, then maybe I won't really need it in no$psx. Anyways, just for curiosity... trying to understand what scrambling means:

http://www.icdia.co.uk/cdprosupport/cdi … ambled.htm tells that data sectors are scrambled, and audio sectors aren't scrambled.

http://club.myce.com/f61/unscramble-sec … ost1267339 tells that scrambling and unscrambling is done by XORing some constants.

So, in the emulation, all I would need to do is:
Do the XORing when doing a DATA-READ on an AUDIO sector.
Do the XORing when doing an AUDIO-PLAY on a DATA sector.
Sounds easy... if I got that right.

You can download a samples of lead-in + first pregap + a piece of program area:

-Alien Trilogy, PC version, US release. First pregap is Sony style (1.74 - 0)

-Celine Dion - A New Day Has Come. A disc protected by Key2Audio, including scrambled data sectors marked as audio in the first pregap (-150,0), fake sessions, CD-Text, ISRCs and MCN. Interesting from technical viewpoint. First pregap is Philips style (10.00 - 1)

Regarding scrambling: data sectors (not audio sectors) are stored actually scrambled. Reason: data sectors not scrambled can contain certain regular data patterns which would render unreadable the disc. If you read as audio a data track from a disc (Read D8 or audio trap disc) you get the scrambled content, and with no offset correction. You cannot extract as data an audio sector (where user data=raw data) because the drive would expect to find sync, header, EDC, ECC... fields and would report a read error.

I know that ccd/img/sub CloneCD format supports scrambled data tracks. Also, IsoBuster can open scrambled data tracks, unscrambling the contents on the fly.