Can not read VCD file in Linux

Discussion in 'C Programming' started by rlp1938, Feb 1, 2011.

  1. rlp1938

    rlp1938 Guest

    In Windows I can copy VCD from the CD files but in Linux the copy
    fails so I wrote a C program to try to copy from the VCD myself.

    Running the program gives this result.
    file read error
    Count 0
    Input/output error
    Count 0
    File desc: 3
    Count 0
    last failure: Input/output error

    What is the difference between Windows and Linux (Ubuntu 10.4) that I
    cannot read the file in Linux?

    Here is the program below:

    /* tryread.c - attempt to read from a cd that gives errors under
    Linux but copies using Windows
    */

    #include <stdio.h>
    #include <errno.h>
    #include <stdlib.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <unistd.h>

    int main(int argc, char ** argv) {
    char *fname = "/media/สร้าง/MPEGAV/AVSEQ01.DAT"; // the file under
    test
    FILE *fpi, *fpo;
    size_t bytes;
    char buf[2048];
    size_t count = 0;
    int ch;
    int fdi; // file descriptor for open(..

    // first attempt - use fread
    fpi = fopen(fname, "r");
    if (!(fpi)) {
    perror( fname );
    exit(1);
    } // if()
    fpo = fopen("test.dat", "w");
    while ((bytes = fread(buf, 1, 2048, fpi)) != 0){
    (void) fwrite(buf, 1, bytes, fpo);
    count += bytes;
    } // while()
    if (feof(fpi)) {
    puts("end of file found");
    } // if()
    if (ferror(fpi)) {
    puts("file read error");
    } // if()
    fprintf(stderr, "Count %d\n", count);

    // ok the above failed so try char by char
    fclose(fpi);
    fpi = fopen(fname, "r");
    count = 0;
    while( (ch = fgetc(fpi)) != EOF ) {
    count++;
    fputc(ch, fpo);
    } // while()
    perror("");
    fprintf(stderr, "Count %d\n", count);

    // ok another failure logged so let's try the lower level stuff
    fclose(fpi);
    fdi = open(fname, O_RDONLY);
    fprintf(stderr, "File desc: %d\n", fdi);
    count = 0;
    while ( (bytes = read(fdi, buf, 2048)) != -1) {
    count += bytes;
    fprintf(stderr, "Read: %d\n", count);
    } // while()
    fprintf(stderr, "Count %d\n", count);
    perror("last failure");
    fclose(fpo);
    return 0;
    } // main()
     
    rlp1938, Feb 1, 2011
    #1
    1. Advertising

  2. rlp1938

    Alan Curry Guest

    In article <>,
    rlp1938 <> wrote:
    >In Windows I can copy VCD from the CD files but in Linux the copy
    >fails so I wrote a C program to try to copy from the VCD myself.
    >
    >Running the program gives this result.
    >file read error
    >Count 0
    >Input/output error
    >Count 0
    >File desc: 3
    >Count 0
    >last failure: Input/output error


    The "Input/output error" you're getting from perror is telling you that the
    kernel was unable to read the file from the disk. Writing your own C program
    hasn't revealed anything that you couldn't have learned using cat.

    There might be some information about why the read failed in the kernel log.

    --
    Alan Curry
     
    Alan Curry, Feb 1, 2011
    #2
    1. Advertising

  3. rlp1938

    rlp1938 Guest

    On Feb 1, 1:05 pm, (Alan Curry) wrote:
    > In article <..com>,
    >
    > rlp1938  <> wrote:
    > >In Windows I can copy VCD from the CD files but in Linux the copy
    > >fails so I wrote a C program to try to copy from the VCD myself.

    >
    > >Running the program gives this result.
    > >file read error
    > >Count 0
    > >Input/output error
    > >Count 0
    > >File desc: 3
    > >Count 0
    > >last failure: Input/output error

    >
    > The "Input/output error" you're getting from perror is telling you that the
    > kernel was unable to read the file from the disk. Writing your own C program
    > hasn't revealed anything that you couldn't have learned using cat.
    >
    > There might be some information about why the read failed in the kernel log.


    Indeed there is:
    [ 570.427740] end_request: I/O error, dev sr0, sector 5068

    That's the last line from dmesg.

    I still don't know why it is that is copies under Windows. NB the copy
    is far from perfect but that is quite normal for VCDs in Thailand
    where I am presently.

    Bob Parker

    >
    > --
    > Alan Curry
     
    rlp1938, Feb 1, 2011
    #3
  4. rlp1938

    Paul Guest

    rlp1938 wrote:
    > On Feb 1, 1:05 pm, (Alan Curry) wrote:
    >> In article <>,
    >>
    >> rlp1938 <> wrote:
    >>> In Windows I can copy VCD from the CD files but in Linux the copy
    >>> fails so I wrote a C program to try to copy from the VCD myself.
    >>> Running the program gives this result.
    >>> file read error
    >>> Count 0
    >>> Input/output error
    >>> Count 0
    >>> File desc: 3
    >>> Count 0
    >>> last failure: Input/output error

    >> The "Input/output error" you're getting from perror is telling you that the
    >> kernel was unable to read the file from the disk. Writing your own C program
    >> hasn't revealed anything that you couldn't have learned using cat.
    >>
    >> There might be some information about why the read failed in the kernel log.

    >
    > Indeed there is:
    > [ 570.427740] end_request: I/O error, dev sr0, sector 5068
    >
    > That's the last line from dmesg.
    >
    > I still don't know why it is that is copies under Windows. NB the copy
    > is far from perfect but that is quite normal for VCDs in Thailand
    > where I am presently.
    >
    > Bob Parker
    >
    >> --
    >> Alan Curry

    >


    First off, I don't work with media like this, but this smacks of
    a copy protection scheme.

    First you have to figure out what kind of copy protection it is using.
    There is a suggestion here, that the table of contents is corrupted
    in a certain way (on purpose, to make copying difficult). The info
    on the CD, will be claiming the CD is bigger than is physically healthy.

    http://club.myce.com/f80/how-beat-copy-protection-112451/

    For Linux, I would try using "dd" to copy the media first to the hard
    drive. Then mount the resulting file "-t iso9660" or the like.

    "Mounting an ISO image from an ordinary file."
    http://wiki.linuxquestions.org/wiki/Mount

    dd if=/dev/cdrom of=NameOfISOFile.iso

    mount -t iso9660 -o ro,loop=/dev/loop0 NameOfISOFile.iso MountPoint

    Something along those lines. The "dd" command works sector by sector,
    rather than relying on the (fake) information in the directory structure.
    This won't exactly solve the problem, because the file system info
    in the virtually mounted CD will still be wrong. But at least you'll
    have proved there isn't a "weak sector" or anything. (Weak sectors
    are another trick for copy protection etc.)

    (Some references to weak sectors, here.)

    http://en.wikipedia.org/wiki/SafeDisc

    To give another example of differences between sector by sector
    access, versus file system level access, I made a home-made movie
    DVD (dual layer, about 7GB), and if I attempt to copy the files
    off the disc, they copy at about 1X and not faster. If instead,
    I use the above "dd" style command, and create a 7GB "NameOfISOFile.iso",
    the file copies at the media limit of 2.4X. I then mount the ISO as above,
    and can extract out the individual files at hard drive speeds. The
    "dd" step saves time overall, because, for some reason, the sector
    by sector copy is not "rip locked". And that is an unprotected disc,
    because I made the disc myself. There is nothing wrong with the actual
    data content, just the response of the optical drive to reading it.

    Paul
     
    Paul, Feb 1, 2011
    #4
  5. rlp1938

    rlp1938 Guest

    On Feb 1, 6:30 pm, Paul <> wrote:
    > rlp1938 wrote:
    > > On Feb 1, 1:05 pm, (Alan Curry) wrote:
    > >> In article <>,

    >
    > >> rlp1938  <> wrote:
    > >>> In Windows I can copy VCD from the CD files but in Linux the copy
    > >>> fails so I wrote a C program to try to copy from the VCD myself.
    > >>> Running the program gives this result.
    > >>> file read error
    > >>> Count 0
    > >>> Input/output error
    > >>> Count 0
    > >>> File desc: 3
    > >>> Count 0
    > >>> last failure: Input/output error
    > >> The "Input/output error" you're getting from perror is telling you that the
    > >> kernel was unable to read the file from the disk. Writing your own C program
    > >> hasn't revealed anything that you couldn't have learned using cat.

    >
    > >> There might be some information about why the read failed in the kernel log.

    >
    > > Indeed there is:
    > > [  570.427740] end_request: I/O error, dev sr0, sector 5068

    >
    > > That's the last line from dmesg.

    >
    > > I still don't know why it is that is copies under Windows. NB the copy
    > > is far from perfect but that is quite normal for VCDs in Thailand
    > > where I am presently.

    >
    > > Bob Parker

    >
    > >> --
    > >> Alan Curry

    >
    > First off, I don't work with media like this, but this smacks of
    > a copy protection scheme.
    >
    > First you have to figure out what kind of copy protection it is using.
    > There is a suggestion here, that the table of contents is corrupted
    > in a certain way (on purpose, to make copying difficult). The info
    > on the CD, will be claiming the CD is bigger than is physically healthy.
    >
    > http://club.myce.com/f80/how-beat-copy-protection-112451/
    >
    > For Linux, I would try using "dd" to copy the media first to the hard
    > drive. Then mount the resulting file "-t iso9660" or the like.
    >
    > "Mounting an ISO image from an ordinary file."http://wiki.linuxquestions.org/wiki/Mount
    >
    >     dd if=/dev/cdrom of=NameOfISOFile.iso
    >
    >     mount -t iso9660 -o ro,loop=/dev/loop0 NameOfISOFile.iso MountPoint
    >
    > Something along those lines. The "dd" command works sector by sector,
    > rather than relying on the (fake) information in the directory structure.
    > This won't exactly solve the problem, because the file system info
    > in the virtually mounted CD will still be wrong. But at least you'll
    > have proved there isn't a "weak sector" or anything. (Weak sectors
    > are another trick for copy protection etc.)
    >
    > (Some references to weak sectors, here.)
    >
    > http://en.wikipedia.org/wiki/SafeDisc
    >
    > To give another example of differences between sector by sector
    > access, versus file system level access, I made a home-made movie
    > DVD (dual layer, about 7GB), and if I attempt to copy the files
    > off the disc, they copy at about 1X and not faster. If instead,
    > I use the above "dd" style command, and create a 7GB "NameOfISOFile.iso",
    > the file copies at the media limit of 2.4X. I then mount the ISO as above,
    > and can extract out the individual files at hard drive speeds. The
    > "dd" step saves time overall, because, for some reason, the sector
    > by sector copy is not "rip locked". And that is an unprotected disc,
    > because I made the disc myself. There is nothing wrong with the actual
    > data content, just the response of the optical drive to reading it.
    >
    >     Paul


    dd gives errors also. I got 624 kb off the device.

    I need some way of grabbing the stuff but somehow ignore the errors as
    Windows does.

    I downloaded and compiled cdrtools which includes readcd. That failed
    also.

    Thanks for the links.

    Bob
     
    rlp1938, Feb 2, 2011
    #5
  6. rlp1938

    jacob navia Guest

    Le 02/02/11 15:30, rlp1938 a écrit :
    > I need some way of grabbing the stuff but somehow ignore the errors as
    > Windows does.
    >


    (1) Start windows
    (2) Copy the cd into a file in the hard disk
    (3) Read THAT from linux, or make a new CD under windows
     
    jacob navia, Feb 2, 2011
    #6
  7. rlp1938

    rlp1938 Guest

    On Feb 3, 6:57 pm, (Gordon Burditt) wrote:
    > > Another option, depending on what you mean by "ignore the errors" (what,
    > > exactly, do you want to do with the part of the file that wasn't read), is
    > > to do something like this (untested pseudo-code):

    >
    > >     Open the source file (binary mode).
    > >     Open the destination file (binary mode).
    > >     Set "current offset" to 0.
    > >     While you haven't reached EOF:
    > >         Read a "chunk" from the file.  (#define "chunk" size)
    > >         If failed, retry up to X times.  (#define the retry count)
    > >         Add "chunk" size to "current offset".
    > >         If still failed:
    > >             Seek source file to "current offset".
    > >             Fill buffer with zeroes (or something else).
    > >         Write buffer to destination.
    > >         (Handle write errors.)
    > >     Close files.

    >
    > I prefer the following logic, and it's proved very useful in
    > recovering CDs (and when I first wrote it, floppies), even one with
    > light visible all the way through it at the edge of recorded data.
    > The most important parameters are input file/device, output file,
    > and the block size (2048 for CDs, 512 for floppies (usually, 128
    > sometimes), 512 (usually) for hard disks).
    >
    > >     Open the source file OR DEVICE (for (UNIX/Linux) (binary mode).
    > >     Open the destination file (binary mode) IN w+ mode, so

    >
    >         you don't wipe out the existing file.>     Set "current offset" to 0.
    > >     While you haven't reached EOF:

    >
    >           Seek source file to "current offset".
    >
    > >         Read a "chunk" from the file.  (#define "chunk" size)

    >
    > The chunk size should be equal to or a multiple of the physical
    > device sector size.  Sometimes UNIX or Linux device drivers won't
    > let you read other than whole sectors and give you a very quick
    > error.  Anyway, there's less work buffering in the OS if you stick
    > to whole-sector alignment and length.
    >
    > I use an adaptive block size which is a multiple of the physical
    > sector size.  It starts off large when there are no errors (this
    > can speed up copies where there are no errors by a factor of 5),
    > and reduces it when it gets an error.  Don't declare a block bad
    > until you've tried to read *only* that sector and failed, otherwise
    > you don't know which sector is bad.
    >
    > >         If failed, retry up to X times.  (#define the retry count)
    > >         If still failed:

    >
    >                 Do not write anything to destination.
    >                 The next read that succeeds will seek over this spot
    >                 and write the data later, leaving an unwritten hole.
    >                 If your OS absolutely won't accept this, write a
    >                 buffer of something recognizable, like all zeroes.
    >
    >                 What does Windows do in this situation?
    >                 (1) give an error on a seek past end-of-file
    >                 (2) write zeroes (or some other pattern) for the
    >                     unwritten data?
    >                 (3) Permit holes in files that read as 0 bytes?
    >           else
    >                 Seek destination file to "current offset"..>            Write buffer to destination.
    > >            (Handle write errors.)

    >           endif
    > >         Add "chunk" size to "current offset".

    >
    >       end while
    >         Actually, here I have logic that keeps track of the bad spots and
    >         goes back and tries them again.  Repeatedly.  And there's a
    >         curses-based display which shows the bad blocks, removing blocks
    >         from the list as retries manage to read them.>     Close files.
    >
    >         Display a list of the blocks you never could read, if any..
    >
    > When you run this, you get a file with unwritten holes (these read
    > as zeroes on UNIX) corresponding to the unreadable spots in the
    > source file.  I am presuming that you will not get bad data from
    > the drive without an error.  Normally you get "CRC error" or something
    > similar instead of corrupted data without warning.  In practice, this
    > assumption has proved correct.
    >
    > Now run the program again, after doing one or more of the following:
    >         - Use a different, supposedly identical copy
    >                 of the same thing.
    >         - Switch to a different physical drive, perhaps
    >                 on a different machine.
    >         - For optical media, clean off the media and try again.
    >         - Clean the floppy drive heads
    >         - or just remove and re-insert the media (helps on floppies)
    >
    > Now, if you have two sector-for-sector copies of the same thing
    > with different and mutually exclusive bad spots, you get a file
    > with all the readable sectors included, that is, a good copy of the
    > file.  The point of not writing for unreadable sectors is to avoid
    > replacing good data (from the first try) with filler (from the
    > second try).  If you have media with a few thousand sectors that
    > each won't read 95% of the time, you might manage to get good copies
    > of all the sectors after a dozen runs of the program (with maybe 5
    > retries each time).  It might take years to get a successful read
    > for all sectors on a single pass.
    >
    > Even if you can't get all the sectors, an all-zero block is generally
    > more identifiable and causes less trouble than random garbage.
    > Perhaps with knowledge of the file format and which blocks were
    > unreadable you can figure out what's bad and what isn't.
    >
    > Actually, writing this program in (close to) Standard C isn't
    > practical on many platforms.  The problem is that fseek() takes a
    > long (often 32 bits) argument, and fsetpos() doesn't let you do
    > math on offsets.  Files I need to handle include DVD images (4.7GB)
    > and hard disk partitions (2TB hard disks are under $200).


    I have installed vcdxrip which just works. All av*.dat are converted
    to av*.mp4. I think the source code of that will be most informative.

    Thanks to all for your ideas.

    Bob Parker
     
    rlp1938, Feb 4, 2011
    #7
  8. In article <>,
    rlp1938 <> wrote:
    >In Windows I can copy VCD from the CD files but in Linux the copy
    >fails so I wrote a C program to try to copy from the VCD myself.
    >
    >Running the program gives this result.
    >file read error
    >Count 0
    >Input/output error
    >Count 0
    >File desc: 3
    >Count 0
    >last failure: Input/output error
    >
    >What is the difference between Windows and Linux (Ubuntu 10.4) that I
    >cannot read the file in Linux?


    Your program has been written under incorrect assumptions (the sector size is
    definitely not 2048 bytes), so it cannot work.

    But you cannot simply increase your sector size, as there is a mix of different
    sector types with different sector sizes. I suspect that you don't know the
    high level structure well enough to know which sectors uses which
    type/sectorsize and it is highly improbable that the device driver supports to
    switch automagically to use the right SCSI commands in order to read the
    specific sector types.

    The right way to read such a CD is "readcd". It sends it's own SCSI commands
    and for this reason does not depend on missing features in the driver.

    I recommend "man readcd" and to use readcd -clone



    --
    EMail:-berlin.de (home) Jörg Schilling D-13353 Berlin
    -berlin.de (uni)
    (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
     
    Joerg Schilling, Feb 9, 2011
    #8
  9. In article <>,
    rlp1938 <> wrote:

    >I need some way of grabbing the stuff but somehow ignore the errors as
    >Windows does.
    >
    >I downloaded and compiled cdrtools which includes readcd. That failed
    >also.


    If this is true, then you used readcd the wrong way. See the readcd man page
    and my previous post. Make sure to use recent original software:

    ftp://ftp.berlios.de/pub/cdrecord/alpha/

    --
    EMail:-berlin.de (home) Jörg Schilling D-13353 Berlin
    -berlin.de (uni)
    (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
     
    Joerg Schilling, Feb 9, 2011
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neil Zanella

    VCD file format

    Neil Zanella, Jul 24, 2003, in forum: VHDL
    Replies:
    3
    Views:
    15,940
    toxic_iguana
    Jun 13, 2006
  2. sunil

    VCD file generation

    sunil, Apr 23, 2004, in forum: VHDL
    Replies:
    5
    Views:
    10,583
    sunil
    Apr 26, 2004
  3. neo_anderson

    vsim-vcd-3228 Error vcd simulation

    neo_anderson, Jan 10, 2008, in forum: VHDL
    Replies:
    0
    Views:
    764
    neo_anderson
    Jan 10, 2008
  4. skishor
    Replies:
    0
    Views:
    1,515
    skishor
    Oct 31, 2008
  5. Brain Death

    Re: Can not read VCD file in Linux

    Brain Death, Feb 1, 2011, in forum: C Programming
    Replies:
    1
    Views:
    357
    Joerg Schilling
    Feb 9, 2011
Loading...

Share This Page