Disc with bad TOC crashes CUERipper

[ToadKing]

Got a CD with this bad TOC:

TOC START
01      16777141        -16764801       -223530.680000
02      12340   19297   257.293333
03      31637   10065   134.200000
04      41702   14465   192.866667
05      56167   16435   219.133333
06      72602   15098   201.306667
07      87700   20255   270.066667
08      107955  16262   216.826667
09      124217  14733   196.440000
10      138950  17480   233.066667
11      156430  21905   292.066667
TOC END

The first track seems to start at frame 75 (tool reports offsets from frame 150, and 16777141 is -75 as a two's compliment 24-bit number) which is against spec. One of my drives reports this TOC as-is and CUERipper crashes when loading the disc info. Another drive I have seems to silently fix the bad TOC and works correctly.

Stacktrace of exception:

Exception Info: System.ArgumentException
   at CUETools.Codecs.Crc32.Combine(UInt32, UInt32, Int64)
   at CUETools.AccurateRip.AccurateRipVerify.Init(CUETools.CDImage.CDImageLayout)
   at CUETools.Processor.CUESheet.OpenCD(CUETools.Ripper.ICDRipper)
   at CUERipper.frmCUERipper.Lookup(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.ThreadHelper.ThreadStart(System.Object)

[c72578]

@ToadKing Thanks for the report and linking to it from: https://hydrogenaud.io/index.php/topic,125779.0.html

The issue concerning the wrong StartSector of track 01 is originating from here:

Bwg.Scsi\TocEntry.cs:77 StartSector = Get32(offset + 4) ; https://github.com/gchudov/cuetools.net/blob/f52b795a1ab336c49ac183d7dabe5f0305555059/Bwg.Scsi/TocEntry.cs#L77

Bwg.Scsi\Result.cs:151

        public uint Get32(int offset)
        {
            return (UInt32)((Get8(offset) << 24) | (Get8(offset + 1) << 16) | (Get8(offset + 2) << 8) | Get8(offset + 3));
        }

https://github.com/gchudov/cuetools.net/blob/f52b795a1ab336c49ac183d7dabe5f0305555059/Bwg.Scsi/Result.cs#L151

Bwg.Scsi\Result.cs:107

        public byte Get8(int offset)
        {
            if (offset >= m_size)
                throw new Exception("offset " + offset.ToString() + " is out side the range of the buffer");

            return Marshal.ReadByte(m_buffer, offset);
        }

https://github.com/gchudov/cuetools.net/blob/f52b795a1ab336c49ac183d7dabe5f0305555059/Bwg.Scsi/Result.cs#L107

Get8() reads m_buffer, which contains the SCSI reply, at the specified offsets. However, these bytes are wrong in case of track 01 of the reported CDs with a bad TOC.

The assignment of the value for the StartSector is a place to add a check and a correction in case of such TOC entries for track 01.

[c72578]

@ToadKing Please have a look at this PR, which contains a build for testing: #325

[ToadKing]

That build seems to work (CUERipper no longer crashes) but the first track definitely has some samples cut off from the start of the track. Not sure if that's something that can actually be read without overreading though.