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: cdparanoia and jitter: how to interpret this? (Read 8934 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

cdparanoia and jitter: how to interpret this?

According to the cdparanoia FAQ:

Quote
-    A hyphen indicates that two blocks overlapped properly, but they were skewed (frame jitter). This case is completely corrected by Paranoia and is not a cause for concern.


Quote
+    A plus indicates not only frame jitter, but an unreported, uncorrected loss of streaming in the middle of an atomic read operation. That is, the drive lost its place while reading data, and restarted in some random incorrect location without alerting the kernel. This case is also corrected by Paranoia.


Quote
' ', '-', and '+' symbols in the progress bar are harmless; the resulting audio file should have no defects.


So then, if five rips of the same tracks produce a consistent (confirmed by checksums) cdparanoia ouput that looks like this  --

Quote
outputting to track01.cdda.wav

(== PROGRESS == [      +          +      +          | 031789 00 ] == :^D * ==)


or, say, this --

Quote
outputting to track02.cdda.wav

(== PROGRESS == [ --                                  --- | 031789 00 ] == :^D * ==)


shouldn't I be concerned, FAQ to the contrary? I've always understood, perhaps wrongly, that + errors were equivalent to EAC's "suspicious position" warning. If that is indeed the case, should one really trust that it was "corrected by Paranoia"?

Now, cdda2wav -libparanoia reports such errors in a different way. ( + ) errors are represented as "atom," of which according to the cdda2wav manual --

Quote
atom:  Number of intra sector jitters (frame jitters) detected


and ( - ) errors are rendered thusly:

Quote
edge:  Number of jitters between sectors detected


A cdda2wav -libpranoia output corresponding to the examples above looks like this:

Quote

100% Track 01 recorded with minor problems (1.4% problem sectors)
100%  0 rderr, 0 skip, 42 atom, 0 edge, 0 drop, 0 dup, 0 drift
100%  345 overlap(0.5 .. 0.7908)

100%  Track 02 recorded with minor problems (0.4% problem sectors)
100%  0 rderr, 0 skip, 0 atom, 28 edge, 0 drop, 0 dup, 0 drift
100%  311 overlap(0.5 .. 0.8342)


Note the shift in language from cdparanoia's "corrected" to cdda2wav's mere "detected"; from "this case is completely corrected by Paranoia and is not a cause for concern" to "minor problems" and "problem sectors." Both programs are using the same ripping engine, but one manual appears to contradict the other.

My question is: are these jitter problems being "corrected" or just "detected"? Are my cited examples equivalent to a less than 100.0% track quality in EAC -- a good rip, but rereads and corrections were necessary?

In other words, are these results acceptable or not? The cdparanoia manual says "not to worry, it's fine!" and the cdda2wav elucidation is just vague and contradictory enough to make me wonder how to interpret these results.

cdparanoia and jitter: how to interpret this?

Reply #1 –
This is how I understand it - imagine that you have a layout like this on the disk, and you want to read 12 "units" from the marked position, i.e. starting by E:
Code: [Select]
....v.......
ABCDEFGHIJKLMNOPQRSTUVWXYZ

You also have the previously read data to correlate with (marked by '.', I don't know how big the real overlap is) and so you can determine which of the following cases apply:
  • If you get EFGHIJKLMNOP, it's exactly what you wanted and everything is fine.
  • If you get GHIJKLMNOPQR, it's quite good as well, but "indicates that two blocks overlapped properly, but they were skewed (frame jitter)". It only means that the drive did not start reading where you wanted, but you can use all the data nonetheless. A '-' is shown.
  • If you get EFGHJKLMNOPQ (the 'I' is missing), then "the drive lost its place while reading data, and restarted in some random incorrect location". If the break did not occur in the newly read area, you can use the data as well, showing a '+' mark.  And if yes, it will be corrected during the next read.
I believe these errors are only minor ones and you can safely assume they are corrected by the overlapped reading method alone.
Full-quoting makes you scroll past the same junk over and over.

cdparanoia and jitter: how to interpret this?

Reply #2 –
I've done a bit of testing with EAC 0.95b4 in WINE and GNU libcdio (which uses libparanoia for extraction) on the same hardware.  When libcdio reports no problems, the output files are sample-for-sample identical to those produced by EAC in every case I've tried.  But when libcdio reports problems of any kind, such as edge jitter correction, the files are not the same as those produced by EAC.

I don't know enough about the low-level details of each implementation to say which result is more accurate, however.

cdparanoia and jitter: how to interpret this?

Reply #3 –
I suppose there's really only one way to find out. Here is a very interesting test with cdparanoia that I performed this afternoon. Please bear with me.

This particular test disc (Einstürzende Neubauten's Silence Is Sexy) consistently produces unusual sector jitter symbol patterns in cdparanoia III 9.8 and cdda2wav -libparanoia. I own two copies of this title: a USA pressing and a German one, and both of them exhibit identical behaviour. How strange is that? I can consistently reproduce these jitter flags across two different pressings, using two different drives. Yes, the discs are indeed different pressings. (For instance, the final track on each respective disc is an entirely different song, and the starting sectors are not the same for any of the tracks.) This album is unusual in that many of the songs have long passages of silence between them (anywhere from 6 seconds to more than 30 seconds). EAC, of course, would handle these silent passages as long pregaps, but as we know, cdparanoia does not recognize pregaps as such. Instead it appends each pregap as silence to the end of the preceding track. In other words, a 2 minute song followed by a 2 second pregap will be rendered by cdparanoia as a single WAV file with a duration of 2:02. That is, 2 minutes of audio plus two seconds of silence at the end of the file.

Let us first establish the TOC and starting sector differences between the two discs, using cdda2wav to report. Here is the USA pressing:

Quote
Table of Contents: total tracks:14, (total time 68:45.30)
  1.( 4:39.03),  2.( 7:00.10),  3.( 2:30.52),  4.( 2:01.30),  5.( 5:40.68),
  6.( 3:54.52),  7.( 1:59.43),  8.( 5:43.72),  9.( 7:49.23), 10.( 2:13.72),
11.( 4:43.70), 12.(10:17.30), 13.( 6:16.65), 14.( 3:53.40)

Table of Contents: starting sectors
  1.(      32),  2.(  20960),  3.(  52470),  4.(  63772),  5.(  72877),
  6.(  98445),  7.(  116047),  8.(  125015),  9.(  150812), 10.(  186010),
11.(  196057), 12.(  217352), 13.(  263657), 14.(  291922), lead-out(  309437)


This is the German pressing:

Quote
Table of Contents: total tracks:14, (total time 69:07.32)
  1.( 4:39.07),  2.( 7:00.11),  3.( 2:30.24),  4.( 2:01.67),  5.( 5:40.52),
  6.( 3:54.55),  7.( 2:01.07),  8.( 5:42.74),  9.( 7:48.57), 10.( 2:15.46),
11.( 4:42.21), 12.(10:17.28), 13.( 6:16.64), 14.( 4:15.44)

Table of Contents: starting sectors
  1.(      0),  2.(  20932),  3.(  52443),  4.(  63717),  5.(  72859),
  6.(  98411),  7.(  116016),  8.(  125098),  9.(  150822), 10.(  185979),
11.(  196150), 12.(  217321), 13.(  263624), 14.(  291888), lead-out(  311057)


Here we should note that both discs are in excellent condition. There are no marks, scratches, dust, or other physical defects known to cause hard reading errors; nor does cdparanoia ever report any such read errors while ripping either of the two discs in the usual manner. Eight of the 14 tracks on the disc (either pressing) produce jitter flags during the ripping process. For the sake of brevity, rather than listing every problem track, let us concentrate on a single track that exhibits this odd behaviour, i.e. track 2. This track begins with approximately 6 seconds of silence. This is the way this particular track on the CD was authored, as a deliberate artistic/aesthetic decision.

The purpose of the following test is to investigate the jitter flag behaviour of the cdparanoia output during the ripping process, and to attempt to establish whether or not different jitter flag results produce different waveforms. In order to make certain that these results are reliably consistent, I wrote a script that instructed the computer to rip the track five separate times during each step of the 6-step process, calculate an SHA1 checksum for the newly written WAV file after each pass, then run a hash check comparison on all five files in order to make sure that they matched. Then on to the next step, using the same method.

After the entire run had completed, I ran the ripping test all over again using a different drive; comparing the newly generated checksums to the ones produced from the first test. Happily, they all matched each and every time, so I can state with reasonable certainty that the rips are consistent over multiple passes, on two different drives.

This test was performed on an iMac G5, using OS 10.5.2. The ripping application used was a recompiled cdparanoia III release 9.8 -- the read ahead value increased, per Monty's instructions, to "=300" in order to defeat audio caching on 2 MB drive buffers. The machine's internal DVD drive was not used. Instead, two external firewire drives were employed to carry out this test -- a Plextor PX-W8432T CD burner, and then the same test was performed again using a Pioneer DVR-108 DVD burner. It is important to note that it was necessary to specify the correct offset value for each drive in order to achieve consistency across the board. The Plextor  has an offset of +355, and the Pioneer drive is +48.

(Offsets get short shrift in the OS X/Linux world. In fact, many users remain altogether ignorant of the concept, or, as I once heard one bellicose doofus braying in another forum, "I don't need offsets! That's just a Windows thing." Even though cdparanoia allows for the use of the -O option, most of the popular cdparanoia-driven GUI front ends do not even allow the user to access it. As far as I am concerned, this is an inexcusable design flaw in both xACT and Max -- the two most popular Mac ripping applications. It also goes without saying that the front end designers really need to edit the read ahead value before compiling cdparanoia, but, quite amazingly, none of them have done so! The unfortunate result is that the vast majority of Mac and Linux users are today needlessly struggling with audio caching and offset problems.)


Now for the actual test. Since each test with either drive proved to be identical, I will only list the results from the first test run, using the Plextor.

Performing a straightforward rip of track 2, we consistently get this result:

Quote
cdparanoia -B -d1 -O355 2
cdparanoia III release 9.8 (March 23, 2001)
© 2001 Monty <monty@xiph.org> and Xiphophorus

Ripping from sector  20960 (track  2 [0:00.00])
     to sector  52469 (track  2 [7:00.09])

outputting to track02.cdda.wav

(== PROGRESS == [-------------------------!----| 052469 00 ] == :^D * ==)

Done.


Note the sector jitter symbol throughout, denoted by ( - ). Near the end of the track, the program tosses up a ( ! ) symbol, which the paranoia help describes as "errors are getting through stage 1 but corrected in stage 2."

Remember that this track begins with 6 seconds of complete silence. In order to satisfy a curiosity, let us now begin ripping at 5 seconds after the starting sector of the track. The resulting WAV file will only have 1 second of silence at the start of the track:

Quote
cdparanoia -d1 -O355 -B "2[:05.00]-2[7:00.09]"
cdparanoia III release 9.8 (March 23, 2001)
© 2001 Monty <monty@xiph.org> and Xiphophorus

Ripping from sector  21335 (track  2 [0:05.00])
     to sector  52469 (track  2 [7:00.09])

outputting to track02.cdda.wav

(== PROGRESS == [..........................................| 052469 00 ] == :^D * ==) 

Done.


(Wherever cdparanoia outputs blank ' ' space, denoting a perfect rip, I am substituting ( ....... ) in its place, as the forum does not render the empty set well.)

As you can see above, starting five seconds into the track produced a perfect output. No sector jitter reported.

Now let us begin ripping the track 4 seconds after the start sector:

Quote
cdparanoia -d1 -O355 -B "2[:04.00]-2[7:00.09]"
cdparanoia III release 9.8 (March 23, 2001)
© 2001 Monty <monty@xiph.org> and Xiphophorus

Ripping from sector  21260 (track  2 [0:04.00])
     to sector  52469 (track  2 [7:00.09])

outputting to track02.cdda.wav

(== PROGRESS == [...........................................| 052469 00 ] == :^D * ==) 

Done.


Same result as above. No errors reported.

Three seconds after the start sector:

Quote
cdparanoia -d1 -O355 -B "2[:03.00]-2[7:00.09]"
cdparanoia III release 9.8 (March 23, 2001)
© 2001 Monty <monty@xiph.org> and Xiphophorus

Ripping from sector  21185 (track  2 [0:03.00])
     to sector  52469 (track  2 [7:00.09])

outputting to track02.cdda.wav

(== PROGRESS == [..................................-----| 052469 00 ] == :^D * ==) 

Done.


Sector jitter shown at the end of the track.

Next, the rip begins 2 seconds after the start sector:

Quote
cdparanoia -d1 -O355 -B "2[:02.00]-2[7:00.09]"
cdparanoia III release 9.8 (March 23, 2001)
© 2001 Monty <monty@xiph.org> and Xiphophorus

Ripping from sector  21110 (track  2 [0:02.00])
     to sector  52469 (track  2 [7:00.09])

outputting to track02.cdda.wav

(== PROGRESS == [------------------------------| 052469 00 ] == :^D * ==) 

Done.


Sector jitter reported throughout the track.

Finally, let's rip the track beginning 1 second after the start sector:

Quote
cdparanoia -d1 -O355 -B "2[:01.00]-2[7:00.09]"
cdparanoia III release 9.8 (March 23, 2001)
© 2001 Monty <monty@xiph.org> and Xiphophorus

Ripping from sector  21035 (track  2 [0:01.00])
     to sector  52469 (track  2 [7:00.09])

outputting to track02.cdda.wav

(== PROGRESS == [V.......................................| 052469 00 ] == :^D * ==) 

Done.


Interesting. If it wasn't for the nasty ( V ) symbol ("uncorrected error/skip") at the start, the rip is otherwise perfect. (But since we are dealing with pure silence at the track's beginning, it is not at all audible.) I have no idea why cdparanoia is consistently reporting an uncorrectable error here.

Please keep in mind that, sample for sample, these results are identically reproducible each and every time, on two different drives (provided of course that their offsets are correctly specified in the command line).

What is even more interesting is that the exact same results will occur on BOTH pressings of the disc, and that their checksums will match. The examples above are from the USA pressing. There's no point in listing these again using the German pressing, as they match completely. (If you want to picture how the results from the German disc look, just shift the numbrs back by 28 sectors.)

But if this behaviour isn't odd enough, here is the truly astonishing thing: when the silent intro bits are taken out of the equation, when the audio portions of all of these rips are lined up in a WAV editor, they match completely. There is not a single different sample or anything out of alignment! This fact proves conclusively that cdparanoia does an excellent job coping with problematic sector jitter.

Also keep in mind that this particular disc is by no means a typical example of what you will regularly encounter using cdparanoia. Most discs will rip easily without exhibiting this strange jitter variation. I have absolutely no clue as to why this disc behaves as it does -- on two different pressings, no less; pressings from different continents, with different tracklistings. The exact same sector jitter problems occur consistently on both versions, which seems to indicate that the odd jitter pattern behaviour originates at the mastering, as opposed to the replication, level. Perhaps it originates from a non-compliant CD-R master. I do not know enough about the redbook spec to even venture a guess as to why the jitter patterns are all over the place here. It seems that what may very well be poorly authored/non-compliant pregaps(regardless of length) cause this sector jitter behaviour in cdparanoia. It may also have something to do with the way in which the program appends pregaps to the track. All of the jitter patterns on this disc originate from the pregap sectors. It would be interesting to see how EAC would handle these passages as pregaps. Someone on the EAC forum did write that he had noticed that EAC performed more than usual sector jitter correction on the pregap areas of some discs -- and ONLY on the pregap areas.

The good news is that cdparanoia copes with this sector jitter flawlessly, and it passed this test with flying colors. It is indeed a very robust program.

Although this test disc is an extreme example -- and one of those oddly performing discs of which I have the rare privilege of having two different pressings to compare, I have noticed this behaviour on other discs as well. Maybe 10% of recent discs may have at least one track that triggers these sector jitter ( - ) symbols. Invariably, these symbols occur at either the beginning or the end of the track. I have yet to encounter a disc manufactured in the 1980s that shows any sign of this sector jitter variation -- or a single one manufactured in Japan that does this. That tells me that quality control has gradually gone downhill everywhere but Japan. I can therefore only conclude that Japanese pressing plants check this and reject anything that does not comply fully with the redbook authoring spec. I am unable to find much information about the redbook requirements for pregap compliance. (It would also be interesting to get hold of a Japanese pressing of this title and see how it compares.)

Lest anyone state "I read that cdparanoia cannot handle pregaps without having to perform sector jitter correction," let me emphasize again that this disc is not typical. The application has no problem whatsoever handling what appear to be compliant pregaps (i.e. almost all other discs). Also, cdparanoia has no problem correcting a disc like this one.

Before you ask why I've bothered to run these tests, allow me to say that I was curious as to why this disc behaves so oddly. More to the point, I wanted to see if the cdparanoia jitter correction was actually working. I am now convinced that it works extremely well and rock solidly so.

Besides, user documentation for cdparanoia is rare, and I've never seen anyone attempt to test it in any concerted manner. So at least this is a start.

I will also make brief mention of the importance of having the correct offset value for the drive specified. I did not test this extensively, but having an incorrect or no offset value made things much worse with this disc, producing a few hard (audible)/uncorrectable skip errors -- but only in the pregap areas.

In conclusion, sector jitter  ("edge" errors for cdda2wav) is nothing to worry about. The cdparanoia FAQ is correct. Don't be afraid of the edge errors. The program can handle them.