Skip to main content


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: CUERipper and sync errors/jitter (Read 1617 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUERipper and sync errors/jitter

Does CUERipper detect synchronization errors/"jitter"?

I ripped a scratched CD in secure mode with 2.1.5 earlier this year and got some audible errors. Today (I've been meaning to try this for a while), I hooked up a standalone CD player and played the CD from start to finish, recording its SPDIF output through the SPDIF input of my soundcard. The result had no audible errors. I trimmed the ends of this file so that it matches CUERipper's rip, i.e. it's the same duration and the waveforms are perfectly aligned.

I then inverted this audio and 50/50 mix-pasted it over the audio of the original rip to see where the differences were. In all but one case, the differences were all single samples that the standalone player was apparently better at reading or concealing, and they were all in the places reported as suspicious positions in the log. So far so good.

There was one anomaly, though.

In the middle of the old file that CUERipper had produced, in a place where there weren't any suspicious positions reported, there was a 382-block chunk that I could now see was offset by -360 samples. That is, the first 360 samples of this chunk were a repeat of the previous 360. I manually repaired this 382-block section by pasting in the equivalent section from the SPDIF rip.

Now I'm wondering what happened with CUERipper. If CUERipper asked the drive for 382 blocks, and it got back 382 that were offset by some odd amount, shouldn't it have noticed this?

I'm also wondering what it means for a drive that supposedly supports Accurate Stream to be producing an offset chunk, assuming that's what happened.

CUERipper and sync errors/jitter

Reply #1
I reported a similar problem. In my case the CD would rip in EAC but not CUERipper possibly due to a factory defect that CUERipper couldn't handle. Similar repeated block of samples plus a much larger chunk of offset samples within the track. Grigory was going to see if he could duplicate the error with a copy of that CD but said it could take some time.

CUERipper and sync errors/jitter

Reply #2
Interesting that you've seen the same symptoms.

I tried the same scratched CD with EAC today and got similar results. In burst mode, no problem... some wrong samples but not too far off from where they should be. In secure mode, in the area of the same scratch as caused problems in CUERipper, there's a 478-block chunk that's offset by -276 samples.


Maybe this offset is not happening at a boundary—like, the ripper asks for a certain range, and the offset portion is in the middle of the range, so it's not being tested for synchronization. It would be also be interesting to see what the drive is returning in each re-read.

CUERipper and sync errors/jitter

Reply #3
I can't find my notes. I'm afraid I may have deleted them after sending the info to Grigory. I do remember I tested the CD repeatedly on 5 different drives. Similar result on three drives. The other two drives ripped the CD OK. One of the problem drives was a Samsung TSSTcorp CDDVDW SH-S203B. That's all I remember for now.

SimplePortal 1.0.0 RC1 © 2008-2021