[PSX] File Extractor (Missing Download)

  • Thread starter Thread starter G
  • Start date Start date
Status
Not open for further replies.
G

G

Guest
As I couldn't find any extractors for this on the net, I wrote this utility to extract data from PSX FF8 image file.
For now it extracts only near 22Mb of files from image. Extracting seems to be correct, although I don't know format of most extracted files (I know some AKAO frame files :) )...

download link: http://www.filefactory.com/file/d41b40/ [source + windows binary]
Usage: ff8extractor.exe <path_to_your_ff8discX.img> <output_directory_path>

WARNING: output directory must exist.
After extraction, file with name 025.ff8 (checked it only from ff8disc1.img) at offset 0x000499b4 contain more offsets for the rest files (I think, that "rest files" contain movie and field files) in ff8discX.img. I don't fully understand format of this file yet, but later I'll extract that too.
Happy hacking!  :-D
 
Last edited:
If I find anythings you want to know (LOL whatever that means) I'll let you know.

I wonder if there is any way to recognize the format of the PS1's video data format.  The first sector reportedly has information about the file in it. IF it is possible to decipher the file information with that it may be possible to make a standard windows CODEC for it.  Interesting thought. Hmmm.

Erstwhile I know some of the information, but I've got so many projects that my hair is turning gray. :D

Thanks for the information, I may modify my tool PS1_ISO to allow "plugins" for special format disc images.

Cyb
 
I wonder if there is any way to recognize the format of the PS1's video data format.
Click to expand...
It isn't problem at all, to look through rest data and to find video frames, but I want an elegant :) solution for this.
Today I am finished with FF8 exploration - I am writing SoundManager for AKAO.
 
Hey G,

First, thanks for writing this program. It'll help me to explore the contents of these discs. I noticed a lot of files with encoded text in them.

Do you have any idea why the number 0x33a was added to the offsets in the ff8discX.img file? I suppose this is a question that only Square can answer.

Thanks.
 
Do you have any idea why the number 0x33a was added to the offsets in the ff8discX.img file?
Click to expand...
Yes, I have :)
0x33a is PSX CD-ROM sector number of beginning ff8discX.img file. PSX CD-ROM can access info only by sector (actually by time information, but it's almost the same).
 
LBA (Logical Block Address) 0x33A
And the ISO minute:second:frame fit this translation criterion
LBA = (M * 60 + S)* 75 + F
Where M = minutes
 S = seconds
 F = frame
60 seconds per minute and 75 frames per second.
1 frame is a sector.
an LBA of 0x33A translates to
M = 0 (+ 2 because the first 2 minutes are a lead in for the CD-ROM)
S = 11
F = 1
02:11:01 is the coding for the sector ID
So it's 11 seconds the second frame into the disk.
The root directory is only 2K (1 sector) and 11seconds worth of data is roughly 1.5megs. This would include all the files save the big image on the disc.

G
My 'file searching' algorithm on the FF8 discs was just that, ugly :D
I had significant more progress on FF9 than FF8 (because it was easier).  I should dig that thing out and look at your code! :)

Cyb
 
I spent five hours pissing about with IOCTL last night, it must be one of the most severely under-documented system calls on the planet..

I can't figure out how to use CDROMREADRAW properly. I assumed that you give a cdrom_msf struct the starting values, and set the buffer (char array) size to the raw sector size and the ioctl fills the buffer with 2352kb of data. So I set up a working msf struct (as cdromreadraw uses a union) and a loop to increment through it.. but thats where I hit a hurdle. The cdrom_msf struct uses type __u8 (char) so I cant increment it!

Has anybody here had any success with cdromreadraw?
 
Has anybody here had any success with cdromreadraw?
Click to expand...
If you are using windows, IOCTL calls isn't supported for RAW data mode, only for audio cd. You need to use SCSI/ASPI layer commands.
 
The reason why IOCTL (Input/Output Control) is so poorly documented is because, by definition, it is.

IOCTL serves as a generic command to pass undocumented functions to the kernel to be then passed on to the device. It's just a way to bypass normal commands to get a device to directly do your bidding. The format of a IOCTL is up to the kernel developer and the device driver programmer on whatever whim they need.
 
If you are using windows, IOCTL calls isn't supported for RAW data mode
Click to expand...
Thats a useful bit of information actually G, thanks. I'm working on a file dumper for Linux at the moment though.

The format of a IOCTL is up to the kernel developer and the device driver programmer on whatever whim they need.
Click to expand...
I have a feeling that contacting them directly on such an issue would result in me getting severely pwnz0rd  :-D

I made a dump of FF7 using both CDRDAO and psxdump.c and attempted to run them through Cyb's ISO tool. The CDRDAO binary just crashed the program and the psxdump image only displayed some of the volume information.. Baffling  :?
 
Yesterday worked on that extractor again...
Now it extracts near 120Mb of data.

http://mandrew182.org.ua/ff8extractor-20070827.tar.bz2
:) Mirror: http://www.filefactory.com/file/482721/

There is holes in image file, for which I cann't find yet any offsets for rest files.
0x000eb800 - 0x03f4f800 [62Mb]
0x03f69000 - 0x0a99c800 [106Mb]
after 0x121cf800 offset [~300Mb] - 95% there is streaming data such as video and adpcm sound
If look in hex editor first two "holes" I can clearly see rest files, just cann't find offsets for them in image file - maybe I'll extract them directly sector by sector later  :evil:
 
Yesterday worked on that extractor again...
Now it extracts near 120Mb of data.

http://mandrew182.org.ua/ff8extractor-20070827.tar.bz2
:) Mirror: http://www.filefactory.com/file/482721/

There is holes in image file, for which I cann't find yet any offsets for rest files.
0x000eb800 - 0x03f4f800 [62Mb]
0x03f69000 - 0x0a99c800 [106Mb]
after 0x121cf800 offset [~300Mb] - 95% there is streaming data such as video and adpcm sound
If look in hex editor first two "holes" I can clearly see rest files, just cann't find offsets for them in image file - maybe I'll extract them directly sector by sector later  :evil:
Click to expand...
can you reupload the dumper since the link has expired ^^" and also do you know in which program can we view these files??
 
Status
Not open for further replies.
Back
Top