Replacing .str file (FMV) in a Playstation image with a larger .str file?

[MHzBurglar]

Hi everyone,

I'm trying to do what seems like a pretty simple hack:  I'd like to replace the opening FMV in the US version of Tales of Destiny with the opening FMV from the Japanese version.

The problem is that the JP opening movie for Tales of Destiny seems to be a larger size than the US one, so I can't simply drop the replacement file in with a program like CDMage, as the disc's indexes will need to be updated to accommodate the size difference.

I tried using the PSX-Mode2 utility to perform a file replacement in the image (as to my understanding it's supposed to re-index everything), and while the resulting image is bootable, the game freezes to a black screen when it tries to load the opening FMV.

It seems like I might need to extract the image, replace the file, and then rebuild the entire PS1 image.  Unfortunately I'm not sure what utilities I can use to accomplish this.

Can anyone who has experience with modifying/rebuilding PS1 images please point me in the right direction?

----------
Edit:
----------
I've found some info/utilities that seemed to be in line with what I'm trying to do, but I still end up with a game that boots to the "Namco" splash screen and then then freezes to a black screen instead of playing the opening FMV.

Here's what I tried:

1. Extract all non-STR and non-XA files with CDMage
2. Extract all STR and XA files with XTractor.NET using the LBA address and size of the files
3. Run mkisoxml.exe against my extracted image directory to build an XML for the disc's file structure (the structure matches the original disc)
4. Run mkpsxiso against my xml file to generate a new CD image
5. run psxlicense.exe against my new image to license it (USA license.)

If I do all of the above, even without actually replacing any files and just using the original files that came on the US disc, I still get a black screen freeze after the Namco logo on my new ISO.  Replacing the OP.STR file has the same result.

I tested my extracted STR files with strplay and they play fine in that, so the FMV files themselves seem to be ok.

Is there something I'm doing incorrectly?


--------
Edit 2:
--------
So, I made a stupid mistake when using mkpsxiso: generating the XML file with mkisoxml doesn't set the datatypes of str or xa files in the XML file; you need to manually edit their datatypes to "str" and "xa" in the XML after generating it.

For good measure, I also grabbed a copy of the license file and defined it in my XML so that mkpsxiso could handle the licensing while building the disc instead of running license.exe afterwards.

Thanks for the replies everyone!  I really appreciate it!

[MysticLord]

I'm not even remotely an expert on this, but some games use custom LBA (logical byte addressing) tables - instead of the disc directory sectors - to find and load files.

I'd contact cebix on github (I think he has a profile here, check his contributor's page).

In all the threads I've seen on the subject, the hackers giving advice assume a level of technical expertise that is pretty rare, and aren't willing to answer basic questions to at least get you started on getting up to the required level. It's a sort of swim or die attitude, and it's pretty common among PS1 hackers which one of the reasons why PS1 hacking scene is much smaller than the SNES one, despite analogous difficulties in SNES bank switching and memory mapping.

Compare the results of these two searches.
https://duckduckgo.com/?t=palemoon&q=snes+bank+formats&ia=web
https://duckduckgo.com/?t=palemoon&q=playstation+lba+tables&ia=web

SNES rom hackers want to provide resources so newbies can get up to speed, while PS1 rom hackers... don't, for some reason.

Why? I don't know.

I do know that you're expected to have the knowledge and skillset of an electrical engineer or math/CS dual bachelor for them to deign to answer your questions, other than telling you that you're wrong. If you don't, then I assume they think you shouldn't be rom hacking or something.

tl;dr

First generation PS1 rom hackers are the baby boomers of the romhacking world.

[blade133bo]

Can try create new str with low bitrate.

[acediez]

Here's what I tried:

1. Extract all non-STR and non-XA files with CDMage
2. Extract all STR and XA files with XTractor.NET using the LBA address and size of the files
3. Run mkisoxml.exe against my extracted image directory to build an XML for the disc's file structure (the structure matches the original disc)
4. Run mkpsxiso against my xml file to generate a new CD image
5. run psxlicense.exe against my new image to license it (USA license.)

