Hi, I am rev-engineering the CDROM format and the various different CDROM-image formats used by various CDR-burning programs.
What I do currently know can be found here http://nocash.emubase.de/psx-spx.htm#cdromdrive (containing some PSX-specifc stuff, general CDROM specs, and specs for NRG, CUE, ISO images).

And, at the moment, I am working on rev-engineering specs for MDS and CCD formats. To make things more difficult, I don't have the Alcohol (CCD) and CloneCD (MDS) programs, and not even a CDROM drive in my current computer, so I am relying on 1 (one) MDS file, and a handful of CCD files that I've found in the internet.

For MDS, it would be very helpful to have more than one file. Could anybody help me there? Things that I am particulary looking for are:
- MDS file with more than 9 tracks (eg. Audio CD, for seeing if the use BCD or non-BCD numbers).
- MDS file with multiple sessions (eg. a recording of a multisession CDR).
- MDS file with EAN (aka CATALOG), ISRC (eg. found on my Audio CDs).
- MDS file with CD-TEXT (found on a few Audio CDs) (maybe more common on homebrew Audio CDRs).
If you can help and could send some MDS files per email, please PM me. I would need only the small MDS file (not the huge MDF file).

For CCD, I have mostly figured out how the format works. There are only two things puzzling me:
The sector size seems to be constant 930h bytes, if that's correct then it's easy to use, if it's wrong, then I've no idea how to obtain the sector size.
The "pregap" (the number of missing sectors at begin of first track) seems to be always 150. Could that be true? Ie. CCD doesn't allow record the first 150 sectors?
There isn't any "PreGapSize" entry in the CCD file, so I would assume that is fixed (unless one is supposed to randomly pick one of the [Entry N]'s, and then to calculate it as "PreGapSize=(Pmin*60+Psec)*75+Pfram-PLBA")

Aside from ISO, CCD, CUE, MDS, NRG - are there any other popular formats that I should be aware of, ie. formats that I should support in my PSX/PSone emulator?
Oh, and are there any existing specs on such formats? Aside from CUE, most of them seem to be left undocumented, so rev-engineering seems to be the only way to deal with them.

nocash wrote:

For CCD, I have mostly figured out how the format works. There are only two things puzzling me:
The sector size seems to be constant 930h bytes, if that's correct then it's easy to use, if it's wrong, then I've no idea how to obtain the sector size.

Yes, it's constant.

nocash wrote:

The "pregap" (the number of missing sectors at begin of first track) seems to be always 150. Could that be true? Ie. CCD doesn't allow record the first 150 sectors?

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).

nocash wrote:

There isn't any "PreGapSize" entry in the CCD file, so I would assume that is fixed (unless one is supposed to randomly pick one of the [Entry N]'s, and then to calculate it as "PreGapSize=(Pmin*60+Psec)*75+Pfram-PLBA")

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

nocash wrote:

Aside from ISO, CCD, CUE, MDS, NRG - are there any other popular formats that I should be aware of, ie. formats that I should support in my PSX/PSone emulator?

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.

Hi nocash.. wait, are you THE nocash? who made the no$ emus?

Anyway, check out libmirage, it's an open source library for cd/dvd rom image reading, and supports many common and uncommon formats, including MDS.

Hope it helps.

4 (edited by nocash 2012-12-16 16:59:56)

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

MikuroK wrote:

Anyway, check out libmirage

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).

F1ReB4LL wrote:

Yes, it's constant.
Only NRG allows to store the first 150 sectors
CDI? CHD?

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.)

nocash wrote:

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

That's awesome, the first time I ever saw an emulator was back in '99 when I saw someone playing pokemon yellow in no$gmb.

It's interesting that you would want to support so many formats, personally i just mount my images and have my emulators access the virtual cdrom drive, which avoids the need for them to support them all. Though I suppose you're also doing it to learn how they all work, just the same as making a psx emulator...

Any chance you'll make it open source/linux compatible? tongue

nocash wrote:
F1ReB4LL wrote:

Yes, it's constant.
Only NRG allows to store the first 150 sectors
CDI? CHD?

Good to know that MDS sector size and pregap are constant. Haven't yet come across CDI or CHD files (but I'll keep them in mind).

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.

nocash wrote:

For MDS, it says that DPM is used only for DVDs... so, for the PSX/PSone, I hope that I can ignore that part.

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.

Oops, yes, I meant that CCD has constant sectorsize+pregap, not MDS.

I wasn't succesful finding MDS collections. And no info on StarForce+DPM, does that combination really exist? Wikipedia does only mention SecuROM+DPM.

How well is CHD working? Does it allow random access (without needing to decompress the whole cdrom-image)? And does it reach a good compression ratio?

8 (edited by nocash 2012-12-16 17:38:56)

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.

nocash wrote:

I wasn't succesful finding MDS collections. And no info on StarForce+DPM, does that combination really exist? Wikipedia does only mention SecuROM+DPM.

Of course it exists, for StarForce-protected CDs MDS stores all the angle measurements, also there's a ton of guides and tools for working with MDS files with DPM (Advanced MDS Editor, BWA Builder, etc.).

nocash wrote:

How well is CHD working? Does it allow random access (without needing to decompress the whole cdrom-image)? And does it reach a good compression ratio?

Yes, it allows the random access (so you can decompress only the needed "chunks", not the whole image). Compression ratio varies, depends on the data and algorythms. Previously it used only the regular zip/zlib, now, IIRC, it has different algorythms (but can't say for sure, better check the sources and/or message boards).

hi nocash

nocash wrote:

What is the "Unknown 01h" byte for? Disc number? Subchannel number? Patch type/version? Number of following 10-byte pairs?

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

// 1 byte Format: the format can be 1, 2 or 3:
// Format 1: complete 10 bytes sub q data
// Format 2: 3 bytes wrong relative address
// Format 3: 3 bytes wrong absolute address

nocash wrote:

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?

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

nocash wrote:

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?

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

themabus wrote:

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!

themabus wrote:
nocash wrote:

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?

...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?

themabus wrote:

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

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?

13 (edited by nocash 2012-12-20 05:48:35)

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

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.

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).

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.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

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.

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

What is a redump image? Another file format?

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

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.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

Nexy wrote:

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.

Don't remember any for PSX smile

22 (edited by nocash 2013-02-02 15:58:50)

Nexy wrote:

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.

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).

Nexy wrote:

Redump images are multi-file cue/bin's, they conform to bin/cue specs.

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).

F1ReB4LL wrote:
Nexy wrote:

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.

Don't remember any for PSX smile

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.

nocash wrote:

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.

Audio is always untouched, so it's only XORing when doing a data read on a scrambled data sector. Scrambled data sector consists of 16-bytes sync header (similar to the regular data sector sync, but slightly different) and 2336 scrambled data sectors, so it's not data-read on audio neither audio-play on data, it has a proper header telling there is some scrambled data below.

24 (edited by pablogm123 2013-02-03 13:00:56)

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

pablogm123 wrote:

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.

Ever tried to burn the scrambled image with CloneCD or other tools? Or mount to virtual Clone drive or other? And how can you say it supports scrambled data?