Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: A newbie needs clarifications about TOC reports (Read 2277 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

A newbie needs clarifications about TOC reports

Hi, first post here.
I recently learned about EAC and started using it.
Ripped a bunch of CDs, obviously after configuring AR and the drive.
Everything went smooth until checking logs, the TOC section to be exactly.
According to AR the tracks were ripped accurately (with high confidence); even CTDB plugin reported high accuracy.
As I said earlier the problem lies with the TOC; it turns out that EAC, CTDB and MusicBrainz all reports different TOC value (especially Starting Sector).
Almost all my logs report 0 as Starting Sector while CTDB and MB reports 150 in every CD i checked.
For this reason almost all tracks have different crc between my rips and CTDB/MB due to different TOC positions.
My main questions are:
Why 3 different values for the same CD?
Who should I trust for accuracy?
Does it matters if AR reports no errors and high confidence?

Thanks

Re: A newbie needs clarifications about TOC reports

Reply #1 –
Quote from: CarloSadarusa on
Why 3 different values for the same CD?
You can use this tool to look up the musicbrainz disc id and freedb id from an EAC/XLD log. If it exists in those databases then you at least know the version/edition you have and should also be able to verify your rip. Obviously this isn't something you'll want to do with 100s of CDs as it'll be quite time consuming.

Some CDs can show "shifted" &/or "drift" TOCs.

Re: A newbie needs clarifications about TOC reports

Reply #2 –
Quote from: CarloSadarusa on
Almost all my logs report 0 as Starting Sector while CTDB and MB reports 150 in every CD i checked.
An audio CD has a 2 second (150 sector) Lead-In followed by the program area. The Lead-In is where the TOC is stored. ref: https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Data_structure
The EAC extraction log TOC excludes the 150 sector Lead-In and starts at the beginning of the program area.
The CT and MB databases show from the beginning of the CD (which includes the 150 sector Lead-In).

Quote
Does it matters if AR reports no errors and high confidence?
The AccurateRip and CUETools databases only use the audio in the program area to calculate checksums used for verification.
korth

Re: A newbie needs clarifications about TOC reports

Reply #3 –
Quote from: jaybeee on
Quote from: CarloSadarusa on
Why 3 different values for the same CD?
You can use this tool to look up the musicbrainz disc id and freedb id from an EAC/XLD log. If it exists in those databases then you at least know the version/edition you have and should also be able to verify your rip. Obviously this isn't something you'll want to do with 100s of CDs as it'll be quite time consuming.

Some CDs can show "shifted" &/or "drift" TOCs.

Thanks for the help/clarification and the link.
I used directly this: http://db.cuetools.net/?tocid= by adding the tocid contained in the log to check.
That way I was sure that the CD is the same that I have.
From here I have discovered that the TOC is different from EAC to CT and MB.
Sometimes even the tracks duration time differers by a few between log and what is reported here.

Quote from: korth on
Quote from: CarloSadarusa on
Almost all my logs report 0 as Starting Sector while CTDB and MB reports 150 in every CD i checked.
An audio CD has a 2 second (150 sector) Lead-In followed by the program area. The Lead-In is where the TOC is stored. ref: https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Data_structure
The EAC extraction log TOC excludes the 150 sector Lead-In and starts at the beginning of the program area.
The CT and MB databases show from the beginning of the CD (which includes the 150 sector Lead-In).

Quote
Does it matters if AR reports no errors and high confidence?
The AccurateRip and CUETools databases only use the audio in the program area to calculate checksums used for verification.


Thanks for the clarification.
So I guess everything is fine since both says "Accurately Ripped" (with high number of confidence)

Re: A newbie needs clarifications about TOC reports

Reply #4 –
Quote from: korth on
An audio CD has a 2 second (150 sector) Lead-In followed by the program area. The Lead-In is where the TOC is stored.
Where does the assumption come from that a disc "starts" 150 sectors before the beginning of the program area, rather than at the beginning of the program area itself? That's definitely not how the standard defines it, and the lead-in is much, much bigger than 150 sectors long.

Re: A newbie needs clarifications about TOC reports

Reply #5 –
I was replying to:

Quote from: CarloSadarusa on
Almost all my logs report 0 as Starting Sector while CTDB and MB reports 150 in every CD i checked.

The positions read from the CD's TOC start at the begining of the program area so the CD won't start playing before LBA 150 (0 relative to the start of the program area) but if the CD player doesn't "start" reading the CD at LBA 0, how does it read the TOC?

Here's the MusicBrainz explanation of how their CD-DA DISC ID is calculated:
https://wiki.musicbrainz.org/Disc_ID_Calculation

The reserved lead-in area of a CD-R is much bigger than 150 sectors (6750 I believe) until the actual lead-in is written to the CD but that's not what's being discussed.
korth

Re: A newbie needs clarifications about TOC reports

Reply #6 –
Here's another reference in a forum post by spoon: https://forum.dbpoweramp.com/forum/dbpoweramp/cd-ripper/15186-proposed-cd-toc-storage-standard

Quote
Here is where it gets complex, 2 seconds in (MSF) really is 150 LBA (if you take the disc start into account), the reason CD drives return 0 LBA, is for a valid audio CD it has to have 2 seconds of lead-in, anything less is not valid, so everything is referenced from 0 LBA, not 150 LBA.

Many metadata providers use 150 as the starting point when calculating the database identifier...
korth

Re: A newbie needs clarifications about TOC reports

Reply #7 –
2 seconds is the minimum for the spec, it can be longer.
 

Re: A newbie needs clarifications about TOC reports

Reply #8 –
Anything beyond 2 seconds will appear in the TOC of EAC.
EAC may show the start sector of track 1 as 75 in the extraction TOC where MusicBrainz and CUETools DB will show as 225 (150+75).
korth

Re: A newbie needs clarifications about TOC reports

Reply #9 –
So, I've done some research/experimentation over the past few days and think I can give some more context to what's happening here.

Audio CDs have three "sections": the lead-in, the program area, and the lead-out. Audio content lives in the program area, and every frame in the program area has an absolute Minute-Second-Frame (AMSF) timestamp, starting from 00:00:00 in the program area's first frame. The discs's Table of Contents (TOC) is stored in the lead-in area, and lists the AMSF values for the frames where each track on the disc starts.  All of this so far is defined in the Red Book standard.

Computers use the SCSI Multimedia Command set (MMC) to control multimedia devices, including optical drives that read audio CDs. This command set came along in the '90s and therefore had to deal with CDs as they already existed. In particular, it needed a way to address blocks (frames) on an audio CD in a more computer-friendly way than the absolute M-S-F timestamps that are on the disc. It does this by mapping the AMSF timestamps on the frames in the CD's program area to a sequence of Logical Block Addresses (LBAs) starting at LBA 0.

SCSI MMC exposes an audio CD's TOC via the READ TOC command, so programs don't need to know how the TOC is stored or how to read and parse it, they just ask for it. (Which is good, because it's kind of a mess up there.) READ TOC can return the track starting positions as the actual absolute M-S-F positions from the lead-in TOC, or with the LBA equivalents of those AMSF positions.

And here's the quirk that spawned this thread: SCSI MMC defines LBA 0 as the frame in the program area with an absolute M-S-F timestamp not of 00:00:00, but of 00:02:00.

(I don't know why, the history isn't well-documented, but it's probably because the CD standard requires a start flag of no less than two seconds to be present in Channel P before the first track starts, implying that the first two seconds will always be empty and therefore there's no reason to make them addressable. That's just my speculation. It does answer my earlier question though, about why you so often see a 150-block offset added to LBA values.)

Because of this, most computer optical drives (Plextors being a notable exception) can't read that first two seconds of the program area; you can't ask them to read LBAs with "negative" positions. And because of that, track positions in a cuesheet—which are relative to the start of the audio file, and therefore relative to LBA 0, will be two seconds later than the absolute M-S-F values definging the starts of those tracks on the disc itself.

So: EAC reports the actual LBA values for each track, and the "cuesheet" M-S-F values for the frames in the audio file that correspond to those track positions. Other tools are adding 150 to the LBA positions to account for two seconds' worth of program area that can't be accessed directly, which is useful if you're also working with the absolute M-S-F values from the TOC. But it doesn't make any sense to use the AMSF track positions to calculate checksums for tracks in a ripped audio file, because the file is 150 frames shorter than the track positions would indicate.

Finally, just to correct some things from earlier in the thread:

  • Two seconds MSF into the program area isn't "really LBA 150", it's LBA 0, period. It's the 150th (well, 151st) block in the program area, but LBAs aren't a count of blocks in the program area.
  • The two seconds before LBA 0 (AMSF 00:00:00-00:01:74) are in the program area, not the lead-in. (They aren't the pre-gap either, though they're always part of the pre-gap. But the pre-gap doesn't end until you reach TRACK 01 POINT 01, which can be multiple minutes later (which is how you get "hidden track-one audio).
  • TOC data is in the lead-in, not the first two seconds of the program area. The positions in Channel Q that store the track positions in the TOC are storing the AMSF timestamps in the program area. The lead-in/TOC really is its own thing completely.

That all took a long damn time to nail down, I need some dinner!  :D

Re: A newbie needs clarifications about TOC reports

Reply #11 –
Quote from: Porcus on
Where in this do "EAC's 30 samples" show up?
The Red Book standard doesn't require a precise correspondence between subcode timestamps and audio samples, with the idea that those would be handled by separate components inside your CD player that might not be perfectly synchronized with each other.

In a PC CD drive, the subcode timestamps and the audio data are usually precisely in sync, but it's up to the drive manufacturer to decide exactly how the various delays in (de)interleaving the audio data should affect that synchronization. Without pulling out a microscope (or a Domesday duplicator) and examining the raw EFM on a CD, there's no way to determine the exact "zero delay" offset, so someone had to guess, and that guess happened to be 30 samples away from the correct answer (as far as I know - has it ever been independently verified?).

Data CDs solve this problem by embedding sync patterns and timestamps inside the "audio" data.

Re: A newbie needs clarifications about TOC reports

Reply #12 –
Yeah, but ... that wouldn't be enough to explain that there even was a "correct answer" and a definite number. But according to
https://hydrogenaud.io/index.php/topic,50301.0.html replies 11 and 73, there is a correct way.
The thread from other forums referenced there, must be found by the wayback machine. Quite a wormhole.

Re: A newbie needs clarifications about TOC reports

Reply #13 –
Each frame of audio is interleaved across 106 frames on the disc. The "correct answer" according to Plextor is to consider the timestamp that lines up with the first of those 106 interleaved frames as the timestamp of the deinterleaved audio.

Re: A newbie needs clarifications about TOC reports

Reply #14 –
Quote from: Octocontrabass on
Without pulling out a microscope (or a Domesday duplicator) and examining the raw EFM on a CD, there's no way to determine the exact "zero delay" offset, so someone had to guess, and that guess happened to be 30 samples away from the correct answer (as far as I know - has it ever been independently verified?).
IpseDixit's methodology that resulted in the 30-sample "correction" certainly makes sense. But as you point out, since the Red Book standard doesn't define things down to that level (because why would it, given the application?) even if you did have Domesday-grade visibility into what's encoded on the disc, there's still a judgement call to be made about how to interpret what you see. It becomes a purely academic exercise pretty quickly.