[DONE] Discussing the multisession cue

[xTMODx]

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

[xTMODx]

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

[Jackal]

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.

[iR0b0t]

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" ?

[Jackal]

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

[iR0b0t]

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.

[xTMODx]

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

[xTMODx]

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



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

[Jackal]

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?

[sarami]

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

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.