• Registered: 2009-03-02
  • Posts: 22

I noticed Fighter Maker (http://redump.org/disc/3246/) has a 3 second pregap.  I am assuming that resizing the data track for this game is the same process as that used for a 2 second pregap, and that you just change the command line:

RESIZE -r -352800 "Track 01.bin"

to

RESIZE -r -529200 "Track 01.bin"

How do you pad the audio track for this game, since "pregap.bin" I found in a Castlevania thread here is only 352800 bytes?


My other question is about PS1 games that have 2 data tracks, like No One Can Stop Mr. Domino (http://redump.org/disc/2823/) and Street Fighter Alpha 3 (http://redump.org/disc/508/).  Is the same process used for dumping the 2nd track as is used for the first track (Extract RAW Data (2352 bytes/block) (*.bin, *.iso))?  And does the 2nd track need to be padded with the pregap.bin file?

I didn't see any other threads asking about this so hopefully I'm not asking something that was already asked before.

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

AKUMA™ wrote:

How do you pad the audio track for this game, since "pregap.bin" I found in a Castlevania thread here is only 352800 bytes?

This pregap.bin file is a simple dummy file of 352800 bytes, for 3 seconds simply create a dummy file of 529200 bytes and use this instead! Same Principe is for other pregap sizes.

AKUMA™ wrote:

My other question is about PS1 games that have 2 data tracks

Yes, extract the second track as the first one, but you can't simply use here the dummy pregap, because it is not a audio data, and the second data track contains data in this section and you have to move thus 2 seconds from the end of the first track to the beginning of the second. You better use "reMove" tool for this operation, it works fine smile

And, you must be sure that this gap data is actual a pregap and not postgap, we would also need the subchannels to find it out...

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

If you have to dump a real disc, do as follow:

1) padding single data track with 0x00, on command promp:

psxt001z ---gen pregap.bin "file_size"

where "file_size"=bytes needed (352800, 529200, etc.), then

copy /b pregap.bin+track02.bin new_track02.bin

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.).

Instead if you have to fix an image, simply take a look at the following thread where there's everything:
http://forum.redump.org/topic/3620/p2pt … -tutorial/
http://forum.redump.org/topic/3959/dc-t … -tutorial/

My patch requests thread
--------------------------------
  • Registered: 2009-03-02
  • Posts: 22

Cool!  Thanks a lot.  I wasn't aware of those tools and threads, or that psxtools had other options besides just the FIX option (the readme file doesn't mention any commands other than ones that got removed).  I'll have a look at that stuff n maybe I can make that ps1redumper I posted a little better.:)

  • Registered: 2006-12-24
  • Posts: 3,847

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.

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

I think you forget the scrambled data, FIRE !

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • Registered: 2006-12-24
  • Posts: 3,847

Oh smile My drive actually refuses to read the audio pregap as a part of the datatrack, so I don't have such a problem and kinda forgot about it smile Anyway, simply padding everything with zeroes isn't a very good idea, imo.

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

hehe smile
yes, i know, we have just to check before if there is some not 00 data, and i forgot to mention it roll

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

There's some PSX disc dumped with data in first audio track pregap?

My patch requests thread
--------------------------------
  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

look at "South Park Rally" http://forum.redump.org/topic/3190/done … sles02690/

and also check my BIG QUESTION topic smile http://forum.redump.org/topic/4142/a-big-question/

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • Registered: 2008-08-07
  • Posts: 441

During my very interesting journey of converting p2p to redump, I've come upon some audio tracks with data in the pregap.  Usually the first couple of bytes in a sector that I see so much on the data tracks.  I thought they were fine since they matched, so I never said anything.  Also, I've come upon some audio tracks with the Riff header in them (which AFAIK means wave format), but they also matched the database so I didn't say anything.  I forgot which dumps were those though.. sad

If its not normal, let me know so I could make a note of it from now on.

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

iR0b0t wrote:

look at "South Park Rally" http://forum.redump.org/topic/3190/done … sles02690/

This is something most than common for all other systems, I talk about first audio track (only PR reports data if there's something or if you simply dump with wrong offset, EAC pad everything with 0x00) and expecially about discs with only one audio track the ones you normally pad.

EDIT: DJoneK, the same, what you found is normal.

My patch requests thread
--------------------------------
  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

EAC don't pad anything, just try to set the offset wrong and you will have some data from previews track in the pregap

DJoneK wrote:

I've come upon some audio tracks with the Riff header in them

that's ok, and not "a faik" AFIAK lol

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

iR0b0t wrote:

EAC don't pad anything, just try to set the offset wrong and you will have some data from previews track in the pregap

First audio track is always padded, EAC cannot read data.

My patch requests thread
--------------------------------
  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

Rocknroms wrote:

First audio track is always padded, EAC cannot read data.

let me try it now...

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

Seems, you've right! neutral

That's also the reason why I had sometimes different data in EAC and PR, but I also used always PR results, because they had same data as the original disc !

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

iR0b0t wrote:

Seems, you've right! neutral

That's also the reason why I had sometimes different data in EAC and PR, but I also used always PR results, because they had same data as the original disc !

You have also to check if that is real data of garbage (example the string that was found in some SS/MCD discs).

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