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

I utilize the red book specs on a daily basis. I insert a CD into the tray of my CD5X, press play, sit back and enjoy. Is it perfect? Doubt it, but I couldn't care as I'm just there to get involved with music.

As I said above, unless the ripper's CDROM drives are offset aligned for consistent boundarydetection between tracks, ripped extracted  *files* from rippers will NOT be bit perfect with each other.. the beginnings and endings of ripped files will slightly differ... however for a given CD consecutive ripped files when played sequentially won't lose data and in that case be bit perfect.

AccurateRip uses a database of recognised CD-ROM drives to provide a given offset which allows consistent boundary detection across drives, so in such a case with an AccurateRip enabled ripper and AccurateRip recognised drive, boundaries will be / should be consistent across different platforms and so this extracted files should be bit perfect with each other.

i really don't think there is any mystique to this.. at the end of the data the extracted sampled data should be completely identical with what is stored on the CD.. the bit where variations can occur is where you start and stop to create an extracted file for a given *track*.

Finally one shouldn't confuse how data is formatted stored on the CD with the actual 'bit perfect' data itself.... just like with files such as ALAC, WAV or FLAC how the data is stored and structured is not relevant to the actual data itself..and can be losslessly converted between formats...  

Simon

joerand posted:

I utilize the red book specs on a daily basis. I insert a CD into the tray of my CD5X, press play, sit back and enjoy. Is it perfect? Doubt it, but I couldn't care as I'm just there to get involved with music.

Ahhh but do you? There are a fair few CDs out there that don't conform to Redbook, such as extended length replay greater than 74 minutes or copy protection etc.... but these non conformities don't tend to bother modern CD players.

Simon,

I can't think of any CDs I own longer than 74 minutes. OTOH - I certainly enjoy my HDCDs.

Then there's the embedded videos and other enhancements on many CDs.

Begs the question - is the typical mass-produced red book CD a bit perfect copy of the master?

I kinda doubt it, in which case there's a fault from ground zero.

Well the good news there is nothing in HDCD that is not RedBook compliant as far as I am concerned.. HDCD is simply a tweaked way of encoding the 44.1/16 PCM.

And yes, unless there are media errors or damage, the PCM encoded on a RedBook CD will be identical to the master..I am not CD-ROM would be a very effective or reliable medium otherwise 

Simon

Simon-in-Suffolk posted:

As I said above, unless the ripper's CDROM drives are offset aligned for consistent boundarydetection between tracks, ripped extracted  *files* from rippers will NOT be bit perfect with each other.. the beginnings and endings of ripped files will slightly differ... however for a given CD consecutive ripped files when played sequentially won't lose data and in that case be bit perfect.

AccurateRip uses a database of recognised CD-ROM drives to provide a given offset which allows consistent boundary detection across drives, so in such a case with an AccurateRip enabled ripper and AccurateRip recognised drive, boundaries will be / should be consistent across different platforms and so this extracted files should be bit perfect with each other.

i really don't think there is any mystique to this.. at the end of the data the extracted sampled data should be completely identical with what is stored on the CD.. the bit where variations can occur is where you start and stop to create an extracted file for a given *track*.

Finally one shouldn't confuse how data is formatted stored on the CD with the actual 'bit perfect' data itself.... just like with files such as ALAC, WAV or FLAC how the data is stored and structured is not relevant to the actual data itself..and can be losslessly converted between formats...  

Simon

Interesting Simon. This seems to me to imply that the answer to 3) is negative and that the relation that two files A and B have to satisfy in order to be bit perfect copies of the same source is slightly more complicated (but still intuitively understandable) that just bitwise equality. Would you agree on this?

My answer to 3) is it depends... I think if the rips are to be used in the target operating model,, i.e. Sequential extracted CD files are provided by the same ripper.. then the answer is yes, otherwise it could be no.

Jan-Erik Nordoen posted:

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

Interesting observation but more pertinent to the "unitserve rips vs core rips" thread than to the current, in my view. Even if we knew with certainty that two different bit perfect files can sound differently on the same replay device, we still would not know more about the notion of bit perfectness, I'm afraid.

Simon-in-Suffolk posted:

