Page 2 of 3

Re: Should we switch to CloneCD format?

Posted: Sun Oct 09, 2011 3:09 pm
by Jackal
There's little point in talking about switching as long as trurip isn't available. It's the only dumping tool that can rip properly to this format, and Truong is maybe the only person besides elby who has thorough knowledge of the .ccd format (which is proprietary and closed).

Also, I'm not really in favor of redumping 15000? CD's.. maybe it's best to separate the systems that really need ccd and subchannels (PC, PCE, etc.) from the ones that don't (like PSX and some other major systems), and maintain the old dumping method for the latter ones.. that would make the operation much more feasible.

Re: Should we switch to CloneCD format?

Posted: Mon Oct 10, 2011 4:48 am
by Nexy
Look, .bin images are no different than .img ones, they are still 2352 ISO images. Alcohol ones with subs are 2448 ISO images. The formats are standard and defined. It's not very hard to figure out the .ccd cue sheet format at all, even I did it with some hours of research and testing. MDS is a lot more difficult to do but can also be done with just some dumping experiments and some knowledge, and looking up open source projects for disc emulation.

Truong is not the only person in the world who knows about things, and acting like he is god or something is just silly. Obviously other people know about it too, you just have to dig for the knowledge.

I've already constructed many clonecd images from seperate parts, it's not difficult at all. The .img file is no different than any other .bin file, the .sub file is the same format which subdump creates. Like I said there is no need to redump entire discs into clonecd format when it's easy enough to construct them with the files we already have with the addition of .sub file, it comes out exactly the same for data only discs. Discs with audio come out different because we take into account write offset when dumping the tracks, in which case our constructed images would be BETTER than what clonecd or alcohol can produce. That's the entire reason we DON'T use those tools for that purpose. Although I DO use CloneCD for specific tasks like safedisc and laserlok, but that is not part of this discussion and is discussed already in other threads.

PSX needs subs too IMO for libcrypt, as well as segacd and whatever else is on CD format. There is no distinction between.

DVD/GDROM/BR is an entirely different matter, I don't feel qualified to discuss anything related to them.

Re: Should we switch to CloneCD format?

Posted: Mon Oct 10, 2011 4:37 pm
by Nexy
To all those who are voting, please post and explain your vote!

Also, if you are NOT a mod or dumper, please do not vote, your opinion about how you want your collection stored is of no use to us or this site.

Re: Should we switch to CloneCD format?

Posted: Mon Oct 10, 2011 4:52 pm
by F1ReB4LL
Nexy wrote:We would still dump discs the way we do now, but also have .ccd (clonecd cue) file and .sub file.
Also a single .img file, at least. Also, probably, an .scr (scrambled .img) file.

But it still won't be an ideal format, since it missing lead-in and lead-out areas. For me, the only real "perfect" format is a single 2448 bytes/sector file, which starts with lead-in sectors, then 1st pregap, then the scrambled user area and lead-out (all the sections with the interleaved subs). It's the only way to store the dump as close to the real CD contents, as possible, also there won't be any cue needed. But you need to write a special tool to dump the discs this way, using the swapping on Plextor drives.

Re: Should we switch to CloneCD format?

Posted: Mon Oct 10, 2011 5:01 pm
by iR0b0t
Adding CCD file descriptor is needed when adding subchannels to the base.

I think F1ReB4LL has all the main details about CCD structure.
We only need to work it out, the rest can be done by the parsers.

The old CUE sheet support and of course split tracks will stay as is.
The only additional feature will be one track dumps (unscrambled + scrambled tracks are also planned).

NOTHING has to be re-dumped as stated by Nexy before!

Dumpers can still do their dumps the old way (cuesheet only) if they have no supported hardware to extract the subs, and/or scrambled dumps.

Don't see any problems there adding subs and ccd  Image
F1ReB4LL wrote:But it still won't be an ideal format, since it missing lead-in and lead-out areas...
Agree, but we still have some time for this Image

Re: Should we switch to CloneCD format?

Posted: Mon Oct 10, 2011 5:06 pm
by Kurems
The explanation of my vote is rather simple and short : I'm agree with all Jackal's arguments, so I choose NO for switching all dumpings in CloneCD Format.

But, CloneCD could be an option for dumping some systems like PC-Engine because of those tricky formats and mastering errors.

EDIT : +1 on F1ReB4LL's post!

Re: Should we switch to CloneCD format?

Posted: Mon Oct 10, 2011 5:12 pm
by Nexy
I agree with F1ReB4LL also, custom format is the best solution.

Problem is getting a tool which can do it. Image

Sub Code is start in that direction however, which is why I posed the question in the first place.

Re: Should we switch to CloneCD format?

Posted: Tue Oct 11, 2011 9:07 am
by F1ReB4LL
Nexy wrote:I agree with F1ReB4LL also, custom format is the best solution.
The one I've described isn't a custom format at all, but a raw dump, in a single file, just as it's written on a CD, contains data, TOC and subs, all as is, all in their right places, no need in cues/ccds/whatever. Converters to ccd/bin-cue/iso-mp3/whatever can be made, of course, when needed.

Re: Should we switch to CloneCD format?

Posted: Tue Oct 11, 2011 11:32 am
by Nexy
As far as I know there is no tools which can deal with such an image, unless you know of one. That makes it a custom disc image format =] Just semantics I know.

Re: Should we switch to CloneCD format?

Posted: Wed Oct 12, 2011 2:54 am
by Isis
Are we just waiting for an upgraded version of this: http://www.cdtool.pwp.blueyonder.co.uk/downloads.htm?

Has all the pieces... but no offset correction - but that can be done with another shifting tool right?


Rambling below:

It looks like this is becoming a tug of war between intent and execution.  Are we going for preserving the authors typos and paper type, or are we just retyping the words he wrote to meet modern digital conventions?  Why preserve mastering errors?  However, I would hate to see data thrown out that may eventually be of use. 

Read everything, refine and correct later!  Given enough time, there will be some tool to shift/skew/add/subtract/merge/fix if we just go for a format that captures as much as possible.