Search options (Page 5 of 32)

Ok but my questions about the timestamp? Is there no way to predict the seed?

This is what a DIC cuesheet should look like now:

REM SESSION 01
FILE "dump (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00
FILE "dump (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    INDEX 00 00:00:00
    INDEX 01 23:07:05
FILE "dump (Track 3).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74
FILE "dump (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74

I think we are in agreement that the Redump site can store the complete cuesheet, but it should only include the REM SESSION lines in the download .cue (and exclude the REM LEAD-OUT, REM LEAD-IN, REM PREGAP because they are standard values that should be the same always)

REM SESSION 01
FILE "dump (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
REM SESSION 02
FILE "dump (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    INDEX 00 00:00:00
    INDEX 01 23:07:05
FILE "dump (Track 3).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74
FILE "dump (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74

@sarami did you receive the Bleemcast discs? http://forum.redump.org/topic/21597/how … ast-discs/

About the timestamps: https://www.epochconverter.com/ldap

DiscImageCreator also decodes the filestamps from DMI and SS, see outputScsiCmdLogforDVD.cpp
and from XDVDFS: execScsiCmdforFileSystem.cpp

Example from http://redump.org/disc/6024/:

DMI:
2005/03/30 20:54:46

SS:
Timestamp of authoring: 2005/03/29 21:07:14
Timestamp of unknown: 2005/03/29 18:38:08

volDesc:
Image creation time: 2005/03/30 02:38:16

I guess it's strange that the image creation date is later than the other timestamps. But this would give a time range of ~8 hours that we could try for brute forcing (if this is even possible).

Of course it's possible that either the dump is corrupt or the ss.txt is bad. Plz paste the contents of the ss.txt.

Can you also use xboxregen on the 2002 FIFA World Cup "cleaned" ISO and confirm it restores to the original hashes?

I will do more tests tomorrow night.

Hi,

great job! 3 questions:

- Is there only 1 seed value for the entire disc? So it shouldn't take long to brute force every disc once they are supported?
- Does nNASOS also fill with "JUNK" pattern, or something else?
- I tried 2 random games (Crimson Skies - High Road to Revenge (USA) (En,Fr,De,Zh,Ko) + Tony Hawk's Pro Skater 2x (USA) ), but it couldn't find a seed value. So just this 1 game is supported for now?

Nobody likes your naming scheme @F1ReB4LL .. The first posts and examples were clear. You are always criticizing me for messing up things, but this is where you are messing up. Adding fictional titles and parts and creating huge and ugly filenames that don't comply with No-Intro standards.

Just an example of how wrong the naming is:

F1ReB4LL filename (completely ignoring the disc title):
World Soccer Winning Eleven 6 + World Soccer Winning Eleven 2002 (Japan) (Demo of [PS2] World Soccer Winning Eleven 6 + [PSX] World Soccer Winning Eleven 2002)

Proper filename (IMO):
World Soccer Winning Eleven 6 + World Soccer Winning Eleven 2002 (Japan) (Promotion DVD)

or alternatively (but as argued before, I think it's better to put it in Disc Title and leave only game titles in Title field):
World Soccer Winning Eleven 6 + World Soccer Winning Eleven 2002 - Promotion DVD (Japan)

I'm not gonna touch any other Audio-CD's. It's not my mess.

You lost me there

I only see 2 solutions:

1. Completely define the area between the sessions in the cuesheet, so that tools can use the MSF lengths in the cuesheet to determine the amount of sectors to generate, without any assumptions or hardcoded values in software. This means that REM PREGAP should be included.

2. Assume that the area between the sessions is always the same and let tools use hardcoded values. So for the gap between the first 2 sessions, assume that LEAD-OUT is always 01:30:00 and LEAD-IN 01:00:00 and PREGAP 00:02:00. If we make these assumptions, then the REM LEAD-OUT and REM LEAD-IN lines are no longer needed and only the REM SESSION lines will suffice.

That looks ugly.. why not just go with REM PREGAP 00:02:00? Everybody keeps ignoring this solution.

Ok, according to this document, the area between Session 1 and 2 should always be: http://web.mit.edu/kolya/sipb/afs/root. … ADME.multi
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00

(= 11400 sectors total)

and subsequent sessions should have:

REM LEAD-OUT 00:30:00
REM SESSION 0?
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00
(= 6900 sectors total)

It would be nice to confirm this from an official document (Philips' "Multisession Compact Disc Specification")