My answer to 3) is it depends... I think if the rips are to be used in the target operating model,, i.e. Sequential extracted CD files are provided by the same ripper.. then the answer is yes, otherwise it could be no.

This effectively means that the answer is, in general, negative: two different files provided by different rippers could both be bit perfect.

This is the position that I was tending to have in the "unitserve rips vs core rips" with the proviso that my understanding of the notion of bit perfectness was (and, up to a certain extent still is) very limited.

If we accept that files provided by different rippers can be bit perfect and different, than the obvious question is whether they can sound differently. But this is a completely different story of course. Perhaps a subject for a new thread?

CharlieP posted:

1) 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?  

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

1) Not necessarily. But of course different things can sound differently and, in principle, even the same file can sound differently at different times, I understand.

2) Of course, what else could affect the result?

When we start arguing about sound qualities of different files (no matter whether they come from bit perfect rippings or not) we are entering a very unsafe territory, I believe. We have to start taking into account specific aspects and functionalities (transcoding, ...) of the replay chain used to assess such sound qualities, let apart the way we conduct tests, etc ... a very interesting subject but nothing to do with what it means for rips to be bit perfect, I'm afraid.

ChrisSU posted:

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!?

I think that you are essentially right and that two bit perfect files have to be bitwise equal leaving aside headers, leading offsets, trailing offsets and, of course, metadata.

This would imply that, for bit perfectess tests to be reducible to bitwise equality tests, the inquired files have to be stripped down in a possibly non completely trivial but certainly understandable fashion.

Of course, this notion of bit perfectness would naturally open the way to the question of whether rip perfect files that differ (in headers, offsets or metadata) can sound differently, but this is a completely different question, of course. 

nbpf posted:

Simon-in-Suffolk posted:

My answer to 3) is it depends... I think if the rips are to be used in the target operating model,, i.e. Sequential extracted CD files are provided by the same ripper.. then the answer is yes, otherwise it could be no.

This effectively means that the answer is, in general, negative: two different files provided by different rippers could both be bit perfect.

This is the position that I was tending to have in the "unitserve rips vs core rips" with the proviso that my understanding of the notion of bit perfectness was (and, up to a certain extent still is) very limited.

If we accept that files provided by different rippers can be bit perfect and different, than the obvious question is whether they can sound differently. But this is a completely different story of course. Perhaps a subject for a new thread?

I see no reason on a like for like basis for any difference in 'sound' from an extracted files. However, and I think this is where some in the thread are getting confused with,  the way the extracted file is presented or communicated or accessed can indeed cause a sonic 'foot print' through system and sub system noise coupling.... but to be clear this is different from the file itself 'sounding' different as the files are identical and so called bit perfect other than possibly a few milliseconds at the start and end of the file. 

S

I may be a bit late into this discussion but for me the whole notion of 'bit perfect' rips is to do with how data is stored on CD for audio. 

Audio CD's should not be compared with, or likened to, CD-ROM's, which while they share the same physical medium, store the data in very different ways. CD-ROM's use sectors that contain additional error correction information as they are not designed to degrade gracefully. When you install a program from a CD-ROM, or copy data files, you expect and need the data to be bit-perfect else it is no good. So if the CD is scratched or has dirt on it that prevents you from reading that data correctly you expect to see, and get, an error. This will prompt you to clean  the CD and then try again. If this doesn't fix the problem you mark the disc as junk and request a new one. A program won't work if the bits change, and likewise data is different... 

For CD audio the requirements are subtly different. There is still error checking, but it's not as stringent, so in the even that damage/dirt on an audio CD causes the error correction to fail, instead of stopping and returning an error, the error correction is designed to make a best guess from the available data and continue. Now, if you're listening to the CD you might hear a glitch, or if the damage is bad the CD might skip. However on a computer, the ripping software will just save the 'corrected data' and march on... This is why the better rippers have the ability to read the data more than once, and clear any drive caching between reads. The assumption is that if the data reads the same way multiple times, it's probably accurate. If it keeps giving different results then you have an issue. Today's CD-ROM drives in PC's can also tell that they can't read a block at all, and can again give you more choices on what to do. 

