Tuesday 1 January 2013

CDParanoia Output

So, I've been playing around of late with something to do with ripping CDs. Specifically a tool to make it very easy to rip Audiobook CDs to put onto an MP3 player, but that's not hugely important.

What I've been trying to do is to use the "cdparanoia" tool to actually rip the CD, and then once ripped it can be converted to the appropriate final format using something like lame. Now, cdparanoia has some useful features for wrapping in a script, including a more useful output format that can be parsed. Unfortunately, as best as I can tell, this output format is never documented anywhere! As such, I've finally given up and gone to the source to work out what it means. And here it is...

The output consists of many many lines similar to:


##: 0 [read] @ 175224
##: 1 [verify] @ 0
##: -2 [wrote] @ 1175

Which isn't especially self explanatory... The actual output is:

##: %d [%s] @ %ld

Where the values substituted in are:
%d -> A number indicating the function being performed
%s -> The name of the function being performed
%ld -> The position being worked on.

The bits of interest here are the function being performed, and the position being worked on.

The function being performed is a number between -2 and 13, as follows:
  • -2 -> wrote
  • -1 -> finished
  • 0 -> read
  • 1 -> verify
  • 2 -> jitter
  • 3 -> correction
  • 4 -> scratch
  • 5 -> scratch repair
  • 6 -> skip
  • 7 -> drift
  • 8 -> backoff
  • 9 -> overlap
  • 10 -> dropped
  • 11 -> duped
  • 12 -> transport error
  • 13 -> cache error
I'm not too sure what all of these actually mean, but the important ones are fairly obvious. These are all taken from the strings table in the code, so are the actual mappings between the function ID and the function name in the output. As such, everywhere you see -2 you will always see [wrote], and so on.

The next part of concern is the progress itself. This is represented by the position value, but not in any way that directly relates to any other numbers you can easily get out. In the CD I'm trialling this with, track one  goes from sectors 0 -> 20139, but the position values are all over the place and mostly significantly higher than this. And there is no obvious connection between the numbers, which doesn't help at all.

Again, reading through the code, you eventually discover how this works. The current sector is the position value divided by CD_FRAMEWORDS, where CD_FRAMEWORDS is half CD_FRAMESIZE_RAW and CD_FRAMESIZE_RAW is 2352. This means that if you take the position value and divide it by 1176 - which is half of 2352 - then you get the sector number.Furthermore, the progress bar that is output shows the sector number calculated from the last position value that we saw from a Verify (1) or Wrote (-2) function, and ignores all of the other ones. This is thus the sector that was last written to disc and not the last sector read. As proof of this, for the CD I'm playing with, the very last output line for a function of Wrote had a position of 23683463, which works out to be sector 20138.9991496599

There's then a whole lot of logic surrounding exactly which smiley face to show, how the progress bar line gets written and so on, but most of that is stuff that external programs don't need to care about.

No comments:

Post a Comment