What does it mean for a CD rip to be bit perfect?

I thought we'd had an endless thread about rips and the very subject of bit perfection just recently. Isn't this the same thing? 

My understanding is as follows.

1. Yes. 2. Yes - the hash values of the two files should be the same. There are other tests. 3. Yes. 4. N/A as the answer to 3. was yes.

Hungryhalibut posted:

I thought we'd had an endless thread about rips and the very subject of bit perfection just recently. Isn't this the same thing? 

Yes, but it very quickly descended into a technobable fest. My prediction is this thread will head off in a similar direction.

The question should be, does it matter.

It's been a long time since i looked at this but i would have thought the only completely valid way of determining whether a rip is 'bit perfect' is to compare it to the original source file used to produce the CD master. All other methods just rely on comparing other peoples rip results from a database (IIRC)

To satisfy myself that XLD was going to be the best solution for me (as my final ripping solution) i compared a rip i'd made of a Naim Label CD with the same file downloaded from Naim Label itself.  I didn't compare the files numerically to check they were identical but listened to them. There was no difference to my ears so this was good enough for me and i've not really worried about the quality of my rips since. 

Happy to be corrected on the above as it's been a long time since i looked at this and methods may be different but i'm interested in others thoughts who are much more experienced in this on the matter. 

If we assume that the notion of "bit perfectness" is not just a marketing buzz, at least the answer to

1) Is it possible to decide whether a file obtained by ripping a CD is bit perfect or not?

should be positive, I believe. However, I can imagine that implementing a test to assess bit perfectness might not be easy. I understand that Rubyripper, for instance, compares via MD5 checksum the results of ripping the same "chunk" of a CD a fixed number of times. A rip is then accepted if these resuls are found to be (MD5 checksum) identical for every chunk. I can imagine that other ripping programs rely on other tests. Thus, I do not have a clear opinion on 2). I also do not know an answer

3) Do bit perfect rips need to be identical?

although this is a crucial question: if bit perfect rips had to be identical, we would have a powerful test in our hands. We still could not establish bit perfectness of identical files, of course. But we could say for sure that two different files cannot be both bit perfect. Finally, an answer to

4) If the answer to 3) is negative, which relations have to hold between two different bit perfect rips A and B? 

would provide us with a better understanding of what it means for two different files to be bit perfect. I would expect this answer to boil down to some notion of equality modulo shift. In other words, I would expect two different bit perfect files to share a common segment, for instance like the strings "ilalalalulu" and  "alilalalu00" which share the "lalalu" segment.

Dozey posted:

My understanding is as follows.

1. Yes. 2. Yes - the hash values of the two files should be the same. There are other tests. 3. Yes. 4. N/A as the answer to 3. was yes.

Hmm ... I am not sure I understand. Which two files would you hash-value compare precisely? If we rip a track of a CD we just get one file. If we had the original file used to press the CD master, we could of course compare the two, as pointed out by James. But without the original file ...

Still, I think that the notion of bit perfectness implied by a comparison between the result of ripping a CD and the (perhaps non available in practice but certainly available in principle) original master is very interesting. In spite of not having a bit perfectness test in practice, we knew that the answer to

3) Do bit perfect rips need to be identical?

would have to be positive: if A and B are bit perfect rips of the master M, then A=M and B=M and therefore A=B. This would immediately tell us that if A and B are not identical, then either A or B (or both, of course) is not bit perfect.

Hungryhalibut posted:

I thought we'd had an endless thread about rips and the very subject of bit perfection just recently. Isn't this the same thing? 

It is true the question of what it means for a rip to be bit perfect was discussed, among others, in the "unitserve rips vs core rips" thread.

The fact that, in that thread, we did not manage to achieve a shared understanding of what it means for a rip to be bit perfect was indeed a strong motivation for opening the current thread. In fact, before the "unitserve rips vs core rips" thread, I had not realized how poor my understanding of the notion of bit perfectness actually was and is!

I hope that in this thread, by looking at bit perfectness in isolation from any concrete and contingent problem, we will be able to focus come up with a shared understanding of this notion. The thread could also serve as a reference for future discussions in which the notion of bit perfectness will inevitably pop up again.

james n posted:

It's been a long time since i looked at this but i would have thought the only completely valid way of determining whether a rip is 'bit perfect' is to compare it to the original source file used to produce the CD master. All other methods just rely on comparing other peoples rip results from a database (IIRC)

...

I think that you have a very strong point. Still, it is not clear (to me) how a comparison should look like in detail. I can imagine rips which are different from the original source file and still bit perfect. Think, for instance, of a ripping software that appends long trails of silence to the original source file. The rip and the original file would be very different but share a common initial segment. In this case we could have different rips which are still bit perfect and question 3) would be answered negatively.

If you add a zero it is no longer bit perfect. It has different bits. The concept of bit perfect implies a comparison between two files. You just define which files you are comparing.

A more interesting issue to me is the observation that identical files can sound different. That is unexpected and counter intuitive to me.

This is gettin' scarry now....

Dozey posted:

If you add a zero it is no longer bit perfect. It has different bits. The concept of bit perfect implies a comparison between two files. You just define which files you are comparing.

