libcdio-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-help] Problem using cdio_read().


From: R. Bernstein
Subject: [Libcdio-help] Problem using cdio_read().
Date: Sun, 25 Feb 2007 11:17:44 -0500

address@hidden writes:
 > 
 > 
 > just a question ,I'm trying to extract and read a cd but i always get an 
 > error
 > with the function cdio_read()
 > 
 > i get the tracks number ,the lsn every thing but i still can't read
 > 
 > 
 > here mys source:
 > int main()
 > {
 >      CdIo*disc;
 >      driver_id_t d_id;
 >      char**search;
 > 
 >      disc=cdio_open ("/dev/cdrom", DRIVER_DEVICE);
 > 
 >      if (disc==NULL)
 >      {
 >              printf("erreur");
 >      }
 >      else
 >      {
 >              cdio_get_default_device(disc);
 >              int i=0;
 >              lsn_t x;
 >              x=cdio_get_track_lsn(disc,2);
 >              printf("lsn  %ld\n",x);
 >              void*buf;
 >              FILE *fildes;
 > 
 >              fildes=fopen("essai","w");
 >              if (fildes==NULL)
 >              {
 >                      printf("erreur");
 >                      return ;
 >              }
 >              buf=malloc(1024);
 >              while(i<x)
 >              {
 >                      off_t y;
 >                      size_t v;
 >                      v=1024;
 > 
 >                      ssize_t x=cdio_read(disc,buf,v);
 >                      if (x=-1)
 >                      {
 >                              printf("erreur lecture\n");
 >                      }
 >                       fwrite (buf,1024, 1, fildes);
 >                      i+=1024;
 >              }
 >      }
 > }
 > 
 > 
 > 
 > 
 > thanks for your concern
...

cdio_read() is what's called a "cooked" and relies on routines in the
OS. Audio tracks generally can't be read this way, so I'm guessing
that's what the problem is. 

It would be good to see the actual error message you are getting and
perhaps some information about the type of CD you are trying to read.

More generally when you report a bug it's good to give

  1. Your input (e.g. what you typed). The program above also
     constitutes input too, so it that's good you included this.

  2. What you got back - the exact output. Often people will omit this
     and offer their interpretation of what they think output means,
     or what they think is wrong. Without the details, such interpretations
     are less helpful.

  3. If it's not otherwise obvious, you should state what you expected
     to get back. In this case I think this is not needed unless the
     data you (eventually) get back doesn't match your expectation.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]