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

Incorrect last track LBA/AMSF on full TOC for some audio CDs #291

Open
periodic1236 opened this issue Oct 9, 2024 · 2 comments
Open

Incorrect last track LBA/AMSF on full TOC for some audio CDs #291

periodic1236 opened this issue Oct 9, 2024 · 2 comments

Comments

@periodic1236
Copy link

periodic1236 commented Oct 9, 2024

Version
32 bit, AnsiBuild, 20241001T225411

Describe the bug
I used DiscImageCreator (via MPF) to rip a large collection of audio CDs using my Plextor PX-W5224TA (FW 1.04).

Comparing dumps made by DIC and redumper (build_415), the FULL TOC interpreted by DIC often lists a wrong starting address for the final audio track, on some but not all CDs.

For instance, on one particular disc (CATALOG 0811576032186), the binary TOC shows index 01 for track 12 (ISRC QZES61930014) to be at LBA 145109 (0x236d5):

0050 : 00 01 E2 C2 00 10 0B 00  00 01 FC 6C 00 10 0C 00   ...........l....
0060 : 00 02 36 D5 00 10 AA 00  00 02 68 EF 00 00 00 00   ..6.......h.....
          ^^ ^^ ^^

but in the _disc.txt I see:

========== FULL TOC ==========
<4 lines omitted>
  Session 1, Ctl 0, Adr 1, Point 0xa2,      Lead-out, AMSF 35:07:60 (LBA[157935, 0x268ef])
<10 lines omitted>
  Session 1, Ctl 0, Adr 1, Point 0x0b,      Track 11, AMSF 28:57:31 (LBA[130156, 0x1fc6c])
  Session 1, Ctl 0, Adr 1, Point 0x0c,      Track 12, AMSF 32:16:00 (LBA[145050, 0x2369a])

whereas the standard TOC a few lines later appears fine:

========== TOC with pregap ==========
<10 lines omitted>
  Track 11, Ctl 0, Mode 0, Index0 130025, Index1 130156
  Track 12, Ctl 0, Mode 0, Index0 144978, Index1 145109

Compare this to lines from redumper's output:

  track 12 { audio }
    index 00 { LBA: [144978 .. 145108], length:    131, MSF: 32:15:03-32:16:58 }
    index 01 { LBA: [145109 .. 157934], length:  12826, MSF: 32:16:59-35:07:59 }

The AMSF is being truncated to a full second, or in some cases even to a minute boundary (e.g. instead of mm:ss:ff it becomes either mm:ss:00 or mm:00:00). The split binary tracks aren't affected (so the dumps are still bit-for-bit correct and identical across tools) but the incorrect time from the FULL TOC is making its way into the CCD file, where the PLBA, PFrame, and/or PSec for the last entry of the session are wrong. So while not a show stopper IMO, if I use the .ccd/.img for anything (emulation, playback, etc.), track N could appear to start in the pregap or even up to a minute into track N-1 instead of where it should.

This does not occur with every audio CD I've ripped, but does so with enough frequency for me to discover it (see below). I found the discrepancy when diff'ing a .ccd against ones I previously obtained from ImgBurn and CloneCD for the same disc in my collection. I don't have access to another compatible Plextor drive, nor multiple pressings for any given CD, but it is certainly reproducible for the same disc/drive/host.

I also tested with multiple versions dating back to DIC 20181022, and the issue was present in all. Sometime (I did not check through the commit history) between 20181022 and 20190627, the LBA scheme in the log reporting was fixed so that LBA 0 aligned with AMSF 00:02:00 instead of MSF 00:00:00, but the last track still had the wrong relative address, while other tracks were good. I tried to run a build from 2017 but it refused to detect my Plextor as supporting opcode 0xD8. It seems to me the bug has existed for quite a long time, but I can't be sure it isn't related to some idiosyncratic setup detail, as I am relatively new to this ecosystem.

Screenshots
I scraped the last line of the FULL TOC section in the _disc.txt log file from all the DIC audio CD dumps I processed, and took a simple random sample of 10 such lines. As you can see, a majority of last tracks have suspicious AMSF values (indicated with trailing arrows; I also confirmed they are wrong). I can provide info about those discs if needed, but this seems pervasive enough that I suspect the cause can be identified easily.

Samples
  Session 1, Ctl 0, Adr 1, Point 0x0e,      Track 14, AMSF 54:19:64 (LBA[244339, 0x3ba73])
  Session 1, Ctl 0, Adr 1, Point 0x1f,      Track 31, AMSF 75:00:00 (LBA[337350, 0x525c6])  <--
  Session 1, Ctl 0, Adr 1, Point 0x07,      Track  7, AMSF 36:00:00 (LBA[161850, 0x2783a])  <--
  Session 1, Ctl 0, Adr 1, Point 0x16,      Track 22, AMSF 70:29:74 (LBA[317099, 0x4d6ab])
  Session 1, Ctl 0, Adr 1, Point 0x08,      Track  8, AMSF 38:21:00 (LBA[172425, 0x2a189])  <--
  Session 1, Ctl 0, Adr 1, Point 0x0c,      Track 12, AMSF 32:16:00 (LBA[145050, 0x2369a])  <--
  Session 1, Ctl 0, Adr 1, Point 0x0c,      Track 12, AMSF 48:54:00 (LBA[219900, 0x35afc])  <--
  Session 1, Ctl 0, Adr 1, Point 0x10,      Track 16, AMSF 43:14:00 (LBA[194400, 0x2f760])  <--
  Session 1, Ctl 0, Adr 1, Point 0x05,      Track  5, AMSF 45:50:24 (LBA[206124, 0x3252c])
  Session 1, Ctl 0, Adr 1, Point 0x1c,      Track 28, AMSF 72:13:00 (LBA[324825, 0x4f4d9])  <--

Log files
Redumper
DiscImageCreator

@periodic1236
Copy link
Author

I just found #42; will need to read up on this issue further.

@saramibreak
Copy link
Owner

It seems to me the bug has existed for quite a long time

Try to dump it by CloneCD and compare CloneCD's ccd and DIC's ccd.

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

No branches or pull requests

2 participants