A more interesting issue to me is the observation that identical files can sound different. That is unexpected and counter intuitive to me.

i sense NBPF's point is that we do not seem to have an accepted way to determine that files are 'identical' ? (of course, i may have misunderstood...)

in which case, the statement "... identical files can sound different" becomes rather difficult to interpret.  but of course, if there is an established/accepted way of determining "identical"  -- then i believe it would be interesting to know what that is... hopefully without a lot of technobable...

enjoy

ken

nbpf posted:

The notion of "bit perfectness" pops up over and over again in this forum, for instance, when discussing features of CD ripping software. I do not know precisely what it means for a rip to be bit perfect and I have the impression that other contributors might be in a similar situation. Thus, the aim of this thread is to achieve some shared understanding of what it means for files obtained by ripping CDs to be bit perfect.  To this end, it seem to me purposeful trying to answer the following questions:

1) Is it possible to decide whether a file obtained by ripping a CD is bit perfect or not?

2) If the answer to 1) is positive, do we have reliable tests of "bit perfectness"? Can we share such tests?

3) Do bit perfect rips need to be identical?

4) If the answer to 3) is negative, which relations have to hold between two different bit perfect rips A and B? 

What's your take on bit-perfectness? Do you think that the answer to 1) is positive or negative? What could be other questions that can help better understanding the notion of bit-perfectness?

1  Yes

2  Yes it's called AcurateRip

3  Yes for the data, no for the metadata

4  n/a

I think nbpf's point was that if you say a file is a bit perfect copy you have to have the original to compare it to. Which is true. There are established ways to determine if two files are identical as i mentioned. With a cd you have the original. What you don't know is whether your cd is a bit perfect copy of a master.

Dozey posted:

If you add a zero it is no longer bit perfect. It has different bits. The concept of bit perfect implies a comparison between two files. You just define which files you are comparing.

...

I am not sure. In the context of ripping, "bit perfect" seems to be commonly used to denote a property of rips. One says that a certain rip is bit perfect, another one is not bit perfect, etc. It is of course possible that assessing (or disproving) the bit perfectness of a rip implies a comparison with another file. But then, the question is where this second file comes from.

A rip needs to extract the sample data accurately from a CD so as to be sample  perfect. There is however the issue of track boundaries, this is the separation  between tracks. These can vary from CD-ROM to CD-ROM, now some rippers use a database along with AccuRip to provide a consistent but arguably arbitrary boundary offset between CD-ROMs. Now rippers that don't use such a database can provide rips where the boundary between tracks can be offset by the odd millisecond. This offset is relative on a given CD and CD-ROM so no actual data is lost, but it might mean rips from different rippers may differ between each other by the odd millisecond at the start and end of tracks, and consequently will not be 100% bit perfect with each other.

ken c posted:

Dozey posted:

If you add a zero it is no longer bit perfect. It has different bits. The concept of bit perfect implies a comparison between two files. You just define which files you are comparing.

A more interesting issue to me is the observation that identical files can sound different. That is unexpected and counter intuitive to me.

i sense NBPF's point is that we do not seem to have an accepted way to determine that files are 'identical' ? (of course, i may have misunderstood...)

in which case, the statement "... identical files can sound different" becomes rather difficult to interpret.  but of course, if there is an established/accepted way of determining "identical"  -- then i believe it would be interesting to know what that is... hopefully without a lot of technobable...

enjoy

ken

There is a natural notion of equality for files which is bitwise equality. When files are store on different file system (for instance on two devices in a network) this notion is often weakened by the one of (MD5) checksum equality. Bitwise equality implies checksum equality but the converse is true only with a very high degree of probability, not with certainty.

It seems conceivable to me that the notion of bit perfectness of rips -- assuming that it can be explained in terms of a comparison between the rip and another file -- requires a weaker notion of equality than bitwise equality. For instance, the strings ". . .abcd. ." and "abcd" are certainly not equal. But if dots are meant to represent absence of sound, they are certainly equivalent "up to leading and trailing intervals of silence". Notions of bit perfectness could rely on this kind of equivalence rather than bitwise equality.

james n posted:

It's been a long time since i looked at this but i would have thought the only completely valid way of determining whether a rip is 'bit perfect' is to compare it to the original source file used to produce the CD master. All other methods just rely on comparing other peoples rip results from a database (IIRC)

For a rip to be bit perfect, surely it just has to be the same as the CD it came from. If this turned out to be different to the master, you would have to complain to the record company, who would no doubt think you were insane for asking the question. So if you can compare your rip with someone else's via the Accurate Rip database, surely that's enough?

Dozey posted:

...

A more interesting issue to me is the observation that identical files can sound different. That is unexpected and counter intuitive to me.

I do not think that this is relevant to the problem of what it means for a rip to be bit perfect and I have never observed that identical files sound differently (but I have many times found different files to sound the same, because of my bad hearing, I guess).

That said, I fail to understand why such experience could be considered to be unexpected or counter intuitive. It seems to me obvious that the same file (or, for that, that two identical files) can sound differently at different times. The state of our replay systems, of our power grids, environments and, perhaps more importantly, the state of our ears, brains, etc. naturally varies in time and certainly can influence what we experience as "the sound of files". Thus, nothing special with identical files sounding differently, it seems to me.

