[gst-devel] Problems to rip CD using cdparanoiasrc

[Pascal Ognibene]

2010/1/23 Tim-Philipp Müller <t.i.m at zen.co.uk>

> On Fri, 2010-01-22 at 21:27 +0100, Pascal Ognibene wrote:
>
> Hi,
>
> > I'm trying to rip a CD using a simple gstreamer pipeline (..)
> > In the code below, I basically use the EOS event to seek to the next
> > cd track.
> > But the behavior I see is weird:
> > -the first track is ripped ok
> > -I call the start_track_rip function for track 2
> > -the program blocks here forever.
> >
> > I must be doing something really wrong but I can't see what, even by
> > the looking at the sources of sound juicer for example.
> > Any help is welcome,
>
> Not related to your problem at all, but you might want to add a queue
> after cdparanoiasrc to make sure encoding continues if there are
> problems reading the CD (dirt on the disc etc.).
>
> I haven't actually run your code, but it looks to me like you get an EOS
> and then change the track number via the property and that's it.
> However, when you get the EOS, streaming has already stopped,
> cdparanoiasrc is not running any longer. At that point, setting the
> property will not make it start up again.
>
> You have two options here:
>
> a) set pipeline state back to READY (or NULL), then change to PLAYING
> again.
>
> b) issue a seek in "track" format (track number might be 0-based in this
> case, don't remember exactly) to make it start up again.
>
> (b) might work in this particular case where you're just writing mp3
> data to a file, but (a) is likely to work better in general, esp. with
> other encoders, if you add muxers or if you add a tag writer.
>
> So in short, try changing
>
>  gst_element_set_state(sink, GST_STATE_NULL);
>
> at the beginning of start_track_rip() to
>
>  gst_element_set_state(pipeline, GST_STATE_NULL);
>


Thank you for your help!

Actually, I stepped through the Sound Juicer code using gdb, and discovered
that they destroy and recreate the pipeline for each track they rip.
I've done the same, and it works fine. I'll try your solution as well to see
if i can get faster seek operations between tracks.
Oh, and I'm going to add a queue in the middle as per your excellent
suggestion - I've been testing with a brand new CD so did not meet rip
glitches yet,
but this will happen for sure in "real life".

Cheers,

-pog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100125/b9c14f2e/attachment.htm>