Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disc with bad TOC crashes CUERipper #236

Closed
ToadKing opened this issue Dec 17, 2022 · 3 comments · Fixed by #325
Closed

Disc with bad TOC crashes CUERipper #236

ToadKing opened this issue Dec 17, 2022 · 3 comments · Fixed by #325

Comments

@ToadKing
Copy link
Sponsor

ToadKing commented Dec 17, 2022

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
Copy link
Collaborator

c72578 commented May 13, 2024

@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) ;

StartSector = Get32(offset + 4) ;

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));
        }

public uint Get32(int offset)

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);
        }

public byte Get8(int offset)

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 added a commit to c72578/cuetools.net that referenced this issue May 19, 2024
In rare cases, the first track is reported to start at a frame lower
than 150. This leads to an incorrect TOC entry. In such cases, the
StartSector is assigned a wrong value of e.g. 16777141 (16777216 - 75).

- Set StartSector to 0 in cases,
  where a value larger than (16777216 - 150) is reported.
- Fixes gchudov#236
- See also:
  https://hydrogenaud.io/index.php/topic,125779.0.html
@c72578
Copy link
Collaborator

c72578 commented May 19, 2024

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

@ToadKing
Copy link
Sponsor Author

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.

@c72578 c72578 closed this as completed in 2987a5c May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants