[k3b] [Bug 137436] Adding support for cdrskin as an alternative to cdrecord/wodim

[Thomas Schmitt]

https://bugs.kde.org/show_bug.cgi?id=137436

--- Comment #43 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

about the newest commit
 
https://cgit.kde.org/k3b.git/commit/?id=c17d307523a08c1e6042381bdbdfe1971fffc84a

> + bin.addFeature("plain-atapi");
> + bin.addFeature("hacked-atapi");

Did you find out what these features mean ?
(Reading libk3b/core/k3bglobals.h i get the suspicion they mean support
 for addresses "/dev/hdX" and "ATAPI:X,Y,Z" respectively. This would be
 supported by cdrskin. But i am not totally sure.)


> + bin.addFeature("burnfree");
> + bin.addFeature("burnproof");

I would decide for one of them. One never knows what other code piece
could be confused if two normally mutually exclusive features are present.


> + if (burnDevice()->supportsWritingMode(K3b::Device::WRITINGMODE_RAW_R96R) ||
> + burnDevice()->supportsWritingMode(K3b::Device::WRITINGMODE_RAW_R16) ||
> + burnDevice()->supportsWritingMode(K3b::Device::WRITINGMODE_RAW_R96P)) {
> +    d->process << "-data";

You may not do this.

The input data for those raw CD modes contain bytes which do not belong
to the payload but rather are CD sector metadata.
Those metadata formats which have only a few ornaments around data payload
get defaulted to -data by cdrskin. But the -raw* family expresses a different
wish of the user (normally one that is illegal in countries with strict
copyright enforcement).

You will have to refuse such wishes. Best would be not to offer these write
modes at all when cdrskin is to be used.


> + if (burnDevice()->description().contains("Virt"))
> + d->process << "--allow_emulated_drives";

This was a misunderstanding between us.
--allow_emulated_drives only lifts the ban on "stdio:/path" addresses. As
long as you use a "/dev/srN" address which leads to an optical drive, libburn
will use its MMC driver to operate it as optical drive, rather than as POSIX
file object.


> + if (d->burnedMediaType & Device::MEDIA_DVD_PLUS_RW)
> + d->process << "blank=deformat_sequential_quickest";

This is the wrong media type (DVD+RW). The special handling of "blank=fast"
applies to to DVD-RW, which has two media types in K3B:
MEDIA_DVD_RW_OVWR and MEDIA_DVD_RW_SEQ.

The type _OVWR indicates a formatted medium which needs no blanking unless
the user wants to deformat it. In that case "deformat_sequential_quickest"
and "deformat_sequential" brings it to type MEDIA_DVD_RW_SEQ.
But this is not necessarily desired when a user orders blanking for the
sole purpose of making the medium writable from scratch. This wish is
fulfilled by growisofs, cdrecord, cdrskin, and xorrecord without blanking
because one can write the medium in random access mode.
growisofs with option -M and program xorriso handle such media as appendable
if they contain an ISO 9660 filesystem.
So if you apply "deformat_sequential*" to MEDIA_DVD_RW_OVWR this would need
special permission by the user.

The type MEDIA_DVD_RW_SEQ behaves much like CD-RW, except the undesirable
consequences of fast blanking.

So i would exchange in above statement MEDIA_DVD_PLUS_RW by MEDIA_DVD_RW_SEQ
and leave MEDIA_DVD_RW_OVWR out of the game for now.


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.