I’m not sure if I found that one of the dump in the database is incorrect or if I’m off for my dumping tool again.

I dumped Hot Shots Golf – Open Tee (USA) and the Database wants a CRC of 141dd4a7. My dump gives me a CRC of 122c8697.

I dumped it with both ISO Tool v1.970 and PSP Filer 6.6 and I’m getting the same CRC. (again my PSP setup is a PSP 1001 with 5.50 Prome-4 CFW).

The reason I bring this up is I do not want to call foul on the current database listing of this title if in fact it is good and mine is bad. Could I maybe have a different version of it?

Here is the info:
SFO file: F:\PSP_GAME\PARAM.SFO
SFO Version: 1.1
BOOTABLE: 1
CATEGORY: UG
DISC_ID: UCUS98614
DISC_NUMBER: 1
DISC_TOTAL: 1
DISC_VERSION: 2.00
PARENTAL_LEVEL: 4
PSP_SYSTEM_VER: 1.00
REGION: 32768
TITLE: Hot Shots Golf: Open Tee™

gamecaptor wrote:

DISC_VERSION: 2.00

i am not sure, never dumped a psp disc, but this looks like a different version to me.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Yeah, it's a different version.

Um, duh, I completely missed that line there that says "version". Well good to know this is a new dump.

55 (edited by Jackal 2011-03-30 19:24:07)

From PSP Filer readme:

Though the reason is not clear now, the last 1-3 record of UMD cannot be read from filesystem. So, doing ripping operation, the iso file is 2k-6k (1record = 2kbytes) smaller than it should be. Since version 3.9, Filer try to fill those “lost tail records” by following sequence:
1. Filer rips as large as possible.
2. Filer checks expected size by peeking ISO file, and if it is larger than ripped size, create a differential size data which is filled with 0.
3. Filer searches ISO file structure, and if there are files which uses “lost tail records”, copy those data into right place of the differential data.
4. Filer appends the differential data to the ripped ISO file.

edit: looks like it's been mentioned several times before in this topic

Somehow, the last 2K-6KB is not extractable on the file system.
And, it sometimes causes problems to some games. (iso doesn't work. icon is corrupt. etc)
Until the dumper, you needed to dump the last file by iRShell or PSPFiler, and replace the last 2K-6KB to the FL iso.(BAHAMUT, pSyPSP and WRG did it.)
PSPfiler 3.9 automaticly repairs the last 2K-6KB to extract the last file like iRShell.

Time to bump this topic for a new discussion!

I noticed about a week ago that we have a few bad dumps in the database. I found these thanks to TheHustle. He had asked me how to dump one of them, but I found out they were not standard UMDs and they could not be dumped the usual way.

http://redump.org/disc/808/ [UCJB-98306]
http://redump.org/disc/1196/ [UCJB-98302]
http://redump.org/disc/1743/ [UCJB-98303]

These are demo discs with a game + video partition and the entire video section is corrupt in the dump I tested "UCJB-98302". I do not know which dumping tools were used to make these dumps, but I'm sure the video partition must be corrupted in all three dumps.

I bought one of the demo discs to try dumping this type of UMD myself, the demo disc I have is "UCJB-98306". My dump does not match the database, which is not surprising. I found a way to dump both partitions correctly, but they have to be dumped to separate .iso files.

Here are the instructions:
Note: UMD_DATA.BIN of each ISO has the partition number, 0001 & 0002.

1) Use UMDKiller V1.2 to dump the first partition. It will be saved to ms0:/ISO/UCJB-98306.iso.
2) Connect your PSP to a PC and rename the dumped ISO as "UCJB-98306_0001.iso" and then move it onto the PC.
3) Use UMDKillerPRX V1.5 to dump the second partition. It will be saved to ms0:/ISO/UCJB-98306.iso.
4) Connect your PSP to a PC and rename the dumped ISO as "UCJB-98306_0002.iso" and then move it onto the PC.
5) Open Notepad and type the text below, make sure to modify the filenames to match your ISOs.

copy /b UCJB-98306_0001.iso + UCJB-98306_0002.iso UCJB-98306_merged.iso

6) Save the file as Merge.bat and move it to the same location as the two ISO dumps.
7) Double-click the Merge.bat to merge the ISOs into one file, "UCJB-98306_merged.iso" is created.
8) Use clrmamepro's Dir2Dat function and uncheck everything except Add MD5+SHA1, create the .dat file to save the three ISO hashes.

There is currently no dumping tool that will dump both partitions at once, and I don't know if this is able to be done either. The dumps in the database were joined together to make the dump one file. I think merging the two ISOs is okay. There are very few game UMDs with two partitions, and we can include the non-merged hashes in the comments. The only issue with merging is that the video partition is unplayable after merging, but that may change in newer PSP CFW.