This is where rip databases come in... your CD may have some damage that means that whilst you may not hear anything obvious, the checksum of your rip will be different to one that came from an undamaged CD. If enough people rip the same CD, then the signature of an undamaged CD will match and this then gives you confidence that you have an accurate rip with no issues. 

CD-ROMs, DVDs and Blu-ray's all have much more stringent data storage and checking algorithms built in to how the data is stored, and so if the drive has no physical read errors for the disc, you know the data is good. IF they didn't have this they couldn't be used to deliver computer code and data (games etc too) reliably. 

CD-Audio stands alone in not having that level of data checking, and this will also have been due to the fact that at it's inception, the CPU's used in players would not have had enough processing power to do all of that anyway. Hence you can't accurately say that you can read CD-Audio data from a disc in a bit perfect fashion as you can for CD-ROM onwards. 

That's my understanding of it, anyway. 

Simon-in-Suffolk posted:

nbpf posted:

Simon-in-Suffolk posted:

My answer to 3) is it depends... I think if the rips are to be used in the target operating model,, i.e. Sequential extracted CD files are provided by the same ripper.. then the answer is yes, otherwise it could be no.

This effectively means that the answer is, in general, negative: two different files provided by different rippers could both be bit perfect.

This is the position that I was tending to have in the "unitserve rips vs core rips" with the proviso that my understanding of the notion of bit perfectness was (and, up to a certain extent still is) very limited.

If we accept that files provided by different rippers can be bit perfect and different, than the obvious question is whether they can sound differently. But this is a completely different story of course. Perhaps a subject for a new thread?

I see no reason on a like for like basis for any difference in 'sound' from an extracted files. However, and I think this is where some in the thread are getting confused with,  the way the extracted file is presented or communicated or accessed can indeed cause a sonic 'foot print' through system and sub system noise coupling.... but to be clear this is different from the file itself 'sounding' different as the files are identical and so called bit perfect other than possibly a few milliseconds at the start and end of the file. 

S

It seems that in the end and in spite of some initial dificulties, we have managed to achieve some understanding of what it means for a rip to be bit perfect. I am going to try to wrap-up:

1) + 2) Is it possible to implement a test that is sufficient for bit perfectness. For instace, we can rely on the AccurateRip database to test our rips. A rip that passes the test is (AccurateRip) bit perfect. But we can have rips that do not pass this test (for instance, because our ripping software uses a different CD drive offset than the AccurateRip database) and yet are bit perfect in the sense that, letting apart leading and trailing zeroes (and, of course, metadata) they contain the same bit sequences of AccurateRip bit perfect files. Thus, AccurateRip bit perfectness tests are sufficient but not necessary for bit perfectness. In principle, it would not be difficult to implement a bit perfectness test that is both necessary and sufficient. But, for the time being, we do not have any necessary and sufficient bit perfectness test to share.

3) + 4) Bit perfect rips that have obtained with AccurateRip enabled rippers and AccurateRip recognised drives have to be identical (modulo metadata, of course). But we can have bit perfect files which are different, as discussed above.

Thanks to all those who have contributed towards archieving this understanding. If you think that there is something wrong in this wrap up, please post your objections!

All very interesting. My understanding of AccurateRip is that it compares your rip to a database of previous rips of the same CD. If there are 100 previous rips and 60 are identical, it assumes those are 'correct'. In practice, this seems an excellent solution, but there are theoretical risks. Firstly, even if, hypothetically, 99/100 are identical, there is still a small chance they are incorrect and it is the 1/100 that is right (or indeed that none of them are right). Also, the fewer the rips in their database, the less reliable the data, meaning that more obscure CDs cannot be assessed as rigorously as mainstream ones.

The answer to the OP's questions should perhaps be that 'bit perfect' is achievable to a rational level but, like quantum physics, the closer you look at it, the madder it gets.

nbpf posted:

Jan-Erik Nordoen posted:

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

Interesting observation but more pertinent to the "unitserve rips vs core rips" thread than to the current, in my view. Even if we knew with certainty that two different bit perfect files can sound differently on the same replay device, we still would not know more about the notion of bit perfectness, I'm afraid.

