Weird TOC from CD

So I have this three days grace CD, it doesn’t say its “copy protected” anywhere on it, but I cannot submit the ID (Log In - MusicBrainz) as doing so returns:

Error message: The provided CD TOC is not valid. This is probably an issue with the software you used to generate it. Try again and please report the error to your software maker if it persists, including the technical information below.

The CD does play, sort of, but not fantastically - VLC gets freaked out after track 7 and EAC sees the CD like this:

Any ideas what might be going on?

1 Like

This release I assume: Release “One‐X” by Three Days Grace - MusicBrainz

Um… is there a scratch on the CD? There are two (or three) ways to get track boundaries. You can either trust what it says in the TOC… and for CD-PLUS cds, like this one, there is a second TOC after the Lead-Out section after the last audio track (Track 12 in this example)… The other way to find the track lengths, is to sequentially read the raw frames (forwards) through the entire audio program, and watch the P and Q subchannel data for what each frame claims to be (track number, track index, MM:SS:FF)

EAC has a configuration option for a couple of read methods like that. (Not all drives can do everything).

Um, but, yeah, it might just be a read error, interacting with a firmware bug in your CD drive…

Edit:
Oh yeah, I mentioned subcode reading, and scratchy CDs, because there is no error correction at all on the subcode data, and so the slightest scratch will garble it up. (Same with the ISRCs which live in the subcode channels too. Check if the ISRCs were malformed.)

4 Likes

Is it factory made silver? Or CD-R?

Back in the 90s I had tools that would let me look at what kind of sessions were burnt on a CD. No idea where I’d find them now though.

That looks like some kind of multi-session thing. Audio and data tracks being interspersed. Does VLC play tracks 10,11,12?

Normal Enhanced CD would be music CD with a data track on the end of it. That looks like it is doing a bit of both which is why the discID generation is failing due to being too weird.

What do you see when you look on the CD using File Manager? Do you find readable files?

Yeah - its a pressed CD, from Aussie. I’ve added a release entry for it now, but no scans yet (had to rebuild my PC over the weekend), https://musicbrainz.org/release/cbc23f75-1dea-456e-a729-2bea14e4f9e0

Nope, VLC just hits a brick wall once it reaches one of these tracks (gives me the buffering bar)

Yep this is what I thought that maybe it was some kind of very odd enhanced CD.

Normal data files like a readme and the video file

It’s not a perfect disc, but not that badly scratched

Could be the case, this is my “old reliable” drive that’s pushing 20 years old now. Gonna try it in another drive.

Edit - yep must be my “old reliable” drive being strange, as its fine in a newer DVD burner

I use the old TEAC because I often find this DVD burner doesn’t read properly either!

2 Likes

Can EAC rip those if you untick the odd ones?

The older drive is likely to be a higher spec than a new one. I think you probably have a CD where production people are trying to be clever. Probably to mess with the rippers. But sometimes to just have fun with the medium.

Does the new drive rip all those tracks okay? Can VLC play 10,11,12 now? Could well be firmware failing to deal with the multiple session.

I guess you have little Flash menus running 320x320 Quicktime videos when inserted in the PC.

Yep

Possibly yeah, that’s why I like it. It’s got a manufacture date of July 2000 - so a good few years before this CD was even thought about. That’s why I thought it was some kind of funny copy protection scheme, which it might still be, and raised it here as I don’t often encounter such CD’s.

It’s running now in EAC, will post results

Edit: the results


- CUETools DB Plugin V2.1.6 -

[CTDB TOCID: LGoKcaJ6HBDFQ05ZQ4ZeJ8TRToU-] found
Submit result: LGoKcaJ6HBDFQ05ZQ4ZeJ8TRToU- has been confirmed
Track | CTDB Status
  1   | (902/915) Accurately ripped
  2   | (907/915) Accurately ripped
  3   | (905/915) Accurately ripped
  4   | (906/915) Accurately ripped
  5   | (909/915) Accurately ripped
  6   | (907/915) Accurately ripped
  7   | (903/915) Accurately ripped
  8   | (902/915) Accurately ripped
  9   | (903/915) Accurately ripped
 10   | (901/915) Accurately ripped
 11   | (905/915) Accurately ripped
 12   | (897/915) Accurately ripped

_________________________________

This was a “quick and dirty” rip, not an accurate one but all the audio is clear, although a timing issue reported on track 1 (which could be due to the disc quality).

Maybe it was written as a multi-session disk with a slightly dodgy session.

Or it could just be the Old Reliable CD player is starting to get a bit fussy in its old age.

1 Like

It looks like a copy protected CD.

1 Like

9 posts were split to a new topic: About CD/DVD players for ripping

I vaguely recall that there was a copy protection scheme which used a bogus TOC on the second (or later) session… I mean, technically, this is literally how CDPlus itself works – that last data track is only mentioned in the second TOC (session). Older CD Players which don’t implement the Orange Book standards, don’t see anything after the lead out of “the first session”… And… the last session written to disc is considered the most current up-to-date TOC to be using for the disc – it’s supposed to include everything “currently visible” on the entire disc. This was intended for CD-RW, CD-MO, and CD-WORM drives and discs. The logical structure is literally: TOC1, stuff, LEAD-OUT1, TOC2, new stuff, LEAD-OUT, TOC3, even more, LEAD-OUT, etc.

Anyway, by design, the latter TOCs on the disc can be completely different from the first (Red Book standard) TOC, and so you can just lie about track lengths and offsets, and any drives which can read CD-RW discs, will believe the TOC in the last session.

4 Likes