PS1 ripping/converting

[MarioPandio]

Ripping your own still isn't really that legit either but its certainly faster (<5min) less bandwidth and time aswell and you know what your getting, format/language/friendly viruses for free. Though I appreciate 'theirs' maybe better accuracy. Plus owning the originals is always nice for use on the real hardwares, proper manuals etc.


I have a few mdf and iso files aswell which work, but your better with bin and img as first options.

 

[second exodous]

Every PS1 game I've ever downloaded has not worked for me, the audio is always screwed up or it just doesn't work. There are a million and one ways to rip them and you need to rip them the way that the emulator needs. That is the reason you should not download them after it just being illegal.


On my Lunar Silver Star Story the first disk cracked IN my Play Station, the new small one, so I had to go looking for someone to get it from. A guy online ripped his for me 3 times before it worked. He was a really nice guy, I can't believe he uploaded it 3 times until it worked for me. That is the only game I've 'illegally' downloaded that has worked and it was a hassle. Everyone says it isn't this way but for me games never work right unless I rip them myself.


Also, if there is ever a big game convention or comic conventions around you those are a great place to find PS games. I've went to a few and they are always cheaper at those kinds of things than they are over e-bay. So if you're hurting for PS games check those conventions out.

 

[Aimless E]

I'm curious about MD5 sums that are created for CD images. I know that if you have the same file from the same rip the md5sum will be the same, but what if I rip a game lets say


wipeout1.bin which gives me e7b16d2b587c9b314791a3866e2de979 will another CD created at the same time and ripped to the same format (being bin/cue) will it have the same md5sum? It stands to reason but as I only have one copy of wipeout It makes it a little difficult to test.


So md5sums post them if you got them.

 

[WizardStan]

md5sum basically just uses a simple math equation and takes every single byte in the file as input. It doesn't use the time or the filename or anything like that, it is just the data the file contains. If even one byte is different, the calculation will come out different. In this way, the md5sum is a kind of check to make sure the file is still the same file you ripped and hasn't been corrupted. Usually it's only used for downloaded files to make sure it downloaded correctly, however, since you're unlikely to see corruption with a file just sitting on your hard drive.

 

[Aimless E]

md5sum basically just uses a simple math equation and takes every single byte in the file as input. It doesn't use the time or the filename or anything like that, it is just the data the file contains. If even one byte is different, the calculation will come out different. In this way, the md5sum is a kind of check to make sure the file is still the same file you ripped and hasn't been corrupted. Usually it's only used for downloaded files to make sure it downloaded correctly, however, since you're unlikely to see corruption with a file just sitting on your hard drive.

Which is why its a good way to check the validity of a file. What I'm wondering is if two computers take two discs, that where manufactured in the same batch, created the same type of image when backing up onto a hard-drive if the files would have the same md5sums.


If not is there a better way of checking a file disregarding filenames as an option.

 

[WizardStan]

Which is why its a good way to check the validity of a file. What I'm wondering is if two computers take two discs, that where manufactured in the same batch, created the same type of image when backing up onto a hard-drive if the files would have the same md5sums.

If the disks contain the exact same data, which tends to be true, then the image will contain the exact same data and will therefore produce the same md5. Not guaranteed, of course, but from a single batch at the very least (not even the exact same time necessarily, probably over a day or two at least) there's a pretty good chance of the data all being exactly the same.

 

[Aimless E]

Which is why its a good way to check the validity of a file. What I'm wondering is if two computers take two discs, that where manufactured in the same batch, created the same type of image when backing up onto a hard-drive if the files would have the same md5sums.

If the disks contain the exact same data, which tends to be true, then the image will contain the exact same data and will therefore produce the same md5. Not guaranteed, of course, but from a single batch at the very least (not even the exact same time necessarily, probably over a day or two at least) there's a pretty good chance of the data all being exactly the same.

Thanks,


I just verified that on my end as well.

 

[Prosthetic_Mind]

All this talk of ripping makes me wonder how well a dd image of the cd would work, and whether the emulator would support it.


For the guy on the previous page with MacOS, since OSX is built off of BSD it should have dd. Look up the man page for it, or (assuming OSX uses the same filesystem structure as BSD/Linux) just use the following template-

sudo dd if=/dev/(cd device) of=/home/name.img (or wherever you want to save the image file) bs=1M

I can't be sure whether or not any of the emulators will be able to read the image file, but you can use the mount command on the pandora to mount it and should be able to point the emulator at the root directory of the CD and still have it work.


Disclaimer- I haven't actually had time to try this on my pandora, but there's no reason I can think of that it shouldn't work. dd makes a bitwise copy of the CD and accurate to the point of producing forensic quality copies. dd does not display any output until it is finished, if you want a progress bar or more output I suggest trying dc3dd or dcfldd (both DoD variants designed for forensics purposes).

 

[CFWhitman]

