[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

Thomas Schmitt via KDE Bugzilla bugzilla_noreply at kde.org
Thu Sep 8 08:00:55 UTC 2016


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

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

Leslie Zhai wrote:
> Please review it https://git.reviewboard.kde.org/r/128860/

I see a box "Testing Done" but no place to state that i did a code
review but did not test.

Shall i write: "Code reviewed but not tested" ?


> I do *NOT* have BD50 (Blu-ray double layer) ISO image,

The problem is neither about the size nor about the medium.
So you could create any non-ISO image file:

  dd if=/dev/zero bs=1M count=100 of=my_100mb_test.img

and use the CD emulator as target device.


Nitpicks:
-------------------------------------------------------------------

The comment

  // set a wanted media type (DVD/BD -> only ISO)

riddled me already when i looked at the code for the first time.

I believe it wants to say that if the image is not IMAGE_ISO, IMAGE_RAW,
or IMAGE_UNKNOWN, then it is a structured CD image description which
cannot be interpreted for DVD or BD media.
So the wanted medium type is  MEDIA_WRITABLE_CD  in this case, and
any medium type for ISO, RAW, and UNKNOWN.

Maybe one should change it to

  // set a wanted media type
  // some image types can be put on any medium, some only on CD

-------------------------------------------------------------------

I still have scruples about the type name "raw" in lines 1152

    else if (imageType == "raw")

and 1200:
                     imageType = "raw";

In man cdrecord (or man wodim) there are lots of references to "raw"
in the sense that CD sector metadata are provided by the input data
of the burn program. A CD sector has 98 * (24 + 8 + 1) = 3234 bytes.
CD-Audio uses 98 * 24 = 2352 for payload. The rest is C1,C2 checksums
and 98 subchannel bytes. CD-ROM uses 2048 for payload. The rest is
filled with more meta-info about the CD sector. Normally we send only
the 2048 bytes to the drive which then computes the meta data.
In "raw" write mode cdrecord sends some or all of the meta-data too.

But this is not what we mean with "raw" image.
So the user should get to see a different word when IMAGE_RAW is being
processed.

(One could argue that IMAGE_RAW should be IMAGE_PLAIN and the text
 should be "plain".
 If i had thought of the raw-raw nomenclature collision i had
 proposed a different macro name. But "IMAGE_RAW" will only be seen
 by programmers, whom i suppose to easily find out that IMAGE_RAW
 is not an image for cdrecord -raw.
)

-------------------------------------------------------------------

Elsewise the changeset looks good to me.
Testing will tell whether it suffices to solve the problem.

Have a nice day :)

Thomas

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


More information about the k3b mailing list