who thinks the MAME chd format is better than cue sheets?
chd is something specifically, its a file container and not a file descriptor !
chd is something specifically, its a file container and not a file descriptor !
Isn't ISO a container too?
4 2011-03-08 14:13:31 (edited by Jackal 2011-03-08 14:16:15)
No it's not.. what we have now is a binary file of the CD which is 2352 bytes/sector. Compressing it to CHD would be the same as compressing it to .zip or .rar for instance.. it would be absolutely pointless to preserve these checksums, if that's what you are aiming at.
Ripper006 is adding CHD support to his project, so I guess it's more MESS-friendly, but to us it's completely pointless.. like iR0b0t said, it's just a container
OK thanks for this explanation
No it's not.. what we have now is a binary file of the CD which is 2352 bytes/sector. Compressing it to CHD would be the same as compressing it to .zip or .rar for instance.. it would be absolutely pointless to preserve these checksums, if that's what you are aiming at.
and, FWIW, as a MESSDev I completely agree with your statement. The redump project is fine as it is and it already does a wonderful job, by listing checksums of the separate tracks.
Ripper006 is adding CHD support to his project, so I guess it's more MESS-friendly, but to us it's completely pointless.. like iR0b0t said, it's just a container
Ripper006 is ripping as well games as separate tracks, of course, not directly as CHD (as you correctly pointed out, it is simply a container format ), but he added the option (I don't know the exact details) to also produce a CHD from the rips.
More than this, what makes his (still in beta) project very interesting, is the capability of handling PCE-CDs weird setup. I haven't had access to any PCECD rip yet, but if his ripping tool is really capable of extracting proper data from the NEC disks, I'm more than happily ready to include his rips in our database
Back to redump.org and CHD: what it could be done, if anyone is interested, is to add a final (& optional) conversion to CHD to programs like pakkISO/unpakkISO (chdman does not modify in any way the CD data and -createcd/-extractcd are 1:1 operations, up to the fact that the output currently always consists of a single .bin file instead of separate Track .bins, so that you have to manually split the .bin into the right number of pieces and to replace the cue with one downloaded from redump.org, due to differences in indexes generated by the 1-bin-vs-multi-bins diff)
Anyway, it is not a redump.org problem, strictly speaking... and I stressed the "optional" part because compression is worse in CHD than in current 7z+ape.
By the way, I would be very grateful if anyone could point me to the creator of pakkISO: I'd be interested to discuss a bit with him the options to use it with MacOSX (since the current proposed solution tends to completely fail for games with >= 3 tracks, and I had to write down some *nix shell scripts to properly handle the PSX rips I found...)
You should speak with ir0b0t, as he currently maintains pakkiso
most people use T7Z currently btw and not pakkiso anymore *cough*
9 2011-03-22 12:49:09 (edited by etabeta 2011-03-22 12:49:33)
I have only found rips in 7z + ape format (possibly outdated sets, but they uncompressed to the correct bin+cue sets so I'm happy with them ).
Do T7Z handle these too? or only 7zipped sets?
t7z doesnt handle the old bin/ape structure sadly ^^
11 2011-03-22 15:08:14 (edited by etabeta 2011-03-22 15:08:40)
I will eventually give t7z a try.
I guess that since pakkiso has been abandoned there is not much point into make it work better on MacOSX... too bad, because pakkiso worked pretty well for sets with 1-2 files through CrossOver/WINE and my script has its own weak points (mainly about disk space usage, since it copies the files before acting on them)
However, I can also easily see why t7z is preferred when you have to update sets
Thanks for the feedback.