In Windows, I may read a VCD's content and play it without any problem. On the same machine and the same drive, in Linux (Ubuntu 20.04), it's not read and I get I/O error. The size if also reported differently. In Windows the AVSEQ01.DAT file size is 724MB and in Linux it's 625MB! I think it's a trick to prevent the VCD to be able to be copied. Maybe if I would install older versions of Windows than 10 I would encounter the same problem as Linux does. It seems that Windows 10 knows the trick and overcomes it, but Linux doesn't, although it's just a guess and I'm not sure about it.
I used dd to create an ISO from the CD. Size is about 450KB! Size of the dat file inside it is the same as the CD itself.
I also paste what's logged in kern.log during read from the CD:
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.177112] sr 0:0:0:0: [sr0] tag#16 Add. Sense: Illegal mode for this track
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.177117] sr 0:0:0:0: [sr0] tag#16 CDB: Read(10) 28 00 00 00 00 dc 00 00 01 00
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.177123] blk_update_request: I/O error, dev sr0, sector 880 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.177132] Buffer I/O error on dev sr0, logical block 220, async page read
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.213084] sr 0:0:0:0: [sr0] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.213091] sr 0:0:0:0: [sr0] tag#4 Sense Key : Illegal Request [current]
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.213097] sr 0:0:0:0: [sr0] tag#4 Add. Sense: Illegal mode for this track
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.213102] sr 0:0:0:0: [sr0] tag#4 CDB: Read(10) 28 00 00 00 00 dd 00 00 01 00
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.213108] blk_update_request: I/O error, dev sr0, sector 884 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Nov 21 05:36:56 hamidi-pc kernel: [ 9446.213117] Buffer I/O error on dev sr0, logical block 221, async page read
+ Reply to Thread
Results 1 to 8 of 8
Is the VCD from India? Some India VCDs are greatly out of spec (some are reported to even have physical defects!) to prevent playing and ripping on PCs.
The avseq.dat "file" isn't really a file at all, just a pointer to sectors in a subsequent cd track. Those tracks are mode2form2 xa tracks, which have (IIRC) 2324 bytes/sector, while standard mode1 or mode2form1 tracks have 2048bytes/sector.
The difference in counting bytes (if you expect to be counting them by their underlying sectors) is the difference between ~724MB and ~638MB. Awefully close to your discrepancy experience.
My guess is that driver in linux is not designed to properly read VCD's mpeg tracks, while the Windows one is.
That would also account for the misunderstanding of the size of the pointer file.
A badly-formatted (whether intentional or not) would just exacerbate this issue.
Thinking about it, if you can see the AVSEQ01.DAT, you should be able to see rest of the files and just copy and play them. As I recall VCDs don't have any special features like menus. Just the video files.
No. They do (have menus). And chapters, and hot links/buttons. If you know what you're doing and have the right software.
Have done more than my share of VCDs with those features in my day.
@lingyi: No, they're apparently not from India. I'm in Iran. The VCD's seem to intentionally bad formatted or formatted in a way that may be playable only in VCD player devices, to protect them from being copied. Since copyright is not executed seriously,
@october262: The player is not the problem. At first, the OS should be able to read it correctly. I used VLC to play it both as file and as VCD with no success.
@Scott: I think this is exactly the note. The problem caused by the driver. Microsoft has improved its driver to detect such kind of format and may read it correctly, but in Ubuntu, they're not written a ready driver for such situation. Let me know if I could get your note correctly. I may not justify such a difference between the two OS'es unless concentrating on the driver as you said.
If so, it seems that we've no choice, right?