Can not read VCD file in Linux

R

rlp1938

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()
 
A

Alan Curry

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.
 
R

rlp1938

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
 
P

Paul

rlp1938 said:
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

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
 
R

rlp1938

rlp1938 said:
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

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
 
J

jacob navia

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
 
R

rlp1938

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).


        you don't wipe out the existing file.>     Set "current offset" to 0.

          Seek source file to "current offset".


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.


                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.

      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
 
J

Joerg Schilling

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
 
J

Joerg Schilling

rlp1938 said:
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/
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top