PS1 PS1 disk last sector mystery data in the ECC section

[Heel]

Okay, so this is maybe me missing on basic research and the info on this is well-known, but I've searched high and low and haven't found any references to this data so going to see if anyone here has any clues.

There appear to be a relatively small percentage of PS1 discs that have entirely empty last sector, i.e. all zeroes after the header, but include mystery data in what should be the ECC section in the last 276 bytes of the sector.

According to psx-spx.consoledev.net/cdromdrive/ we're dealing with a Mode2Form1 sector so that section is intended for ECC data:


Normally, ECC section should be all zeroes when user data is empty like this. However, in these handful of games there appears to be a special message encoded in the ECC section. Here's an example from Panzer Bandit:


Out of the games I own, the full list of games that seem to include these are:

• Capcom Generation vol. 5 (JP)
• Gaia Seed (JP)
• Misadventures of Tron Bonne (US)
• Panzer Bandit (JP)
• Pocket Fighter (US)
• Resident Evil 2 Dualshock Edition (US version, both discs)
• Castlevania Symphony of the Night (US)
• Soukuu no Tsubasa Gotha World (JP)

I have probably around 120 ps1 games total and these are the only ones I've been able to identify, but there is clearly a consistent pattern, it's always a zero filled sector at the end that's actually part of a series of such empty sectors that presumably make up an empty file on disc. Number of preceding empty sectors is variable per game, but there is always a consistent pattern to the bytes themselves in terms of length and position, and two bytes in particular are always the same: 0xF7 at the 4th position at the start of ECC and 0x3D at the 5th position before the end.

Here's another example from Capcom Generation vol. 5:



There doesn't seem to be any other pattern that ties these games together that I can identify, they're from a variety of publishers and developers, and released in different regions.

Anyway, curious if anyone has any clues as to what this might be and how to decode this info. I'm specifically interested in this because I'd like to regenerate ECC data on EBOOT extracted images and this is one piece of data I have no clue how to recover at the moment.

Thanks!

 

[aldostools]

Anyway, curious if anyone has any clues as to what this might be and how to decode this info. I'm specifically interested in this because I'd like to regenerate ECC data on EBOOT extracted images and this is one piece of data I have no clue how to recover at the moment.

I don't know an answer, but maybe this code could help you.
https://github.com/Lameguy64/mkpsxiso/blob/master/src/mkpsxiso/edcecc.cpp

A possible workaround is to include in your tool a customizable database with the additional data needed to generate a proper 1:1 image. You could provide a few examples and let the users add the data for additional games.

 

[Heel]

I don't know an answer, but maybe this code could help you.
https://github.com/Lameguy64/mkpsxiso/blob/master/src/mkpsxiso/edcecc.cpp

A possible workaround is to include in your tool a customizable database with the additional data needed to generate a proper 1:1 image. You could provide a few examples and let the users add the data for additional games.

Appreciate the pointer! Unfortunately this is not normal ECC data, the code in psxtract already generates correct EDC/ECC sections, but these are somehow special with ECC section of the sector being used for some other purpose as far as I can tell.

In terms of adding game specific patches, that's something I've been considering, and might eventually implement... But I can't help but feel it's a slight cheat as it technically requires having the physical disc in order to obtain, and I want to be able to get the full experience from the digital purchase, or as close to it as possible

This diff this causes between the physical disc dump and digital dump is purely cosmetic and I don't think most people will even bother double checking the hashes vs redump.org in reality. At this point I'm just really curious what this stuff is as it seems to not be documented anywhere...

 

[aldostools]

Appreciate the pointer! Unfortunately this is not normal ECC data, the code in psxtract already generates correct EDC/ECC sections, but these are somehow special with ECC section of the sector being used for some other purpose as far as I can tell.

In terms of adding game specific patches, that's something I've been considering, and might eventually implement... But I can't help but feel it's a slight cheat as it technically requires having the physical disc in order to obtain, and I want to be able to get the full experience from the digital purchase, or as close to it as possible

This diff this causes between the physical disc dump and digital dump is purely cosmetic and I don't think most people will even bother double checking the hashes vs redump.org in reality. At this point I'm just really curious what this stuff is as it seems to not be documented anywhere...

It wouldn't be a cheat if that data is not calculated. The database of additional ECC data could be expanded by the community and only the physical disc would be needed for the games that haven't been added.

By the way, the EDC/ECC routines that I linked are from mkpsxiso which is a tool that "builds PlayStation CD images from an XML document."

 

[Nagtan]

Hi, I know this post is old, but for the sake of knowledge I will explain what those bytes are.

I didn't tested the games the OP mentioned but probably those games has digital audio, because this pattern is present in other CD-DA games like tomb raider, red asphalt, etc. So I'm assuming that the last sector he mean is the last one of the 150 postgap sectors.

Currently this ECC data is not documented anywhere because is... a BUG.

The normal ECC calculation for P & Q parity uses 4 zeroed header bytes (3 address bytes + 1 mode 2 byte), but apparently the mastering tool that sony used at those times had a bug (other than the zeroed form2 EDC bug) that calculated the REAL header bytes instead of a zeroed ones in the last postgap sector for games with digital audio.

So, this "mysterious" data is nothing like a "special message" or a "copy protection" or something, is only an ECC calculation bug, and those bytes can be safely zeroed or copied to another image without them as long as it has the same header sector.