This script was made with this "benchmark app" of "Final Fantasy XV Windows Edition" as a base. No "endian-guessing" support for now.

In case you get ridiculous names when you make a separate folder for the extracted ".earc" file through this script, make sure to always extract the files on either the "datas" folder, or on a separate folder of its own.

However, if you think that extracting just one ".earc" archive like this isn't enough, you might want to go further. In that case, execute quickbms through way of command-line, use the script on ALL ".earc" files(if any), and then extract all these files with the script you just plan on using in either of these folders. Here's an example:

Hi, popping in here in light of the release of the game. I tried running it on those files, but they didn't work whatsoever. Trying to came out with this error:

Tried it on several different earc files as well. No luck for any of them. I checked other earcs from other folks as well, and they all had the same deal. Attached here is Noctis' earc for his model. I quickly took a glance at the hexes and I think nearly everything is identical to the demo earc files save for a few lines. If you need more samples, let me know. Thank you for your efforts.

whoops, turns out there's an "encryption" flag i have never heard of by offset 0x7(it goes by the byte 0x80). this is why you see shit like this.you can bring up some more .earc files if you wish, and yes that includes not only these said files from actual release but from the "PLAYABLE DEMO" version of the game as well.

and if possible, do bring up the .exe from that "PLAYABLE DEMO" thing. i heard from some forums that the actual PC release of the game contains Denuvo protection.

I don't have the demo anymore so I can't help there. What I can do is upload a few randomly selected samples from the full game if that helps. I can upload more from the full game if needed but the exe is too big for my poop upload speed (250 MB).

Is it still gonna be possible to open the earc files at some point soon or would it require more than just some retooling? We had some small fully functioning mods for the demos and I had hoped that Square wouldn't reformat anything

(also if you need any .earc files from the playable demo, i think I have a few backed up)

Your scimitar.bms worked nicely for Assassin's Creed 1. But some extracted files are compressed, and while assassin_creed2.bms seems to work, I see you mention scimitar_compressed.bms. I can't find it though, could you upload it?

this .mvi format was only used on Dragon Quest VIII and Rogue Galaxy, although it's basically an .pss file at its very core. based on what i researched out of this format, this one uses an static encryption key with "xor" as its encryption algorithm.

although it was only intended for .mvi file decryption, it can also be used to encrypt .pss files into its target format.

this format as used in the second Siren game is actually much simpler compared to the first Siren game. the format itself is built around SPK.ROM, much like how the archive format as used in the first Siren game was built around siren.tbl.

the ROM.### archives themselves weren't split into a fixed size anymore(which meant that one file could not be stored in the middle of a split archive anymore, now it has to be stored in its entirety within that archive file as well), and the referenced offset values (as seen in SPK.ROM) were accommodated for each split archive part rather than encompassing the whole archive like those all siren.### archives. there were even "name locations" for these said archives for each file as well.

the first Siren game used a rather simple structure for a .tbl file; you have the usual "offset/size/name location" values and the accompanying filename itself which was located in said "name location" value as indicated for each file.

however, the siren.### archives themselves were an entirely different matter. basically they were the result of a "fixed size" splitting method whose size was about 512MB, and as a result only the last splitted part of the archive had inferior size than that. not helping matters is the fact that the offset value itself references said offset of a file as if these archives were a single entity. as a consequence of this, i had to improvise my quickBMS skills so the files stored in that archive could be extracted without any problems whatsoever.

UPDATE(10/07/2018): this script will now not cause any more crashes with quickbms.exe. this means that the "file-extraction-in-the-middle-of-splitted-archive" part has now been improved.

Nice job...but not enough. because the files are still not enough to import. in other words, it is still not about raw. or exported files need to be re-extract. for example: viewtopic.php?f=9&t=7424 but you've already seen it.

Could you do something about it? or is there someone you can recommend? Thank you in advance.

Last edited by TSelman61 on Thu Jun 07, 2018 9:13 pm, edited 1 time in total.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum