Search options (Page 12 of 14)

This has been known for a long time now, but the idea hasn't been pushed much.

The bright side is, entire discs do NOT need to be redumped, only the sub code, and a .ccd file generated for that dump.

I vote yes for several reasons, sub code preservation (anomalies, flags). Wider range of type support (CD-Xtra, etc). Scrambled image support.

Well come up with a better solution and suggest it then rather than make posts like your first one which I found offensive and bordering on trolling.

Much talk already on changing to clonecd format also, I may as well post the idea here too and absorb the negative reactions to that too. There are limitations to this format too, but not as many as bin/cue, and it's easy enough to convert existing images to it with just ccd generation and sub code files added.

Also talk of entire disc dump being scrambled.

Conflicting opinions on all of these subjects, it's rather annoying imo.

What bothers me the most is the childish way in which ideas get discussed at times, we are all adults, should act like adults and discuss the possibilities and ideas in a rational matter rather than acting like spoiled 12 year olds. I for one do not appreciate it all when I spend thousands of dollars and put hundreds of hours of my own time in this project, only to see such bullshit posted.

Themabus: I'm not sure what your getting at here.

Sure flags do not get stored, and they can change in the middle tracks or gaps, which is why the subs are needed.

As for P and Q, from my experience P doesn't matter only Q matter when it comes to gaps. Many tracks can end up wrong size if you go by P, it's pretty simple to test if you merge the image together into a whole disc and compare the size of the whole thing to how many LBA there should be in the image. Often times this comes out wrong if you don't check the frames. Why is that? Because Q track number and Q index needs to be paid attention, this can often conflict with TOC and P channel, and usually does. P channel tends to be off by 1 sector always in almost every single dump with CDDA I've done.

TOC may point to an area in the track which is marked as gap in the Q channel (CD Lock for instance). Other discs may say there is a gap of 2:02 , which it correct by Q channel (which is what EAC goes by) but this can conflict with TOC. Which will make the track the wrong size as the first 2 sectors after where TOC says is start of track are marked as index 00 in the subs. I can come up with many such examples. Another example is Blood, where the final sector of the data track is filled with 00, it is marked both in the TOC AND subs as part of Track 01 and not Track 02. Where if you go by the guide, you would be mistaken thinking this is part of the gap of track 02.

Granted I do PC strictly, and PC is just badly mastered and nothing to be done about it, other than at least try to get the tracks sizes correct so that the disc image is the right size. It's most important to have correct size of Tracks FIRST. Rest can be handled by cue and subs for any discrepancies in the mastering process.

We should always be trying to dump things to the best of our understanding and using the tools we have at our disposal.

Since redump is focused on games that's why I said what I did. Maybe we can have a sister site for os/apps/drivers etc.

Lock this topic, these kinds of questions are stupid, and don't even deserve a response imo.

I rather don't like the splitting idea because many stuff can overlap OS versions. Better to just have a field which says which OS's the games were intended to run, it's always on the CD cases/Boxes.

I've tested this tool a lot, it works great, but it can be slow. =]

I hope you have a plextor drive, it REALLY makes dumping PC games much easier.

If you have any questions about dumping any certain protection not covered in the guide or the stickies, feel free to ask here or on IRC.

you can also dump it with isobuster using the from-to way. If you know how the guide works and follow the instructions for dumping the data track, you already know where the pre-gap starts. Then you just dump from there to the the LBA of Track02+1 sector.

You then need edit the pregap a bit in a hex editor, you need to cut the crap bytes off the start (the ones you used to detect offset) note how many bytes it is. Then in a calculator you do 2352-bytes, the result is how many bytes to cut off the end of the pre-gap.

It's easy to figure out than the clonecd way.

it's simple to use a tool like ultraiso to convert bin/cue to clonecd, and clonecd supports multisessions in it's own format... BIN/CUE does not support multisessions at all, so I don't know about what your doing.

And yeah, you should ask on a dreamcast forum about burning such things, or CDFreaks.

@Fireball, no it doesn't matter what drive you use, it will offset the subs the same. I have the magic 2.5 sheep burner though, I will have to dig it out and test.

@marzsyndrome, you can pretty much think that CDRWin is dead and won't be updated anymore. Same for most other old burning programs. Like I said, give clonecd a go, it should work for what you need.