As a test, I also tried to dump Video UMDs using UMDKillerPRX V1.5, but only the 0002 partition will dump. PSP Filer 6.6 and UMDKiller V1.2 cannot be used on Video UMDs, so these UMDs will have to remain unsupported for now.

So how should we proceed? I think it would be safe to add the fixed dumps with the non-merged hashes in the comments.

Enker I got hold of one of these discs to dump, it was Stealth/Wipeout Pure.

So I dumped both isos the way you said.

I looked at the isos in isobuster.

The game iso, had reference to the VIDEO folder but no STREAM folder.

The video iso, had FULL reference to all the game files, but they  were zero bytes.

In an ideal world we get a proper dump of one of these discs, I don't think it would work properly ever, or at least not until cfw changes just to support these discs properly.

What I mean is to play the video, you need the iso to be mounted, this then allows you to play the video, but I doubt you could then flick to the game. Anyway.

If you join the game then video, the game works.

If you join the video then game, the video works.

Or you can put one iso (the video iso) in ISO/VIDEO and the game iso in ISO that allows you to watch the video and play the game, the only thing it doesn't allow is mounting the video and then switching to the game, doubt this would ever work even if you injected the game files into the video iso. Which could be done by using Apache, it still would only be to test what happens.

I don't think joining the isos is the way forward they somehow need to be fused into one iso, rather than stuck together.

Years ago when Gran Turismo came out it was Dual Layer on the PS2, and I followed a tutorial that used programs I have long forgotten about, but it involved extracting both layers merging the layers into one then it would work on hdloader, it was long time ago and I have forgotten the ins and outs, it worked anyway, and it was what reminded me about dual layer, layer breaks, which I then spoke about here and IRobot made a tool to find layer breaks.

Anyway I believe these isos need to be merged rather than joined, or used as separate isos.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

I think the 0 byte files in the filesystem is due to the partitioning, since the Volume Space Size for both isos is correct. Video UMD dumps also have 0 byte files in the PSP_GAME folder, but the first partition on Video UMDs is not dumpable yet.

We probably won't be able to add these dumps to Redump until there's a dumping tool that can dump both partitions at once, to ensure that there isn't a gap between them.

There's a discussion about adding them here: http://forum.redump.org/topic/17909/psp … ombo-disc/

59 (edited by user7 2018-05-19 01:10:08)

>We probably won't be able to add these dumps to Redump until there's a dumping tool that can dump both partitions at once, to ensure that there isn't a gap between them.

I don't see the problem adding the good-two-tracks to redump even through additional data may be missing. Similar to how all the data for CD-Rom discs have subchannel data that can't be perfectly dumped afaik or CD-Rom's with DRM may still be added to redump - but require MDS dumps to actually play.

If the two ISOs are perfect dumps of the data they contain, then they should be added IMO, their integrity is not compromised, only additional data may need to be included later.

All my posts and submission data are released into Public Domain / CC0.

We could add the merged dumps if others agree that it's okay. It's been almost 5 years since I posted that info, so that's why I said they probably wouldn't be added to Redump.

Its probably okay to add the merged dumps, but please comment both separate partitions as well if you are going to add those.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Are the three yellow dumps going to be marked as Red status or are we keeping those entries?

http://redump.org/discs/system/psp/status/3/

They lack of video partition if that's correct. Can be set to red.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

The entire video partition is just random data in the dump I checked "UCJB-98302", so I will set them to Red status.

http://redump.org/disc/52119/

I am sure this is still a bad dump, unless when you open the iso in isobuster, and all the files have the proper LBA and file sizes, like I said I don't think joining 2 isos gives you a good dump. It didn't with my umd I tried.

The iso that gets added to the join second doesn't even get seen if you no what I mean.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

Seems like keeping the tracks separate would be more accurate... at least we know the two tracks are perfectly dumped (even if additional data would need to be added later).

All my posts and submission data are released into Public Domain / CC0.

67 (edited by Enker 2018-05-20 19:36:02)

We can use the split tracks if the UMDs are found to be formatted that way. I think it's most likely all on one track, but maybe UMDs have a special mode to deal with two tracks.

Can someone who speaks Japanese reach out to the PSP Filer dev asking if he would take on this challenge of dumping these types of discs? His contact info is here http://www.geocities.jp/mediumgauge/

Basically just translate this message and send:
"Hi, thanks so much for your great app PSP Filer!

We're dumping discs for redump.org preservation project. We preserve PERFECT dumps of discs for our dat.
We use PSP Filer as a rule for all our PSP dumps because the app dumps all game UMDs perfectly. However there are a few oddities which we are unable to dump perfectly with PSP Filer because they have video partitions, such as the Stealth movie / WipeOut demo combo disc http://www.mobygames.com/images/covers/ … -cover.jpg
Also "Demo Disc for PSP Vol. 1" has this partition as well.

As of right now there is no known "PERFECT" way to dump these discs. Would you be willing to update PSP Filer to handle these situations so we can perfectly preserve these discs?

Thanks for your time smile"

All my posts and submission data are released into Public Domain / CC0.

69 (edited by Jackal 2018-07-01 07:39:30)

IIRC PSP dumping is different from normal dumping. Instead of reading a range of sectors, the PSP is accessing the data through the filesystem.. So the last sectors of a PSP dump could be erroneous and some tools are known to create bad dumps. I don't think the PSP Filer developer can do anything about this, because he's restricted to what the PSP allows? Maybe there are any optical drives that can be hacked/modified into reading UMD discs? tongue

https://web.archive.org/web/20130719120 … iller.html
Does anybody have the source code of UMD Killer PRX EDITION V1.5?
I want it because I haven't understood how to dump the disc in the kernel mode.

Jackal wrote:

Maybe there are any optical drives that can be hacked/modified into reading UMD discs? tongue

Has anyone tried to insert them into the PC drive? I've heard the ideas but were there any real experiments?

https://www.ecma-international.org/publ … MA-365.pdf -- looks like a normal DVD structure? Same sector format, same lead-in sector format, no BCA, are you sure they aren't readable? The centre hole is 11mm for UMDs vs 15mm for CDs/DVDs, so you either need a custom spindle or to carefully enlarge the hole before inserting it into the drive.

sarami wrote:

Does anybody have the source code of UMD Killer PRX EDITION V1.5?
I want it because I haven't understood how to dump the disc in the kernel mode.

https://archive.org/download/UMDKillerV … .2_src.zip
https://archive.org/download/UMDKillerV … .5_src.zip

72 (edited by sarami 2018-08-17 04:10:55)

Thanks. I understood how to show the letters in kernel mode screen.

ioctl command list
http://www.psdevwiki.com/ps3/Talk:PSP_E … ntal_Patch