Jan, I have just realized that the "unitserve rips vs core rips" has been closed. Thus, my suggestion to discuss the differences (be these in bit perfectness, sonic quality or whatever else) between US and Core rips in that thread is not anymore viable.

The subject deserves its own thread, in my view. But, should no fundamental objections to my tentative wrap-up come up, I consider the question of what it means for CD rips to be bit perfect well understood and I have no objections if the focus of this thread shifts towards discussing the possible impacts on the sound quality of differences in bit perfect files. 

Solid Air posted:

All very interesting. My understanding of AccurateRip is that it compares your rip to a database of previous rips of the same CD. If there are 100 previous rips and 60 are identical, it assumes those are 'correct'. In practice, this seems an excellent solution, but there are theoretical risks. Firstly, even if, hypothetically, 99/100 are identical, there is still a small chance they are incorrect and it is the 1/100 that is right (or indeed that none of them are right). Also, the fewer the rips in their database, the less reliable the data, meaning that more obscure CDs cannot be assessed as rigorously as mainstream ones.

The answer to the OP's questions should perhaps be that 'bit perfect' is achievable to a rational level but, like quantum physics, the closer you look at it, the madder it gets.

The problem discussed here is not whether the AccurateRip test is reliable or not but whether it is sufficient and necessary for bit perfectness or just sufficient. The temporarily conclusion seems to be that it is just sufficient (and, as you point out, perhaps also not very reliable) and that, for the time being, we do not have a bit perfectness test that can be trusted to be both necessary and sufficient. In practice, this means that we cannot exclude that a rip that does not pass the AccurateRip test is bit perfect. In turn, this implies that it is possible that two bit perfect rips are different. This situation seem to apply, among others, to US and Core rips: both are bit perfect, have the same size but are not equal.

Am I the only person who wants to scream "enough!!!!!!" over this bloody topic?????

No Jon, it's not just you. The previous one was closed, and its bastard offspring has now emerged. Who really cares? Well, some clearly do, but it just goes on and on and on, interminably. If it was in Graham's big red chair, it could be flipped. 

Jon, HH, that's why I stopped posting until you pointed out the excessive angst.  This post is to agree with you.

The details required for further explanation go into information theory and statistics to a level that is completely unnecessary for something of no practical benefit:  If the CD rips OK (i.e. without read error from a computer type drive) then it's fine.

jon honeyball posted:

Am I the only person who wants to scream "enough!!!!!!" over this bloody topic?????

To which sanguine subject do you refer Jon ; bit-perfectness or audible differences in rips?

Jan-Erik Nordoen posted:

jon honeyball posted:

Am I the only person who wants to scream "enough!!!!!!" over this bloody topic?????

To which sanguine subject do you refer Jon ; bit-perfectness or audible differences in rips?

Yes. 

jon honeyball posted:

Am I the only person who wants to scream "enough!!!!!!" over this bloody topic?????

Hungryhalibut posted:

No Jon, it's not just you. The previous one was closed, and its bastard offspring has now emerged. Who really cares? Well, some clearly do, but it just goes on and on and on, interminably. If it was in Graham's big red chair, it could be flipped. 

Huge posted:

Jon, HH, that's why I stopped posting until you pointed out the excessive angst.  This post is to agree with you.

...

jon, HH, Huge, following a thread one does not understand or care about is not compulsory! Just ignore it. You do not need it and it does not need you either. Best, nbpf 

jon honeyball posted:

... 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. 

I have no idea what it means to "descend into technobabble" but I can hardly imagine that this discussion could be in any way offensive to anyone, let apart engineers. I have myself a PhD in engineering and all I can say is that I do not feel in any way offended by laymen discussing themes related with my work. Why should I? I am indeed very confident that the engineers who have designed redbook and the engineers at Naim (and, in fact, most halfway reasonable folks) do not care at all and certainly do not feel offended by our attempts at understanding what it means for CD rips to be bit perfect!

jon honeyball posted:

Jan-Erik Nordoen posted:

jon honeyball posted:

Am I the only person who wants to scream "enough!!!!!!" over this bloody topic?????

To which sanguine subject do you refer Jon ; bit-perfectness or audible differences in rips?

Yes. 

I guess jon is screaming at both subjects :-)