You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 63 of 66)
Topics by F1ReB4LL User defined search
Posts found: 1,551 to 1,575 of 1,638
Rocknroms wrote:2) 2 consecutive data tracks, you have to calculate real pregap first, then use "remove":
remove -size="bytes_to_move" track01.bin track02.bin
where "bytes_to_move"=bytes of pregap (352800, 529200, etc.).
You can just always use this method, 2nd audio track pregap can also contain non-zero data, I don't think it's correct just to pad it with zeroes.
Actually, just a few secs 
Track Mode Flags Start Length
-----------------------------------------------------------------
01 DATA 4 00:00:00 ( 0) 01:58:00 ( 8850)
02 AUDIO 0 01:58:00 ( 8850) 32:20:32 (145532)
03 AUDIO 0 34:18:32 (154382) 00:15:28 ( 1153)
04 AUDIO 0 34:33:60 (155535) 00:14:55 ( 1105)
05 AUDIO 0 34:48:40 (156640) 00:11:62 ( 887)
06 AUDIO 0 35:00:27 (157527) 00:11:38 ( 863)
07 AUDIO 0 35:11:65 (158390) 00:10:52 ( 802)
08 AUDIO 0 35:22:42 (159192) 00:21:38 ( 1613)
09 AUDIO 0 35:44:05 (160805) 00:12:42 ( 942)
10 AUDIO 0 35:56:47 (161747) 00:12:10 ( 910)
11 AUDIO 0 36:08:57 (162657) 00:14:03 ( 1053)
12 AUDIO 0 36:22:60 (163710) 00:22:25 ( 1675)
13 AUDIO 0 36:45:10 (165385) 00:08:57 ( 657)
14 AUDIO 0 36:53:67 (166042) 00:17:05 ( 1280)
15 AUDIO 0 37:10:72 (167322) 00:11:30 ( 855)
16 AUDIO 0 37:22:27 (168177) 00:12:10 ( 910)
17 AUDIO 0 37:34:37 (169087) 00:13:08 ( 983)
18 AUDIO 0 37:47:45 (170070) 00:12:12 ( 912)
19 AUDIO 0 37:59:57 (170982) 00:17:35 ( 1310)
20 AUDIO 0 38:17:17 (172292) 00:14:45 ( 1095)
21 AUDIO 0 38:31:62 (173387) 00:11:45 ( 870)
22 AUDIO 0 38:43:32 (174257) 00:13:15 ( 990)
23 AUDIO 0 38:56:47 (175247) 00:24:20 ( 1820)
24 AUDIO 0 39:20:67 (177067) 00:15:13 ( 1138)
Leadout 39:36:05 (178205)
FILE "IMAGE.bin" BINARY
TRACK 01 MODE?/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
INDEX 00 01:58:00
INDEX 01 02:00:00
TRACK 03 AUDIO
INDEX 00 34:18:32
INDEX 01 34:29:47
TRACK 04 AUDIO
INDEX 00 34:33:60
INDEX 01 34:41:52
TRACK 05 AUDIO
INDEX 00 34:48:40
INDEX 01 34:54:47
TRACK 06 AUDIO
INDEX 00 35:00:27
INDEX 01 35:06:22
TRACK 07 AUDIO
INDEX 00 35:11:65
INDEX 01 35:18:07
TRACK 08 AUDIO
INDEX 00 35:22:42
INDEX 01 35:40:05
TRACK 09 AUDIO
INDEX 00 35:44:05
INDEX 01 35:52:47
TRACK 10 AUDIO
INDEX 00 35:56:47
INDEX 01 36:04:57
TRACK 11 AUDIO
INDEX 00 36:08:57
INDEX 01 36:18:60
TRACK 12 AUDIO
INDEX 00 36:22:60
INDEX 01 36:31:67
TRACK 13 AUDIO
INDEX 00 36:45:10
INDEX 01 36:49:15
TRACK 14 AUDIO
INDEX 00 36:53:67
INDEX 01 37:06:72
TRACK 15 AUDIO
INDEX 00 37:10:72
INDEX 01 37:18:27
TRACK 16 AUDIO
INDEX 00 37:22:27
INDEX 01 37:30:37
TRACK 17 AUDIO
INDEX 00 37:34:37
INDEX 01 37:43:45
TRACK 18 AUDIO
INDEX 00 37:47:45
INDEX 01 37:55:57
TRACK 19 AUDIO
INDEX 00 37:59:57
INDEX 01 38:13:17
TRACK 20 AUDIO
INDEX 00 38:17:17
INDEX 01 38:27:62
TRACK 21 AUDIO
INDEX 00 38:31:62
INDEX 01 38:39:32
TRACK 22 AUDIO
INDEX 00 38:43:32
INDEX 01 38:52:47
TRACK 23 AUDIO
INDEX 00 38:56:47
INDEX 01 39:12:32
TRACK 24 AUDIO
INDEX 00 39:20:67
INDEX 01 39:31:55
FILE "Track01.bin" BINARY
TRACK 01 MODE?/2352
INDEX 01 00:00:00
FILE "Track02.bin" BINARY
TRACK 02 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:00
FILE "Track03.bin" BINARY
TRACK 03 AUDIO
INDEX 00 00:00:00
INDEX 01 00:11:15
FILE "Track04.bin" BINARY
TRACK 04 AUDIO
INDEX 00 00:00:00
INDEX 01 00:07:67
FILE "Track05.bin" BINARY
TRACK 05 AUDIO
INDEX 00 00:00:00
INDEX 01 00:06:07
FILE "Track06.bin" BINARY
TRACK 06 AUDIO
INDEX 00 00:00:00
INDEX 01 00:05:70
FILE "Track07.bin" BINARY
TRACK 07 AUDIO
INDEX 00 00:00:00
INDEX 01 00:06:17
FILE "Track08.bin" BINARY
TRACK 08 AUDIO
INDEX 00 00:00:00
INDEX 01 00:17:38
FILE "Track09.bin" BINARY
TRACK 09 AUDIO
INDEX 00 00:00:00
INDEX 01 00:08:42
FILE "Track10.bin" BINARY
TRACK 10 AUDIO
INDEX 00 00:00:00
INDEX 01 00:08:10
FILE "Track11.bin" BINARY
TRACK 11 AUDIO
INDEX 00 00:00:00
INDEX 01 00:10:03
FILE "Track12.bin" BINARY
TRACK 12 AUDIO
INDEX 00 00:00:00
INDEX 01 00:09:07
FILE "Track13.bin" BINARY
TRACK 13 AUDIO
INDEX 00 00:00:00
INDEX 01 00:04:05
FILE "Track14.bin" BINARY
TRACK 14 AUDIO
INDEX 00 00:00:00
INDEX 01 00:13:05
FILE "Track15.bin" BINARY
TRACK 15 AUDIO
INDEX 00 00:00:00
INDEX 01 00:07:30
FILE "Track16.bin" BINARY
TRACK 16 AUDIO
INDEX 00 00:00:00
INDEX 01 00:08:10
FILE "Track17.bin" BINARY
TRACK 17 AUDIO
INDEX 00 00:00:00
INDEX 01 00:09:08
FILE "Track18.bin" BINARY
TRACK 18 AUDIO
INDEX 00 00:00:00
INDEX 01 00:08:12
FILE "Track19.bin" BINARY
TRACK 19 AUDIO
INDEX 00 00:00:00
INDEX 01 00:13:35
FILE "Track20.bin" BINARY
TRACK 20 AUDIO
INDEX 00 00:00:00
INDEX 01 00:10:45
FILE "Track21.bin" BINARY
TRACK 21 AUDIO
INDEX 00 00:00:00
INDEX 01 00:07:45
FILE "Track22.bin" BINARY
TRACK 22 AUDIO
INDEX 00 00:00:00
INDEX 01 00:09:15
FILE "Track23.bin" BINARY
TRACK 23 AUDIO
INDEX 00 00:00:00
INDEX 01 00:15:60
FILE "Track24.bin" BINARY
TRACK 24 AUDIO
INDEX 00 00:00:00
INDEX 01 00:10:63
Gaps match EAC ones.
amarok wrote:Yeah, good job indeed. I wonder what will happen when all PSX/PS2 games are dumped since most dumpers don't care that much about other systems. Impressive work anyway 
We'll start to dump subchannels 
Subs are needed, can't say anything without them.
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...
684-294=390, +684 and +390 are both very common values. Just a thought, though...
Update: hmm... VX010-J1-2F V IFPI L232 -- V usually means either +390 or +684... http://forum.redump.org/post/9124/#p9124
Update2: http://redump.org/disc/5107/ -- this one is probably +390 (00:02:00 and 00:01:74); http://redump.org/disc/4095/ -- probably also +390; http://redump.org/disc/5267/ -- maybe +666 (if it shares the same offset with the Game CD)...
http://redump.org/disc/5577 -- r09, could you check the ringcode?
All the gaps are 00:02:00 here.
Actually, you should choose any and tweak all the settings by yourself. Both "Read SubChannel Data from Data Tracks" and "Read SubChannel Data from Audio Tracks" should be checked.
CloneCD shows correct gaps in most cases, if you're still interested.
There is a pregap for the 2nd track, but it's after the main track (nope, it's not a postgap, first 150 sectors of the track are with index 01, the rest are with index 00), I don't know, how to understand this.
r09 wrote:As far as I know, if the offset is corrected the pregaps should be empty, so I think I'm doing something wrong, but I don't know what.
Can someone help me with this?
Nope, it's a usual thing with 0-write-offset CDs, so everything is correct.
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?
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...
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...
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: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?
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.
Talking about PCE - I'm looking at the Road Spirits sub. 'LH-18A1H' shows 00:04 gap for all the ingame CDDA tracks. 'PREMIUM' shows something different:
LH-18A1H wrote:01 03 01 03 25 56 00 06 26 61 EE 76
01 03 01 03 25 57 00 06 26 62 74 44
01 03 01 03 25 58 00 06 26 63 01 9C
01 04 00 00 00 04 00 06 26 64 B7 91
01 04 00 00 00 03 00 06 26 65 C0 64
01 04 00 00 00 02 00 06 26 66 5A 56
01 04 00 00 00 01 00 06 26 67 A4 A5
01 04 01 00 00 00 00 06 26 68 B8 C8
01 04 01 00 00 01 00 06 26 69 02 B8
01 04 01 00 00 02 00 06 26 70 6F 72
PREMIUM wrote:01 03 01 03 25 56 00 06 26 61 EE 76
01 03 01 03 25 57 00 06 26 62 74 44
01 03 01 03 25 58 00 06 26 63 01 9C
02 00 00 00 00 00 00 00 00 64 0D 57
01 03 01 03 25 60 00 06 26 65 6F 99
01 03 01 03 25 61 00 06 26 66 F5 AB
01 03 01 03 25 62 00 06 26 67 0B 58
01 04 01 00 00 00 00 06 26 68 B8 C8
01 04 01 00 00 01 00 06 26 69 02 B8
01 04 01 00 00 02 00 06 26 70 6F 72
I've tried to clean both - same result. Q-CRCs are correct for both, absolute MSFs are the same. I don't really understand, how it can be possible to get 2 different sequences of data (both correct) from the same sector. I can only suppose, that you've used different dumping tools for different drives and one of the tools has some weird error-correction algorithm, which involves regenerating fields and Q-CRCs...
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...
2Rocknroms: your drive has another disease. Most of your subs also have a similar issue (track02 index MSF offsets before and after the pregap). Most, but not all - seems you've used a different drive for some of them.
Cyberbots - Fullmetal Madness (J) (T-1216G) - bug
Gussun Oyoyo S (J) (T-26101G) - bug
Whizz (J) (T-36102G) - bug
Puzzle Bubble 2X (J) (T-1106G) - bug
Samurai Spirits - Amakusa Kourin (J) (T-3116G) - bug
Chibi Maruko-Chan no Taisen Puzzledama (J) (T-9507G) - bug
Gunbird (J) (T-14402G) - no bug
Kyutenkai (J) (T-1801G) - no bug
Can you put these subs somewhere? About multiple index ones -- seems, EAC has a serious bug with postgap detecting, checked my EAC-generated cues, some tracks have totally wrong indexes and last tracks postgaps are missing.
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).
There's always a random block (1-3 sectors, usually) after the track02 pregap taken from the earlier part of the CD, also there's the same sector before and right after that block.
01 02 00 00 00 03 00 05 56 04 -- pregap
01 02 00 00 00 02 00 05 56 05 -- pregap
01 02 00 00 00 01 00 05 56 06 -- pregap
01 02 00 00 00 00 00 05 56 07 -- 1st copy of this sector, Q-Index is 00
01 02 00 00 01 74 00 05 54 07 -- taken from the earlier part of the CD
01 02 00 00 01 73 00 05 54 08 -- taken from the earlier part of the CD
01 02 00 00 01 72 00 05 54 09 -- taken from the earlier part of the CD
01 02 01 00 00 00 00 05 56 07 -- 2nd copy of this sector, Q-Index is 01
01 02 01 00 00 01 00 05 56 08
There are also various offsets along the whole sub.
iR0b0t wrote:okay, i will use PX-760A to read the subs out, but which tool is the best for it?
i can also use cdreader
I'd like to see clonecd ones at first. Both clonecd and PR 100b ones would be even better.
Maybe these ones weren't read with Plextor. If he check his dumps at least twice on different drives and another one can read them, it's fine. But this particular one reads subchannels wrong and completely unsuitable for dumping.
iR0b0t's drive is busted, it's not able to read the subs correctly, all his dumps are suspicious now.
Posts found: 1,551 to 1,575 of 1,638