ChrisSU posted:

james n posted:

It's been a long time since i looked at this but i would have thought the only completely valid way of determining whether a rip is 'bit perfect' is to compare it to the original source file used to produce the CD master. All other methods just rely on comparing other peoples rip results from a database (IIRC)

For a rip to be bit perfect, surely it just has to be the same as the CD it came from. If this turned out to be different to the master, you would have to complain to the record company, who would no doubt think you were insane for asking the question. So if you can compare your rip with someone else's via the Accurate Rip database, surely that's enough?

I think that you are right in principle but there are two issues that I find difficult to understand here. A practical issue and a conceptual issue:

The practical issue is that it is not clear to me what it means for a rip  to be identical as the CD it comes from. I do not know precisely how this kind of equality could be tested and I tend to believe that, if it was testable, there would be indeed no point for ripping programs like Rubyripper to check the (checksum) equality 3 successive rips of the same chunk.

The conceptual issue is that Simon's post seems to suggest (but I might have misunderstood him, of course) that comparing a rip via the Accurate Rip database could actually be too strong for bit perfectness. In other words, there could be rips that would not pass the test in spite of being bit perfect.

Huge posted:

nbpf posted:

The notion of "bit perfectness" pops up over and over again in this forum, for instance, when discussing features of CD ripping software. I do not know precisely what it means for a rip to be bit perfect and I have the impression that other contributors might be in a similar situation. Thus, the aim of this thread is to achieve some shared understanding of what it means for files obtained by ripping CDs to be bit perfect.  To this end, it seem to me purposeful trying to answer the following questions:

1) Is it possible to decide whether a file obtained by ripping a CD is bit perfect or not?

2) If the answer to 1) is positive, do we have reliable tests of "bit perfectness"? Can we share such tests?

3) Do bit perfect rips need to be identical?

4) If the answer to 3) is negative, which relations have to hold between two different bit perfect rips A and B? 

What's your take on bit-perfectness? Do you think that the answer to 1) is positive or negative? What could be other questions that can help better understanding the notion of bit-perfectness?

1  Yes

2  Yes it's called AcurateRip

3  Yes for the data, no for the metadata

4  n/a

Thanks for the precisation Huge! I should have mentioned that all the notions of identity, equality tests, etc. dicussed here are meant for the data only, not for the data+metadata compound, of course.

I tend to agree with your answers but ... there is a nagging problem: accepting that a rip that passes the Accurate Rip test is bit perfect does not necessarily imply that rips that fail to pass the Accurate Rip test are not bit perfect. In other words, the Accurate Rip test could be sufficient but not necessary for bit perfectness.

There are a lot of examples of equality tests that are sufficient but certainly not necessary. Thus, for instance, bitwise equality is sufficient for checksum equality but certainly not necessary. We can construct examples of files which are not bitwise equal but checksum equal.

If we assume that passing the Accurate Rip test is sufficient but not necessary for bit perfectness, we cannot conclude that the answer to 3) needs to be positive (modulo metadata, of course): in this case, we could indeed have two files, say A and B which are genuinely different and bit perfect. The differences would result in one file passing the Accurate Rip test and the other one not.

Of course, if the Accurate Rip test was necessary and sufficient for bit perfectness, 3) would have to be answered positively, as you suggest. Thus, the crucial question is whether we can consider the Accurate Rip test to be sufficient and necessary for bit perfectness or just sufficient. I simply do not know.

nbpf posted:

The conceptual issue is that Simon's post seems to suggest (but I might have misunderstood him, of course) that comparing a rip via the Accurate Rip database could actually be too strong for bit perfectness. In other words, there could be rips that would not pass the test in spite of being bit perfect.

Leaving aside the issue of lead-in zeros and headers, to my mind, we have arrived at a point where the 'bits are bits' argument actually applies. If a digital file is nothing but a string of ones and zeros, then that sequence of ones and zeros is either the same as on the disc it was copied from, or it's different. The same = bit perfect. Different = not bit perfect. And perfect is an absolute term, which makes it particularly appropriate to use it in this context. But as a layman, maybe I'm missing the point completely!?

Assuming the musical data in two files are identical, but that the files differ in a) metadata, or b) track boundaries, or c) both - will they sound different?  

If they sound different, might the means of playback affect this result?

Core and Serve rips are bit-perfect (which I take as 'no data is lost'), are identical in size, but differ slightly in offset. Played back from the same media on the same player (Core, Serve, UnitiLite, MacBook), they differ in sound, and markedly in effect. No improvement has been noticed on re-ripped files with updated Core FW (v1.2.5798).

Jan

Ok hands up who has a copy of the red book spec?

And let's be pedantic. Who wants a copy of what's on the cd? What about reed Solomon? 8 to 14 modulation? P and q subcodes?

Cos if you don't understand the fundamentals then it will seem like "technobabble". Although I have to say trying to have an arm waving discussion about what bit perfect means without "descending into technobabble" seems to be almost offensive to the engineers who designed redbook and the engineers at naim and elsewhere.