• Registered: 2008-02-10
  • Posts: 144

New Dump:
no libcrypt
2 second gap indicated in subcode.

I dumped the tracks without the gap and the crcs match the db (i.e. the data is fine)

With the gap:
hashes:

rom ( name "Street Fighter Alpha 3 (U) (Track 1) [SLUS-00821].bin" size 484081584 crc d5e20d47 md5 c232562dced4e65664a9c5410e6e57a3 sha1 ec98188f53dbfa08a59d89c981e9ca68b7f1748e )
    rom ( name "Street Fighter Alpha 3 (U) (Track 2) [SLUS-00821].bin" size 43248576 crc e0078f93 md5 76acbc2b9390e485edd7af7a15630bbf sha1 491e2ad423ce9a554a4f0ccd8ea22a66ca1d6fa5 )

Cue:

FILE "Street Fighter Alpha 3 (U) (Track 1) [SLUS-00821].bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00
FILE "Street Fighter Alpha 3 (U) (Track 2) [SLUS-00821].bin" BINARY
  TRACK 02 MODE2/2352
    INDEX 00 00:00:00
    INDEX 01 00:02:00

If you have the db dump it can be easily corrected with themabus' fantastic reMove.exe program over at http://forum.redump.org/viewtopic.php?id=2559

reMove  "Track 1.bin" "Track 2.bin"

What does "Offset Status: EAC" mean?

  • Registered: 2006-12-23
  • Posts: 4,137

It means it was dumped with the old EAC method.. thanks for verifying and fixing, but could you include the write offset also plz?

  • Registered: 2008-02-10
  • Posts: 144

Since they're both data tracks is it really needed in this case? Anyway, via px_d8.exe, the offset is +2

4 Reply by NiKoTiN (edited by NiKoTiN 2008-04-25 21:29:04)

  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

DELETED! Oops smile

5 Reply by NiKoTiN (edited by NiKoTiN 2008-04-25 21:31:32)

  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

huygens wrote:

2 second gap indicated in subcode.

I think it's postgap, not pregap
The postgap is present at both tracks

Whether there can be a data-track without a postgap?

  • Registered: 2008-02-10
  • Posts: 144

Is there any way to tell the difference in subcode? There should be some standard way to dump two data track games.

So should it be:

Postgap:
dump tracks directly with isobuster
indicate track 01 postgap in cue (how can you indicate a postgap in cue?)

or

Pregap:
move 150 sectors from track 01 to track 02
indicate track 02 pregap in cue.

would either of these approaches give you the same data and subcode once mounted / burned?

7 Reply by Sotho Tal Ker (edited by Sotho Tal Ker 2008-04-27 16:51:06)

  • Registered: 2008-03-10
  • Posts: 355

you can use "PREGAP" and "POSTGAP" to specify different gaps.
The difference between

INDEX 00 00:00:00
INDEX 01 00:02:00

and

PREGAP 00:02:00
INDEX 01 00:00:00

is small, and can lead to identical or different results. Read on. smile

The difference between PREGAP/POSTGAP and INDEX 00/01:
pregap/postgap insert artificial silence. Makes not difference if the pregap/postgap consists of 0x00 only.
INDEX 00 writes from the start of the file, so if there are non 00 bytes in the pregap they will be written
INDEX 01 is the only INDEX that is written in the TOC of the disc.

(Oh, yeah, you can start the INDEX 01 at 00:02:00 for the second example, too. Thus the first 2 seconds of the data will be replaced with artificial silence on writing)

  • Registered: 2008-02-10
  • Posts: 144

Thank you, I wondered about the difference between those. So in this case postgap couldn't be used? I ask because in this case it's a gap between data tracks and therefore contains headers.

The entry for the game seems to be messed up now. The second data track has been changed to my dump (with pregap), but the first data track and cue are still the same.

  • Registered: 2008-03-10
  • Posts: 355

what happens if you extract the full CD in raw mode? Does it match the tracks extracted on each own and merged together? It should.

For single data track games extracting full CD and extracting Track1 only will give you the exact same file, thats why i ask

As another testcase you could write back the image to a CD-RW and compare the subcode with subcode analyzer.

I personally think, data tracks do not need a pregap, but I could be wrong.

  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

huygens, I examined subchannels of some images from the Internet with two data tracks, result such:
Street Fighter Alpha 2 (U) [SLUS-00258] & Street Fighter Zero 2 (J) [SLPS-00415] - have no track 2 pregap and track 1 have postgap
Breath of Fire IV (U) [SLUS-01324] - track 2 have 2sec pregap, but track 1 have no postgap
It's strange...
The developer of all these games CAPCOM

huygens, can you upload the subchanel (*.sub) and CCD produced in CloneCD of your Street Fighter Alpha 3 disc?

11 Reply by huygens (edited by huygens 2008-04-27 19:59:17)

  • Registered: 2008-02-10
  • Posts: 144

Sotho Tal Ker: the full image dumped in raw mode does match the merged tracks.

NiKoTiN:

here's the ccd and sub.

http://www.mediafire.com/?bj1nbcy3nua

It appears if CloneCD can be trusted it's a track 2 pregap.

  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

Yes, it's the truth, a track 2 has a pregap big_smile

Moders, please update also a track 1 hashes and a track 2 pregap field (00:02:00)

rom ( name "Street Fighter Alpha 3 (U) (Track 1) [SLUS-00821].bin" size 484081584 crc d5e20d47 md5 c232562dced4e65664a9c5410e6e57a3 sha1 ec98188f53dbfa08a59d89c981e9ca68b7f1748e )

13 Reply by iR0b0t (edited by iR0b0t 2008-04-28 07:26:02)

  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,727

