Disc Reading is Incorrect

[kix]

Disc reading is completely broken, and needs rewriting.

[lorenzo]

It would appear that the burn_disc_read() function is in fact completely broken. Most of the code for the function is disabled, and enabling it causes libburn to fail to build. I am currently exploring the possibility of fixing this problem and will submit a patch if I can get it compiling and working.

[pollux]

Do you have an ETA for the revival of burn_disc_read or an equivalent that at least can create an iso file from a disc ?

[scdbackup]

No substantial plans from my side for now.

With copying an ISO-9660 from a CD or DVD i see the problem rather with determining the exact size and not so much with reading the raw data.

If it is a single track and session then normal block devices like /dev/hdc or /dev/sr0 should be able to sequentially deliver all needed bytes - plus some trailing garbage.

If it is about a CD then the blocks in the gaps between the tracks (resp. sessions) are not readable from my kernel 2.4 /dev/sr0. If one uses the info from cdrskin -toc or test/telltoc --toc then it should be possible to read the tracks (e.g. via program dd) and to compose them to an image. Including 0-padded block runs as placeholders for the non-data areas between tracks. With ISO: "lba" = 2048 byte filesytem block address.

I understand that the capabilities of a libburn read command would mainly be to retrieve audio sectors (old name: frames) and to retrieve raw data sectors including ECC and sneaky subchannels and whatever is encoded in the difference between 2352 and 2048 bytes.

An ISO-9660 filesystem gets mounted on the block device and thus must be accessible as 2048 byte sectors. You do not need a special read command. open(2), lseek(2) and read(2) will do. With DVD don't forget to compile with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 .

As said, with CD media the Table Of Content will help to find out start and end of the tracks. With DVD+RW media you will need an understanding of the size determining parameters in the image. (Or a recognizable end mark after the end of the image.) growisofs.c does such examinations of the ISO image, i believe.

In the range of the libburnia project, such ISO size determination would be a job for libisofs and not for libburn.

[scdbackup]

It comes to me that copying a multi-session ISO filesystem is a tricky thing. One would have to extract the sessions separately and manage to put them on the new CD onto the same addresses as on the old CD.

(Better would be to imitate the trick of growisofs.c which changes the start of the first session and could burn everything together as one big track.)