How to edit file sizes in the TOC of a CD image

[HwitVlf]

I have a file on a Playstation CD which is doesn't fill up it's last sector. Meaning the CD has some blank data at the file's end. I've dumped the CD to a BIN\CUE and I would like to edit the files size so that it extends all the way to the end of it's last sector. I assume this is fairly easy to do by editing the BIN TOC in a hex editor? But I'm having trouble finding format info for CD table of contents.

If anyone can share some info or point me toward a tutorial it would be appreciated.

If anyone is wondering why I want to do this, it's because need to add a little text to a file for a Playstation game translation. The text file is just a tad too small for the translated text so I'm hoping to extend it to the end of its last sector without having to move any other files or rebuild the whole CD.

Thanks

[iR0b0t]

If that text file is not placed at the very end of the toc, or there is no non-allocated space immediately after that file, you will have to re-allocate the entire toc beginning with that specific text file.

Sectors 18+19 for folders (20+21 also folders, in switched byte order), 22+ for files.

[pablogm123]

If you are lucky (fictitious example) that file is using just 240 bytes of the last allocated sector (rest of user data is just slack), so for mode 2 form 1 sectors you still have available 1808 bytes of slack you can use freely once altered the file size in the file record, easy to spot seeing the last sector of that file in the IsoBuster's sector viewer. The ideal situation would be that file is the last one in the file system, so you can increase freely and easily the size (increasing by a few of sectors the size of file system according to the PVD if needed). Check the starting/endings LBAs of files by IsoBuster to determinate if you are in luck. And for seaching the file record, search for [Original file name];1 . Reallocating the file to a new LBA would be a no go path in my opinion, you don't know if the starting LBA of that file expected by game is hard coded in game code and whatnot, or just checks starting LBA according to file system.

Observe those values are actually duplicated, first copy in Little Endian format, second copy in Big Endian format. So you have to modify both.

Little Endian: 0C FC 03 00
Big Endian: 00 03 FC 0C

Once modified anything, run CDmage, scan for errors and REBUILD fields so that EDC/ECC data matches the new user data.

Disclaimer: never tried this by myself, I purchase retro games just for the RedBook sountracks, so I haven't found so far any need of altering a data track.

[HwitVlf]

Thank you both. I was able to do it with your advice 

The file was 0x752C big (29,996 bytes).
Since there is 0x800 bytes worth of "file data" in each CD sector, each sector will end at even intervals ie 0x800, 0x1000, 0x1800, 0x2000, 0x2800 and so on. So if I'm thinking right, the file's last sector should end at 0x7800 which leaves some unallocated space at the files end:

  0x7800
- 0x752c
-----------
    0x2d4 (724 bytes of unallocated space - that's a lot of room for text!)

I found the 2 copies of the file size right above the file name in a hex editor. And it worked well to edit them to the new file size (0x7800).

It's worth noting that the Playstation routine that loads data from the CD into RAM ignores the file boundaries anyways. Like you say pablogm123, the load sizes and  start-sector are written into the game's programming. The load routine uses with 3 variables.
1. Destination in RAM
2. Location of source data on CD (LBA value)
3. Number of bytes to load

Those values are usually stored in a table in the game's exe. So changing the file size  really has nothing to do with making the game load more data. All this edit will do is let CDMage inject/extract data into that wasted space at the end of the last sector. I'll edit the game exe separately to get it to load the new-larger file!

Thanks again, BIG help