The tool reports the start values as offsets from 150 frames from the start of the disc. The first track is the weird one. It looks like the start sector is supposed to be 75 frames, which is against spec where it should be at least 150 frames from the start. So when when the tool tries to read it it wraps around to 16777141 (which happens to be the two’s compliment value of an unsigned 24-bit value of -75). That in turn messes up the calculation of the duration values for the first track.
My other drive seems to see this bad value and silently fixes it by setting it to 0:
My question here: Should I submit a DiscID for this disc? There isn’t really a way to properly calculate the Disc ID for the first one and the first one, while it works, isn’t technically the “correct” one.
A copy of Rumours. It looks like a very early CD pressing going by CD matrix (just 3010-2 SRC-07, no SID codes) but I can’t find any exact match for it on MB/Discogs.
Ah it’s musicbrainz-isrcsubmit python program.
It uses mediatools.exe for extracting ISRC without duplicates, but it uses the official libdiscid (the same as Picard) for disc ID.
But what version does it use now?
There was no updates since long time by @JonnyJD.
Both isrcsubmit and Picard seem to both “fix” the issue by setting the first track start position to frame 150, which makes it so submission works but judging by the tool’s output it doesn’t look like it’s “correct”.
EDIT: More info, it looks like isrcsubmit and Picard actually both use libdiscid for getting the TOC/DiscID, and isrcsubmit only used mediatools.exe for ISRC codes. libdiscid seems to use a Windows API to get the TOC, while mediatools.exe executes raw SCSI commands on the drive to get them. It’s possibly the Windows API is also doing that handling of bad TOCs as well, but raw SCSI commands do not.
To be clear, we are talking of python musicbrainz-isrcsubmit, or isrcsubmit.py, with libdiscid, which has more TOC bugs fixed than the older isrcsubmit.exe.
The tool allows submitting the “fixed” DiscID just fine, and due to how DiscIDs are generated it may not be possible to calculate one for the actual corrupted one. I only made this topic because it looks like the actual TOC may be different/corrupted and was wondering if it still made sense to submit that to the DB.
Hi,
to your second drive, the output looks pretty normal to me. The reserved 150 sectors at the start are usually not displayed. Perhaps the first drive cannot read the CD correctly, or it is confused by the 32 sector silent pregap to track one (usually to be found on SRC discs).
You should at least try to submit. If it’s somehow corrupted, it can be removed, but I guess it will be fine, if you use your second drive.
