Lifeline/Operators Side (PS2) ripping help! by AceK at 7:13 AM EDT on March 11, 2014
Ok, so this is a little tough for me maybe because I have no clue about scripting and likewise of understanding the use of VFS advantage of ripping.

So far, I did manage to get an audio file ripped and had to convert it to .genh (the file name according inside the data proposes that the music uses .int format, which plays bad when extracted using this name, but does better in .mib. Even then with .mib prefix, it needs interleave adjustments to improve quality, which .genh provides).

Audio sample of (assuming) HM12_P1.genh EDIT: Frequency is wrong, should be 48000.

The audio (along with gameplay data) is all coming from an approx 3.51 GB file called "OS.SNP". Oddly, there is another file called "OS.FAT", and it's pretty small file size, but it gives detail of names. Since I have little to no experience with messing around of VFS, I'm curious if this even a VFS table or not :(

OS.FAT

I would guess it relates to "OS.SNP", but in the beginning of file, I don't remember coming across "/", "archive", or "033paracelsus". I assumed that the first thing I came across from "OS.SNP" was "HM12_P1.int".

My big problem now, is that after the offset data from the audio above, there are now formats that I think maybe relates to movie format, AVF and VSF formats. So, of course the problem I have with this is that I lack scripting knowledge. I'm looking for a way to understand how to batch process anything starting with the header (so far)...

"4153433120" (ASC1)
"4153433140" (ASC1)
"4153433160" (ASC1)
"41534331E0" (ASC1)

...and copy anything all the way to EOF. EOF in this case consists of either coming across any of these flags...

"41564631" (AVF1)
"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
"454E4443000000000000000000000000" (ENDC)

...if "7364337374727633" (sd3strv) ever comes through the process, make a new file.


So, my series of questions.

1. Was this game ever ripped?
2. Does OS.FAT look like a VFS?
3. I need general advice about learning batching process. I never tried it before, but I need to in order to get this process down reliably.

edited 7:38 AM EDT March 11, 2014

edited 4:01 AM EDT March 12, 2014
by snakemeat at 8:36 AM EDT on March 11, 2014
OS.FAT definitely looks like file table or VFS lookup table.
by AceK at 5:24 PM EDT on March 11, 2014
Well I guess that's a good thing. I only wish I can get more familiar with VGMToolbox's VFS extractor. VFS looks really new to me, would really like to start getting to know it better.

http://i.imgur.com/Pbqos2g.png

I am guessing 10 20 21 from 0x0 portion of the red boxes representing if whether the data is a folder or a file?

Looking at it, 10 = Folder, 21 = File... 20 = ? I have no idea what 20 can be.

When VGMToolbox refers the "Data File" and "Header File", does "Data File" represent the data bank itself (in this case, "OS.SNP") and "Header File" represent the table (in this case, "OS.FAT")?
by snakemeat at 10:31 PM EDT on March 11, 2014
When VGMToolbox refers the "Data File" and "Header File", does "Data File" represent the data bank itself (in this case, "OS.SNP") and "Header File" represent the table (in this case, "OS.FAT")?

Yes.

Not sure about the other info though.

EDIT: Here's a VFS Extractor plugin for the SNP file. Each of the "*.a" files is an archive in itself. Hopefully this can help you learn a little more about the tool. I know it is completely undocumented, sorry. One thing to note is that the VFS extractor will skip any file with size of zero, which means it skips the "directory" entries.

The .a archives seem pretty simple except that the data start offset is at 0xC within the file header and it appears to use relative offsets from the value at 0xC. Unfortunately, the VFS extractor does not currently support a data start offset, so you'd have to manually update your File Start Offset calculation.

Also, it looks like some of the .a files contain SQ/HD/BD data, good for making PSF2s. The modules are in "iopmodules.a"

edited 11:28 PM EDT March 11, 2014
by AceK at 2:29 AM EDT on March 12, 2014
Thanks so much! I'll try and learn from this .xml, again thanks for helping me out on this issue!

I checked the bgm, where PSF2s could arise, but the audio data inside are mainly sfx. Of course there maybe sfx like in the "load screen" that plays a synth tone in 3 different pitches.

Oddly, there are more Japanese content than English audio as far as .int content goes, I guess they are just left overs of what's already redone in movie format, or just used music in English version with voices on the side from another file.

Now about the movie format, .is format (containing AVF/VSF strings with audio header being ASC), the only way I could get audio for this to work is doing an alteration mentioned above using QuickBMS (I somehow managed to get it to rip as .ASC, but I don't know how to make it all packed in one file and skip to another file when "sd3strv" text string comes up.)

This ends up being a problem like my early rip with Street Fighter EX3 (In SFEX3, the game I assume ran character bgms all in the same time with multiple channels. To get it to play separately without going to another song each second, the files required to be "deinterleaved", thus altering the raw file itself). It's not really considered a raw rip because the data would be modified so idk if uploading it was right.

So, I was wondering what you would prefer in this situation? Perhaps, I can include the .is files and add in a BMS script with a batch.bat that converts any .is format into a .MIB for those that want to play it. Only issue is, I'm not too experienced in BMS scripts.

EDIT: I'm updating a bit since I'm learning... so, hope you don't mind if I post the script here... It's still not normal regardless, I'm not sure why the next batch of files don't repeat the pattern normally (I want it to go back into finding any text string "ASC1" at offset 0x???????0 [I'm guessing the 0 in '''findloc OFFSET string "ASC1" 0 ""''' represents in the 0x???????0]) Another problem if this does get sort out and ASC1 files can successfully get extracted, I want to know what does it take to pack all these split files into one?

<i># ASC Extractor from a file consisting of AVF/VSF format

findloc OFFSET string "ASC1" 0 ""
get ASC1HEADER long
get ASC1SIZE short
get DUMMY1 short
get ASC1SIZE short
get DUMMY2 long
get DUMMY3 short
for i = 0 < OFFSET
log "" OFFSET ASC1SIZE
math OFFSET += ASC1SIZE
next i
</i>


This is what I came up so far, and it probably is terrible for a first try :(. On top of that, I don't know how to remove the ASC header name in the script, as well as changing prefix into an .MIB through packing.

Example file of an .is = http://www.mediafire.com/download/4wln82g7gc3tf06/hm_18.is


edited 7:45 AM EDT March 12, 2014

edited 11:55 PM EDT March 12, 2014
by snakemeat at 9:32 AM EDT on March 12, 2014
Happy to hear about the analysis.

I'll try and learn from this .xml,

Just to be clear, the XML file is generated when I saved the presets from VGMToolbox. You don't necessarily have to inspect the XML, as much as the values it loads into the VFSExtractor tool when you load it in VGMT.

Regarding the video, my guess is that each audio block has some sort of ID field in it. And that you have to link blocks with the same ID together.
by AceK at 11:43 PM EDT on March 12, 2014
The only details I could find relating to ASC is in their header itself (0x00 to 0x0F).

00-03 = "41534331" (ASC1) *Basic name tag header. The decimal 1 probably is a representation of version or simply the format it's titled, not sure. Regardless, I haven't came across anything outside of 1.*

04-07 = "????0000" *Length size of the data offset just below the header (reading hex backwards like usual to get correct data). 0000 can be something like 0001 most likely if the size is REALLY big, but high chances it won't considering it splits in blocks. Regardless, it usually is 0000. The data offset calculation does not include the header string itself, only the data.*

08-0B = "????0000" *To be honest, I'm not sure entirely sure the purpose for this is. I would presume it's just a replica of 04-07 data, ie, length size of data offset. They usually contain the same data.*

0C-0F = "00000000" *Not entirely sure what this is. I would go on a limb and say it's just dummy data.*

So... judging by this...

findloc OFFSET string "ASC1" 0 ""
get ASC1HEADER long
get ASC1SIZE long
get ASC1SIZE long
get DUMMY2 long

*I notice I have to ASC1SIZE's... not sure if that's the right thing to do, or if I should just mark it as a dummy.*

This should clear the header portion I hope. I still am not sure if the 0 and "" afterward is right to put in the BMS. As a side note, "ASC" string can come up outside the header :(, so I hope there is a way to certify any issue won't happen, it sounds troublesome for someone like me.

After thinking about it, I think I have the script backwards. I need to be removing the AVF/VSF/ASC header and removing VSF data along with, which will leave only the ASC portion. Of course, I would need a way to remove the header.

I'm going to trial and error more with QuickBMS to see if I can get proper results. I really need to know functions that can repeat the process properly (search for ASC1 again and process, repeat), and I also really need to figure out how to remove data through BMS properly. I'm going to have to remove the header data itself along with the other unneeded data of .is .AVF .VSF header, and .VSF data. I need to understand the "math" function a bit more too, as I have no idea what does the += 0 or += 1 do.

As for dominance order of this format...

.is -> .AVF -> .VSF/.ASC

.is = Container that includes files, usually starts with text string (sd3strv3). For now, I can't make out the rest of the header, but I wouldn't consider about focusing on it since AVF1 is the one I probably should be focusing on.

Length size clarification

AVF1 = Includes anything below the AVF1 header (so, AVF1 header exluded), and consists of all of both VSF2 and ASC1 data, including their header string.

VSF2 = Includes anything below VSF2 header, so, VSF2 header excluded.

ASC1 = Includes anything below ASC1 header, so, ASC1 header excluded.

edited 11:56 PM EDT March 12, 2014
by MiLØ at 2:30 AM EDT on April 14, 2014
I ripped Liflene a while ago but didn't get around uploading it anywhere.

OS.SNP was extracted with plugin for gnie's Xpert tool.
Music *int files were scanned in Cube Media Player, interleave was changed from 512 to 1024 to make them playable. Then save as WAV.

Would like to see videos playable someday.

edited 2:30 AM EDT April 14, 2014
by AceK at 11:34 PM EDT on April 14, 2014
MiLO it's already uploaded in the "The Official Streamed VGM Distribution Thread" a while back. I used .genh since the .int files didn't contain proper interleave data like you mentioned, and I wanted to avoid converting to another format as much as possible.

Also yes, audio rip of the video files aren't done, don't know if I'll get around it anytime soon since I lack BMS script knowledge.

edited 11:36 PM EDT April 14, 2014
by MiLØ at 2:02 AM EDT on April 15, 2014
Ok I see. Streamed VGM is always a good way to go but there was actually something useful from converting to WAV. Quite a few tracks had needless chunks of silence at start or end of them, and there was at least one instance when a music track was in-between 2 dialog tracks separated by silence from them all inside a single *int file.
So I was editing all that silent stuff out in SoundForge and putting aside the dialog clips.

As for the video files, if understood correctly the video part is completely unplayable and you were working on the audio, correct? If that's the case then personally I'm not holding my breath for it. Audio without video is... well, it's not what I'd be after.


Go to Page 0

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source