Redump Forum

F1ReB4LL wrote:

themabus wrote:what's the point of checking every CD manually

It's not needed anymore, there's a tool almost ready. 2themabus: i'd like to have some PCE CD ones, if possible (better some tougher ones).

that would be really great. i hope it will solve many things.
but i think - ultimately it's still a person that should make a certain decision.
for example ther's some PCE CDs that have 2:00 Track 01->02 gap, when all the rest have it @3:00.
and it is the only difference: no audio silence part of the gap marked as such in subchannels.
back then i kept those CDs @2:00 but today i would go for 3:00, as with all the rest CDs.
i think such differences has no meaning - they're mostly result of immature mastering equipment (hardware or software)

i hope, that some day there will be an option to reconfigure gaps included in PerfectRip.
for example: if you get 2:00, 1:74, 2:00, 2:01, 2:00, 2:00 - you would be able set them to 2:00 before dumping starts.
so there would be no need of moving sectors or dumping with no gaps,
no difficulties because of different drives returning different layouts.

themabus wrote:i hope, that some day there will be an option to reconfigure gaps included in PerfectRip.
for example: if you get 2:00, 1:74, 2:00, 2:01, 2:00, 2:00 - you would be able set them to 2:00 before dumping starts.
so there would be no need of moving sectors or dumping with no gaps,
no difficulties because of different drives returning different layouts.
If the doors of perception were cleansed every thing would appear to man as it is,
infinite

It's not needed. Your 'premium' drive also gives shit. So, I'm afraid your theory about PCE CD layouts is beaten 'Premium' subs (both normal and 'audio' ones) have either missing or doubled sectors in certain places, that affects pregap length. 'LH-18A1H' subs look reliable, I'll send you all the cues/logs/comments later.

Edit: or maybe the theory is not beaten completely yet...

F1ReB4LL, I probably understood what you are talking about. It might be because of Alcohol, by the way, again, it's not a problem of the drive and it's not important to detect right pregap manually (if it's a problem with new tool you are talking about, you might have same problem with sync errors). I'll make new cues with PR as soon as I have time (along with the other ones you required).
Yes, EAC has a problem detecting postgap, my cues are made by PR.

F1ReB4LL wrote:It's not needed. Your 'premium' drive also gives shit. So, I'm afraid your theory about PCE CD layouts is beaten 'Premium' subs (both normal and 'audio' ones) have either missing or doubled sectors in certain places, that affects pregap length. 'LH-18A1H' subs look reliable, I'll send you all the cues/logs/comments later.
Edit: or maybe the theory is not beaten completely yet...

yes, i'm aware of that. those .SUBs i've sent you were taken on Alcohol or CCD -
both those programs would return slightly 'improved' subchannel info.
AFAIR this could be witnessed most dramatically,
when an ordinary Audio Trap CD with multiple tracks is used to dump other CD
and there would be marks in returned subcode, matching to TOC entries from Trap CD.

edit:
i tried and could not reproduce this on current versions of CCD or Alcohol.
here is fragment from my older post:

Alcohol and CloneCD both masked some problems with subchannel, Alcohol seems to do it somewhat less but it has problems (track data actually gets damaged) with at least saturn data tracks when gap is large - 6 seconds (maybe 5) or more (mode changes on saturn, maybe it does not affect psx, i think i did not test, don't remember really). also when swapping toc with audio cd i think both Alcohol and CCD will output gaps in subcode from audio cd's toc. so it's strange, they like insert gaps in subcode instead of reading, i don't trust them at all after that. CDTool seems to be most accurate.

i used to report bugs like this, so maybe it was fixed with version updates, but i'm nut sure.

but it would be very difficult to convince me, that genereal
Audio->Data 3:00; Data->Audio 2:00; Audio->Audio 0:00
layout is incorrect
or for example, that each CD should have some random gaps instead of all audio - 0:00

on the other hand, i like very much how currently tracks on DC are separated:
all audio sectors in one file; data sectors in other
even though i think it's incorrect regarding INDEXes - i could not check
but i believe gap from Audio->Data it's still likely to be 3:00 seconds large difference, not 2:00.
well but i kind of regret now keeping 3:00 gaps for PCE - where data file would start with audio silence.
only application reproducing correctly CD from such cue sheet is CDRWIN anyway
and even though INDEXes are correct - probably Q-TNO aren't.
so 2:00 in cue sheet, reproduced on different application, might get incorrect Q-Index but correct Q-TNO.
it's as good as 3:00 but much better looking, IMHO.
so it's really more a philosophical thing.

edit:
to avoid confusion:
previously i've mentioned some PCE CDs having this gap set to 2:00, not 3:00 and that i think they should be 3:00.
well what i meant - i think they should not be different from the rest CDs, whichever pattern is chosen.
but i personally prefer Audio->Data being 2:00, so that audio and data sectors would end up separated one from another.

currently dumping by layout would be difficult and tedious unless such gap managment is implemented in imaging application.
so this is my understanding of problem.

Rocknroms wrote:it's not a problem of the drive and it's not important to detect right pregap manually

It is. In your case, there's a sector missing between track01 and track02, it can be the last track01 sector or it can be the first track02 sector. If it is the first track02 sector, gap should be 1 frame larger and 00 index should be 1 frame earlier, so it is important.

F1ReB4LL wrote:

Rocknroms wrote:it's not a problem of the drive and it's not important to detect right pregap manually

It is. In your case, there's a sector missing between track01 and track02, it can be the last track01 sector or it can be the first track02 sector. If it is the first track02 sector, gap should be 1 frame larger and 00 index should be 1 frame earlier, so it is important.

There's nothing missing, for example in Cyberbots Q-AFRAME=68 is missed in count and repeated 2 times at the end of pregap. Probably it's a Alcohol bug mixed with sync errors (by the way I have to understand why you point at a bug in the drive? You have a proove? Maybe all PX-760A has a problem?)

Here is the sub taken with PR. Q-AFRAME=69-72 are zeroed
T-1216G

Rocknroms wrote:Here is the sub taken with PR. Q-AFRAME=69-72 are zeroed
T-1216G

What's about other subs taken with PR? Good/same 1-sector offset before the 2nd track/zeroed sectors before the 2nd track?

I already heard people say before that clonecd/alcohol sometimes alter the subs.. so you should always try to use Perfectrip in CCD mode.. I also don't think that the drives are causing this.

F1ReB4LL wrote:

Rocknroms wrote:Here is the sub taken with PR. Q-AFRAME=69-72 are zeroed
T-1216G

What's about other subs taken with PR? Good/same 1-sector offset before the 2nd track/zeroed sectors before the 2nd track?

yes, but Cyberbots is the only one with zeroed sectors.

T-36102G here is Whizz (this sub confirms at all 2.02 pregap) ---> old sub missed Q-AFRAME=01 and repeat it at the end of pregap.

T-26101G here is Gusson Oyoyo S ---> old sub missed Q-AFRAME=46 and repeat it at the end of pregap.

44
45
46
46
There's no frame/sector missing, it's only messed up.

Jackal wrote:I already heard people say before that clonecd/alcohol sometimes alter the subs.. so you should always try to use Perfectrip in CCD mode.. I also don't think that the drives are causing this.

Actually, my Benq doesn't read track02 pregap itself, cdreader also gives error there, but with clonecd all the sectors in the sub are fine, so, clonecd generate those sectors, I guess. Though, I can't understand the fact, why there's always a DCP flag set for track02 pregap and not only in clonecd subs, but also, for example, in CDRWin-generated cuesheets - so maybe a drive's firmware also 'helps' a little.