Search options (Page 4 of 4)

Doesn't 7zip have a greater compression over RAR and wasn't there a purpose for keeping the tracks in separate files even when torrenting? What this is suggesting is going to kill everything that has been worked on with packIso, especially with keeping the tracks separate so people can get only the tracks they need without having to download the whole image or even seed the tracks they currently have while downloading the ones they may not. Not to mention all the current torrents that have been made using packIso (which is being accepted by the torrenting community from what I can see).

I'll admit that the packIso format may not be the best compression but it is at least much better then the current alternative torrentzip and still offers the ability to keep tracks separate and keep the files the same for sharing purposes. The time it takes to unpack a packIso archive is also a big help unlike what is being suggested here where if I wanted to say play a game or make a patch I would have to wait at least 30 minutes just to decompress it which wouldn't be very helpful at all for me even if I were to only access them very rarely.

As far as setting the date, that is what the rmdtrash.exe file does in packIso. It sets the dates on the files themselves before they are compressed so that all of the 7zip archives have the same date for each files on everyone's computer. It also clears the archive bit set by the OS in the file system to further clear out unwanted data for compression.

Everyone seems to be so worked up over using clrmamepro that you have forgotten the purpose of the archives to begin with and although I can understand why you would want to use it the way you are going about this seems to be a bit far fetched as far as actual usability for everyone. I've already mentioned that adding packIso checksums is all we would have to do in order to get a dat for packIsoed files while still maintaining  our original compression. As long as there is someone that has a copy of the game that matches the database then they can make a packIso archive and post the checksums of the files and in the case of the data track the checksum of the ecm'd file in the 7zip archive should be taken instead of the archive itself so that file name changes won't effect anything.

The compression percentage is not something that we need to worry about attaining nor should we worry about whether or not the archives are compatible with any emulator or front-end application. The purpose of the archives is just to store them in a way that makes it easy for everyone to get and decompress for use however they see fit after they get the archive and right now packIso is the only thing I can see that really offers that at this time.

Acutally Jackal I have found that the copy protection on hollywood DVDs can be preserved using Alcohol 120%'s media descriptor format (mds/mdf). I dumped several DVDs from my brother with it so I could decrypt them later because I didn't have DVD Decrypter on my computer at the time. I'm only guessing but I think the CSS copy protection info is stored in the mds file which is always pretty small. Of course mounting the image won't allow it to be played back but DVD Decrypter sees that there is copy protection (which it can't see when only mounting a normal ISO dump) and is able to get the CSS keys from the Alcohol dump.

I personally think DVD movies and stuff should be more of a branched project though...the ARccOS protection on some DVDs won't be easy to get around though. I've seen DVD Decrypter's clock show upwards of 6 hours when trying to read the non-existent data on those "protected" sectors.

Oh and to dumper welcome to redump and I hope you enjoy what we have to offer here.

Have you tried using different gap detection methods in EAC? If you continue to get the same gaps on multiple drives with different gap detections then I guess the gaps would be correct. I'm not too sure but I think this might be common of older PC games.

Well as far as CSS encrypted DVDs yes they can be dumped directly. All you have to do is unlock the DVD by begining playing it with any DVD player software and you can go from there dumping it with ISOBuster and what not but the thing is that the DVD will still retain the CSS encryption on it when you do that. I know it totally defeats the purpose of even being able to use the image for anything but getting checksum info from but that is how the senior staff wants it so it's hard to argue with that.

As far as the other DVDs you mentioned like the Xenosaga series I can't really say for sure if those will be accepted so you will have to wait for a more senior staff member to respond to that question.

I know this has nothing to do with Sega CD games but it does have some relivence to this topic. I understand what you are trying to say Snake but there are games like Tomb Raider for PSX whre the last track (track 57) is nothing but silence except for one byte of data near the end of the last sector that can't be read in drives that can't overread into the lead out and that are not reading based on corrected offsets. This one byte also makes a completly different checksum compared to if you just read that track as is and assumed that because you see no more data (or no data at all in this case) that there really is no more data to read.

Oh woops I meant to say "Game version".

I've had the error you mentioned only on my drive that has a large read offset (-677 EAC) but on all other drives that don't overread it doesn't give me any error.

Oh ok I see what you're saying. I'll look into it and see which will work. If I recall the different dump methods create different size images so whichever one creates the same filesize as all the other dumps on our database would most likely be the correct one.

[EDIT]
It looks to me like rawdump and friidump are pretty much the same thing except that friidump has the source included so I guess either one should work although what I read said rawdump is faster.