jpcsp/src/jpcsp/HLE/modules/IoFileMgrForUser.java
public int hleIoIoctl(int id, int cmd, int indata_addr, int inlen, int outdata_addr, int outlen, boolean async) {
    // UMD file seek set.
    case 0x01010005: {
    // UMD file ahead (from info listed in the log file of "The Legend of Heroes: Trails in the Sky SC")
    case 0x0101000A: {
    // Get UMD Primary Volume Descriptor
    case 0x01020001: {
    // Get UMD Path Table
    case 0x01020002: {
    // Get Sector size
    case 0x01020003: {
    // Get UMD file pointer.
    case 0x01020004: {
    // Get UMD file start sector.
    case 0x01020006: {
    // Get UMD file length in bytes.
    case 0x01020007: {
    // Read UMD file.
    case 0x01030008: {
    // UMD disc read sectors operation.
    case 0x01F30003: {
    // UMD file seek whence.
    case 0x01F100A6: {

ppsspp/Core/HLE/sceio.cpp
static u32 sceIoDevctl(const char *name, int cmd, u32 argAddr, int argLen, u32 outPtr, int outLen) {
    case 0x01F20001:  
        // Get UMD disc type
    case 0x01F20002:  
        // Get UMD current LBA
    case 0x01F20003:
    case 0x01F100A3:  
        // Seek UMD disc (raw)
    case 0x01F100A4:  
        // Prepare UMD data into cache.
    case 0x01F300A5:  
        // Prepare UMD data into cache and get status
    case 0x01F300A7:
        // Wait for the UMD data cache thread
    case 0x01F300A8:
        // Poll the UMD data cache thread
    case 0x01F300A9:
        // Cancel the UMD data cache thread
    // TODO: What do these do?  Seem to require a u32 in, no output.
    case 0x01F100A6:
    case 0x01F100A8:
    case 0x01F100A9:

static int __IoIoctl(u32 id, u32 cmd, u32 indataPtr, u32 inlen, u32 outdataPtr, u32 outlen, int &usec) {
    // TODO: Should not work for umd0:/, ms0:/, etc.
    // Get UMD sector size
    case 0x01020003:
    // Get UMD file offset
    case 0x01020004:
    case 0x01010005:
    // Get UMD file start sector.
    case 0x01020006:
    // Get UMD file size in bytes.
    case 0x01020007:
    // Read from UMD file.
    case 0x01030008:
    // Get current sector seek pos from UMD device file.
    case 0x01d20001:
    // Read raw sectors from UMD device file.
    case 0x01f30003:
    // Seek by sector in UMD device file.
    case 0x01f100a6:

complement
    sceIoDevctl: 0x01F20001 // pspUmdInfo
    sceIoDevctl: 0x01F20002 // Maximum Logical Block Address of L0 + L1
    sceIoDevctl: 0x01F20003 // Maximum Logical Block Address of L0

I found command
    sceIoDevctl: 0x01F20014 result=0x00000000 // always 05 80 00 32
    sceIoDevctl: 0x01F200A0 result=0x00000000 // 01 or 10 or 20
    sceIoDevctl: 0x01F200A1 result=0x80010016 // unknown (argument is out)
    sceIoDevctl: 0x01F200A2 result=0x80010016 // unknown (argument is out)

73 (edited by LedZeppelin68 2018-07-17 05:32:22)

Hi, i have modded UMDKiller PRX edition and wish to explain, how it works

https://pastebin.com/iJsTSgST

the main part is this code

opening UMD for reading, not the file system, the media itself
fd = sceIoOpen("umd0:", PSP_O_RDONLY, 0777);

allocating buffer in memory
umdbuffer=malloc(2097152);

reading 1024 sectors in buffer
sceIoRead(fd, umdbuffer, 1024);

opening file for writing on memorystick
redump = sceIoOpen("ms0:/ISO/REDUMP.iso", PSP_O_WRONLY| PSP_O_CREAT | PSP_O_TRUNC, 0777);

writing buffer bytes to file
sceIoWrite(redump, umdbuffer, 1024*2048);

it works with sectors, not file system

working buffer is 1 or 2 megabytes doesn't affect the perfomance, ripping time is equal, PSFiller == UMDKiller (300 Mb Tron Evolution in ~3:30 minutes)

What have been modded.

the original killer reads and saves chunks of 512 sectors at once.
this is ok when the size of UMD is a multiple of 512 (my test Tron Evolution is multiple, what a luck)
and i can't understand if original source does have the routine to handle not multiple UMDs, maybe this sceIoRead is so clever and can handle it by itself?

ok, there is a function "sceIoLseek" it can show the end sector, and if we add +1, it will be the size of the UMD
there is another place, that stores complete size in sectors, 16th sector of UMD, at the offset 0x50h

16 * 2048 + 0x50h = 0x8050h

Tron Evolution (ULES-01494)

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00008000  01 43 44 30 30 31 01 00 50 53 50 20 47 41 4D 45  .CD001..PSP GAME
00008010  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00008020  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00008030  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00008040  20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00          ........
00008050  00 4A 02 00 00 02 4A 00 00 00 00 00 00 00 00 00  .J....J.........

00 4A 02 00 = 024A00h = 150016

I added this check, reading 16th sector and determine the full size of UMD

then I'm splitting the dumping process in two parts there it dumps chunks multiple of 1024
and the remaining non-multiple chunk

range1 = umdFullSize / 1024;
range2 = umdFullSize % 1024;

umdbuffer=malloc(2097152);
for(i=0;i<range1;i++)
{
    sceIoRead(fd, umdbuffer, 1024);
    sceIoWrite(redump, umdbuffer, 1024*2048);
}
free(umdbuffer);

if(range2!=0)
{
    umdbuffer=malloc(range2*2048);
    sceIoRead(fd, umdbuffer, range2);
    sceIoWrite(redump, umdbuffer, range2*2048);
    free(umdbuffer);
}

this is more simple and clear solution

to use this PRX, your should place it in "seplugins" directory on memorystick
add the line to seplugins/vsh.txt "ms0:/seplugins/UMDKiller.prx 1" without quotes
1 means enabled

don't forget to reset the handheld, place umd in drive, wait until it appears in XMB and press NOTE button

Post's attachments

UMDKiller.zip 30.36 kb, 27 downloads since 2018-07-17 

You don't have the permssions to download the attachments of this post.

I'm trying to dump a demo with a video partition from another region (Europe) than my PSP (USA) with UMD Killer. Fake Region didn't seem to help on CFW, it just goes to a black screen. Any advice?

All my posts and submission data are released into Public Domain / CC0.

You can't fake the region to rip UMD's, you need a PAL PSP, a long time ago using a pandora ms you could switch regions from USA Japan and Europe, but it was permanent, unless you re-done it back again.

I have a UMD Video with HK region and the only way I can dump it is with a Hong Kong Region PSP.

The fake region might do something more to do with the online side of things, if you fake the region to Japan, it might go on the Japanese sony network like my proper Japanese model does, maybe?

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.