[Bregalad]

OK I'm going to ask a VERY noobish question. I've hacked ROMs for the NES and GBA and this is pretty simple as you don't have to deal with a file system or files.

I'd like to know how people who did hacks or translations for the Playstation (or any other disk-based console) did to be able to re-build an ISO which is identical to the original with only the hacked data that differs.

I tried of course to extract ISO data with both Deamon Tools and ISOBuster, and to rebuild one iso with the files I extracted, but of course the result ended very different from the orignal file, and not even playable in an emulator 

This is probably because some data is losst in the process (for example where on the disk the file are placed, and maybe some other "hidden" data).

[Rolen47]

If your hacked files are the exact same size as the originals (or smaller), then you can use CD Mage Beta to insert the files without screwing up the rest of the ISO. If your hacked files are larger, then you'll have to do something else; you could probably use TOC Changer.

[Bregalad]

Thank you very much, I think I'll experiment without altering the file's size at first.

I guess changing the file allocation table is the ISO equivalent of modifying the pointers in a ROM 

[Auryn]

If u are working with playstation u can extract all the files u want from the iso even with winrar if i want and reinsert them with CD mage or isobuster (or was it magiciso??).
The only files u can't extract correctly like that are the .xa (normally audio), .str (normally video) or any file with video or audio inside.

The order of the files is relativelly important (isobuster will rebuild an iso with files in different order) so maybe it willl still work or maybe crash... depends on the game.

So the idea is usually to keep the files in the image, extract what u need from the iso (with cd mage or so) and reinsert it at the same place (with cd mage or so).

About TOC changer...no, it's not really the same as a repointer.
Almost all playstation cd have empty holes (empty sectors) between one file and the other and TOC changer allow u to change the TOC to use this empty holes and make the file(s) adiacent one to the other.

All this apply to all disc based systems, just check what sector size use the system and compare it will all type of data (raw data, audio and video). As example the saturn, it will have a session with raw data and normally more audio tracks after it. U need to work on the raw data and let the audio alone.

[tomaitheous]

(or any other disk-based console)

 PC-Engine didn't use a CDFS system, so the ISO data tracks are just large binaries. There are no files according to a file table. You have to figured it all out on your own. Create your own extraction and insertion tools. Games access data directly as LBA sector offsets. The values are either hard coded or in a custom table in ram. Thought it has a 'track' relative offset that the LBA value is added to. SegaCD, from what I gather, works the same way. While it is ISO9660 compliant with a CD File table, I know of only 1 game that uses it. Willy Beamish, which makes it really slow (the game will load the FAT every time, then parse it, then load the data it needs). All other SegaCD games do what the PCE games to; direct LBA access via hardcoded values or some internal custom table.

 Do PSX games keep a copy of the CDFS table in ram the whole time, from boot?

[Gemini]

PlayStation games only keep the root record and the last accessed directory (which is limited to the first sector only, causing access bugs with large lists).

[PhOeNiX]

Indeed, TOC Changer is a repointer too. It can change the LBA of any file inside the image. Changing the LBA you wiil be able to move your files inside the ISO.

[Auryn]

Indeed, TOC Changer is a repointer too. It can change the LBA of any file inside the image. Changing the LBA you wiil be able to move your files inside the ISO.

thing that is very bad to do with games such as Vagrant story :p

[PhOeNiX]

Obviously TOC Changer cannot  resolve problems regarding custom file systems, but it's still usefull once you edit the custom file system.

[Bregalad]

Oh so I understand, steamed XA and movie data is stored differently on sectors, so it cannot be normally read with PCs, as some bytes which are normally used for error correction / checksum are actually used for data.

But all the other files can be read and written to normally. Thanks for the info.

[PhOeNiX]

Only XA audio is stored that way. Movies are made up of interleaved sectors of video and audio streams depending on the encoding parameters. Let's say, 8 sectors of video data (regular sectors) and 2 sectors of audio (Mode 2 form 2 sectors), that's why you still need to dump movies the raw way.