Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Can not read VCD file in Linux

Reply
Thread Tools

Can not read VCD file in Linux

 
 
rlp1938
Guest
Posts: n/a
 
      02-01-2011
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, 204) != -1) {
count += bytes;
fprintf(stderr, "Read: %d\n", count);
} // while()
fprintf(stderr, "Count %d\n", count);
perror("last failure");
fclose(fpo);
return 0;
} // main()
 
Reply With Quote
 
 
 
 
Alan Curry
Guest
Posts: n/a
 
      02-01-2011
In article <(E-Mail Removed)>,
rlp1938 <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
rlp1938
Guest
Posts: n/a
 
      02-01-2011
On Feb 1, 1:05*pm, (E-Mail Removed) (Alan Curry) wrote:
> In article <(E-Mail Removed)..com>,
>
> rlp1938 *<(E-Mail Removed)> 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


 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-01-2011
rlp1938 wrote:
> On Feb 1, 1:05 pm, (E-Mail Removed) (Alan Curry) wrote:
>> In article <(E-Mail Removed)>,
>>
>> rlp1938 <(E-Mail Removed)> 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-co...ection-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
 
Reply With Quote
 
rlp1938
Guest
Posts: n/a
 
      02-02-2011
On Feb 1, 6:30*pm, Paul <(E-Mail Removed)> wrote:
> rlp1938 wrote:
> > On Feb 1, 1:05 pm, (E-Mail Removed) (Alan Curry) wrote:
> >> In article <(E-Mail Removed)>,

>
> >> rlp1938 *<(E-Mail Removed)> 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-co...ection-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
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      02-02-2011
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
 
Reply With Quote
 
rlp1938
Guest
Posts: n/a
 
      02-04-2011
On Feb 3, 6:57*pm, (E-Mail Removed) (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
 
Reply With Quote
 
Joerg Schilling
Guest
Posts: n/a
 
      02-09-2011
In article <(E-Mail Removed)>,
rlp1938 <(E-Mail Removed)> 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:(E-Mail Removed)-berlin.de (home) Jrg Schilling D-13353 Berlin
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (uni)
http://www.velocityreviews.com/forums/(E-Mail Removed) (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
 
Reply With Quote
 
Joerg Schilling
Guest
Posts: n/a
 
      02-09-2011
In article <(E-Mail Removed)>,
rlp1938 <(E-Mail Removed)> 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:(E-Mail Removed)-berlin.de (home) Jrg Schilling D-13353 Berlin
(E-Mail Removed)-berlin.de (uni)
(E-Mail Removed) (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Can not read VCD file in Linux Brain Death C Programming 1 02-09-2011 10:41 AM
vsim-vcd-3228 Error vcd simulation neo_anderson VHDL 0 01-10-2008 12:46 PM
Reader to read VCD format cd pate2010 Computer Support 6 05-11-2005 10:15 PM
Can not delete file: Can not read from source file or disk. Pundit Computer Support 0 02-28-2005 03:27 AM
Can standard DVD players read VCD disks Birk Binnard Digital Photography 15 03-05-2004 04:42 AM



Advertisments