[paranoia-dev] Wrapper program difficulties

[Monty]

> The default output (progress bar, smilies and all) is more machine-readable
> than the information provided by the -e --stderr-progress switch!  Because of
> an unfortunate isatty call, however, cdparanoia refuses to provide its
> default progress-bar ouput, forcing the wrapper to use the -e switch.

The isatty() call is a 'damned if you do, damned if you don't' situation.  It's
there becaQuse of a multitude of complaints I from users about piping the 
output
to a file.

> Except that -e does not print a beginning and an end, so the wrapper cannot
> calculate a progress bar.  

Hmm, that's a fair complaint.  -e does give give a start and end, but not in
the same format as the rest of the information, eg:

Ripping from sector      32 (track  1 [0:00.00])
          to sector   20094 (track  1 [4:27.37])

outputting to cdda.wav

##: 0 [read] @ 63504
##: 0 [read] @ 128184
##: 0 [read] @ 192864
##: 0 [read] @ 212856
##: 0 [read] @ 47040
##: 0 [read] @ 111720
##: 0 [read] @ 176400

> If the wrapper is written in a high-level language,
> it will not know CD_FRAMESIZE_RAW, which means it cannot even determine the
> sector!  

CD_FRAMESIZE_RAW is always 2352 bytes per sector.  This will not vary.

> Finally, cdparanoia outputs a huge amount of unneeded information,
> hurting system performance (important when you're ripping AND encoding at
> the same time).

It tells you every detail of what it's doing.  It's probably worthwhile to be
able to pare this down.  However, the cdparanoia app was never meant to be a 
high-performance programming interface.  The library was meant for 
performance...

In other words, I tried to plan ahead for all the reasonable uses people would 
think of, but I didn't necessarily come to all the correct conclusions.

> After looking at the source, I think that adding intelligible, machine-
> readable output to cdparanoia should not be too hard...  I'll do it and
> submit a patch if it's a good idea.  Please tell me if I'm missing
> something or if making Paranoia wrappable would be time well spent.

I don't think you're missing that much; the -e output can stand improvement, 
nor should improving -e be that difficult.  If the existing cdparanoia is the 
wrong fit for your application, you can also code something exactly to your 
tastes farily easily; cdparanoia itself is just a thin shell around the two 
libraries included in the distribution (and release 10/pIV will be the same).

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Paranoia homepage: http://www.xiph.org/paranoia/
To unsubscribe from this list, send mail to 'paranoia-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.