after fixing the image to new hashes, psxt001z shows follows:

Sector 205667: Form 1 Subheader/Data/EDC/ECC
...
Sector 205816: Form 1 Subheader/Data/EDC/ECC

that are the last 150 sectors, should they not to be fixed?

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

It should not be fixed. It not a postgap, these are sectors of data! The gap is moved to the beginning of the Track 2

  • Registered: 2006-12-23
  • Posts: 4,137

I'm really confused about these discs.. I dumped Street Fighter Alpha 2: http://redump.org/disc/4055/ using perfectrip and it gave me a data track 352800 bytes smaller than isobuster.. the audio track was 352800 bytes larger..

But perfectrip always assumes a 2 seconds pregap on the first audio track afaik, and I think it's not normal that the data track postgap would show errors on psxt001z?

I also don't think clonecd is very accurate with subchannels and if you used .sub files from downloaded images that also isn't safe!

I hope ThemaBus will read this post.. how can we be sure that all dumps with a Data track02 are correct?

The best method to me seems using Isobuster on both tracks.. but are the gaps correct then?

  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

Vigi wrote:

The best method to me seems using Isobuster on both tracks..

I so think too. I think all data tracks must have the postgap.
But what about that: subchannel indicates pregap (sectors countdown)

  • Registered: 2006-12-23
  • Posts: 4,137

I don't know.. all I know is that psxt001z gives errors (cdmage doesn't) at the end of the first data track if it's shortened (and the 2nd data track has pregap added)

43248576 bytes (shortened datatrack or perfectrip dump?):

Breath of Fire IV - Utsurowazaru Mono (J) [SLPS-02728]
Street Fighter Alpha 3 (U) [SLUS-00821]
Street Fighter Zero 2 (J) [SLPS-00415]
Street Fighter Zero 3 (J) [SLPS-01777]
Street Fighter Collection (E) (Disc 2)

42895776 bytes (-352800):

Breath of Fire IV (U) [SLUS-01324]

If the data track should indeed be 352800 bytes smaller and it SHOULDN'T be fixed, then all these dumps should be checked, because some may be --fixed after all.

Maybe track02 is a file that's linked on the first data track and we can use the filesystem size to know the correct size?

  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

Vigi wrote:

Maybe track02 is a file that's linked on the first data track and we can use the filesystem size to know the correct size?

Yes, it's a file 'ZNULL.DAT'.
In Street Fighter Zero 3 (J) [SLPS-01777] it starts @ 206005 sector after postgap/pregap (?)

  • Registered: 2006-12-23
  • Posts: 4,137

I've ripped the disc again using perfectrip at a lower speed.. I got no corrupt C2 pointers this time..

Now only Breath of Fire IV remains with the wrong data track size.. someone will have to redump/fix it.

Also, how can we be sure that the other dumps haven't been --fixed incorrectly?

edit: I just checked with cdmage and the 43248576 bytes track should be correct. The LBA of the ZNULL.dat file matches the track02 start when dumped properly (and track01 ends 1 sector before the first ZNULL.dat sector.

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

hi. i'm sorry, i won't be able to access my pc for quite some time so i can't verify anything.
i tried to write down of how i remember it ...sorry, it's a mess:
IsoBuster extracts tracks by TOC LBA..LBA, does not move gaps around so two successive data tracks will be as with gap=0 and track 01 + ..track n-1 + track n  should be full cd size, i guess PerfectRip maybe does manipulate gap, but i'm not sure.
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'm not really sure on this but i think some cds had the same gap stucture on sector level, but different in subcode - so one game can have let's say 300 sectors marked as pause right after data but other one will have only last 150, even though sectors are structured the same. i think it was half with edc/ecc, half - without.
psxt001z, i guess checks sectors to be empty at the end of track, because of that last bad sector, that's often on psx, but between two data tracks they frequently aren't empty (can be edc/ecc or data) so it would damage track, but ther's never bad sector anyway.
all cds i checked (mostly saturn) had pause in subcode between 2 data tracks (gap <> 0). i moved sectors marked as pause to next track. so the same sectors will be marked as pause again, independent of how theoretically gaps should be structured.
for PSX i did not --fix first track.

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • From: Moscow, Russia
  • Registered: 2007-10-10
  • Posts: 720

The checksums for Breath of Fire IV (U) [SLUS-01324] with the moved gap to the second track

    rom ( name "Breath of Fire IV (U) (Track 1) [SLUS-01324].bin" size 645066576 crc 29d0f94c md5 145a7d7ac3469fcb974bbb309ebd61b1 sha1 24be71b32aeb52a930bc08dccda5db61e904de8a )
    rom ( name "Breath of Fire IV (U) (Track 2) [SLUS-01324].bin" size 43248576 crc ed4f34b5 md5 c5f4302e3c783b0b9c22f15db7f6b6a9 sha1 dc0fa59967976a4e37315a6b63a7bbbc9536a85a )
  • Registered: 2006-12-23
  • Posts: 4,137

Actually, we checked BOF4 yesterday and it appeared to be correct. There wasn't a dummy file linked on the first track's filesystem like with other games (Street Fighter Alpha etc). But if Themabus thinks it should be different after checking, then that would make sense to me as well tongue

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

i'm sorry, i don't really know.  i remember xenogears also checking this game and found no pause in subcode (also he gives different crc for track 01, it's strange, but maybe he did --fix). but i myself always had this pause in such layout cds (also on japanese bof4 with CCD, like xenogears' subcode), but it does not mean much, i guess - i checked too few, maybe this really is special case or maybe it depends on drive+software used. i guess original would have to be rechecked again (better on Truman's CD Tool) to know for sure, i shouldn't have told xenogears to use ccd sad

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website