If you want to rip PS1 discs from a Mac, you can use cdrdao as Prometheus does on Linux.


First, get Darwin Ports installed from here.


Then you can use the port command just like from any BSD system to install cdrdao. Instructions are here.


After that, you should be able use the same command that Prometheus does, using whatever device name your optical drive is referred to as in OS X. It may very well be /dev/cdrom, but I don't know that for sure.

 

[WizardStan]

All this talk of ripping makes me wonder how well a dd image of the cd would work, and whether the emulator would support it.

That's exactly how you get an ISO.

dd makes a bitwise copy of the CD and accurate to the point of producing forensic quality copies.

Not really. dd copies the data, however there's more than just data (ie, user readable files) on a CD: track information, subchannel data, none of this is directly readable from the CD device file so won't be copied with dd. That's where bin/cue fill in where ISO fails; bin/cue maintains track information and subchannel data where ISO simply cannot.

 

[Cas]

If you want to rip PS1 discs from a Mac, you can use cdrdao as Prometheus does on Linux.


First, get Darwin Ports installed from here.


Then you can use the port command just like from any BSD system to install cdrdao. Instructions are here.


After that, you should be able use the same command that Prometheus does, using whatever device name your optical drive is referred to as in OS X. It may very well be /dev/cdrom, but I don't know that for sure.

Hi


Thanks will try that once I have come to terms with my Pandora

 

[Prosthetic_Mind]

All this talk of ripping makes me wonder how well a dd image of the cd would work, and whether the emulator would support it.

That's exactly how you get an ISO.

dd makes a bitwise copy of the CD and accurate to the point of producing forensic quality copies.

Not really. dd copies the data, however there's more than just data (ie, user readable files) on a CD: track information, subchannel data, none of this is directly readable from the CD device file so won't be copied with dd. That's where bin/cue fill in where ISO fails; bin/cue maintains track information and subchannel data where ISO simply cannot.

Really? I didn't realize that ISOs were actually bitwise copies. I use dd for forensic purposes and I just assumed that if it can produce forensic images of hard drives that it'd be just as good for cds.


Out of curiosity, if you can't read the track/subchannel information from the device file, where can you read it from?

 

[WizardStan]

Out of curiosity, if you can't read the track/subchannel information from the device file, where can you read it from?

That's a good question which I can't fully answer. I know it is there on the /dev/cdrom (or whatever) device file as evidenced by the fact that cdrdao can get the TOC and subchannel data out of it, however simply attempting to read the raw data (via dd or cat) from the device yields only the data bytes.


edit: reading the cdradao source, it opens the device file and sends ioctl commands to it which are low level commands directly to the hardware. The CD ROM hardware accepts these commands and returns the requested information to the ioctl call. These low level commands are not part of the default behavior of the device: treating it as a basic file simply reads the data channel.


Incidentally, your hard drive scenario can be improved with ioctl commands as well. You can send commands to find out all kinds of information about the hard drive which are not part of the default behavior.

 

[Prometheus]

Just a quick question, here: Does anyone know if cdrdao is available in the Ångström repository? The feed browser is down at the moment, so I can't tell.


If it is, and if there's a way to spit the bin/cue to somewhere other than the home directory, it should be possible to do CD rips (not just PSX, but Mega CD and PC-Engine CD as well, for example) directly on the Pandora, no?

 

[WizardStan]

There's no cdrdao, but there is cdrkit which seems to offer something very similar. It advertises the ability to rip audio CDs, but I don't know whether that transfers to anything else. Documentation seems to be lacking.

 

[may88]

What about compressed images? I think there is some limited support for that in the latest emulator.


Has anyone had any luck using those?


I found I utility that created eboots but gave up on that at the time as that was a PSP format and the emulator I was using didn't support that, but may be now I need to dig that up again.


I have 25Gb of ripped my PSX games so far. Shame to fill my 32Gb SD quite so soon.

 

[#1 GameMaster]

What about compressed images? I think there is some limited support for that in the latest emulator.


Has anyone had any luck using those?


I found I utility that created eboots but gave up on that at the time as that was a PSP format and the emulator I was using didn't support that, but may be now I need to dig that up again.


I have 25Gb of ripped my PSX games so far. Shame to fill my 32Gb SD quite so soon.

I've not had a problem using the eboot format on it but that was with r6. I'm sure if it works on r6 it works on r7. The only reason I don't know is because I had to send my Pandora back because of a faulty second SD card slot. It would probably be best for you since you seem to want to limit the space it takes. It really helps conserve your space because it shrunk my collection down to 42GB from 60GB. I tested a few games in bin and eboot formats, and didn't notice a change in FPS either.

 

[may88]

^ Thanks. Need to find where I put the eboot thingy prog and re-rip my collection. Still to be honest I may just wait until I have a Pandora and then do it game by game so I can test them.

 

[samedi]

I've got a headache now after reading all that...... :blink: