Ok, a release for Argentina with 12 tracks has been submitted with the disc IDand some artwork
I caused the issue by using two CD drives, one that is capable of receiving C2 error information and one that is not…
Picard sees 12 tracks when the CD is in the non-C2 capable drive and submits a disc ID that has 12 tracks and matches the release. EAC sees 12 audo tracks and a 13th one that it calls “Datatrack”. it is not a data track as defined by the MB style guide.
If I look at it in the windows file explorer (with autoplay turned off!) it’s actually a folder with the copy control software in it, a player and an uninstaller:
If I use the C2-capable CD drive, the same CD appears to have only 8 audio tracks to EAC and Picard (looking at the URL). Submitting this disc ID does not match with a 12 track release…and the error message that started this adventure appears. So that’s the number of tracks problem sorted out!
I think this C2 stuff is something to do with the copy control software. PITA!
When I rip the CD with EAC, I’m getting no errors but no other entries in the AR database to match against…
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:34.42 | 0 | 16091
2 | 3:34.42 | 4:11.33 | 16092 | 34949
3 | 7:46.00 | 3:36.42 | 34950 | 51191
4 | 11:22.42 | 2:52.28 | 51192 | 64119
5 | 14:14.70 | 3:31.40 | 64120 | 79984
6 | 17:46.35 | 3:48.05 | 79985 | 97089
7 | 21:34.40 | 4:01.07 | 97090 | 115171
8 | 25:35.47 | 3:50.05 | 115172 | 132426
9 | 29:25.52 | 3:21.53 | 132427 | 147554
10 | 32:47.30 | 4:02.57 | 147555 | 165761
11 | 36:50.12 | 4:27.03 | 165762 | 185789
12 | 41:17.15 | 3:48.07 | 185790 | 202896
13 | 47:37.22 | 26:20.53 | 214297 | 332849
Range status and errors
Selected range
Filename E:\inprogress\kt\KT Tunstall - Eye To The Telescope.wav
Peak level 99.0 %
Extraction speed 14.9 X
Test CRC BC6AFC6E
Copy CRC 1C0CCCB1
Copy OK
No errors occurred
AccurateRip summary
Track 1 cannot be verified as accurate (confidence 54) [AD8A6D20], AccurateRip returned [96873D74] (AR v2)
Track 2 cannot be verified as accurate (confidence 58) [10DB93C8], AccurateRip returned [B8E2550B] (AR v2)
Track 3 cannot be verified as accurate (confidence 62) [62F00039], AccurateRip returned [9841C041] (AR v2)
Track 4 cannot be verified as accurate (confidence 61) [76FFEAB9], AccurateRip returned [1D4C829E] (AR v2)
Track 5 cannot be verified as accurate (confidence 55) [1C551E57], AccurateRip returned [75A8552C] (AR v2)
Track 6 cannot be verified as accurate (confidence 61) [B0E52182], AccurateRip returned [D7F73A11] (AR v2)
Track 7 cannot be verified as accurate (confidence 57) [E49CFB93], AccurateRip returned [340D19D5] (AR v2)
Track 8 cannot be verified as accurate (confidence 60) [21D25CAE], AccurateRip returned [1EF58083] (AR v2)
Track 9 cannot be verified as accurate (confidence 60) [3A5A16D0], AccurateRip returned [1A672C20] (AR v2)
Track 10 cannot be verified as accurate (confidence 64) [EB5ABB00], AccurateRip returned [2D979629] (AR v2)
Track 11 cannot be verified as accurate (confidence 57) [6D1E4513], AccurateRip returned [A68312E0] (AR v2)
Track 12 cannot be verified as accurate (confidence 61) [B01A693E], AccurateRip returned [42B094CD] (AR v2)
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database
End of status report
---- CUETools DB Plugin V2.1.6
[CTDB TOCID: gDspqAAvURxE2S9.Jueukuz575Y-] found
Submit result: insufficient quality
Track | CTDB Status
1 | ( 0/2872) No match
2 | ( 0/2872) No match
3 | ( 0/2872) No match
4 | ( 0/2872) No match
5 | ( 0/2872) No match
6 | ( 0/2872) No match
7 | ( 0/2872) No match
8 | ( 0/2872) No match
9 | ( 0/2872) No match
10 | ( 0/2872) No match
11 | ( 0/2872) No match
12 | ( 0/2872) No match
==== Log checksum 16411595C947E9D9218185F07EAFF52ED7798136F8A8E8E7774E6625DE76619D ====
Thanks to all for your help.
Watch out for those C2 capable drives.
Now you have added the discID, don’t forget to hit the “set track durations” bit on the DiscID page. That tweaks the values to thousandths of second.
Nice… I learnt something there. Now need to check what my main ripping drives are doing. I think they are behaving… (Interesting: I see I have one of each type)
These “copy protection CDs” are often breaking the “Is this a real CD?” rules anyway. (Red Book?) It is why you never see a CD logo on them.
Yeah, tracks 13 and 14 seem to show the same 26:20 time as you had. So I guess this Release could just be deleted. Or massaged with a large hammer and then merged into another Enhanced one.
I agree… looks like it was meant to be a copy controlled cd like mine - Edit #45367002 - MusicBrainz
This edit is trying to add data track incorrectly wrt the guidelines.
I think it is only different due to a disc ripper reading it in another variation of wrong. Just another “not really a CD” doing what it is supposed to and confusing a CD rip tool.
I suggest we Nuke it from Orbit, only way to be Sure…
Not “the done thing” according to guidelines. So we have to pull it apart bit by bit, then merge it into something once it fits. Delete the bogus discID, then delete the bad “data tracks”… once shaped up clean it can be merged into something it closest fits.
There is no remove option. We must merge. Any form of ability to delete is a figment of your imagination…
I’ve submitted deleting edits for the disc id and the medium, but can’t seem to remove the bogus tracks. Am I correct in concluding that I have to wait for the two edits to complete before the track list can be edited?
Trailing data tracks are not part of the disc ID. Submit your disc ID directly from the CD, not the EAC log (which doesn’t tell about which track is a data tracks).
The disc ID in your case should habe only 12 tracks.
UPDATE: I tested the EAC log myself: Actually Picard is able to detect the data track here and the disc ID would match the 12 track releases. But this was only fixed in Picard 2.8.2, so don’t use any older version to handle this disc ID and you should be fine. For reference, this is the proper disc ID:
I was submitting from Picard and the CD directly. I was not using the EAC log. It was the EAC display that indicated that there was an 13th track. It called it “Datatrack”. It did not say it was of type data track. This caused confusion on my part (and I think @IvanDobsky )
Yes, agreed, but as I tried to explain above, when reading the CD in a drive with C2 error capability it shows to have only 4 audio tracks. Picard (version 2.8.5) generates the URL below to open MusicBrainz with 4 tracks in it:
I believe the difference in the number of audio tracks is caused by the copy protection techniques being used which is messing up the reading of the CD by the CD drive. EAC shows 4 and 12 audio tracks in the corresponding drives as well. So, this is not a Picard or EAC problem.
I did not realise that the URL contained the number of tracks, @jesus2099 explained… A minor improvement to Picard would be to display the number of tracks it has read from the CD has on the error screen. I assumed it was 13 due to the EAC display, but I did not understand it was 4.
