CDVDBurn 3 coming soon

More on topic, what’s the programmatic difference between the – and + formats? I know the earlier – uses some sort of tracking to locate the laser, while the later + uses wobble (and is more accurate for it), but I guess the obvious question is why writing data to disc isn’t a high(ish) level operation? From the description, it sounds like some of this stuff gets pretty low level, hence the wait for the -R support.

The short version: all formats are differently handled on the command level. CDVDBurn has separate routines for all media types, each of them configurable for encountered variants between what the standards say and what real hardware does.

And yes, this is dumb to the extreme. I am still so glad that it was BD and not HD-DVD that finally was adopted as the next-gen format. HD-DVD was a specification nightmare. BD is nice and easy.

I’ll give you an example for some of the complexity. If you want to write a Data CD (in a writing mode called “track at once”) with an ISO9660 image prepared for being the first session, the command sequence is roughly

• set the write speed the user chose (and the medium-drive combination will respect or not)
• configure the write (via something called a “mode page”, which goes back to SCSI-1 days) – writing mode (TAO in our example), real write or simulation, should buffer-underrun-protection be used, which size are the data blocks, single session or multi session
• check that the medium is actually empty and the first logical write address is really 0 (i.e. the addresses inside your ISO image will match the reality later on)
• reserve the track you are going to write, or write to something known as “the invisible track” (depending on the drive, only one method might work)
• start throwing your data at the drive, always checking before if the drive’s free buffer is big enough to swallow it (or else you might run into command timeouts during your write block operation which are difficult to recover from); some drives accept large blocks of data, some only smaller amounts (usually, 32 KiB blocks are a good idea)
• if you run out of data, you tell the drive that you are now finished by explicitly saying “sync cache”
• wait long enough that the drive’s buffer is really empty – the “sync cache” returns immediately, and if you send the next command to early, you might get strange errors
• close the track you have just written, and again…wait until the drive has finished
• close the whole session – this is the time when the drive actually writes the “TOC” into the lead-in of the track (the area before the space where the real data is situated), and again…wait

Sounds complicated? Audio CD in “Session at once” mode is even more complicated, and again likes to differ between different drives in ever-so-subtle ways.

The “easy” formats are DVD+RW, DVD-RAM and BD-R(E). You set the speed (after asking the drive which speeds it can offer for the medium inside), you check that the medium is already formatted (DVD-RAM is sold formatted, DVD+RW and BD-R(E) is usually unformatted) and if not you format it (enquire for possible formats, choose the right one and send the formatting command), and then you just start writing your data (sequentially in the case of a mastered image, but “random access” is also supported for those media types, but with a granularity of 32 KiB or 64 KiB).

The complexity in DVD-R(W) world is that there are two completely different writing modes and endless variants in both modes on how to write such a data track – in theory, it is not too different to a Data CD, but in practice, it took me 15 years to work it out. The writing mode I now use was not available in typical drives back in 2004, but seems to be common in drives manufactured since around 2008.

Another complexity is to cater for all the different states a medium might be currently in. DVD-RW might be in “Restricted Overwrite” mode or in “Sequential Recording” mode. It might be unformatted, partly formatted or fully formatted. Or in “intermediate state”. Really, you can’t make that stuff up. Needless to say that those states also differ from media type to media type.

Hum, the support of BD-R M-DISC would be quite an achievement.

Hum, the support of BD-R M-DISC would be quite an achievement.

I think this already works, but I only have exactly one BD-R M-Disc here to test, and it is the “small” one (25 GB).

The XL types (100 GB) are rather expensive, and I am not sure that I really trust that multi-layer stuff.

Just to let you know that the first beta test version has been sent out to testers a few moments ago. I am currently quite happy with the overall drive compatibility, all my drives have successfully written CD-R, CD-RW, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD-RAM, BD-R and BD-RE (if the medium type is supported of course!), and only a few niggles remain to be fixed. So it is time to broaden the testing base.

If you have not received an email and want to help with testing, please mail me along with some information about the drives and machines you could use for testing.

Drives I have had success with during testing include Samsung (aka Toshiba-Samsung-Storage aka TSSTcorp), LG (aka Hitachi-LG Data Storage aka HL-DT-ST), Asus and Lite-On.

Hi Steffen. This all sounds good.

I have an LG GP57EW40 that I bought a while ago and it just doesn’t work on my IYONIX with my current version of CDVDBurn. Don’t suppose you could tell me if this new version of CDVDBurn would drive my drive.

Thanks Greg

I have all the CD and DVD writers you can image :)
In fact, hundreds of them, since I have hundreds of second hand PC to prepare…

For practical reasons, I would prefer to make tests with a Pi and a USB to SATA or USB to PATA interface. But I have RISC OS computers with native PATA interfaces too.

I have an LG GP57EW40 that I bought a while ago and it just doesn’t work on my IYONIX with my current version of CDVDBurn. Don’t suppose you could tell me if this new version of CDVDBurn would drive my drive.

Many of the tests during development were done with a brand-new LG GP57ES40 which is basically your model, but in a differently coloured case (silver instead of white).

The IYONIX is still on the list of platforms I need to test (most testing was done on Titanium, ARMX6 and various Raspberry Pis), but I see no reason why it shouldn’t work. I’ll start with the IYONIX tests hopefully this week, then we’ll know for sure.

@ Steffen,
I have a Lite-On LH-20A1P on my Iyonix and a Hitachi Slot Drive GS40 N on my Titanium machine if you want to test against them, both running RISC-OS 5.29.

I also have a Dell DS-8ABSH (Ex Titanium) if you want that tested.

Regards Ron.

I have a Lite-On LH-20A1P on my Iyonix and a Hitachi Slot Drive GS40 N on my Titanium machine if you want to test against them, both running RISC-OS 5.29.

You should already have received the beta test version by email. If I got your email address right of course!

Thanks for your support, much appreciated.

Thats good news Steffen for my LG GP57EW40. I will actually be running it on my PI2 as my IYONIX and RISC PC have both developed a hardware issue it would seem.