it is a different error now
PX-716A
PX-760A
and the logs https://www.mediafire.com/file/9oj3vbc4 … 60.7z/file
51 2019-05-16 19:28:48 (edited by xTMODx 2019-05-16 19:30:15)
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
with _mainError.txt
https://ufile.io/76zmfz0o
without _mainError.txt
https://www.mediafire.com/file/xl7c12s6 … ut.7z/file
54 2019-05-17 12:19:16 (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?
- iR0b0t
- Administrator
- Offline
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 2019-05-18 07:08:08 (edited by Jackal 2019-05-18 07:08:26)
sarami wrote:
Also fixed.
Fixed where? And what about the wrong track01 size? 
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:74new 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:7459 2019-05-18 11:30:36 (edited by xTMODx 2019-05-18 11:31:08)
Jackal wrote:
sarami wrote:Also fixed.
Fixed where? And what about the wrong track01 size?
he send me the link with pm but he queoted it here http://www.mediafire.com/file/eq80y20l9 … st.7z/file
60 2019-05-19 05:58:44 (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 2019-05-19 18:33:59 (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
63 2019-05-25 06:43:31 (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.
- iR0b0t
- Administrator
- Offline
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" BINARYBut 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.
- iR0b0t
- Administrator
- Offline
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-332133The 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:74The 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
69 2019-05-25 12:28:26 (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 2019-05-26 08:51:45 (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 lengthWhy 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 
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