CUERipper: Incorrect TOC generated in log with AVCD

[daihakken]

When ripping audio tracks from AVCDs (CD with video/data tracks in the first few tracks of the discs and the rests are audio), CUERipper rips it perfectly, except the TOC is generated with a deformed length of track 1:

CUERipper:

    Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 | 954434:45.23 |         0    | 4294956397   
        2  |  0:06.52 |  8:08.26 |       502    |    37127   
        3  |  8:15.03 |  4:25.73 |     37128    |    57075   
        4  | 12:41.01 |  4:40.00 |     57076    |    78075   
        5  | 17:21.01 |  3:53.01 |     78076    |    95551   
        6  | 21:14.02 |  3:59.15 |     95552    |   113491   
        7  | 25:13.17 |  3:50.56 |    113492    |   130797   
        8  | 29:03.73 |  3:48.33 |    130798    |   147930   
        9  | 32:52.31 |  3:19.55 |    147931    |   162910   
       10  | 36:12.11 |  5:09.38 |    162911    |   186123   
       11  | 41:21.49 |  3:51.13 |    186124    |   203461   
       12  | 45:12.62 |  4:24.20 |    203462    |   223281   
       13  | 49:37.07 |  4:26.23 |    223282    |   243254   
       14  | 54:03.30 |  5:12.32 |    243255    |   266686   
       15  | 59:15.62 |  3:16.36 |    266687    |   281422

EAC:

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 |  0:06.52 |         0    |      501   
        2  |  0:06.52 |  8:08.26 |       502    |    37127   
        3  |  8:15.03 |  4:25.73 |     37128    |    57075   
        4  | 12:41.01 |  4:40.00 |     57076    |    78075   
        5  | 17:21.01 |  3:53.01 |     78076    |    95551   
        6  | 21:14.02 |  3:59.15 |     95552    |   113491   
        7  | 25:13.17 |  3:50.56 |    113492    |   130797   
        8  | 29:03.73 |  3:48.33 |    130798    |   147930   
        9  | 32:52.31 |  3:19.55 |    147931    |   162910   
       10  | 36:12.11 |  5:09.38 |    162911    |   186123   
       11  | 41:21.49 |  3:51.13 |    186124    |   203461   
       12  | 45:12.62 |  4:24.20 |    203462    |   223281   
       13  | 49:37.07 |  4:26.23 |    223282    |   243254   
       14  | 54:03.30 |  5:12.32 |    243255    |   266686   
       15  | 59:15.62 |  3:16.36 |    266687    |   281422 

Tested 4 discs and it is consistent across this kind of discs. Discs with data track at the rear side is unaffected. This behaviour is exhibited in both CUERipper-style and EAC-style log.

P.S.: I also notice gap detection differences between EAC and CUERipper, is that a bug or intentional behaviour?
P.S.2: May I ask where I should request drive support and suggest features?

[c72578]

@daihakken Thanks for your report.
Could you please also post the following info:

• Version of CUERipper:
• Used drive:

[daihakken]

@c72578
Of course!

• Version of CUERipper: 2.2.2 (from the official site)
• Used drive: TEAC DV-W28EAD / PIONEER BD-RW BDR-S08

I was solely using TEAC DV-W28EAD, and now I have tested with another drive on hand, the TOC is still abnormal:

Used drive  : PIONEER BD-RW   BDR-S08   Adapter: 1  ID: 0
(...)
TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 | 954434:45.23 |         0    | 4294956397   
        2  |  0:06.52 |  1:53.35 |       502    |     9011   
        3  |  4:32.12 |  3:55.60 |     20412    |    38096   
        4  |  8:27.72 |  4:02.31 |     38097    |    56277   
        5  | 12:30.28 |  3:51.16 |     56278    |    73618   
        6  | 16:21.44 |  4:32.73 |     73619    |    94091   
        7  | 20:54.42 |  3:44.64 |     94092    |   110955   
        8  | 24:39.31 |  3:33.28 |    110956    |   126958   
        9  | 28:12.59 |  4:26.44 |    126959    |   146952   

Again, the audio data is the accurately ripped, which matches the results from CTDB.

Edit: both drives are using Laptop IDE > USB / SATA > USB adapter respectively. Unfortunately, I don't have access to SATA/IDE ports directly to isolate if it's a USB-related problem.

[c72578]

@daihakken So far, this issue could not be reproduced with disks, where the first track is a data track.
Did you have a chance in the meantime to read one of the affected disks on a drive, which is directly connected (without the USB adapter)?
It looks like an overflow occurs, when determining the End sector of the first (data) track.