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 smile '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.

My patch requests thread
--------------------------------

F1ReB4LL wrote:

It's not needed. Your 'premium' drive also gives shit. So, I'm afraid your theory about PCE CD layouts is beaten smile '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

My patch requests thread
--------------------------------

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.

My patch requests thread
--------------------------------

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.

Rocknroms wrote:

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.

Here's what we have:

Original wrote:

00 00 00 00 00 00 00 00 00 00 00 00 41 01 01 06 40 72 00 06 42 72 5B BB
00 00 00 00 00 00 00 00 00 00 00 00 41 01 01 06 40 73 00 06 42 73 E1 CB
FF FF FF FF FF FF FF FF FF FF FF FF 41 01 01 06 40 74 00 06 42 74 F6 F8
FF FF FF FF FF FF FF FF FF FF FF FF 41 01 01 06 41 00 00 06 43 00 2A FA
FF FF FF FF FF FF FF FF FF FF FF FF 01 02 00 00 01 74 00 06 43 02 4D 80
FF FF FF FF FF FF FF FF FF FF FF FF 01 02 00 00 01 73 00 06 43 03 3A 75

PerfectRip wrote:

00 00 00 00 00 00 00 00 00 00 00 00 41 01 01 06 40 72 00 06 42 72 5B BB
00 00 00 00 00 00 00 00 00 00 00 00 41 01 01 06 40 73 00 06 42 73 E1 CB
00 00 00 00 00 00 00 00 00 00 00 00 01 02 00 00 02 01 00 06 42 74 90 D1
FF FF FF FF FF FF FF FF FF FF FF FF 01 02 00 00 02 00 00 06 43 00 37 A2
FF FF FF FF FF FF FF FF FF FF FF FF 01 02 00 00 01 74 00 06 43 01 7D E3
FF FF FF FF FF FF FF FF FF FF FF FF 01 02 00 00 01 73 00 06 43 02 2A 54

PR ones are autogenerated or what? If they were autogenerated based on sector contents - yes, I understand this. But if they weren't - I can't understand 2.00 vs 2.02 without at least 2 strings missing in the original (and only 06:43:01 is missing here, in this case it really doesn't affect pregap).

Rocknroms wrote:

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.

PerfectRip wrote:

01 24 01 00 33 56 00 25 52 27 84 CF
01 24 01 00 33 57 00 25 52 28 DF 71
00 00 01 00 33 58 00 25 52 29 AA A9
A9 01 24 01 00 33 59 00 25 52 30 83
E0 01 24 01 00 33 60 00 25 52 31 37
53 01 24 01 00 33 61 00 25 52 32 AD
61 01 24 01 00 33 62 00 25 52 33 53

01 24 01 00 33 63 00 25 52 34 89 24
01 24 01 00 33 64 00 25 52 35 FE D1

just LOL. Q-channel bytes are shifted, don't know what to say... I only wonder, if PR has failed, while autogenerating or while dumping&verifying subchannels. After Whizz my doubts about PR are even stronger...

PR never alters subs as long as the 'keep sony pregap' checkbox is unchecked (always leave this unchecked when doing 1:1 sub dumps!).. if it's unchecked then any errors are from the drive and not from PerfectRip.

If the checkbox was already unchecked, then either the original output is wrong or there's a bug in PR.

ps. clonecd is known to jump over gaps sometimes and autogenerate them, so if you want to be 100% sure that the .sub output is correct, I think it's best to use PR with the proper settings.

Jackal wrote:

ps. clonecd is known to jump over gaps sometimes and autogenerate them, so if you want to be 100% sure that the .sub output is correct, I think it's best to use PR with the proper settings.

What's about cdreader? Tried to read a CD - as usual, got some sectors with wrong Q-CRC. Tried to reread one of them - same result. Changed the drive(!) - same result. Looks like subs aren't "clean" on CDs themselves...

After installing a new ide controller to support 4 drives fo DC games I got everything messed up (the reason why I have problems with Lite-on in DC thread), the 2 drives attached to new controller are checked as scsi. I tried to fix it, but now also plextor is seen as scsi and I cannot do anything (any program says it's a drive not supported!).
From what I can find probably everything is messed up because of virtual drives, I'll try to fix it otherwise I'll have to format pc.

EDIT: I fixed the MB ide channel drivers, anyone know if it's possible to have a right detection on drives attached to a pci-express card with that stupid jmicron controller (even on CDfreaks they said to let the stardard drivers, but with a card it seems it's not possible)?

My patch requests thread
--------------------------------

F1ReB4LL wrote:

Looks like subs aren't "clean" on CDs themselves...

Who says they should be? PR + cdreader output should be reliable... have you tried selecting ASPI instead of SPTI in cdreader? anyway, just use the latest perfectrip with 'keep sony pregap' disabled.

Jackal wrote:

have you tried selecting ASPI instead of SPTI in cdreader?

It doesn't work with SPTI (i.e. without wnaspi32.dll) at all, if you forgot.

Jackal wrote:

anyway, just use the latest perfectrip with 'keep sony pregap' disabled.

Have some spare Plextors and wanna share with me? smile

Rocknroms, concerning post 38, my dumps where fixed you can remove that nfo, and you can also update the first post with subs

problems with pregap detection in perfectrip:

ClockWerx (J) (Track 06) http://redump.org/disc/5088/
King of Fighters '96, The (J) (Track 13) http://redump.org/disc/5250/
Thunderhawk 2 - Firestorm (G) (Track 07) http://redump.org/disc/5194/

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

I'll fix everything left, posting also new subs in the weekend.

My patch requests thread
--------------------------------

Rocknroms wrote:

About IFPI, this is not part of ring code. Along with laser-burned digits you mentioned is part of barcode of IFPI that has nothing to do with Sega and/or Saturn

I've checked all my CDs, seems that there is a relationship between an IFPI code after V and an offset value:

L231: +78, +666, +672, +1254, +1260

L236: +1764

L237: +390, +678, +684, +1860, +1926

Check your CDs, please. Seems, these codes are needed, afterall...

F1ReB4LL wrote:
Rocknroms wrote:

About IFPI, this is not part of ring code. Along with laser-burned digits you mentioned is part of barcode of IFPI that has nothing to do with Sega and/or Saturn

I've checked all my CDs, seems that there is a relationship between an IFPI code after V and an offset value:

L231: +78, +666, +672, +1254, +1260

L236: +1764

L237: +390, +678, +684, +1860, +1926

Check your CDs, please. Seems, these codes are needed, afterall...

I'll check everything *** as soon as I have time to check.

*** I have to post all the other subs, as I said I installed clonecd so I'll try to make subs with it for your wip too.

My patch requests thread
--------------------------------

http://anonym.to?http://www.ifpi.org/co … -guide.pdf
this document describes 2 different SID codes:
1. IFPI xxxx - Mould code (like for PSX - completely useless, imho http://redump.org/disc/1155/)
2. IFPI Lxxx - Mastering code (like here - indeed associated with master)
so likely those Mastering codes could be used to determine an Audio CD offset as F1ReB4LL hypothize,
but other than that they would provide no further information, imho.
adding those codes for every Mixed Mode CD to current db would make them unsearchable and difficult to access
and would only increase noise.
if their only purpose for us is to be used as Audio CD mastering equipment identifier,
maybe it's beter to keep an Mastering code -> Offset relation table instead

edit:
my Saturn CDs. last two are Dreamcast.
ther's some matches and some new ones
it's interesting that those Mould codes actually still somewhat hint on offset
(also it seems like Sega pressed good half of CDs on a single machine?..)
so we could make an table that would associate two first digits from Mould codes with corresponding Mastering codes
and 2nd table that would list offsets for each Mastering code with their frequencies.

N/A
Offset: 18  (= 12345 ?)
3Q02        T-  32510GP- 02369   A
3Q0C        T-  3107GP-  01161   A
Offset: 222 (= L221 or L223 ?)
3901        GS- 9005P-   00268A  2A2   C 4Y

12345
Offset: 18
3Q0D        GS- 9140P-   01434   A
3Q0C        T-  27903GP- 01716   C

L221
Offset: 222
3901        T-  1505GP-  00295   1M2   C 52

L223
Offset: -607
3928        GS- 9066P-   00550   2M4   C 5Y
Offset: 0
N/A         T-  17401GP- 00547   1M1   C 5Y
3902        T-  20610GP- 01841A  13MB2 C 79
3904        T-  31101GP- 01156   2M2   C 6Y
3904        T-  7612GP-  00741   2MM1  C 63
3904        T-  20205GP- 01087   1MM1  C 6X
3905        GS- 9134P-   01373   2M1   C 71
3905        T-  26405GP- 00800   4MM1  C 65
3905        T-  15035GP- 02199   1M6   C 82
3907        T-  1202GP-  00715   2M3   C 62
3908        GS- 9084P-   01101   2MB1  C 6X
3910        T-  27907GP- 02368   1M1   C 88
3910        GS- 9168P-   01946   3MM1  C 7X
3911        GS- 9138P-   01459   1M3   C 73
3912        T-  20106GP- 02075   1M1   C 7Z
3913        GS- 9097P-   01195B  23MB2 C 81
3914        T-  15035GP- 02200   2MB2  C 82
3915        GS- 9133P-   01313A  11MM1 C 6Z
3916        T-  15035GP- 02201   1MM1  C 82
3925        T-  26405GP- 00801   3MM1  C 65
3925        GS- 9037P-   00958   8MB7  C 74
3925        GS- 9037P-   00959   9MB8  C 75
3925        GS- 9096P-   00915   1M5   C 67
3926        T-  4507GP-  02008   1MC2  C 7Y
3927        T-  4502GP-  00698   1M7   C 62
3938        T-  20612GP- 02239A  10MM1 C 84
3965        T-  20106GP- 02076   4MM1  C 7Z
3979        GS- 9097P-   01195   2MB3  C 6Y
3980        T-  9522GP-  01654   1MB3  C 76
3984        T-  15035GP- 02202   2M1   C 82
Offset: 222
3901        GS- 9039P-   00348   5MM1  C 55
3901        GS- 9039P-   00348   4M7   C 56
3901        GS- 9015P-   00298   3B2   C 52
Offset: 1176
3905        T-  9517GP-  01435   1MM1  C 72

L231
Offset: 666
4011        T-  15009GP- 00899-  P1C   V
4011        T-  13306GP- 01007-  P1C   V
4011        T-  2103GP-  00887-  P1C   V
4021        GS- 9129P-   01412-  P3C   V
4011        T-  30001GP- 01272-  P1C   V
Offset: 672
4111        T-  20301GP- 01276-  P3C   V
4011        GS- 9169P-   02229-  P1C   V
Offset: 1254
4011        T-  14301GP- 01281-  P2C   V
4011        T-  17004GP- 01052-  P1C   V
4011        GS- 9169P-   02230-  P1C   V
4011        T-  35504GP- 02298-  P1C   V
4011        GS- 9034P-   00693B- P1C   V
4011        T-  14304GP- 01751-  P1C   V
4011        GS- 9194P-   02221-  P1C   V
Offset: 1260
4011        GS- 9101P-   01012A- P1C   V

L237
Offset: 390
4001        T-  13301GP- 00418-  P1K   V
4011        GS- 9051P-   00697-  P1K   V
4011        GS- 9159P-   01823-  P1K   V
4011        T-  14301GP- 01280-  P2K   V
4011        T-  14304GP- 01750-  P1K   V
4011        T-  14304GP- 01752-  P1K   V
4011        GS- 9194P-   02222-  P1K   V
4011        T-  30001GP- 01270-  P2K   V
4011        T-  30001GP- 01271-  P1K   V
4011        T-  30001GP- 01273-  P1K   V
4011        T-  5305GP-  01098-  P1K   V
4011        T-  13322GP- 02013-  P1K   V
Offset: 396
4011        GS- 9169P-   02228-  P1K   V
Offset: 684
4011        T-  15025GP- 01461-  P1K   V
4011        GS- 9079P-   00579B- P2K   V
4011        GS- 9057P-   00416A- P2K   V
4011        GS- 9099P-   01150-  P1K   V
4011        T-  2103GP-  00886-  P1K   V
4011        T-  22101GP- 01013-  P1K   V
4011        GS- 9050P-   00611-  P1K   V
4011        GS- 9126P-   01302-  P1K   V
Offset: 1860
N/A         T-  1301GP-  00299-  P1K   V
4011        GS- 9013P-   00310-  P3K   V
Offset: 2154
N/A         GS- 9001P-   00259-  P1K   V
N/A         T- 10601GP-  00258-  P3K   V

------------ Dreamcast ------------

L262
Offset: 13
4429        610-7817-0332 MT B03

L046
Offset: 13
6-5-19-NL    MK-51049-0160SS EMI CD HOLLAND @ 6

When we discussed about IFPI in past months, I said quite similar things of yours, Themabus. I suggested to add another field for IFPI.
"Ring code" + "IFPI code" =  "cd matrix"

It seems to me, anyway and again, that IFPI code as to do with mastering and not with sega catalogue.

My patch requests thread
--------------------------------

then i second that.
indeed ring code would bee needed at least to keep duplicates out.
it wouldn't help for my audio CDs at least at first tho - they have completely different IFPIs or haven't got them at all,
but as it gets larger it would become more and more useful.

edit:
btw her's an neat excel db with Mould codes -> Countries -> Manufacturers
http://www.redbrick.dcu.ie/~griffin/ifpi.html
we could use a part of that information

F1ReB4LL, how can you fix and determine if a sector is data or audio without a real cd? (Gale Racer is clear, but the other?) At least an explanation before fixing, I always said that there was no hint that those gaps are wrong (Gunbird and Whizz) so why did you fix them? There are new hints that those gaps are wrong?

My patch requests thread
--------------------------------

I have Gunbird. About Whizz - judged from your original sub. Original entries are preserved, so there's nothing fatal, I can switch them at any moment, if you give me enough proof.