You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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.
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):
but in the _disc.txt I see:
whereas the standard TOC a few lines later appears fine:
Compare this to lines from redumper's output:
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 eithermm:ss:00
ormm: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 thePLBA
,PFrame
, and/orPSec
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
Log files
Redumper
DiscImageCreator
The text was updated successfully, but these errors were encountered: