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: The impossible ripping (Read 2669 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The impossible ripping

Hello, I am new to the forum and I send a big greeting to all.


My native language is not English so I feel sorry for my mistakes and I appreciate your understanding.


I would appreciate it if you could help me in a topic that has me stuck without being able to rip my CDS for not being able to do it correctly due to a failure that ruins my scan completely.

Every time I buy a new CD I immediately rip it home.

I ripped my CDs with DBpoweramp and used a Plextor PX-891sa drive, displacement +6.
Immediately and as I rip security and confirmation, I use an HG70N, scroll +667.

My method is the following:

First ripping with the drive Plextor PX-891SA unit, Mediatek chipset, displacement +6.
Result; all the correct tracks matching CRCs.
copy ok

Second ripping with the drive HG70N unit, Renesas chipset, offset correction +667.
Result; all the correct tracks matching CRCs.
copy ok

When registering and collating the logos of the different rips with one and another unit, all the tracks coincide except the beginning of the last track, the error is always at the beginning of the last track.
This last track never matches, and yet Dbpoweramp gives the scan as good and accuraterip verifies it with confidence 200. This is repeated with approximately 90% of the CDS that I rip.
 
Comparing the resulting Wav of the Plextor and the Hg70n in the audio editor the result is that the Plextor in that last track loses 661 samples in comparison to the wav produced by my HG.

This results in a different CRC for each reader unit.

The reading of the wav in the Nero Wave Editor does not show anything abnormal ... The wav files separately are fine but by comparing them they do not coincide?

The plextor is missing 661 samples and the HG is missing 6, this is grotesque!


These missing samples correspond to music or are samples of silence outside the normal and musical range of the CD?

There's the error, in those missing samples, but why does this happen and how do I solve it, like ripping without missing those samples?

These samples are lost in sector 0: 09: 10: 624 - 0: 09: 10: 639, sometimes in 00: 00: 00: 00.
This range to which sector of the CD corresponds, pregap, lead-out or CD music range?

Are the units reading the pregag, one 6 samples and another 667 samples?
These units do not read lead-in or lead-out, so ... What happens?

The displacement of the plextor added to the missing samples results in the displacement of the HG, 661 + 6 = 667.
What can this mean?


Can I give the ripping as valid if two different optical units create different CRCs?

The CDS are quality newly purchased in stores of musical prestige and with the CDDA seal. As they are products that respect the CD format, I take it for granted that it is not C2 errors or errors produced by any anti-copy system.

If I do not rip the same CD in two different units, I do not know what happens.


Naturally, I tried with EAC to see what happened and the error is extended to all the tracks and not just to the last one.


What an irritating enigma!

Thank you all and a greeting from Madrid.
Pionnered S.

Re: The impossible ripping

Reply #1
all the tracks coincide except the beginning of the last track, the error is always at the beginning of the last track.

Sure it is at the "beginning" of the last track? Not at the end?

It is hardly a coincidence that 661 equals 667-6 ...

Re: The impossible ripping

Reply #2
Quote
The plextor is missing 661 samples and the HG is missing 6, this is grotesque!
I'm pretty sure it's silence and 661 out of 44,100 samples per second is only 15 milliseconds.

Re: The impossible ripping

Reply #3
@Pionnered:
Quote
These samples are lost in sector 0: 09: 10: 624 - 0: 09: 10: 639, sometimes in 00: 00: 00: 00.
This range to which sector of the CD corresponds, pregap, lead-out or CD music range?
I am not sure what you mean about the 00:00:00:00, but I take it that 9:10:624 is the end of the last track?

Here is the point: an offset correction of 667 means that dBpoweramp shifts the bitstream 667 samples to correct for what the drive does. But unless you choose the option to read into lead-in/lead-out - and the drive supports it - it means that 667 samples will have to be inserted, and they are blank. On the CD itself, the music stops earlier in all cases I have encountered (probably because of issues like these!) - but it could be just the background noise from the master tape.
Take note that a physical stand-alone CD player need not behave any different.

* I suggest you do the following:
Install the foobar2000 media player (Hydrogenaudio hosts its official forum, and there is a lot of help to get).
Download the foo_bitcompare component and install it (in foobar2000: Ctrl+P (or: File -> Preferences) and then Components at the top).
Compare the two tracks. Post the output here.
I expect that you will get an output saying that 661 samples differ at the end, that they are silent in one of the tracks, and that the peak difference is a very small number.


Also, I see that you use dBpoweramp-
Make sure that it writes complete logs: https://www.dbpoweramp.com/images/cd-rip-guide-opt-2.png
Not sure if we will need them for this problem, but anyway: logs are good for you, generally ;-)

Re: The impossible ripping

Reply #4
Unless your drives can overread, you will lose start or end samples depending on the drive offset. AccurateRip works with all drives so this data is not taken into account.

Re: The impossible ripping

Reply #5

Thank you all for your answers

They have helped me a lot in another perspective on the problem and I really believe that it is a mistake at the end of the last clue and not at the beginning of it as I mistakenly believed.

Porcus:
I acted as you said, I downloaded foo_bitcompare and installed it in the Foobar components. However, after trying it I do not know how, where to enter? Foobar to execute it?

If you indicate to me how I do it in the Foobar, as soon as I have the analysis, I upload it immediately.

Keep in mind that I am a dilettante in these matters and this is where I begin to learn.

I have already configured dbpoweramp as you pointed me, but in a new ripping, the analysis remains unchanged, keeping the missing tracks.

I hope, as you say, that it is a different reading to the rhythm and that it contains the digital silence in the range of the lead-out, without affecting the music.
If so, what I do not understand is why does not it happen with all the CDs?

