I hope this isn't too off-topic, but found an interesting problem. I have an old CD that I want to back up. If a copy from fresh (putting the CD for the first tame) using the System Drag 'n' Drop, cp or rsync it just hangs.
The files are video files. I can play the video files in VLC. If I watch the whole video, I can copy the video file to my hard drive instantly. I assume VLC has loaded the data into hard drive.
I wrote a simple cp program in Rust. It opens to files, and via buffer of a fixed size, reads one file into that buffer and then writes the buffer to the other (basically uses std::fs::copy, one file to another).
I have tried adjusting the buffer size (as, as far as I can see, it is the only thing I can change) to get the data copying at a reasonable pace. The best ones I have so far found are 1 KiB and 96 KiB buffers. But the copy is excruciatingly slow. Nothing like watching the video in real-time.
My questions are:
- why is this happening?
- what does vlc do that the OS isn't doing?
Most video players (I don't know about VLC specifically) have some "error tolerance"; primarily because they're designed to cope with unreliable sources (e.g. "free to air TV" with radio interference, streaming over internet with packet losses, etc). Mostly; if part of the data is corrupt or unavailable it will just cause "glitches" in playback, like a small area of one frame that is the wrong color (or a whole frame being skipped) for video and/or a brief period of silence in audio, and these glitches can be very difficult to notice.
It would be "very normal" for a video player (designed with "error tolerance") to handle read errors from CD by simply skipping the corrupted/unavailable data and letting the error tolerance (that had to exist anyway) deal with it.
For copying raw file data, there is no error tolerance - every bit of every byte is (supposed to be) an exact copy of the original and pieces of the data can't be skipped/ignored.