This is pretty much the exact approach I've used to rebuild disc completely. The only difference is that I've used PSYQ SDK's license files directly into the mkpsxiso building process, I don't run psxlicense.exe after it.

I recently learned that mkpsxiso's author LazyGuy64 created a isodumping tool, which seems to take care of the process of extracting files of all formats, license, and creating a mkpsxiso XML automatically. I haven't tested it yet, but it sound like a good way to doble check whether you did this first part correctly.
http://www.romhacking.net/utilities/1574/

If the extracted files' sizes and disc LBA structure match the original game, and the game still freezes at some point after boot, it probably means the game has a custom table of contents (files LBA location and sizes), somewhere in its code. There isn't a common format for this, there's as many different solutions to this as PS1 developers.

LBA lookup method:

You can look for it "from outside" (without looking into the game's code) by searching for LBA values directly. You take the LBA values for the disc files from the original disc (using CDmage, IsoBuster), convert them to hexadecimal in little endian format, and look for that on the game's executable through an hex editor.

Example: LBA 13.975 (decimal) -> 00003697 (hexadecimal big endian) -> 97360000 (hexadecimal little endian)

You may be lucky enough to find it this way, and by recognizing patterns, identify the whole table's format.

Example from Mega Man X4 (table format):

Code Select Expand

[00 00 00 00] [00 00 00 00] [00 00 00 00]
     LBA           SIZE      FILE TYPE ID

Example from Resident Evil (process of finding the table):
https://www.romhacking.net/forum/index.php?topic=32362.msg409400#msg409400



If that doesn't work (maybe the LBAs are listed in a different format?), I can't think of any other approach that wouldn't involve debugging and looking for it by tracing code. So you might need to get into more advanced territory, even if it's just for a seemingly small change.

I've done it for a handful of games, using different methods. Last time I did it was Goemon Shin Sedai Shuumei. I inevitably ran into it after digging deep enough into the code that loads any given file to RAM. I started my documentation by finding S-JIS text samples in the files. After that, I looked for the sample in RAM in-game, that led me to the code that loads it into RAM, which in turn led me to the disc contents reading subroutine, and finally to reverse enginering the disc content table's format.

You could always settle for a lower quality video that keeps the file the same size as the original file or smaller, as blade133bo suggests. But if you want to use this as a learning experience, here's a few resources I usually recommend for people starting on PS1 hacking:

Debugging resources:

(I use no$psx for debugging)

Bitwise operations (the basic instructions commonly used by CPUs):
https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Bitwise_operation.html

MIPS instruction set ("MIPS assembly language" section) (the specific instruction set used by the PS1 CPU):
https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/MIPS_instruction_set.html

no$psx documentation ("CPU Specifications" section) (to learn how each MIPS instructions can be read through the no$psx debugger):
http://problemkaputt.de/psx-spx.htm#cpuspecifications

I also recommend following complete process videos (like this one by user ShadyRounds https://youtu.be/YVlcZa7xJz8) to get a feel of the workflow, learn the concept of address breakpoints, etc.

I recently listed pretty much everything I've written on the subject, for someone who had a similar issue as you in this thread:
https://www.romhacking.net/forum/index.php?topic=32362.msg409309#msg409309
(I'm recycling a lot of tips from those posts)

tl;dr

First generation PS1 rom hackers are the baby boomers of the romhacking world.

Wow... 🤭

I just wanna say, I got the exact opposite experience. I had zero real programming (much less romhacking) experience prior to 2018, when I started my first PS1 project. But by asking specific questions and showing whatever progress I could make (or at least, what I tried and didn't work), I always got lots of help from people on these forums.

In PS1 hacking there's too many different game-specific hurdles to take care of (sector modes, custom tables of contents, custom file formats, individual file checksums, etc). It makes it very difficult to have a single comprehensive source of information for all cases, and makes it hard for even an experienced hacker to give general guidelines about a game they're not familiar with. So, the more specific your questions and the more explicit you are about what you've tried so far, the more likely you will get help. The most often recommended resources (like the ones I just listed) will give you enough to get there.

[MHzBurglar]

This is pretty much the exact approach I've used to rebuild disc completely. The only difference is that I've used PSYQ SDK's license files directly into the mkpsxiso building process, I don't run psxlicense.exe after it.

I grabbed a copy of the license file and applied it directly in the building process.  When I went into the XML to add the license path, I also noticed that I made a huge "beginner's mistake": I didn't previously realize that I had to manually define the datatypes of the str/xa files in my XML file as "str" and "xa; mkisoxml.exe defined the paths of the files when it built the XML, but it just set the datatype to generic "data" for everything.

Between both of these changes, I was able to build "JP intro" versions of both Tales of Destiny and Tales of Eternia!

Now, if I could just figure out how Tales of Eternia ("Destiny II") controls parsing the XA files for script dialogue, and could implement the XA file/timings from the Japanese version, I could make a complete undub patch like the PSP version!  I actually usually like the dubs in Tales of games, but Eternia's dub was TERRIBLE!

I recently learned that mkpsxiso's author LazyGuy64 created a isodumping tool, which seems to take care of the process of extracting files of all formats, license, and creating a mkpsxiso XML automatically. I haven't tested it yet, but it sound like a good way to double check whether you did this first part correctly.
http://www.romhacking.net/utilities/1574/

Thanks for letting me know about that!  I'm definitely going to try this out the next time I need to extract a disc.

Also, thank you for the explanation of how to find/edit (big/little endian) LBA values!  I'm glad it didn't come to it this time, but I'm saving this and the post for RE:DC for future reference as well as the debugging resources you listed.

[acediez]

Now, if I could just figure out how Tales of Eternia ("Destiny II") controls parsing the XA files for script dialogue, and could implement the XA file/timings from the Japanese version, I could make a complete undub patch like the PSP version!

I had to adjust music tracks timmings recently, on the same Goemon game I mentioned. I used the same LBA lookup method I just described: I looked for the main XA file's LBA (in hexadecimal little endian format) and it matched with the first item on the table. The table looked like this:



I hope yours has a similar format and you can also find it like this. Good luck!

[ponlork]

i would like to know this as well. i'm working on a PS RPG maker mod and i want to replace the 4 sec opening ASCII logo with a 1 minute video opening. Wouldn't changing the LBA or whatever make it difficult to create patches? i dont know anything about it but i assume rebuilding it will shift the bytes and stuff and when creating a ppf patch it'll look for differences and it'll end up finding the entire ISO to be different.

anyway, about the Tales of Destiny FMV, i'll take a peek at it but does the filesize differ greatly? like does the jp version have a longer duration, maybe the frame rate and resolution is different.
May 26, 2021, 06:50:39 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
okay i think i know what the problem is. i took at gander at it and use jpsxdec to analyze both ISOs:



it appears that the video resolution and frame rate are exactly the same, the problem is the XA audio for the str. The USA version has a audio duration of 1:58 while the Japanese version has a duration of 2:02. So really you just need to modify the XA audio track, unless the Japanese FMV differs but in my eyes it looks identical.

back in 2017 when i was a complete noob to all this, i made this video demonstrating how to replace rip PS1 games and remove part of the soundtrack in order to be able to fit it onto a Super Nintendo Classic while retaining a partial soundtrack: https://www.youtube.com/watch?v=CQo1nnpsgyw

the tutorial is unrelated to what you're doing but somewhere in there i showed how to replace the XA track. that's all u really have to do. and yeah PSX hobbyists and homebrew devs tend to be real stingy when it comes to sharing info. im guilty of that myself sometimes lol i guess some of them are worried about having a flood of poor quality hacks. they put info out there in a way that is convoluted where they assume the average user isn't going to grasp. it's kinda like when that dude who was working on the mizzurna falls translation project, he put his source on github assuming the average person dont know how to compile it, so when some bozo did and upload it he got angry. well why u put it up for if u dont expect people to not have the technical skills to figure it out. its your fault. the nerve of some people right?

and speaking of which, i get annoyed that Namco keeps changing the opening music in their tales of games. most people say it's licensing issues but i dont believe that's the case for most of it. they did finally use the original song in tales of vesperia but they made Bonnie Pink sing a English version which was cool. and i believe Tales of Xillia was the first one where they used the original japanese vocal track by Ayumi Hamasaki. i remember when they released Tales of Phantasia for the GBA and the english version didnt include the song and that got me upset

edit: though the japanese audio track does have about 1-2 seconds of audio fading out. so the method above would abruptly cut. so if u really want that extra second of music fading out then u probably have to rebuild it for that extra 200kb of data. i suppose its possible to edit the song too so that it fade out earlier

[acediez]

Wouldn't changing the LBA or whatever make it difficult to create patches? i dont know anything about it but i assume rebuilding it will shift the bytes and stuff and when creating a ppf patch it'll look for differences and it'll end up finding the entire ISO to be different.

xdelta recognizes shifted data, so the patch size will increase if the amount of unique new data increases, but changing the location of the content will barely have an effect. If you're worried about distribution, you should probably worry about including copyrighted data on your patch (such as videos or entire voice tracks from a different version of the game). Technically not allowed by romhacking.net's rules, but in reality, plenty of hacks do it and are still allowed on the site. Regardlesss, if you want to go as clean as possible, some undub projects are distributed using custom patching scripts that use both versions of the game as input, instead of the usual patch formats.

so if u really want that extra second of music fading out then u probably have to rebuild it for that extra 200kb of data. i suppose its possible to edit the song too so that it fade out earlier

Are you still talking about the OP.STR opening video, or you mean an actual audio track?
If it's the opening video, and if the game doesn't have a custom table of contents, the game will play the file by its new length, no need to adjust anything else. That's how it has been on my experience.
But if it's an XA audio track, it most likely has a table of track start position/lengths somewhere in the game's executable.

[ponlork]

I would like to create an original RPG, like with original art, animation and music. Though I'll probably have to ask permission from ASCII if I can use their rpg maker 1 engine to create an original game. I have read in the manual from 2000 that they allow distribution, however the way people did it before were through PS1 memory cards and dexdrive sharing. My idea is to completely modify the entire iso with custom assets
May 26, 2021, 01:17:18 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Are you still talking about the OP.STR opening video, or you mean an actual audio track?
If it's the opening video, and if the game doesn't have a custom table of contents, the game will play the file by its new length, no need to adjust anything else. That's how it has been on my experience.
But if it's an XA audio track, it most likely has a table of track start position/lengths somewhere in the game's executable.

Correct me if I'm wrong but aren't Ps1 str videos mixed with a accompanying Xa audio file? So my idea is to extract both the English and Japanese XA to wav, then open them on a audio editor and trim the Japanese wav so that it matches the English audio exactly at 1:58 duration. Maybe apply a fade out earlier so it doesn't abruptly cut.

The Japanese ver contains a vocal track which is why the duration is longer. Then once the duration matches, simply insert the modified Japanese XA back into the iso using that tutorial video I linked.

The way I see it is like imagine you have a video where u want to replace the audio track. U would demultiplex it and then take another audio file and mux it back. Or imagine u have a mkv container that has multiple audio tracks. The video file will always be the same length but the audio tracks may differ in duration from the video but when multiplexed it'll be in sync even if the audio duration is shorter than the video, it'll still be 2:02 in length when combined

[acediez]

I've never replaced the video or audio components of a STR file separately. I understand your logic, but I don't have any experience doing it that way.

What I have done is:
- extract the STR files as uncompressed AVI and/or WAV using jpsxdec (for either or both versions of the game, depending of what you need)
- edit the video completely with a video editing software
- encode the edited version  to uncompressed AVI 37800hz audio
- convert it to STR (using ikskoks's STR Converter).

After that, I rebuild the whole disc using mkpsxiso, through the process I described before.
And finally, update the custom table of contents with the LBA/filesizes data of the new build (your game might not need you to do this, but mine did).
I did this to match the japanese opening to the american version of Mega Man 8, which had a few cuts timed slightly different.

This is probably the longest route to get this result. You might find a more direct approach to only touching the audio track and nothing else. But if you don't, keep this approach in mind.