On the other hand, point out that mature with EAC and the result was very bad. EAC produces error in all the tracks and not only in the last as it happens with Dbpoweramp.

Thank you
Pionnered S.

Re: The impossible ripping

Reply #6
I acted as you said, I downloaded foo_bitcompare and installed it in the Foobar components. However, after trying it I do not know how, where to enter? Foobar to execute it?
You open both files in foobar2000. With both marked (click on one, shift+click the other) in the playlist, you right-click and choose Utilities -> Bit-compare tracks.

Post the output.

You can also do this with multiple files: drag + drop the first folder, and drag + drop the second "above the first track already there".
Take note that they are in order say 1, 2, ..., 9, 1, 2, ..., 9.
Select all, either by Ctrl+A or Edit->Select All.
Right-click -> Utilities -> Bit-compare tracks.
foobar2000 will compare the top half with the bottom half. (It has no way of "reordering", so you must have the order right yourself!)

I have already configured dbpoweramp as you pointed me, but in a new ripping, the analysis remains unchanged, keeping the missing tracks.
"missing tracks"? You mean, differing tracks?

Telling dBpoweramp to write logs will not change how it rips. It just gives you log files you can read to understand what is going on. Let's do the foo_bitcompare first.

and that it contains the digital silence in the range of the lead-out, without affecting the music.
If so, what I do not understand is why does not it happen with all the CDs?
Because it often isn't "digital silence". It is "the end of the tape", and so there is some signal there. Think of a vinyl record. At the end there is a locking groove. If you stop listening after it has gone half a round in the locking groove, you "lose" something that's there - but certainly nothing valuable.
The offset correction is because drives never ended up on one single way of determining where the disc should start and where it should end. One of your drives will read 661 samples more at the beginning than the other, and 661 samples less at the end.

EAC produces error in all the tracks and not only in the last as it happens with Dbpoweramp.
I would then guess that you have made some wrong configuration. (dBpoweramp is easier to configure, I think.)
You could try to let fb2k compare a folder ripped with EAC with one ripped with dBpoweramp. I have an idea what will show up.

Re: The impossible ripping

Reply #7
I already have it!

The Foobar editor threw these results ...



https://i.imgur.com/0pHIMZa.jpg


Pionnered S.

Re: The impossible ripping

Reply #8
TL;DR: this is about as expected.

Listen to the music: about when in the track does the actual music end?

To interpret the log:
So the track length is 9:10.64 (number of samples / 44100).
Differences start 667 samples before the end (not the beginning!)
667 is is the offset of one of the drives. 667 samples each channel, so the number of differences could be at most 1334. It is 1290.
The greatest difference is 0.0003052 in the right channel. That is some thirty-four dB below the peak of the track. In the left it is about the same.

Re: The impossible ripping

Reply #9
The music ends at 09:07 and the full track at 09:10:64. The different samples are produced between these two moments, in the minute 09: 10: 624 and the minute 09: 10: 639, outside the range of the song.

This also happens in the other CDs, in all it happens outside the range of the music and almost ending the track.

I do not know if I will be correct, but I have concluded that it is a problem of the different characteristics of each optical unit and not an error of the CD itself.

You can not confirm the ripping with a different chipset unit because it will give different readings depending on its displacement index.
To use a second reading unit as confirmation of an effective ripping and without errors, two reading units with different chipsets capable of Overloading each of them are needed.

It is better to rip with +6 than with +667 of displacement, supposedly less data will be lost.

Why does not it happen on all CDs and do I have correct ripping with identical CRCs confirmed with the two units despite their different characteristics?

Are the units reading out of the range of the CD in the lead-out without the ability to overread?

If it is not sound of what nature these missing samples are? I understand that outside of music there should not be data.

The problem does not affect the music, therefore it is a good ripped or I have to look for a unit capable of Overread?
Pionnered S.

Re: The impossible ripping

Reply #10
The music ends at 09:07 and the full track at 09:10:64. The different samples are produced between these two moments, in the minute 09: 10: 624 and the minute 09: 10: 639, outside the range of the song.

This also happens in the other CDs, in all it happens outside the range of the music and almost ending the track.

That is as expected. It happens with audio CD players too. There is a good reason not to make the CD with track ending at the knife-edge end of the music. And not to start the music at the absolute beginning of track 1 index 1.

I do not know if I will be correct, but I have concluded that it is a problem of the different characteristics of each optical unit and not an error of the CD itself.

Correct!

It is better to rip with +6 than with +667 of displacement, supposedly less data will be lost.

Well ... the track extends into the "useless" part, and that secures against this - although one could think of cases where they have not been so smart when manufacturing the CD.  So "kinda yeah", but would you ever encounter a case where it matters?


In the table at http://www.accuraterip.com/driveoffsets.htm you find offsets up to at least +1776. Negative offsets are rare, but you find -1164. The difference between those two is 1/30th of a second. The +667 is 15 ms.

Why does not it happen on all CDs and do I have correct ripping with identical CRCs confirmed with the two units despite their different characteristics?

Because on many CDs, it is indeed digital silence. One of them will read digital silence, and the other will miss 15 ms and replace it by digital silence.

If it is not sound of what nature these missing samples are?
It is "sound". But if the music is over and all you got is tape hiss at -35 dB, you won't notice that it stops turns to silence 15 milliseconds shorter earlier.

 

Re: The impossible ripping

Reply #11

These explanations have been of great help to me and the matter has been quite clear to me.

Thanks Porcus and a great greeting :)
Pionnered S.