#1 Burning Software

Hello, here is a reproducible symptom I am observing:

Take an ISO file.
- I tried with both gparted-live-0.26.1-3-amd64.iso on SourceForge which is 278 921 216 bytes long
and void-live-x86_64-20160420-mate.iso which is 638 582 784 bytes long.

Burn it to a CD, using 'Burn Image". In my case, I am using a Verbatim CD-RW 700 MB, 8x-12x as target, so there is an erase first. And my DVD burner is an internal ASUS DRW-24B3ST.

Then read the CD to an ISO image file, with a different name, using "Grab Image".

Look at the size of the image file = it has 4096 bytes more !!
- Using vbindiff between the source and re-read images, I can see that 4096 0's have been added at the end, in both cited cases.
- So with the above 2 cited examples, the gparted re-read image is 278 925 312 bytes long, and the void linux one is 638 586 880 bytes long.


Why so ?


Note 1: if I burn the ISO files using Nero, there is no such problem, The re-read ISO image are perfectly identical with original ones in length and in contents.

Note 2: This is a problem when one wants to verify that a burned image is similar to source, or to verify which one has been burned. Using things like MD5SUM, the additional 4 KB of 0's at the end modifies the hash result.


Is it possible to correct things to get the exact same data written to the CD ?

Thank you for any answer, erwin34.

No explanation ? Why is Nero ok but not StarBurn ?

What burning mode do you use? What media type is it? We normally don't add any padding unless image is to small to be recorded but either way I'm brining in engineers to take a look @ this issue.

...as a workaround I'd suggest to use StarBurn's built-in recorded image verification as it works flawlessly with what we record. It isn't hash-based (1:1 memcmp) and it ensures data can be actually READ from the optical medium

Hello, thank you for the answer.

Media being written = for example Verbatim CD-RW Hi-Speed 8x-12x 700MB SERL, but it does this with others.
Burning mode = default one, Track-At-Once.
Size of G:\gparted-live-0.26.1-3-amd64.iso written with Burn Image = 278 921 216 bytes.
Size of GParted-live.iso read with Grab Image = 278 925 312 bytes.
The source ISO can be found here -> https://sourceforge.net/projects/gparted/files/gparted-live-stable/0.26.1-3/

Here is the log of one such "Burn Image":


And then the log for the subsequent "Grab Image":



On the work around: yes, I thought of it, but verification only works when burning the media. It is not working when inserting an already burnt media at a later time, and of course not able to tell to which image between multiple it corresponds ..


Let me know if you need more information, or if you want me to do some tests / additional tracing.

Thanks, erwin34.

Alexander is checking reported issue meanwhile... Thank you for your feedback!

Hello, thank your for report. I've reproduced it and will fix ASAP.
Regards, Alex.

Hello, thank you .
Available to test anything if you need to. Let me know.
Erwin34.

We'll keep you posted as soon as we'll have something to test. Stay tuned

Hello, any news ? I still see version 15.15 available on the Editions page http://www.starburnsoftware.com/products/starburn/editions

Hello,

Sorry for delay, StarBurn 15.7 will be available next week.

StarBurn V15.7 has been released.

Release notes:

• ISO/UDF import for a big file system structure has been fixed.
• ISO 9660 section for DVD-VIDEO has been fixed.
• R/W speeds refreshing has been fixed for physical and virtual devices.

I downloaded version 15.7 (named 15.17 on the download site ..) and I confirm after testing that the bug is fixed.
Thank you.

I ordered a license then (waiting for my registration key by mail I suppose).

Best regards, erwin34.

We are glad to hear that !