redump.info Forum

Posted: **Sun May 19, 2019 3:12 am**

dumped with new version, it still doesnt match the db, here the log files
https://www.mediafire.com/file/r4l14zjv … /2.7z/file

Posted: **Sun May 19, 2019 12:33 pm**

sarami wrote:Uploaded test ver. (download's link is same.)

download link is updated and it produce the hash from the db now. thanks

uploaded the log files, can someone check the log files if everything is fine now... the big "_mainError.txt" bug is fixed too

https://www.mediafire.com/file/jqyi2yvj … /3.7z/file

Posted: **Sat May 25, 2019 12:43 am**

Yeah the dump itself seems to be fine now, but there's still 1 problem with the cuesheet: https://redump.info/disc/39048/

Session 1: 0-92629
Session 2: 104030-332133

The cuesheet has:

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
FILE "dump (Track 2).bin" BINARY
TRACK 02 MODE2/2352
INDEX 01 00:00:00
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

The area between the 2 sessions is 92630 - 104029 = 11400 sectors = 02:32:00, so the Track 2 pregap of 2 seconds is still unaccounted for in the cuesheet. How to define it, since it's not included in the dump? PREGAP 02:00 / REM PREGAP 02:00?

@xTMODx do you have this disc also still? https://redump.info/disc/40793/

Or does anyone else have some more discs to test? Just to confirm that there's no weird stuff going on.

Posted: **Sat May 25, 2019 2:35 am**

Jackal wrote:the Track 2 pregap of 2 seconds is still unaccounted for in the cuesheet. How to define it, since it's not included in the dump? PREGAP 02:00 / REM PREGAP 02:00?

We don't use PREGAP command in our normal cuesheets. But regardless of that, using this command with or without REM addition within the TRACK command would be incorrect because the track file does not include the pregap data. IMO an additional REM command should be placed like that:

Code: Select all

REM LEAD-IN 01:00:00
REM ...
FILE "dump (Track 2).bin" BINARY

But as what command exactly?...

We could of course increase the REM LEAD-IN value for that corresponding pregap length, but it would be technically incorrect.

Is there such a thing as "REM RUN-IN" ?

Posted: **Sat May 25, 2019 2:41 am**

No harm in using REM PREGAP then? it's clear that any REM elements are not included in the dump.

Posted: **Sat May 25, 2019 2:45 am**

I don't know, as for myself i see the REM element as a commented out CODE which would be usually at the exact same place.

Posted: **Sat May 25, 2019 5:13 am**

Jackal wrote:Yeah the dump itself seems to be fine now, but there's still 1 problem with the cuesheet: https://redump.info/disc/39048/

Session 1: 0-92629
Session 2: 104030-332133

The cuesheet has:

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
FILE "dump (Track 2).bin" BINARY
TRACK 02 MODE2/2352
INDEX 01 00:00:00
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
The area between the 2 sessions is 92630 - 104029 = 11400 sectors = 02:32:00, so the Track 2 pregap of 2 seconds is still unaccounted for in the cuesheet. How to define it, since it's not included in the dump? PREGAP 02:00 / REM PREGAP 02:00?

@xTMODx do you have this disc also still? https://redump.info/disc/40793/

Or does anyone else have some more discs to test? Just to confirm that there's no weird stuff going on.

yea i have it i will dump it later today

Posted: **Sat May 25, 2019 5:38 am**

disc https://redump.info/disc/40793/

logs https://www.mediafire.com/file/ygz7l70d … s1.7z/file

Posted: **Sat May 25, 2019 6:28 am**

Ok, this disc has the same thing, also:

REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00

Same also for the Bleemcast discs: /viewtopic.php?t=16855 … ast-discs/

But again, 11400 sectors between the 2 sessions, which means that 2 seconds are undefined in the cuesheet.

@sarami, is DIC really measuring the LEAD-IN and LEAD-OUT length, or are they predetermined?
And what does FFFFFFFFFFFFFFFFFFFFFFFF in subchannels signify? The Bleemcast discs had 135 sectors with FF, so I assumed this indicated the pregap length, but according to the measurements, it should be 150 sectors.

REM PREGAP detection should also be added to DIC then. And I don't know what to do with cases like Bleemcast, where the pregap contains relevant data. Including this data in the dumps would conflict with already established standards?

Posted: **Sat May 25, 2019 9:48 pm**

Jackal wrote:is DIC really measuring the LEAD-IN and LEAD-OUT length, or are they predetermined?

LEAD-OUT length = 1st LBA of lead-in of 2nd session - 1st LBA of lead-out of 1st session
LEAD-IN length = 11400 - 150 - LEAD-OUT length

Jackal wrote:what does FFFFFFFFFFFFFFFFFFFFFFFF in subchannels signify?

It's channel P. P is a flag bit that indicates the start of a track. It's almost 2s (150 sectors), but it's not necessarily 2s.

redump.info Forum

[DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue

Re: [DONE] Discussing the multisession cue