Comment 27 for bug 82307

If this error occurs near the end of the MPEG stream, then the MPEG stream would have played fine up to that point, and would not cause a problem with watching the film, however the actual file if copied will try every byte, and will fail on those at the end. This means that a disk manufacturer could deliberately specify such a file table as a trivial system to prevent people copying the file so easily. An MPEG stream ripper should still be able to get the data, but a straight file copy will fail.

Somewhat more insidious would be to insert bad blocks into parts of the file which playback of the mpeg will cause to be skipped - like a section of the header holds the offset for the first frame, or a frame for the next frame. Again - a stream ripper should also get around this.

One way to try to prove this might be to attempt, without copying, to load the files into a media player:
mplayer /media/cdrom/mpegav/avseq01.dat

If the errors are still there then it is something else.
I tried this on a VCD on my machine, and immediately when trying to copy a file the same error was shown - which suggests it is not the end of the file. I then tried to play the .dat file in mplayer, which also failed with "Seek Failed". So it must be something else.

Just to clear any idea that it might be specific hardware (which I doubt), it might be worth putting which drive hardware is being used. I am using an External USB2 LG DVD+-/RW Model 8SA-2164D.

If I try to make an image of the CD with dd:
dd if=/dev/scd0 of=/tmp/vcd.iso
dd: reading `/dev/scd0': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.4244 seconds, 0.0 kB/s

This response is nearly immediate.

Even with these results, It is possible that something is deliberately done to the VCD's file system to cause such errors to occur. However, the alternative proposed by Simos Xenitellis is now sounding more likely. Is there someone here willing to give that a go?