IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Why can't you extract all the data on a factory-pressed CD when it
guest0190
post Sep 5 2012, 21:28
Post #1





Group: Members
Posts: 13
Joined: 8-August 12
Member No.: 102135



In the past when I have burned a CD with EAC (with read and write offset correction values consistent with Andre Wiethoff's reference), I have been able to rip files from it identical to the source files.

Based on what I could gather from this forum, I used to be of the conviction that with a drive capable of overreading and overwriting, the exact same files that were burned to a CD can be extracted from it again, and that the only disadvantage of using a drive not capable of overreading was that a few samples at the beginning or end of the first or last audio file would be replaced with silence, regardless of what the samples originally contained.

Recently, however, it has come to my understanding that it is very hard (or even impossible) to extract the original files that were burned to it from a mass-produced CD.

My question is simple: How is it that I can rip files identical to the source files from a CD I have burned myself, but not from one that is factory-pressed? And, perhaps more importantly, how is it that I managed to achieve this using 'incorrect' offset values?

I apologise in advance for any difficulty I might have understanding any mathematical arguments you put forth. I fear I am slightly dyscalculic.

(I have decided, henceforth, to rip using the 'ideal scenario' reference which is 30 samples before that established by Mr Wiethoff, but I am not sure if it is relevant.)
Go to the top of the page
+Quote Post
AndyH-ha
post Sep 5 2012, 22:19
Post #2





Group: Members
Posts: 2207
Joined: 31-August 05
Member No.: 24222



Do the offsets have anything to so with anything except timing? The audio data will be identical when extracted correctly, regardless of whether or not you pay any attention to the offsets. If the extracted tracks are not exact duplicates, bit for bit, of the source from which the CD was created, it is because something on the CD can't be read correctly, and this will differ due to offsets.

I think the majority of "mass produced CDs are still pressed, not written with laser on CD-R media. The read error rates are generally significantly higher on pressed CDs than on good computer written CD-Rs, but generally well within the range where perfect, bit for bit playback happens. I've never heard about any difficult with perfect extraction either. However, without the original source file to compare to your extraction from the CD, you have no way to know if your extraction is indeed identical.

I suppose these on-line databases that you can use to verify your extraction are based on other people's extractions. The assumption is that if everyone's work shows the same thing result, it is indeed correct. I would say that is a good assumption and worrying about it beyond that is not really different than worrying about stepping on sidewalk cracks.
Go to the top of the page
+Quote Post
pisymbol
post Sep 5 2012, 22:59
Post #3





Group: Members
Posts: 43
Joined: 22-March 09
Member No.: 68274



Is this the TAO (track at once) vs DAO/SAO (disc at once) issues that result in burning CDs? (TAO will yield an issue at the end which is why you burn data for instance in DAO mode)

I have never heard you could not read back what you wrote on a CD before. In fact I have never heard that EAC or XLD won't read bit for bit what's on the CD before...

Where do you read this? (just so I can learn a little too)

This post has been edited by db1989: Sep 6 2012, 11:39
Reason for edit: deleting pointless full quote of OP
Go to the top of the page
+Quote Post
2Bdecided
post Sep 6 2012, 10:31
Post #4


ReplayGain developer


Group: Developer
Posts: 5106
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



There's subcode, HTOA, offsets, pregaps etc which you'll have varying degrees of success reading, depending on your drive and method - but apart from these, you can get the exact audio data back, and you are getting the exact audio data that was pressed.

Some audiophools don't believe this is the case, but some mastering engineers check exactly that: that the audio data from the pressed CD matches what they sent off. Sometimes it doesn't, but that's because another stage of unwanted signal manipulation was added to the chain by someone down the line - and that's exactly why they check it.

There's a study somewhere investigating the supposedly different "sound" of CDs glass mastered + pressed at different factories. They looked at the issue of the CDs (and master tape) being bit-identical very carefully.

Cheers,
David.
Go to the top of the page
+Quote Post
Rollin
post Sep 6 2012, 14:09
Post #5





Group: Members
Posts: 190
Joined: 5-March 08
Member No.: 51815



If your drive has positive offset correction value and quantity of "zero" samples in end of CD is less than offset value, then you need overread in lead-out to exactly rip CD and overwrite in lead-out to exactly write it to CD-R.
If your drive has negative offset correction value and quantity of "zero" samples in beginning of CD is less than offset value, than you need overread in lead-in to exactly rip CD and overwrite in lead-in to exactly write it to CD-R.
If quantity of "zero" samples in beginning/end of CD is more than drive offset value, then audio data will not be affected.

Also read http://blowfish.be/eac/Setup/setup5.html#no5c

This post has been edited by Rollin: Sep 6 2012, 14:15
Go to the top of the page
+Quote Post
greynol
post Sep 6 2012, 15:11
Post #6





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



You need to take into account the offset of the burner if you're going to address overwriting.

Also, what if there are non-null samples beyond the EAC-defined limits in either direction if not both directions?

This post has been edited by greynol: Sep 6 2012, 15:29


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
pisymbol
post Sep 6 2012, 16:49
Post #7





Group: Members
Posts: 43
Joined: 22-March 09
Member No.: 68274



QUOTE (Rollin @ Sep 6 2012, 09:09) *
If your drive has positive offset correction value and quantity of "zero" samples in end of CD is less than offset value, then you need overread in lead-out to exactly rip CD and overwrite in lead-out to exactly write it to CD-R.
If your drive has negative offset correction value and quantity of "zero" samples in beginning of CD is less than offset value, than you need overread in lead-in to exactly rip CD and overwrite in lead-in to exactly write it to CD-R.
If quantity of "zero" samples in beginning/end of CD is more than drive offset value, then audio data will not be affected.

Also read http://blowfish.be/eac/Setup/setup5.html#no5c


What is the history behind all of this?
Go to the top of the page
+Quote Post
greynol
post Sep 6 2012, 17:31
Post #8





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Countless discussions on this forum, digital-inn, and cdfreaks (club.myce) no doubt. Feel free to do a little digging.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
Manlord
post Sep 6 2012, 18:30
Post #9





Group: Members
Posts: 25
Joined: 2-April 10
Member No.: 79529



QUOTE (Rollin @ Sep 6 2012, 15:09) *
If your drive has positive offset correction value and quantity of "zero" samples in end of CD is less than offset value, then you need overread in lead-out to exactly rip CD and overwrite in lead-out to exactly write it to CD-R.
If quantity of "zero" samples in beginning/end of CD is more than drive offset value, then audio data will not be affected.


I am not sure if I understood this correctly.

I use one of the old famous Plextor PX-716A. It's one of these units which has an offset of +30 (and therefore a offset of 0 according to the theory referred by the OP).

Till now I have thought that despite of having overread in & out I would lose a few samples if I used a +30 offset. So I had to chose between losing a few samples (that would be silence most of the time) and being abble to use AR or rip with a offset of 0, maintaining all "theoric samples", having the supposed absolute offset but not being able to use AR.

According to Rollin, there wouldn't be that difference in the number of kept samples due to the overreading capability. Is that assumption right?
Go to the top of the page
+Quote Post
greynol
post Sep 6 2012, 18:55
Post #10





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



The greatest number of samples that can be replicated to a cd-r/rw using that drive will be done when the read offset correction and write offset are both set to zero. This has everything to do with the limitations of the drive and nothing to do with the measured reference.

OT:
I have that drive. It is pretty good but although it was actually made by Plextor with a Sanyo chipset, it is not one of the "famous" ones. Regardless, the hype over old Plextor drives is just that. Ironically, the PX-230 appears to have a better track record of delivering error-free rips according to statistics from the AccurateRip database. It was not made by Plextor.

This post has been edited by greynol: Sep 6 2012, 19:09


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
pisymbol
post Sep 6 2012, 20:15
Post #11





Group: Members
Posts: 43
Joined: 22-March 09
Member No.: 68274



QUOTE (greynol @ Sep 6 2012, 12:31) *
Countless discussions on this forum, digital-inn, and cdfreaks (club.myce) no doubt. Feel free to do a little digging.


Okay, will do.
Go to the top of the page
+Quote Post
guest0190
post Sep 6 2012, 20:22
Post #12





Group: Members
Posts: 13
Joined: 8-August 12
Member No.: 102135



http://www.digital-inn.de/exact-audio-copy...se-offsets.html
http://www.digital-inn.de/exact-audio-copy...ay-offsets.html
http://www.hydrogenaudio.org/forums/index....showtopic=50301
http://club.myce.com/f61/offsets-handling-...channel-111913/

There are a few links relevant to the topic. I am not sure if any of them explicitly states that the differences between these two references (which I will readily admit I do not understand in the first place) prevents extraction of the same files that were burned to the CD, but that was how I interpreted it.

The bottom line, as far as I can tell, seems to be that it is hard to tell where the actual data on the CD starts. (I have previously shared with greynol that this strikes me as unintuitive, as I feel that the CD drive should have no problem recognising where the little pits on the surface of the disc start and where they end - but that is an aside.)

Again, my problem is that I have a hard time understanding how this is consistent with the fact that my own experiments showed me that I could indeed get the same files back from a CD that I burned to it.

Another, albeit related, thing that confuses me, is how I were able to accomplish this despite my drive consistently reading 30 samples prior to where it 'should' be reading. I suspect the answer lies in basic math, but nonetheless, I would be glad if someone could clarify.
Go to the top of the page
+Quote Post
db1989
post Sep 6 2012, 21:24
Post #13





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (guest0190 @ Sep 6 2012, 20:22) *
There are a few links relevant to the topic. I am not sure if any of them explicitly states that the differences between these two references (which I will readily admit I do not understand in the first place) […]
IpseDixit’s later calculated reference is verifiable as being exactly correct, meaning that a drive calibrated to it will not exhibit any offset between the times of the data that are requested and the data that are actually returned. Andre’s is a bit off (30 samples, to be exact), but most applications supporting offsets and verification of tracks according to them (read: about three) were firmly entrenched in using it by the time IpseDixit presented his findings, so they tend to offer the new offset as an optional extra if at all.

QUOTE
[…] prevents extraction of the same files that were burned to the CD, but that was how I interpreted it. […] Again, my problem is that I have a hard time understanding how this is consistent with the fact that my own experiments showed me that I could indeed get the same files back from a CD that I burned to it.
No one has said anything about not being able to extract the same audio, but you must account for offsets to ensure that you don’t miss a bit at the start or end, by accounting for the offsets of both the present reading drive and the and antecedent writing drive.

QUOTE
The bottom line, as far as I can tell, seems to be that it is hard to tell where the actual data on the CD starts. (I have previously shared with greynol that this strikes me as unintuitive, as I feel that the CD drive should have no problem recognising where the little pits on the surface of the disc start and where they end - but that is an aside.)
It’s quite simple. The audio is written as a continuous stream in the main data, whereas the information on which parts of it correspond to which tracks is written elsewhere. Your drive can get information on what to read, either from the table of contents or from your instruction, but it’s not necessarily true that it can then seek to exactly the right place in the nondescript stream of audio.

QUOTE
Again, my problem is that I have a hard time understanding how this is consistent with the fact that my own experiments showed me that I could indeed get the same files back from a CD that I burned to it.
Again, no one has said that this is impossible, so please do not portray anyone as having done so. It’s perfectly possible, just maybe with a little preparation.

QUOTE
Another, albeit related, thing that confuses me, is how I were able to accomplish this despite my drive consistently reading 30 samples prior to where it 'should' be reading. I suspect the answer lies in basic math, but nonetheless, I would be glad if someone could clarify.
Did you apply offset correction during reading and writing, or if not does your drive have inverse read (e.g. +30) and write (e.g. -30) offsets? Again, this isn’t very complex.

This post has been edited by db1989: Sep 6 2012, 21:26
Go to the top of the page
+Quote Post
greynol
post Sep 7 2012, 01:51
Post #14





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Didn't we just have another discussion saying fairly clearly that pits and lands do not directly translate to bits in the audio stream and that the data for each frame of audio is distributed over an area so errors can be corrected perfectly from minor damage?

It shouldn't be too much of a stretch to accept that such a scheme would result in different hardware resolving the data to any specific address differently; especially when the specification does not require address resolution to an exact sample.

Combine this with pressings that differ by thousands, if not tens of thousands of samples (or more!) on a track by track basis and you quickly realize that this reference business is much ado about nothing.

This post has been edited by greynol: Sep 7 2012, 06:07


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
hyman
post Sep 7 2012, 08:12
Post #15





Group: Members
Posts: 3
Joined: 21-January 12
Member No.: 96592



QUOTE (greynol @ Sep 7 2012, 00:51) *
Didn't we just have another discussion saying fairly clearly that pits and lands do not directly translate to bits in the audio stream and that the data for each frame of audio is distributed over an area so errors can be corrected perfectly from minor damage?

It shouldn't be too much of a stretch to accept that such a scheme would result in different hardware resolving the data to any specific address differently; especially when the specification does not require address resolution to an exact sample.

Combine this with pressings that differ by thousands, if not tens of thousands of samples (or more!) on a track by track basis and you quickly realize that this reference business is much ado about nothing.

That is not quite correct. The spreading is part of the encoder called CIRC scheme (consisting of delays and interleaves stages) and it is fixed, i.e. same spread amount is applied to all samples/sectors. The problem arises because the specification:
1. is to have the subchannel which contains the addressing (location) data to be treated as a separate stream from the audio samples data (main channel) (as mentioned by db1989)
2. does not describe that subchannel should be perfectly aligned from subchannel address 00:00.00 to first audio sample, so hardware designers found it easier to simply leave the skew (offset) created by the buffering used for the "spreading" of bytes (CIRC).

From my understanding it appears you are implying a randomness? Not quite, the offsets were a result of the buffering skew and are fixed values for each drive, in contrast the CIRC "spread" is the same for all drives. The randomness is when observing among different drives (ones using different buffering skew).

Pressed CD have recorded offsets because this applies to pressing plant recorders (LBR) as well, simply because they are glorified (made of higher quality) CD writers, many of which the chipset is from ordinary consumer manufacturers (e.g. TEAC, Sony) so these LBRs will naturally have a write offset, and further complications arise because if every plant use a different LBR they will be recording with a different write offset to the CD glass master.

This post has been edited by hyman: Sep 7 2012, 08:14
Go to the top of the page
+Quote Post
greynol
post Sep 7 2012, 12:30
Post #16





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (hyman @ Sep 7 2012, 00:12) *
From my understanding it appears you are implying a randomness?

Not at all, no. While I wasn't specific about the mechanism (which was already given in the cdfreaks discussion that the OP read), I did say the spec does not impose the requirement that there be sample-accurate indexing. Rather, I was simply trying to point out that the pits and lands are not laid out in the same sequential way that analog audio is laid out on tape or vinyl.

This post has been edited by greynol: Sep 7 2012, 12:35


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
guest0190
post Sep 7 2012, 16:15
Post #17





Group: Members
Posts: 13
Joined: 8-August 12
Member No.: 102135



Thank you all for your answers.

So if I understand this correctly, any uncertainty in the situation stems from the fact that in order to extract the unaltered files that were written to it from any given CD, one would need to know the write offset of the drive that wrote it (or, in the case of commercial CDs, the write offset of the drive that wrote the master CD)? I can certainly understand how that is not a feasible scenario!

My drive has an AccurateRip-configured read offset correction of +6. Does that mean it should be changed to -24, should I wish to follow the newer reference?
Go to the top of the page
+Quote Post
Manlord
post Sep 7 2012, 17:05
Post #18





Group: Members
Posts: 25
Joined: 2-April 10
Member No.: 79529



QUOTE (guest0190 @ Sep 7 2012, 17:15) *
My drive has an AccurateRip-configured read offset correction of +6. Does that mean it should be changed to -24, should I wish to follow the newer reference?


Right, but be aware that you won't be able to check your rip against AR.

You really have 3 options:
    a) Continue using +6 and AccurateRip
    b) Use the new reference of -24 and believe that your rips are more accurate
    c) Don't worry about offsets at all


