mirror of
https://github.com/aaru-dps/Aaru.git
synced 2026-02-04 00:54:33 +00:00
CDs with audio tracks not matching Redump/DiscImageCreator. #237
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @RibShark on GitHub (Sep 25, 2018).
Prerequisites
Check and fill as appropiate:
Description
When dumping (certain?) discs with audio tracks, the output does not match that of DiscImageCreator which is used by redump.org.
Exact command line used:
DiscImageChef.exe dump-media -i F: -f -o RayColl.cueExpected behavior:
When using the
comparecommand and comparing to a dump made by DiscImageCreator, the sectors should be identical.Actual behavior:
On a disc (Rayman Collector), the number of sectors in track 1 according to DiscImageCreator is 120371. DiscImageChef reports the same disc as having 120521 sectors in track 1. When running the
comparecommand against the two dumps, the image is identical until sector 120371. 120371-120372 are reported as being different, 120373-120521 have different sizes (2048 bytes in DIChef, 2352 in DICreator) but are otherwise identical. All sectors from 120542 onwards are reported as being different.In the log created by DICreator, "Skipping 512 blocks from errored block 120352." appears between reading track 1 and 2.
The dump on redump has a 2:01 pregap on track 2, which according to redump's wiki means that it contains a scrambled data sector. This may well be the cause of the issue.
@claunia commented on GitHub (Sep 25, 2018):
Your report is three part.
First part,
This is due to @saramibreak's tool applying the drive offset I don't yet do, but will do, so moved to #198
They are audio sectors but as they are marked as data sectors by the TOC, that's where the size difference (and the drive read error on them) comes from. Just aesthetical, so nothing to fix there
@saramibreak's tool uses the pregap to set the track borders, I do according to the TOC, as the rainbow book says it should be done (and that's why the drive failed, as it tries to read the pregap sectors and data, they don't pass the ECC, so the drive returns error status, and trimming them the drive doesn't care because they don't have a data sync mark). Nonetheless I'll revise the rainbow books because my memory may fail 😄 and if applicable reopen the issue.