Wrong analysis of TOC

[Kurist2010]

When you load the bin+cue corresponding to the cue sheet below, the start position and total length of track 2 will be notified with a shift of the pregap (2 seconds). The file size of image.bin is 605908128 bytes.

image.cue

FILE "image.bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
  TRACK 02 MODE1/2352
    PREGAP 00:02:00
    INDEX 01 01:06:19

For CD-ROM drives (this is correct)

Lead out - Red Book 57:18.64 - High Sierra 03EEE4       
Track 01 - Red Book 00:02.00 - High Sierra 000000 - CD/DA
Track 02 - Red Book 01:10.19 - High Sierra 0013FF - DATA

For v2024.04.01 (this is wrong)

Lead out - Red Book 57:16.63 - High Sierra 03EE4D       
Track 01 - Red Book 00:02.00 - High Sierra 000000 - CD/DA
Track 02 - Red Book 01:08.19 - High Sierra 001369 - DATA

[morio]

@Kurist2010 the current implementation of bin/cue doesn't support pregap. What are you using to grab the the track information? It would be helpful to use to test implementation of pregap support.

[Kurist2010]

If you use CDP, a free software for MS-DOS of Japan's NEC PC-9801, you can display the TOC relatively easily. It can be obtained from the following, but separate hardware is required to operate it.

See here. This is a Japanese site.

[PetteriAimonen]

I'm looking into this, so far I have managed to reproduce the issue using a CD-R burned from the .cue.

cdrtools readcd -fulltoc shows for physical CD-ROM drive:

Using dev=4,0,0.
Read  speed:  7056 kB/s (CD  40x, DVD  5x, BD  1x).
Write speed:  7056 kB/s (CD  40x, DVD  5x, BD  1x).
TOC len: 59. First Session: 1 Last Session: 1.
01 10 00 A0 00 00 00 00 01 00 00 
01 14 00 A1 00 00 00 00 02 00 00 
01 14 00 A2 00 00 00 00 39 12 40 
01 10 00 01 00 00 00 00 00 02 00 
01 14 00 02 00 00 00 00 01 0A 13 
00 00 00 00 00 00 00 00 00 00 00 
Lead out 1: 257764

With ZuluSCSI 2024-08-22:

Using dev=0,1,0.
TOC len: 59. First Session: 1 Last Session: 1.
resid: 1
01 10 00 A0 00 00 00 00 01 00 00 
01 14 00 A1 00 00 00 00 02 00 00 
01 14 00 A2 00 00 00 00 39 10 40 
01 10 00 01 00 00 00 00 00 02 00 
01 14 00 02 00 00 00 00 01 08 13 
00 00 00 00 00 00 00 00 00 00 00 
Lead out 1: 257614

with the 0x0A vs. 0x08 corresponding to the error.

The data reading from the drive accordingly starts from byte offset 10178560 instead of 10485760. Data itself appears correct, just in wrong position.

[PetteriAimonen]

This should work now, test build available here: https://github.com/ZuluSCSI/ZuluSCSI-firmware/actions/runs/11049237148/artifacts/1981362565

[Kurist2010]

Test builds worked as expected.