Thanks to CueTools DB you will be able to check your rips independently of the offset used.

This post has been edited by Manlord: Sep 7 2012, 17:06
Go to the top of the page
+Quote Post
greynol
post Sep 7 2012, 17:10
Post #19





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



You won't be able to use CT to check titles ripped with an alternate offset against the AR database if there are only v2 hashes, which will certainly(?) be the case with new releases.

This post has been edited by greynol: Sep 7 2012, 17:38


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
Porcus
post Sep 7 2012, 19:35
Post #20





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (guest0190 @ Sep 7 2012, 17:15) *
in order to extract the unaltered files that were written to it from any given CD, one would need to know the write offset of the drive that wrote it (or, in the case of commercial CDs, the write offset of the drive that wrote the master CD)?


Yes. So the +30 or -30 won't matter much, and you can rather stick to the EAC suggestion.

Unless you know the write offset used by the master plant / writer,
- your files will be offset by an unknown number
- if you take care of the offset when burning, you will still get the same audio as on the pressed CD
- ... which is also offset by an unknown number.

Your files and the CD will differ by 30, and two wrongs don't make a right, but I wouldn't (and I don't) worry.

This post has been edited by Porcus: Sep 7 2012, 19:44


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
guest0190
post Sep 7 2012, 22:47
Post #21





Group: Members
Posts: 13
Joined: 8-August 12
Member No.: 102135



QUOTE
You won't be able to use CT to check titles ripped with an alternate offset against the AR database if there are only v2 hashes, which will certainly(?) be the case with new releases.


Purely out of curiosity, why is this? Did the old checksums ignore null samples in the beginning and end?
Go to the top of the page
+Quote Post
korth
post Sep 7 2012, 23:05
Post #22





Group: Members
Posts: 431
Joined: 13-March 11
Member No.: 88969



Lack of programming to do cross-pressing verification for ARv2. See also this message.


--------------------
korth
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th August 2014 - 19:26