51 (edited by xTMODx 2019-05-16 19:30:15)

it is a different error now
PX-716A
https://abload.de/img/1fejhi.jpg

PX-760A
https://abload.de/img/11hk6f.jpg

and the logs https://www.mediafire.com/file/9oj3vbc4 … 60.7z/file

sorry : http://www.mediafire.com/file/eq80y20l9 … st.7z/file

Dump is complete now but only track 2 is matching crc from the db.
In the cue file track 2 is Audio but should be Data/Mode 2.
_mainError.txt is 1,67gb big i will upload with it and without it
Dumped with PX-716A

https://abload.de/img/17vk9o.jpg

with _mainError.txt
https://ufile.io/76zmfz0o

without _mainError.txt
https://www.mediafire.com/file/xl7c12s6 … ut.7z/file

54 (edited by Jackal 2019-05-17 12:22:51)

It's this disc btw: http://redump.org/disc/39048/

The DIC Track01 .bin isn't divisible by 2352, so I guess there's still a bug somewhere.

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 AUDIO
    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
REM LEAD-OUT 01:30:00
FILE "dump (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74

The LEAD-OUT seems to be in the wrong place also?

xTMODx wrote:
sarami wrote:

Some were fixed. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
But perhaps all bug haven't fixed yet.

thanks it produce same result as the previous release

Thanks.

Jackal wrote:

The LEAD-OUT seems to be in the wrong place also?

Also fixed.

----
Some dumpers dump multisessional disc and lead-out length's is 6750 (01:30:00)
http://forum.redump.org/post/69590/#p69590
REM LEAD-OUT and REM LEAD-IN is still needed?

sarami wrote:

Some dumpers dump multisessional disc and lead-out length's is 6750 (01:30:00)
http://forum.redump.org/post/69590/#p69590
REM LEAD-OUT and REM LEAD-IN is still needed?

I would say YES. There is no guarantee that some discs won't be using non-standard ones.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

57 (edited by Jackal 2019-05-18 07:08:26)

sarami wrote:

Also fixed.

Fixed where? And what about the wrong track01 size? wink

sarami wrote:
xTMODx wrote:
sarami wrote:

Some were fixed. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
But perhaps all bug haven't fixed yet.

thanks it produce same result as the previous release

Thanks.

Jackal wrote:

The LEAD-OUT seems to be in the wrong place also?

Also fixed.

----
Some dumpers dump multisessional disc and lead-out length's is 6750 (01:30:00)
http://forum.redump.org/post/69590/#p69590
REM LEAD-OUT and REM LEAD-IN is still needed?

oh wait i think i missed something. I only compared the .dat file and they looks same. but now i have checked the cues and it fixed some stuff.

old cue

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 AUDIO
    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
REM LEAD-OUT 01:30:00
FILE "dump (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74

new cue

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

59 (edited by xTMODx 2019-05-18 11:31:08)

Jackal wrote:
sarami wrote:

Also fixed.

Fixed where? And what about the wrong track01 size? wink

he send me the link with pm but he queoted it here http://www.mediafire.com/file/eq80y20l9 … st.7z/file

60 (edited by sarami 2019-05-19 05:59:09)

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

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

62 (edited by xTMODx 2019-05-19 20:05:29)

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

63 (edited by Jackal 2019-05-25 07:14:20)

Yeah the dump itself seems to be fine now, but there's still 1 problem with the cuesheet: http://redump.org/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? http://redump.org/disc/40793/

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

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:

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

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

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

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.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Jackal wrote:

Yeah the dump itself seems to be fine now, but there's still 1 problem with the cuesheet: http://redump.org/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? http://redump.org/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

disc http://redump.org/disc/40793/

https://abload.de/img/13zj76.jpg

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

69 (edited by Jackal 2019-05-25 12:52:04)

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: http://forum.redump.org/topic/21597/how … 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?

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.

71 (edited by Jackal 2019-05-26 09:19:39)

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

sarami wrote:
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

Why not to read that area and measure the lead-out/lead-in/pregap sizes according to subs? Plextor allows to read all those sectors, I guess?

F1ReB4LL wrote:
sarami wrote:
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

Why not to read that area and measure the lead-out/lead-in/pregap sizes according to subs? Plextor allows to read all those sectors, I guess?

I get it from subch. From 1st 0xaa to 1st 0x00 and 0xa0 is lead-out length.

sarami wrote:

I get it from subch. From 1st 0xaa to 1st 0x00 and 0xa0 is lead-out length.

I've misunderstood your "LEAD-IN length = 11400 - 150 - LEAD-OUT length" formulas, then smile I've thought you just assume the lead-out/lead-in sizes.

http://www.mediafire.com/file/eq80y20l9 … st.7z/file
changed: LEAD-IN length = 1st LBA of 1st track of 2nd session - 1st LBA of lead-in of 2nd session