Search options (Page 59 of 66)

Any drive manages the 1st gap as a part of data track, if there are any scrambled sectors - they will be descrambled. Also don't forget, that you can't get a complete gap in isobuster dump of the first track - with positive combined offset there's always a garbage between the data and audio sectors and, as a result, the very end of the gap is cut.

In my opinion, we shouldn't have any descrambled images at all - a dump should represent the unmodified content of the disc. Descrambling gives us lots of problems. Yes, there are images with the data sectors in audio - some of them have those sectors marked as data in the subs (TFX, Base Jumpers, etc.), others - don't (many Saturn ones, like Gunbird; some PC ones, like that Twinsen's Odyssey). I've wanted to split them somehow, that's why in the first case data sectors are descrambled and in the second they are left scrambled. If we want proper dumps, both should be left unscrambled (along with the data tracks) and the subs should be also preserved.

First of all, the database can't currently handle them at all -- CDs with different rings and same tracks usually have different subs, so they should be assignable to a ringcode, not to an entry. As for the actual dumping -- yes, subs should be dumped either via multiple rereadings (prepare to wait ~8-12 hours per CD) or cleaned manually or automatically (this can easily ruin any protection).

Looks like you have a very shitty drive(s). Either one of them (DVDRAM GMA-4082N, LG2.sub) "decided" to fix the gap subchannels part after meeting the first gap (00 02 73) sector, or the other two (DVD-RAM GSA-H55N and PX-740A) refused to return the proper data (and according to your words - it's the 2nd case). PX-740A (=BenQ DW1640) - is it able to read the first audio gap on any disc at all? My DW1650 gives read error on 99% when dumping the pre-audio datatracks with IsoBuster - it refuses to read "errorneous" zeroed sectors as a part of datatrack, your case is probably the same.

You need a chopfile tool or similar. bytes_to_skip = (datatrack_length + combined_offset_in_bytes); length = audiotrack_length.

For example: http://redump.org/disc/6896/ -- datatrack_lenth is 319512144, audiotrack_length is 24025680 (both should be found using the subs only), combined offset for the most plerxtors with +30 read offset would be +30+0=+30=120 bytes. So, bytes_to_skip = 120+319512144=319512264 bytes. But _only_ if the gap is marked as data in the subs. If audio - should be cut from CloneCD dump instead (and in 3 stages). Anyway, upload the subs at first.

Nope, MDS files aren't consistent and very drive (and speed) dependant, also, you must manually fix them in most cases (by interpolating the graph, etc.)

What's illegal in measurements?

It's possible, but the gap in the end of track 1 in 99% cases is incomplete. Basically, you should skip the (1st_track.size+combined_offset.size*4) and cut 150 sectors (150*2352=352800 bytes) after that. combined_offset.size*4 = garbage.size (in bytes). But any regular track 1 dump contains only (150*2352 - combined_offset.size*4) bytes of gap.

Imagine the 2MB CD, where 1st data track is 1MB and the 2nd audio track is 1MB, first 2 secs of 2nd audio track is pregap. The disc is burned with +100 offset and the drive has +30 read offset. CloneCD dump will contain: 1MB data track, then (100+30)*4 bytes of garbage, then 1048576-(100+30)*4 bytes of the 2nd audiotrack, total size of the dump = 2MB, the last (100+30)*4 bytes of the audio track will be missing. Track 1 dump from IsoBuster will contain: 1MB data track, then (100+30)*4 bytes of garbage, then 352800-(100+30)*4 bytes of the gap, the last (100+30)*4 bytes of the gap will be missing. (The example isn't very good, though, because 2097152 bytes can't be divided to 2352, so there can't be a 2MB disc, but I've wanted some rounded numbers).

There are 3 ways to cope with that.
1 - to write a proper dumping tool, if someone is interested, I'll help with technical docs, algorithms and testing (don't have enough time for coding).
2 - to extract the sector range in IsoBuster/CD Reader/CD tool/whatever (the next sector after the data track, length should be (352800+combined_offset.size*4)/2352 sectors (150,22 should be rounded to 151, 154,678 to 155, etc.), then you should cut the gap, skipping the garbage bytes: skip the combined_offset.size*4, the rest should contain the complete gap.
3 - to extract the bytes range from CloneCD dump - skip the (1st_track.size+combined_offset.size*4) and cut 150 sectors (150*2352=352800 bytes) after that.

Any drive fixes the offset for datatracks automatically.

Plextors have very weak lasers (or very underpowered), even lightly scratched medias give tons of c2 errors and often even freeze the drive (doesn't send any data and tray is locked). EAC has better error correction/rereading algorithm, so maybe that's the reason (PR doesn't tries to fix any c2 errors by rereading). You can also try to lower the speed in PR.

And, btw, what's your OS? AFAIK, PR has major problems on Vista and W7.

All the administration will talk purely on Russian from now on, this is the last post on English. The site itself will be also translated. You can learn our language, use google translator or whatever.

Sorry, our db doesn't support multisessions yet. And there's no way to make a proper .cue at all, that's why all the dumps from such CDs are usually in alcohol (mds-mdf), clonecd (ccd-img) or diskjuggler (cdi) formats.

LGs aren't swappable, IIRC. Try to insert some CD, then insert a pin into the eject hole -- all the LG drives I've seen eject the tray automatically.

About D8 -- what does px_d8 write? Also try to run this cachex tool: "cachex -i -p d:" (use a letter of your drive instead of d:), if you have SPTD drivers installed on your system - uninstall them (otherwise, info will be incorrect).

This method is unreliable for finding the offset for PC games, btw. There's a number of games with 0 disc offset, but some garbage in the 2nd track pregap, so the offset will be found wrong in this case (Jackal has dumped some of such games).