Invalid discids or TOCs with data track size applied to the last track


#1

While searching for and fixing my latest screw-ups I happened on several Beatles enhanced CDs where there were invalid (wrongly calculated) discids. These are easy to spot since the album length is around 30 minutes greater than the other discids. These are Enhanced CDs with a data track and at least 2 different submitters have done this. I removed the “please please me” one with a note as to why. There is at least one more, but I suspect all the 2009 Beatles remasters may have these and maybe other artists. I did not remove or manually search for any others without guidance, but maybe a script would do this better. The “Abby Road” release c93e1d4c-89fa-3139-9c65-8542a39f07d1 still has this invalid discid 26I8wRa_RZ.QoVd5_EKFuSNL2ws- , I did not look any further. My edit for “please please me” https://musicbrainz.org/edit/49849854


#2

thanks, discid and ISRC’s applied


#3

Continuing the discussion of bad discids, I thought jesus2099 might like this one as he has talked about it a couple of times and I did not truly understand it till a couple of days ago. It does appear that “faulty” software back in the Windows XP days was generating TOC’s for Enhanced CDs with the last track being 2 seconds longer than it should be.

I actually run an app like that on XP in a virtual machine on my Windows 10 box. I keep it around since it is a grandfathered Gracenote media library (no developer or support any longer). I sort of detected the difference earlier when I created this original note, there was something different about my TOC and the isrcsubmit TOC, but was not worried about it at the time.

Two days ago I finished the adding of my collection to the Database and getting RIDs for all my releases and uploading discids and ISRCs. I start running reports on my data and found my 43 discids generated from the TOC’s of the old library program and those generated from my EAC logs were different and they all were Enhanced CD’s. Running more verification’s and outputting a log with both discids and their TOCs showed this to be true.

I had added 10 bad discids, 6 to existing releases, and 4 to new releases I created. Since I track everything I do I knew where those were and removed the 6 “I created” from the existing releases and the 4 releases that I created. for the 4 releases I created I added the correct discid, and for the other 6 the correct discid was already in place “for the release I was using”.

More investigation shows that other releases in the same release groups have the 2 second longer discid. Out of the 43 Enhanced CD’s I have 39 have a combination of both the correct discid and the 2 second longer discid in the database, depending on the release and the release group.

The question is should I do anything about this? Maybe! Is the problem of faulty software gone and a cleanup will fix things or will some of them just get re-added by faulty software still out there? Also can I guarantee that there was not a CD that had a 2 second longer last track whether it was Enhanced or not. I cannot prove conclusively that the discid is bad. Also we we talking about 43 of the albums I know about, not the total that exist.

I am not sure what is more harmful, going through and profiling what we think are bad and removing them, or just leaving them alone knowing that they are there and that they may never get a match to them.

Thoughts? Questions?


#4

Yes, please use newer software to generate and submit this data.

As long as people use the old and faulty software it can always be used to add broken data.

No, you can’t be 100% sure. If there was a specific bug that always led e.g. to a discrepancy of an exact number of sectors (a CD has 75 sectors per second of audio) it might be rather unlikely that a random different pressing has also this exact discrepancy.

On the other hand I am not sure we should remove the faulty ones. They can still be used for identify a CD (e.g. someone using an older player with a faulty disc ID calculation), and that’s the primary use case of disc IDs.


#5

I had already remove my 10 faulty discids before I wrote the note. For some time now I have been think about writing something to analyze the different discids applied to a release to determine if they are correct. I have had move a discid to another release in the release group and remove discids that had no place to be moved to, and those were the easy ones to detect.


#6

Wasn’t it 2:30 mistake on last audio track rather than 2:00?


#7

In this case its 150 frames (2 seconds), and there are 30-40 of these discids that I know of. It appears that some libraries/programs added in a extra 150 frames (or did not remove) into the leadout calculation. I thought about investigating into it more, but without the Bluebook spec I have to assume the MB code is correct. A couple of examples follow only difference is 2 seconds in the leadout:

Yellow Submarine by The Beatles (enhancedCD)


https://musicbrainz.org/cdtoc/VFAlg43lwHij7kaPeDWP8Y1Zf88-
https://musicbrainz.org/cdtoc/Gz3JMBDT6PGPUtzVvF_dTOwvgYk- (leadout 150 frames longer)
Full TOC: 1 13 178885 150 12129 27466 37283 51631 80507 97848 108403 121919 132171 148423 158875 168833
Full TOC: 1 13 179035 150 12129 27466 37283 51631 80507 97848 108403 121919 132171 148423 158875 168833

Piano Man by Billy Joel (enhancedCD)


https://musicbrainz.org/cdtoc/wt2i3PZBT.fSAL4s354jWeIpjYU-
https://musicbrainz.org/cdtoc/6zVULNJvE3f.a8GPBee.l_wffBo- (leadout 150 frames longer)
Full TOC: 1 10 196074 150 19374 44783 59704 74219 99893 114559 132214 148279 163287
Full TOC: 1 10 196224 150 19374 44783 59704 74219 99893 114559 132214 148279 163287


#8

If the track count is the same and if the correct disc ID is there and applied, I would have kept the wrong disc ID as well, so that anyone with buggy soft could still lookup the CD.


#9

I thought about it, but decided I would remove my bad entries because I knew they were bad. I left the others alone since I could not prove they were bad, they are not hurting anything and to some degree may be helping.